IETF Secretariat | 20 Sep 00:32 2014
Picon

IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6374


Dear Dan Frost, Stewart Bryant:

 An IPR disclosure that pertains to your RFC entitled "Packet Loss and Delay
Measurement for MPLS Networks" (RFC6374) was submitted to the IETF Secretariat
on 2014-09-19 and has been posted on the "IETF Page of Intellectual Property
Rights Disclosures" (https://datatracker.ietf.org/ipr/2436/). The title of the
IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to
RFC 6374."");

The IETF Secretariat

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Rakesh Gandhi (rgandhi | 19 Sep 23:22 2014
Picon

Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hi Dimitri,

Thank you for your review comments.

Gist of your comments is that there is a way in RFC4875 to bulk the requests for queries via a path message and also add a list of S2Ls in a PathErr message. 
This method can be used for re-optimizing a group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

As you hinted below, proposed draft provides a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the LSP-ID.

If you agree with above understanding, we can clarify in the draft accordingly.

Thanks,
Rakesh



From: <Papadimitriou>, "Dimitri (Dimitri)" <dimitri.papadimitriou <at> alcatel-lucent.com>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <rgandhi <at> cisco.com>, "Tarek Saad (tsaad)" <tsaad <at> cisco.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt <at> tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt <at> tools.ietf.org>
Cc: "mpls <at> ietf.org" <mpls <at> ietf.org>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

<!-- /* Font Definitions */ <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} p.emailquote, li.emailquote, div.emailquote {mso-style-name:emailquote; mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:1.0pt; border:none; padding:0cm; font-size:12.0pt; font-family:"Times New Roman","serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Courier New"; color:windowtext; font-weight:normal; font-style:normal;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} <at> page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} -->

Hello Rakesh,

 

See below for my answers:

 

From: Rakesh Gandhi (rgandhi) [mailto:rgandhi <at> cisco.com]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); draft-tsaad-mpls-p2mp-loose-path-reopt <at> tools.ietf.org
Cc: mpls <at> ietf.org
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi WG,

 

Forwarding following reply from Tarek to the MPLS mailing list.

 

Thanks Tarek and Dimitri.

 

Regards,

Rakesh

 

 

From: "Tarek Saad (tsaad)" <tsaad <at> cisco.com>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou <at> alcatel-lucent.com>, DEBORAH BRUNGARD <db3546 <at> att.com>, Loa Andersson <loa <at> pi.nu>, "rtg-ads <at> tools.ietf.org" <rtg-ads <at> tools.ietf.org>, "mpls-chairs <at> tools.ietf.org" <mpls-chairs <at> tools.ietf.org>, Martin Vigoureux <martin.vigoureux <at> alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt <at> tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt <at> tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick <at> metaswitch.com)" <Jonathan.Hardwick <at> metaswitch.com>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

 

Hi Dimitri,

 

Thanks much for reviewing the draft and for your feedback. Please see inline..

 

From: <Papadimitriou>, "Dimitri (Dimitri)" <dimitri.papadimitriou <at> alcatel-lucent.com>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <db3546 <at> att.com>, Loa Andersson <loa <at> pi.nu>, "rtg-ads <at> tools.ietf.org" <rtg-ads <at> tools.ietf.org>, "mpls-chairs <at> tools.ietf.org" <mpls-chairs <at> tools.ietf.org>, "VIGOUREUX, MARTIN (MARTIN)" <martin.vigoureux <at> alcatel-lucent.com>, "draft-tsaad-mpls-p2mp-loose-path-reopt <at> tools.ietf.org" <draft-tsaad-mpls-p2mp-loose-path-reopt <at> tools.ietf.org>
Cc: "Jonathan Hardwick (Jonathan.Hardwick <at> metaswitch.com)" <Jonathan.Hardwick <at> metaswitch.com>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello,

 

Here is my review of this document:

 

The statement "notification of preferred path exists for a single S2L sub-LSP only." and what comes in Section 3 of this document is questionable

 

i) there is a mode of operation already included in RFC 4875 which allows such reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP basis, that section states clearly

 

"14.2.  Sub-Group-Based Re-Optimization

 

   Any node may initiate re-optimization of a set of S2L sub-LSPs by

   using incremental state update and then, optionally, combining

   multiple path messages."

 

[TS]: the draft is in agreement of the above statement from rfc4875 and this is called out in the draft (below) with the shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.

"The ingress LSR that receives (un)solicited PathErr notification(s)

   for individual S2L sub-LSP(s), may prematurely start re-optimizing

   the sub-set of S2L sub-LSPs.  However, as mentioned in [RFC4875]

   Section 14.2, such re-optimization procedure may result in data duplication

