http://blog.gmane.org/gmane.ietf.mpls hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.mpls/14421 <pre> 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 : Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel Author(s) : Adrian Farrel Stewart Bryant Filename : draft-ietf-mpls-retire-ach-tlv-00.txt Pages : 5 Date : 2013-05-23 Abstract: The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of TLVs in undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-retire-ach-tlv-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> internet-drafts< at >ietf.org 2013-05-23T21:04:05 http://comments.gmane.org/gmane.ietf.mpls/14420 <pre>Hi, I have done my usual AD review of this draft on receipt of the publication request from the MPLS WG chairs. As well as the desire to remove issues that might otherwise show up during IETF last call and IESG review (thereby saving resources), my review is to make sure that I understand the intention and details of the work so that I can support the document as it goes through these later reviews and also the publication process. As you will see from my comments below, I am not currently comfortable with the document. At the moment I am not saying that the proposals are bad and dangerous, although I am at least believing them to be unnecessary and based on some misstatements of the problems that need to be addressed. I understand that the chairs report there is WG consensus behind this document in its current form, but I am unable to support it for publication as an RFC. You have two options open to you to advance your work as a standards track RFC. Firstly, you could seek to address my concerns through a combination of changes to the text and discussions with me. Secondly, you can attempt to find another AD to sponsor the work - possibly Stewart is a good starting point. For the moment, I am returning the I-D to the working group. Thanks, Adrian --- Was this document shown to the CCAMP working group? The P2MP work (4875) was developed in partnership with CCAMP because it was intended to be equally applicable to MPLS-TE and GMPLS. Presumably this is also true of this work. You might find that by consulting CCAMP you are able to get some more P2MP implementers to have a look at the problems this draft is proposing to solve. --- I am surprised that the working group has taken this approach to the described problem of re-merge avoidance. This problem is addressed by the combination of PCE and Path Keys. However, if the working group has considered that approach and has consensus to take this other approach, I will not object. Could the chairs confirm that the existing mechanisms have been considered and that the WG determined to add new extensions to the signaling protocols instead. --- I'm afraid I find myself wondering whether this document is addressing the wrong problem :-( Re-merge is a bad thing to have as a persistent situation, and certainly must not be allowed to cause data duplication downstream of the re-remerge point. However, avoiding re-merge by selecting disjoint paths is not the solution. If re-merge happens, it is because the path to one set of destinations has intersected the path to another set of destinations. When this happens, one of the two paths to the re-merge point must be optimal (for *any* definition of optimal) or the paths are equally optimal. In either case, the correct solution is to move all of the destinations (the union of the two sets) onto the same path and prune out the sub-optimal one. In this case, the bottom line will be that the upstream branch was wrong to use two distinct domain border nodes for the two sets of destinations. That is the problem that needs to be fixed. What I seem to be reading here is an attempt to avoid re-merge that favors the use of suboptimal paths. In many network configurations that will be impossible. But in any case, it will prove as costly in terms of network resources as the re-merge itself. The discussion about re-optimization using 4736, is a different problem that you can raise. The description of the problem doesn't really surface until the description of the solution in Section 1.1, which is a pity. This is largely a descriptive issue, although I would argue that the partial reomptimization is easily handled using partial resignaling, and therefore without any protocol extensions. --- Please fix the minor spacing not reported by idnits. --- idnits shows several problems with references. You are missing RFC 2119 from the normative references. You are missing RFC 4874 from the informative references. You are missing RFC 2205 from the normative references. RFC 4726 is an informative reference, but not cited. Possibly work it into the 4th para of the Introduction? RFC 5920 is a downref. Does it need to be a normative reference? RFC 4736 is a downref. It appears that you are using it in a normative way - please confirm this so that we can handle the downref correctly. Document Shepherd - please update the write-up to correctly note the downrefs that remain after this work. --- Please remove citations from the Abstract. The Abstract is stand-alone text and cannot have external references. --- The Abstract is not clear and needs work. - The issues *may* arise, but do not always arise - The "computation of loosely routed inter-domain P2MP-TE LSP paths that are re-merge free" is not an issue and is not addressed in this document. Please describe the actual issue you are addressing. - s/vs./versus/ - I don't think "the loosely routing domain ingress border node is not aware of the reoptimization scope" describes a problem well because the issue is the "there is no way to indicate which branches of the P2MP tree are to be reoptimised". - In the light of my observation that techniques already exist to address the problems described in this document, it may be too strong to say "This document defines the required protocol extensions needed for ..." Maybe change this to "This document defines signaling protocol extensions for..." --- It would really help the reader and reviewers if someone could take an editorial pass on the document. This is not so much a problem of English usage as missing words and such like. A native speaker would clean it up very quickly and avoid the risk of the RFC Editor accidentally breaking the technical content. --- In the Introduction... Consequently one of the requirements for signaling P2MP LSPs is to choose a P2MP path that is re-merge free. Is this a signaling requirement? 1. Surely it is a path computation requirement, if it is a requirement at all. 2. Isn't the point that signaling is supposed to detect and resolve re-merge issues rather than avoid them? --- In the Introduction... For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). A border node is a node between different routing domains. "domain" or "routing domain"? --- In the Introduction... In that case, the border node for a new domain will be given loose next hops for one or more destinations in a P2MP LSP. s/will be/may be/ ? --- In the Introduction... A border node can ensure that it computes the re-merge free paths while performing loose hop ERO expansions by individually grafting destinations. Note that the computed P2MP tree by a border node in this case may not be optimal. Why are you suggesting a mechanism for computing paths? That is an implementation detail. Furthermore, suggesting a mechanism that is almost certain to generate a suboptimal solution seems perverse! --- In the Introduction... In that case, existing protocol mechanisms do not provide sufficient information for it to be able to expand the loose hop(s) such that the overall P2MP LSP tree is guaranteed to be re-merge free. Weeeeell... Even if you don't want to use PCE and Path Key, you could use RRO and XRO with suitable staggered processing at the branch node. That would provide sufficient information using existing protocol elements, although a small (but obvious) piece of processing needs to added at the branch node --- In the Introduction... [RFC4875] specifies two approaches to handle re-merge conditions. The first method is based on control plane handling the re-merge. In this case the node detecting the re-merge condition, i.e. the re-merge node initiates the removal of the re-merge sub-LSP(s) by sending a PathErr message(s) towards the ingress node. However, this can lead to a deadlock in setting up the P2MP LSP in certain cases; for example, when the first S2L setup causes the re-merge with all subsequent S2Ls in the tree. I am glad you are now discussing the mechanisms in 4875, but I disagree that there is a deadlock condition as you claim. You are saying that if the first S2L sub-LSP takes a route that causes all other S2L sub-LSPs to re-merge then there will be deadlock. Far from it! What will happen is that a PathErr will be sent for each subsequent S2L sub-LSP stating "re-merge", and the destinations for each subsequent S2L sub-LSP will be added to the set of destinations in the first S2L sub-LSP. So, what is the issue with the first mechanism in 4875? --- In the Introduction... [RFC4736] defines procedures and signaling extensions for reoptimizing an inter-domain P2P LSP. Specifically, an ingress node sends a "path re-evaluation request" to a border node by setting a flag (0x20) in SESSION_ATTRIBUTES object in a Path message. A border node sends a PathErr code 25 (notify error defined in [RFC3209]) with sub-code 6 to indicate "preferable path exists" to the ingress node. The ingress node upon receiving this PathErr may initiate reoptimization of the LSP. [RFC4736] however does not define a procedure to reoptimize the entire P2MP LSP as a whole tree. I'm afraid that the mechanism you have accurately described could be used precisely as specified for reoptimising the whole tree since such reoptimization takes place from the ingress node. But I think (from 1.1) that you are trying to describe the subtleties involved in reoptimizing only some parts of the tree downstream of the reporting border node. Firstly, you need to clarify the problem being addressed with clearer text in the Introduction. Then you need to decide why you need to address the problem. In 4736 there is no distinction made about which of the loose hops should be reomptimised and which not. So it is unclear why you should want to apply such a filter in the case of a P2MP LSP. If there is a reason it would be good to set it out in more detail. It is also possible that the ingress will want to dampen its activity to ensure is receives all 25/6 reports before starting reoptimization. It is also possible that if you ignore the way 4875 handles remerge, this could get complicated. --- In the Introduction... The Sub-Group-Based reoptimization is not always applicable because it can lead to data duplication inside the backbone. I am suspicious of this statement! Are you saying that the remerge issues may give rise to data duplication? Or is it the make-before- break nature that may cause the problem? Is it a transitory problem during the one or two seconds of signaling change, or is it a long-term problem? If you want to persist with this assertion then you need to substantiate it in the draft. --- The comparison in Section 1.1 of re-merge "avoidance" with crankback is interesting, but the two issues are different. Crankback is designed to facilitate re-route to avoid blocking resources, while re-merge avoidance is about moving destinations from one sub-tree to another. But, you could consider the PathErr mechanism of 4875 as crankback because it reports the error relating to the re-merge node, it unpicks the LSP setup, and it allows an upstream node to "correct" the issue. The only thing that you might want to add to 4875 is the replacement of the ID of the reporting node with the ID of the reporting domain so that the upstream node can apply meaning to the PathErr. Maybe if the problem was clearly described, this solution would stand out. --- Section 1.3 says that this work is limited to "multiple routing domains that belong to a single administrative area. Use case for the Multiple administrative domains (e.g. autonomous systems) is outside the scope of this document." A couple of points: - An "administrative area" is a new term and the next sentence uses "administrative domains" so that is probably what you mean. - It is unclear whether multiple ASes is in scope since the second sentence appears to rule them out, but multiple ASes may be under the care of one administrator. - You haven't given any reason for excluding multiple administrative domains, and that would help people understand what your objectives are and what the problems are. --- Section 3 It is RECOMMENDED that boundary re-routing is requested for P2MP LSPs The use of upper case "RECOMMENDED" is equivalent to "SHOULD". This is usually protocol requirements language. Anyway, if you use "SHOULD" you also need to discuss the associated "MAY". --- In Section 3.1 you recommend that the ingress node of a P2MP LSP selects the same ingress border node in the loose hop ERO for all sibling S2L sub-LSPs that transit through a given domain. This, of course, produces sub-optimal LSPs and can be resolved using PCE. But I am interested in the overlap between this statement and the scope statement in 1.3. You are recommending using only single attachments between domains: that means that remerge can only happen when the sub- LSPs transit different domains and come back together in a further domain. But since you are (apparently) limiting to IGP areas and ruling out ASes, the largest domain diameter you have is 3 with the result that remerge is entirely impossible! --- In Section 3.1 you have "RECOMMENDED". What is the associated "MAY"? --- Here's another example from Section 3.2 If an ingress border node on the path of the P2MP LSP is unable to find a route that can supply the required resources or that is re- merge free, it MUST generate a PathErr message for the subset of the S2L sub-LSPs which it is not able to route. This implies that the border node is trying to find a disjoint path. Such a path represents a waste of network resources that is *worse* than the data plane remerge case that you reject as a bad idea. The point of re-merge avoidance is simply moving destinations from one sub-tree to another and it can only be done at the branch point for the two trees - or even at the ingress depending on your signaling approach and explicit paths. --- Section 3.2 For this purpose the ingress border node SHOULD try to find a minimum subset of S2L sub- LSPs for which the PathErr needs to be generated towards the ingress node. These are the S2L sub-LSPs on an incoming interface that has less number of S2L sub-LSPs compared to the second incoming interface that is causing the re-merge condition. OK. It took me four or five readings and a lot of pain to parse what you are trying to say. You are saying that, if the border node is a branch node for two sets of sub-LSPs that are remerging, then the border node should fix this by moving the smaller set to share the path with the larger set. There are two reasons why this is a bad idea: 1. The first set may have been set up with a Path/Resv exchange, while the second set has not been set up and a PathErr was returned. Maybe the remerge node could have made the decision you are suggesting, but even that sounds like a bad idea. 2. The choice of the correct path to the remerge node should be made according to which is the shortest path, not which path has the most destinations. --- Section 3.2 The RSVP-TE Notify messages do not include S2L_SUB_LSP objects and cannot be used to send errors for a subset of the S2L sub-LSPs in a Path message. This is not true! A Downstream Notify message (headed upstream) is described in RFC 3473 as: &lt;Notify message&gt; ::= &lt;Common Header&gt; [&lt;INTEGRITY&gt;] [ [&lt;MESSAGE_ID_ACK&gt; | &lt;MESSAGE_ID_NACK&gt;] ... ] [ &lt;MESSAGE_ID&gt; ] &lt;ERROR_SPEC&gt; &lt;notify session list&gt; &lt;notify session list&gt; ::= [ &lt;notify session list&gt; ] &lt;upstream notify session&gt; | &lt;downstream notify session&gt; &lt;downstream notify session&gt; ::= &lt;SESSION&gt; [&lt;POLICY_DATA&gt;...] &lt;flow descriptor list&gt; And according to RFC 4875, &lt;flow descriptor list&gt; nets down to one or more of... &lt;S2L sub-LSP flow descriptor&gt; ::= &lt;S2L_SUB_LSP&gt; [ &lt;P2MP_SECONDARY_RECORD_ROUTE&gt; ] --- Section 3.2 A border node receiving a PathErr message for a set of S2L sub-LSPs MAY hold the message and attempt to signal an alternate path that can avoid re-merge through its domain for those S2L sub-LSPs that pass through it. However, in the case of a re-merge error for which some of the re-merging S2L sub-LSPs do not pass through the border node, it SHOULD propagate the PathErr upstream towards the ingress node. If the subsequent attempt by the border node is successful, the border node discards the held PathErr and follows the crankback roles of [RFC4920] and [RFC5151]. If repeated subsequent attempts by the border node are unsuccessful, the border node MUST send the held PathErr upstream towards the ingress node. How can an attempt to avoid re-merge be unsuccessful? There is already a suitable path. We know this because the re-merge has happened. --- Section 3.2 If the ingress node receives a PathErr message with error code "Routing Problem" and error value "ERO resulted in re-merge", then it SHOULD attempt to signal an alternate path through a different domain or through a different border node for the affected S2L sub-LSPs. The ingress node MAY use the error node information from the PathErr for this purpose. This is plain wrong. It should attempt to move the destinations to the same sub-tree, not try to signal the remerging destinations on a diverse sub-tree. --- Section 4 purports to be about the dataplane re-merge handling scenario, and it starts well. But then... The following sections define the RSVP-TE signaling extensions for "P2MP- TE Re-merge Recording Request" and "P2MP-TE Re-merge Present" messages. That look like it is control plane work and so does not belong in this section. Furthermore, this section appears to be offering a third solution to add to the two noted in 4875. That is, you are proposing that dataplane handling should be used, but that the control plane should be used to resolve the issue. This is an OK idea, but was discussed at the time of 4875 when two approaches handling this situation were discussed. 1. Use a Notify message sent after the Resv 2. Use a non-destructive PathErr sent after the Resv Admittedly, neither of those approaches is quite tidy, but it was thought that if you cared about the remerge you would fix it at setup time, and if you didn't care, then you didn't care. Thus the case you are fixing is a corner case (care a bit, but not too much) and the existing untidy solutions are enough. Nevertheless, the mechanism you describe does provide some additional useful diagnostics, and so should not be ruled out. Of course, those diagnostics are already visible simply by inspecting the full set of RRO information from the various S2L sub-LSPs as a re-merge point will show up as the same node appearing in two different sub-trees. Thus, the question only applies when RRO information is being stripped at domain boundaries. However, this last issue is the one you note in the final paragraph of section 4.3. There you appear to say that since the re-merge report info would be stripped from the Resv, the Resv should be discarded and a PathErr sent upstream. That would be fine, but it does seem to leave half an LSP provisioned and doing nothing (downstream between the border node and the re-merge point) --- 4.3 This can be achieved by computing and selecting alternate path(s) for the S2L(s) bypassing the re-merge node(s). Again, avoiding the remerge node is not the best result. --- Section 5 Re-merges between S2Ls in a single domain can occur due to provisioning errors or path computation errors in the environment where IGP-TE or PCE is used. What is a "provisioning error"? Are you referring to cases where the EROs of P2MP trees are entered by hand? What has IGP-TE to do with this? If PCE (whether a separate component or embedded in an LSR) is making such fundamental computation errors, then we should certainly not crash, but I also don't think we should optimise the protocol to handle it. This represents a critical implementation bug! --- Section 6.3 Using signaling procedure defined in [RFC4736], an ingress node MUST initiate "path re-evaluation request" query to reoptimize a destination in a P2MP LSP. Note that this message MUST be used to reoptimize a single or a sub-set of the destinations in a P2MP LSP. Ingress node MUST send this query in a Path message for each destination it is reoptimizing. When a Path message for a destination in a P2MP LSP with "path re-evaluation request" flag [RFC4736] is received at the border node, it MUST re-compute the loose-hop ERO to see if a preferable path exists for that destination. I am hugely worried about your use of 2119 language in this text. Is it your intention to redefine the procedures of RFC 4736? Because that is what you are doing! Perhaps you consider that you are only defining the procedures for P2MP LSPs with the claim that they were not covered by 4736. I don't see on what evidence such a claim would be made, and I am particularly concerned that you have turned the request in 4736 into a demand in your draft. --- Section 6.3 is almost impossible to understand. I think there are probably some assumptions that a request to reoptimise the path to a single destination would: a. be made b. be responded with "not telling you, but I could reoptimise the whole sub-tree." On the other hand, there also seems to be a desire to send a reoptimise request that identifies just on destination, but is actually a request to reoptimise the whole tree. Colour me confused! _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> Adrian Farrel 2013-05-23T20:11:02 http://comments.gmane.org/gmane.ietf.mpls/14419 <pre>Working Group, we have a quite simple and straightforward draft, that is also necessary to progress other working group drafts - draft-farbryantrel-mpls-retire-ach-tlv. The draft has been through an MPLS-RT review and updated after the (small) comments in that review. All reviewers agree that the draft is ready to be adopted as a working group draft. The working group chairs has re-read the thread on this draft and found a good support in the working group to make it a working group document. The working group chairs has therefore decided to make the draft an MPLS working group document. The authors have stated that they do not know of any IPR applicable to this draft; in the unlikely event that some have IPRs that are applicable please disclose this on the mpls wg mailing list. Could the authors please re-post the draft as draft-ietf-mpls-retire-ach-tlv-00. /Loa for the mpls wg co-chairs </pre> Loa Andersson 2013-05-23T16:36:45 http://comments.gmane.org/gmane.ietf.mpls/14418 <pre>Hi, Update to take account of MPLS-RT reviews. Many thanks to them for their input. Adrian _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> Adrian Farrel 2013-05-23T13:44:41 http://comments.gmane.org/gmane.ietf.mpls/14412 <pre>Folks, We updated the draft by modifying the introduction, typos in section 5, and adding a section highlighting the changes on rfc3811. Your review and comments are highly appreciated. Regards, Will -----Original Message----- From: internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Sent: Wednesday, May 22, 2013 3:30 AM To: Tina TSOU; Will Liu (Shucheng); Vishwas Manral; Will Liu (Shucheng) Subject: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt A new version of I-D, draft-manral-mpls-rfc3811bis-02.txt has been successfully submitted by Vishwas Manral and posted to the IETF repository. Filename: draft-manral-mpls-rfc3811bis Revision: 02 Title: Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management Creation date: 2013-05-20 Group: Individual Submission Number of pages: 22 URL: http://www.ietf.org/internet-drafts/draft-manral-mpls-rfc3811bis-02.txt Status: http://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis Htmlized: http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-manral-mpls-rfc3811bis-02 Abstract: This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. This document obsoletes RFC3811 as it addresses the need to support IPv6 extended TunnelID's by defining a new TC- MplsNewExtendedTunnelID which suggests using IPv4 address of the ingress or egress LSR for the tunnel for an IPv6 network. Changes from RFC3811 and the effect of the new TC to other related documents are summarized in Section 4 and 5, respectively. The IETF Secretariat _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> Will Liu (Shucheng 2013-05-22T03:02:41 http://comments.gmane.org/gmane.ietf.mpls/14407 <pre>Mach, et al. - In section 4.1. Sending an Echo Request, it is stated: The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply. It would appear that the semantics of TLV 21 are very different than the semantics of TLV 1. Since TLV 1 defines a FEC stack which maps to a single LSP. Why do you want the NIL FEC which only makes sense as part of a FEC stack? Under what circumstances would you ever use one of the multicast FECs (sub-TLVs 17, 18, 19, 20)? What is the meaning of a return path to a VPN IPv4 prefix, or VPN IPv6 prefix? Note that if the prefix is multi-homed it may not even return to the originating PE! What is the meaning of a return path to an L2 VPN endpoint? George _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> George Swallow (swallow 2013-05-21T16:22:52 http://comments.gmane.org/gmane.ietf.mpls/14398 <pre>The following errata report has been submitted for RFC6428, "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6428&amp;eid=3629 -------------------------------------- Type: Technical Reported by: Alan Davey &lt;alan.davey&lt; at &gt;metaswitch.com&gt; Section: 3.5.3 Original Text ------------- The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Corrected Text -------------- The length is the length of the data following the length field. The Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6428 (draft-ietf-mpls-tp-cc-cv-rdi-06) -------------------------------------- Title : Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile Publication Date : November 2011 Author(s) : D. Allan, Ed., G. Swallow Ed., J. Drake Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> RFC Errata System 2013-05-21T14:13:50 http://comments.gmane.org/gmane.ietf.mpls/14392 <pre>The IESG has approved the following document: - 'Applicability of MPLS-TP Linear Protection for Ring Topologies' (draft-ietf-mpls-tp-ring-protection-06.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ Technical Summary This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to Multi-Protocol Label Switching Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Protection on rings offers a number of opportunities for optimization as the protection choices are starkly limited (all traffic traveling one way around a ring can only be switched to travel the other way on the ring), but also suffers from some complications caused by the limitations of the topology. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document shows how MPLS-TP linear protection as defined in RFC 6378 can be applied to single ring topologies, discusses how most of the requirements are met, and describes scenarios in which the function provided by applying linear protection in a ring topology falls short of some of the requirements. Working Group Summary This document was the subject of considerable debate in the MPLS working group. There was some concern about whether this work prohibited or devalued the development of specialised protection techniques for deployment in ring topologies. The document was re-worked to make it clear that it is basically an applicability statement showing how linear protection defined in RFC 6378 can be applied to ring topologies, what function can be achieved, and what issues remain. It was made clear to the working group that specialist ring protection techniques were still in scope for the working group provided that they demonstrate improvements over the application of linear protection, and provided they can interwork with general protection in the wider MPLS-TP network. A second WG last call was held and the document gained consensus. Please see RFC editor note for a commentary on the number of front-page authors. Document Quality This an informational document, it describes how the technologies defined in earlier RFCs can be applied to ring topologies. The document has been reviewed needed, the working group last call was brought to the attention of SG15 in ITU-T. Personnel Loa Andersson (loa&lt; at &gt;pi.nu) is the document shepherd Adrian Farrel (Adrian&lt; at &gt;olddog.co.uk) is the Responsible AD RFC Editor Note Please allow an exception to the normal front-page limit so that all eight named authors can be present. The WG chair/ shepherd explains it as follows: &gt; Early 2010 we had 5 or 6 different drafts addressing "mpls-tp- &gt; ring-protection" from one aspect or another. Most of these &gt; drafts had 2 or maybe 3 different authors. &gt; &gt; The WG chairs took an initiative to discuss the possibilities to &gt; merge all drafts into one. The discussion was partially &gt; successful, and all draft but one, were merged into a single &gt; document. Texts from all drafts were merged into draft- &gt; weingarten-mpls-tp-ring-protection (later to be adopted as &gt; the working group draft draft-ietf-mpls-tp-ring-protection. &gt; &gt; The number of authors on the first page reflect text &gt; contributions made to the drafts that were merged. --- You may rename and reposition Section 1.4 according to your style guide. --- If (and only if) you consider it necessary, you may consider some of the text as Tables and apply captions as follows... In Section 3.1 on page 19 "Table x : Backup LSPs for Node Protection" In Section 3.1.1 on page 20 "Table x : Nodes Traversed by Protection: LSPs" In Section 3.1.1 on page 21 "Table x : Bandwidth Utilization on Links During Protection" In Section 3.2.2 on page 25 "Table x : Context Specific Labels for Connected LSPs" _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> The IESG 2013-05-21T01:40:55 http://comments.gmane.org/gmane.ietf.mpls/14387 <pre>Hi, Please fix a small typo. Section 9.1.2. and section 9.3.2. mplsTunnelExtOppositeDirTnlPtr --&gt; mplsTunnelExtOppositeDirPtr Regards, Muly _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> Muly Ilan 2013-05-20T12:59:20 http://comments.gmane.org/gmane.ietf.mpls/14375 <pre>Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls&lt; at &gt;ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) </pre> Loa Andersson 2013-05-16T17:49:11 http://comments.gmane.org/gmane.ietf.mpls/14364 <pre>The current proposed text is at https://datatracker.ietf.org/doc/charter-ietf-mpls/ Keep commenting and discussing with your chairs. Adrian _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> Adrian Farrel 2013-05-15T10:59:21 http://comments.gmane.org/gmane.ietf.mpls/14363 <pre>State changed to Informal IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-mpls/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> IETF Secretariat 2013-05-15T10:56:38 http://comments.gmane.org/gmane.ietf.mpls/14356 <pre> 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 : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-07.txt Pages : 40 Date : 2013-05-14 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> internet-drafts< at >ietf.org 2013-05-14T15:02:41 http://comments.gmane.org/gmane.ietf.mpls/14355 <pre> 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 : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuan Fang Chao Zhou Lianyuan Li Kamran Raza Filename : draft-ietf-mpls-ldp-multi-topology-08.txt Pages : 18 Date : 2013-05-13 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document updates RFC4379. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-multi-topology-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> internet-drafts< at >ietf.org 2013-05-14T00:25:47 http://comments.gmane.org/gmane.ietf.mpls/14352 <pre> The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Downstream-on-Demand in Seamless MPLS' &lt;draft-ietf-mpls-ldp-dod-08.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-05-27. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> The IESG 2013-05-13T16:01:30 http://comments.gmane.org/gmane.ietf.mpls/14351 <pre> 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 : Seamless MPLS Architecture Author(s) : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-03.txt Pages : 41 Date : 2013-05-13 Abstract: This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mpls-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> internet-drafts< at >ietf.org 2013-05-13T14:02:13 http://comments.gmane.org/gmane.ietf.mpls/14350 <pre> 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 : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-08.txt Pages : 33 Date : 2013-05-13 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-dod-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> internet-drafts< at >ietf.org 2013-05-13T13:54:54 http://comments.gmane.org/gmane.ietf.mpls/14349 <pre> 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 : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-07.txt Pages : 33 Date : 2013-05-13 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-dod-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> internet-drafts< at >ietf.org 2013-05-13T12:40:54 http://comments.gmane.org/gmane.ietf.mpls/14345 <pre>Working Group, draft-ietf-mpls-ldp-multi-topology has been being updated after working group last call. We will request publication of the document as an RFC on the Standards Track. As part of the shepherd write-up, that is sent as part of the request for publication to the IESG, we need to know about existing or intended implementations of draft-ietf-mpls-ldp-multi-topology. Please send mails to the mpls wg mailing list (mpls&lt; at &gt;ietf.org) or the working group chairs to inform us about implementations. /Loa (as wg co-chair) </pre> Loa Andersson 2013-05-12T10:06:14 http://comments.gmane.org/gmane.ietf.mpls/14341 <pre>Working Group, The working group chairs have discussed an MPLS wg charter update for sometime. We have converged on the text below and while we understand that it still not "perfect" (for some value of perfect) we believe that it is good enough to serve as a basis for a working group discussion of our charter. Please note that this is not a "re-charter", but a normal charter update (maintenance) that should take place when adopting new work items or finalizing others. The only "issue" is that we have not maintained the charter to the degree we should have during the last years when the work load has been quite heavy. Please view the text below as a starting point for an update of our charter and send your comments to mpls&lt; at &gt;ietf.org. We would like to see your comments before June 7th, 2013. -------------------- Proposed new charter text ------------------------- Description of Working Group The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The responsibility includes procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) (including the necessary management objects expressed as MIB modules or using other techniques). The current WG work items are: •Maintain existing MPLS requirements, mechanisms, and protocols, in coordination with other working groups, e.g. CCAMP, PWE3 and OPSAWG working groups. •Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE and LSP Ping to meet new requirements. •Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications. •Determine MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG •Define necessary extensions for MPLS key protocols for dual-stack and IPv6 only networks •Coordinate with the CCAMP working group on the extensions of MPLS and GMPLS protocols •Document current implementation practices for MPLS load sharing. •Document mechanisms for securing MPLS networks in coordination with the KARP working group. •Document mechanisms for adding multi-topology support to existing MPLS protocols. •Document use cases for MPLS protocols. -------------------------- end proposed text ------------------------ Loa (for the wg chairs) </pre> Loa Andersson 2013-05-11T08:42:44 http://comments.gmane.org/gmane.ietf.mpls/14336 <pre> 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 : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-06.txt Pages : 33 Date : 2013-05-10 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-dod-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mpls </pre> internet-drafts< at >ietf.org 2013-05-10T16:15:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mpls