The make-before-break reoptimization method as described in rfc4875 section 14.1 avoids the former duplication problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there’s no explicit way for a mid-LSR to notify the ingress to trigger this specific mode of reoptimization-- short of possibly re-using the PERR code/subcode for “preferable path exists” as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. when a single message may not be large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-LSPs in each and would require additional logic to infer all S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by (example) waiting for some time to aggregate all possible PERR messages before taking action. 

We also believe having a sub-set of S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group based reoptimization mode described in section 14.2.

 

In other cases, a PATH message that is intended to carry the “path re-evaluation” flag — as defined defined in rfc4736—with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and only a subset of the S2L sub-LSPs that are routed over same next-hop will be propagated in the descriptor list of the PATH message propagated to downstream mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can unambiguously use it to distinguish which LSP mode of reoptimization to invoke.

 

[DP2] It is the requestor (initiator of the PathErr) which expands the ERO (right ?) and sequence their signaling (thus any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have such control taken by the root of the tree ?

 

The protocol format chain can be found here below to see possibility for generating such request via notification:

 

   <notify session list>       ::= [ <notify session list> ]

                                   <upstream notify session> |

                                   <downstream notify session>

 

   <upstream notify session>   ::= <SESSION> [ <ADMIN_STATUS> ]

                                   [<POLICY_DATA>...]

                                   <sender descriptor>

 

 

   <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>

                                    [ <ADSPEC> ]

 

   With:

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                   IPv4 tunnel sender address                  |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |       Reserved                |            LSP ID             |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                   Sub-Group Originator ID                     |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |       Reserved                |            Sub-Group ID       |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

I read behind this draft that this new mode of operation (the fact subpaths "are loose or abstract hop expanded" doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside incremental state update --introduced for scaling reasons. In any case, the justification/motivation for this mode of operation is missing in the document.

 

 

ii) with PathErr as defined in RFC 4875 it includes a [ <S2L sub-LSP descriptor list> ]

thus, it is even less clear why one would like to move with or more generally signaling it differently ("Request flags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization may result in transient data

duplication as the new Path messages for a set of S2L sub-LSPs may

transit one or more nodes with the old Path state for the same set of

S2L sub-LSPs.”

[TS]: Please see reply above for the first one.

 

[DP2] I am not sure you have captured this comment, and would reformulate it as follows: under which conditions the number of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence of sub-LSP, ii) the initiator has no mean to sequence the resulting Path messages such as to avoid situation of Section 14.2, iii) assuming this would be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the root a procedure than can be performed by the requestor itself ?

 

[DP2] On the other hand, there is a wide question, why do you consider only the case with loose ERO’s ? I mean the fragmentation problem is only one cause of occurrence of duplication (which could happen from any transient event during establishment of P2MP LSP), in that case, the question of introducing a more general procedure with an EOL (end of list bit) would certainly be more appropriate as it would solve two problems at once.

 

 

Regards,

Tarek

 

The proposed draft doesn’t solve cases where this would occur, and on the other, the cases it covers are already by RFC 4875 (re-optimize a loose set from a single branching point is already covered).

 

Many thanks,

-dimitri.

 

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
IETF Secretariat | 19 Sep 15:19 2014
Picon

Milestones changed for mpls WG

Changed milestone "Submit draft-ietf-mpls-p2mp-loose-path-reopt for
publicatiion", set state to active from review, accepting new
milestone.

Changed milestone "Submit draft-ietf-mpls-lsp-ping-reply-mode-simple
for publication", set state to active from review, accepting new
milestone.

Changed milestone "Submit draft-ietf-mpls-rfc6374-udp-return-path for
publicatiion", set state to active from review, accepting new
milestone.

URL: http://datatracker.ietf.org/wg/mpls/charter/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

IETF Secretariat | 19 Sep 15:15 2014
Picon

Milestones changed for mpls WG

Changed milestone "Submit draft-ietf-mpls-tp-oam-id-mib for
publication", set due date to December 2014 from May 2014.

Changed milestone "Submit draft-ietf-mpls-tp-te-mib for publication",
set due date to December 2014 from June 2014.

URL: http://datatracker.ietf.org/wg/mpls/charter/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

IETF Secretariat | 19 Sep 15:13 2014
Picon

Milestones changed for mpls WG

Changed milestone "Submit draft-ietf-mpls-seamless-mcast for
publication", set due date to December 2014 from November 2014.

URL: http://datatracker.ietf.org/wg/mpls/charter/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

IETF Secretariat | 19 Sep 15:05 2014
Picon

Milestones changed for mpls WG

Deleted milestone "Submit draft-ietf-mpls-tp-1ton-protection  for
publication".

URL: http://datatracker.ietf.org/wg/mpls/charter/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

internet-drafts | 17 Sep 15:53 2014
Picon

I-D Action: draft-raza-mpls-oam-ipv6-rao-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : IPv6 Router Alert Option for MPLS OAM
        Authors         : Kamran Raza
                          Nobo Akiya
                          Carlos Pignataro
	Filename        : draft-raza-mpls-oam-ipv6-rao-01.txt
	Pages           : 5
	Date            : 2014-09-17

Abstract:
   RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the
   Router Alert option must be set in the IP header of the MPLS Echo
   Request messages, and may conditionally be set in the IP header of
   the MPLS Echo Reply messages.  While a generic "Router shall examine
   packet" Option Value is used for the IPv4 Router Alert Option (RAO),
   there is no generic Router Alert Option Value defined for IPv6 that
   can be used.  This document allocates a new generic IPv6 Router Alert
   Option Value that can be used by MPLS OAM tools, including the MPLS
   Echo Request and MPLS Echo Reply messages for MPLS IPv6.

   The initial motivation to request an IPv6 Router Alert Option (RAO)
   code point for MPLS OAM comes from MPLS LSP Ping/Traceroute.
   However, this codepoint is applicable to all MPLS OAM and not limited
   to MPLS LSP Ping/Traceroute.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-raza-mpls-oam-ipv6-rao/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-raza-mpls-oam-ipv6-rao-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-raza-mpls-oam-ipv6-rao-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Gregory Mirsky | 10 Sep 21:22 2014
Picon

MPLS IEs in IANA's IP Flow Information Export (IPFIX) Entities registry

Dear All,

in several places of describing MPLS Label element IEs the registry still refers to the EXP field even though the RFC 5462 updated RFC 3032 and renamed it “Traffic Class” (TC). Below is the list of IEs that may benefit from updating Description and Reference information:

·         mplsTopLabelStackSection

·         mplsTopLabelStackSection2

·         mplsTopLabelStackSection3

·         mplsTopLabelStackSection4

·         mplsTopLabelStackSection5

·         mplsTopLabelStackSection6

·         mplsTopLabelStackSection7

·         mplsTopLabelStackSection8

·         mplsTopLabelStackSection9

·         mplsTopLabelStackSection10

·         mplsTopLabelExp (should this be deprecated and mplsTopLabelTc be created instead?)

·         postMplsTopLabelExp (should this be deprecated and postMplsTopLabelTc be created instead?)

 

 

Regards,

        Greg

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Shamjhana | 10 Sep 21:05 2014

SDN/MPLS 2014 Conference

The SDN/MPLS 2014 Conference will take place November 2-5 in Washington DC and will
include an extensive four day program consisting of tutorials, technical
sessions, panels, and exhibits. The key topics to be discussed at this
year's conference include: Virtualization, SDN, Cloud and Data Centers, NFV,
PCE, Mobility, Traffic Engineering, Transport SDN, Orchestration,
multi-play applications across common infrastructure and other emerging technologies.

 

The SDN/MPLS 2014 Conference program is available at http://www.isocore.com/sdn-mpls/
Tutorials (Sunday): http://www.isocore.com/sdn-mpls/tutorials.htm
Technical sessions (Mon- Wed): http://www.isocore.com/sdn-mpls/technical_sessions.htm

Please make sure to register for the SDN/MPLS 2014 by September 15 for reduced rate registration. Please do so at:

http://www.isocore.com/sdn-mpls/attendees.php

Lastly, the conference hotel is the Marriott Wardman Park in Washington DC. Please
note discounted rates are available for a limited time only. Please book your

reservations at:

https://resweb.passkey.com/Resweb.do?mode=welcome_gi_new&groupID=25088120

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Loa Andersson | 10 Sep 12:05 2014
Picon

late IPR poll on draft-ietf-mpls-seamless-mcast

Working Group,

draft-ietf-mpls-seamless-mcast have been through wglc and been updated
after the wglc. We are ready to request publication.

However we have made a procedural mistake that needs to be corrected.
In the mail that started the wglc I wrote:
"There are one IPR disclosure against this document. The authors has
  stated that he is unaware of any other IPRs that relate to this
  document."

It is correct that there are one IPR disclosure, but we had never done
an IPR poll and we did not have any responses. This was my mistake - I'm
sorry for that - this mail is intended to correct this mistake and
start the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-seamless-mcast?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

Currently there are one IPR disclosures that relates to this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The 
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
(as MPLS WG co-chair)
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Loa Andersson | 10 Sep 10:06 2014
Picon

Implementation poll for draft-ietf-mpls-pim-sm-over-mldp

Working Group,

We are preparing the Publication Request for draft-ietf-mpls-pim-sm-
over-mldp. One question we have to answer in the Shepherd Write Up is
about existing implementations.

This is to start the Implementation Poll.

If you have or are aware of existing implementations of draft-ietf
-mpls-pim-sm-over-mldp please send this information to the
working group mailing list or directly to the working group chairs.

/Loa
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls


Gmane