The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] RE: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt
Hi Jean-Philippe Thanks a lot for these comments Please see inline, > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoyé : vendredi 3 novembre 2006 14:22 > À : LE ROUX Jean-Louis RD-CORE-LAN; zzx-rahul@juniper.net > Cc : mpls@ietf.org > Objet : Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt > > Hi, > > First of all, my full support to the ID, this is for sure a > needed solution in several cases. > > Here are my comments/suggestions: > 1) To be discussed next week (live will be easier): it might > be useful in some cases to tradeoff the rerouting times for > the P2MP backup efficiency, provided that the failure > detection times stays bounded of course and on the order of a > few ms. Note that in situations where P2MP backup may be > useful, it may make sense to have the PLR not immediately > upstream to the protected element. We can use an distributed > bidding mechanism to determine the PLR based on the P2MP > backup cost and the distance between the PLR and the > protected element. Yes I see what you mean. In the topologies I have in mind this is not really a problem, but I agree that what you suggest may be helpful in some specific topologies. By the way one may run BFD between the PLR and the protected node so as to speed up the detection time. This needs to be futher investigated... Also a flag could be defined in the LSP ATTRIBUTE object to indicate whether protection by the immediately upstream LSR is required or not... > 2) In the introduction, don't you want to indicate that the > use of bypass P2MP tunnels may lead to more states compared > to the P2P case because of the requirement to fully intersect > the protected primary ? Yes we could add some text to discuss the tension between states and bandwidth consuption, which is actually a classical tension in multicast environments. Here this is particularly true if bypass tunnel leaves exactly match the set of Merge Points of a protected primary. By the way, we need feedback on the possibility to rely on Bypass tunnels whose leaves are actually a superset of the downstream Merge Points. This would allow a given bypass to protect much more P2MP LSPs, and would drastically reduce the number of bypass. The counter part is that during failure traffic may be sent to LSRs that are not MPs, they will drop the traffic (again the tension!) > 3) Trade-off between a set of P2P, one P2MP bypass tunnels > and a set of P2MP bypass tunnels. There are cases where it > might be preferable to use a set of P2P because of the number > of states if the PLR has to protect a large number of primary > P2MP tunnels and the PLR cannot find a good overlapping > bypass P2MP. An alternative is also to use a "few" P2MP > bypass tunnels in that case: the PLR would have to do some > replication but still much less than with P2P bypass tunnels. This is a good point. This needs to be addressed in the draft. Note also that combination of P2MP and P2P Bypass may be required for backward compatibility with MP that do not support upstream label assignement. > 3) It would be useful to indicate that a P2MP TE LSP may be > protected by some PLRs using P2P and by other PLRs using P2MP > bypass tunnel along the protected P2MP primary path (thus comment 5)). Hum I'm not sure this is the role of the head-end to specifiy if P2P or P2MP or both should be used on the PLR. To me this is a local decision to the PLR. > 5) It might be useful to define: > * a flag in the LSP-ATTRIBUTE to indicate at each PLR whether > the primary P2MP TE LSP is protected by a set of P2P bypass > tunnels or one P2MP bypass tunnel I'm a bit sceptic, see above comment > * a flag in the LSP-ATTRIBUTE to report "Partial" protection > of the primary P2MP TE LSP, by partial I'm referring to the > ability to only find a P2MP backup that does not fully > intersect the primary TE LSP. That would make sense. If carried within the LSP-ATTRIBUTE object this would indicate whether partial protection is allowed or not, and when carried in the RRO this would allow reporting partial protection > Or is partial protection simply not supported? This needs to be discuss. Thanks for these really useful comments. See also below comments to your in-line comments. Best Regards, JL > > Comment in line (Search for JP>) > > Network Working Group > J.L. Le Roux > Internet Draft > France Telecom > Category: Standard Track > Expires: February 2007 > R. Aggarwal > > Juniper Networks > > > > August > 2006 > P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels > draft-leroux-mpls-p2mp-te-bypass-00.txt > Status of this Memo > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. > Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum > of six months > and may be updated, replaced, or obsoleted by other > documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Abstract > > This document defines procedures for fast reroute protection of > point-to-multipoint (P2MP) MPLS-TE LSPs, with point-to-multipoint > bypass tunnels. During branch node failure the traffic on > a protected > P2MP TE-LSP is tunneled within a P2MP bypass tunnel > towards the set > of Merge Points. To avoid data duplication, the backup label is > assigned by the PLR following the RSVP-TE upstream label > assignment > procedure. > Le Roux, Aggarwal Fast Reroute with P2MP Bypass Tunnels > [Page 1] > > > Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 > > > Conventions used in this document > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this > document are to be interpreted as described in RFC-2119. > Table of Contents > > 1. > Terminology.................................................2 > 2. > Introduction................................................3 > 3. Solution > overview...........................................3 > 4. PLR > procedures..............................................4 > 4.1. Before > failure..............................................4 > 4.2. During > failure..............................................5 > 5. MP > Procedures...............................................5 > 6. Backward > compatibility......................................6 > 7. Security > Considerations.....................................6 > 8. > References..................................................6 > 8.1. Normative > references........................................6 > 9. Authors' > Addresses:.........................................7 > 10. Intellectual Property > Statement.............................7 > > > 1. Terminology > This document uses terminologies defined in [RFC3031], [RFC3209], > [RFC4090] and [RFC4461]. It defines the following new terms: > P2MP Bypass tunnel: Point-to-Multipoint Bypass Tunnel. A P2MP TE- > LSP that is used to protect a set of P2MP TE-LSPs > traversing a > common node. The Ingress LSR of a P2MP bypass tunnel > is the PLR > and the leaf LSRs are a set of LSRs, on the > protected P2MP LSP, > downstream of the protected node. > > P2MP Facility Backup: A local repair method in which a P2MP bypass > tunnel is used to protect one or more P2MP TE-LSPs that > traverse the PLR (P2MP Bypass Ingress), the resource being > protected, and the set of Merge Points (P2MP Bypass leaves) > downstream to the protected resource. > Backup P2MP LSP: The LSP that is used to backup up one of the > many protected P2MP LSPs in P2MP Facility Backup. > > Backup S2L sub-LSP: A S2L sub-LSP of a backup P2MP LSP. > > > . > Le Roux, Aggarwal [Page 2] > > > Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 > > JP> It might be useful to define the notion of overlapping P2MP > Bypass tunnel > where's all the leaf LSRs of the bypass tunnel intersect the > protected primary P2MP tunnel. OK, anyway this will have to be clarified, you may intersect the protected tunnel on a non MP... > > 2. Introduction > > [RFC4090] defines fast reroute extensions to RSVP-TE for local > protection of P2P MPLS TE LSPs. Two techniques are > defined: the one- > to-one backup method, which creates a detour LSP for each > protected > LSP at each PLR, and the facility backup method, which creates a > bypass tunnel that can be used to protect a set of LSPs by taking > advantage of MPLS label stacking. > > [RSVP-P2MP] defines extensions to RSVP-TE for setting up P2MP TE- > LSPs. It specifies extensions to one-to-one and facility > backup Fast > Reroute procedures defined in [RFC4090] so as to support > fast reroute > protection of P2MP LSPs. > The facility backup solution defined in [RSVP-P2MP] only relies on > P2P bypass tunnels for link and node protection. This faces the > following limitation: The protection of a P2MP LSP against node > failures requires, when the protected node is a Branch > LSR, a set of > P2P Next Next Hop (NNHOP) Bypass tunnels towards all LSRs > downstream > to the protected node. During failure the PLR has to replicate > traffic on each P2P NNHOP bypass tunnel, and this may lead to > significant inefficient bandwidth usage. > To overcome this limitation it is highly desired to > define extensions > to the fast reroute facility backup solution, so as to > support P2MP > Bypass tunnels. > > JP> See my previous comments regarding the trade-off between number > of states and > backup tunnel efficiency. OK some text can be added here > > This draft specifies extensions to the Fast Reroute procedures > defined in [RFC4090] and [RSVP-P2MP] to support P2MP TE-LSP node > protection with P2MP bypass tunnels. > Procedures defined in [RFC4090] and [RSVP-P2MP] MUST be followed > unless specified below. > > 3. Solution overview > > The P2MP Facility Backup method defined in this document relies on > the use of P2MP bypass tunnels. A P2MP bypass tunnel can > be used to > protect a set of P2MP TE-LSPs by taking advantage of MPLS label > stacking. > A P2MP Bypass tunnel is used to protect a P2MP TE-LSP > against branch > LSR failures. The bypass tunnel head-end is the PLR, and > the bypass > tunnel leaf LSRs are the set of MPs, that is the set of LSRs > downstream to the protected branch node, on the protected > P2MP TE- LSP. > The P2MP bypass tunnel protects the set of S2L sub-LSPs > that transit > the protected node. > > When P2MP facility backup method is used, during failure > the PLR MUST > send data for each protected P2MP LSP into the P2MP bypass tunnel. > Label stacking is used: The inner label is the backup > label for the > backup P2MP LSP, that will be used on the MP to forward traffic to > > Le Roux, Aggarwal [Page 3] > > > Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 > > > the corresponding protected P2MP LSP, and the outer label > is the P2MP > bypass tunnel label. > To avoid data replication on the PLR, the same backup > label MUST be > used for all S2L sub-LSPs towards all MPs of a given > backup P2MP LSP. > This backup label will indicate to the MPs that packets > received with > that label should be switched along the protected P2MP LSP. > For that purpose upstream label assignment procedures defined in > [MPLS-UPSTREAM] and RSVP-TE extensions for upstream label > assignment > defined in [RSVP-UP] MUST be used. To signal a backup > P2MP LSP, the > same backup label, is distributed by the PLR to the set of MPs, in > the context of the P2MP bypass tunnel. This requires the > backup P2MP > LSP to be signalled prior to the failure. > > JP> Which is required anyway to guarantee fast rerouting and always > the case for Protection recovery > (by contrast with recovery) > > On the MP, backup S2L sub-LSPs (i.e. S2L sub-LSPs of the > backup P2MP > LSP) are merged with protected S2L sub-LSPs. The MPs, (i.e. the > bypass tunnel leaf LSRs), maintain a context specific ILM > > JP> Spell ? > > for the > P2MP Bypass tunnel. The context of an inner label (i.e a backup > label) > is determined by the underlying P2MP bypass tunnel on which it is > received. This requires deactivating PHP on the P2MP > bypass tunnel. A > label, in a given Bypass tunnel specific ILM, is mapped to the > outgoing interfaces and labels of the corresponding protected P2MP > LSP. > 4. PLR procedures > 4.1. Before failure > To protect a P2MP LSP against a branch node failure, a PLR MUST > > JP> The MUST is what I propose to change (see comments above) > depending on the path > quality for the P2MP bypass, number of states, ... compared > to using P2P bypass. OK > > select a P2MP bypass tunnel with a set of leaf LSRs with the > following properties: > - These leaf LSRs are transit or egress LSRs on the protected > P2MP LSP. We will denote this subset as {LSR1.LSRn}. > - {LSR1.LSRn} are downstream of the protected node on the > Protected P2MP LSP. > - In the event of failure of the protected node, traffic > received on the protected P2MP LSP by the PLR, can be > delivered to all the leaves of the protected P2MP LSP > downstream to the failed node, if it is tunnelled to > {LSR1.LSRn} over the P2MP bypass. > > JP> This is where we could discuss using one or more P2MP bypass (if > non overlapping) OK > > PHP MUST be deactivated on the P2MP Bypass tunnel, in > order to allow > MPs to determine the context for the backup labels assigned by the > PLR. > The backup label (i.e. the inner label) used for every backup S2L > sub-LSPs, (i.e. the inner label within the P2MP bypass > tunnel), of a > given backup P2MP LSP MUST be the same, so as to avoid traffic > replication on the PLR. This label MUST be assigned by > the PLR using > upstream label assignment procedures. > > > Le Roux, Aggarwal [Page 4] > > > Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 > > > Backup P2MP LSPs MUST be signaled prior to the failure. > To signal the backup P2MP LSP, the PLR MUST send one or more Path > messages to each MP. The Path messages to signal a backup P2MP LSP > are sent to the MPs using directed signaling; they are > addressed to > the MPs, without Router Alert option. > The PLR MUST use the sender template specific method to identify a > Path message for a backup P2MP LSPs. Hence the PLR will set the > source address in the sender template to a local PLR address. > A Path message to a given MP comprises one or more backup S2L sub- > LSPs that transit through this MP. > > The backup label MUST be assigned by the PLR, in the > context of the > underlying P2MP Bypass tunnel, following upstream label assignment > and P2MP RSVP-TE context identification procedures > defined in [RSVP- > UP]. Hence, a Path message sent to a MP for a backup P2MP LSP MUST > include an Upstream Assigned Label object carrying the > value of the > backup label. It MUST also include an RSVP-TE P2MP LSP > TLV within an > IF_ID RSVP TLV, that carries the session object of the underlying > P2MP Bypass tunnel. This allows MPs to identify the label space of > the backup label assigned by the PLR. The same backup > label MUST be > sent to all MPs of a protected P2MP LSP. > > Note that the PLR MUST continue to refresh Path messages for the > protected P2MP LSP along the nominal route. > The processing of backup S2L sub-LSP SEROs/SRROs MUST follow > backup LSP ERO/RRO processing described in [RFC4090]. > > 4.2. During failure > > When the PLR detects a link or/and node failure > condition, it has to > reroute a protected P2MP LSP onto the P2MP bypass tunnel using as > inner label the backup label assigned for this P2MP LSP. > The PLR MUST continue to send Path messages for the > backup P2MP LSP. > > JP> Need to discuss the replication of Path messages by the branch > node along the backup P2P LSP Actually there is no any replication, the Path message is not sent within the P2MP Bypass, it is IP routed to the MP... > > The RRO/ERO flags MUST be updated as per defined in > [RFC4090] 5. MP Procedures > A MP receives one or more Path messages for the protected P2MP LSP > and one or more Path messages for the backup P2MP LSP. > > Note that, as specified in [RFC4090], the reception of a > backup LSP's > Path message does not indicate that a failure has occurred or that > the incoming protected LSP will no longer be used. > > A S2L sub-LSP is received > > JP> "Received" confusing terminology OK will change to "included" > > within a Path message for the protected > P2MP LSP and within a Path message for the backup P2MP > LSP. These two > Path messages are distinguished thanks to the sender-template > specific method. As specified in [RFC4090], each of these Path > messages will have a different SENDER_TEMPLATE. The protected LSP > can be recognized because it will include the > FAST_REROUTE object or > > Le Roux, Aggarwal [Page 5] > > > Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 > > > have the "local protection desired" flag set in the > SESSION_ATTRIBUTE > object, or both. > A MP MUST install the upstream assigned label received in a backup > LSP Path message, within an ILM specific to the underlying bypass > tunnel, which is identified by its session object, > carried within the > IF_ID RSVP_HOP object of the backup Path message. An upstream > assigned label for a backup P2MP LSP MUST be mapped to > the outgoing > interfaces and labels of the corresponding protected P2MP LSP. > > As specified in [RSVP-UP], the Resv message sent by a MP > to the PLR, > does not carry any Label Object. > The processing of backup S2L sub-LSP SEROs/SRROs MUST follow > backup tunnel ERO/RRO processing described in [RFC4090]. > 6. Backward compatibility > > Procedures with MPs that do not support upstream label > assignment are > to be defined (combination of P2P and P2MP bypass LSPs). > 7. Security Considerations > > No new security issues are raised in this document. > 8. References > > 8.1. Normative references > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS > Architecture", > RFC 3031. > > [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP > Tunnels", RFC3209. > [RFC4461] S. Yasukawa et al., "Signaling Requirements for > Point-to- > Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", > RFC4461. > [RFC4090] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to > RSVP-TE for LSP Tunnels", RFC4090. > > [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, > "Extensions to RSVP-TE > for Point to Multipoint TE LSPs", > draft-ietf-mpls-p2mp-rsvp-te, work > in progress. > > [MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label > Assignment and Context Specific Label Space", draft-ietf-mpls- > upstream-label, work in progress. > Le Roux, Aggarwal [Page 6] > > > Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 > > > [RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for > RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress. > 9. Authors' Addresses: > > Jean-Louis Le Roux > France Telecom > 2, avenue Pierre-Marzin > 22307 Lannion Cedex > FRANCE > Email: jeanlouis.leroux@francetelecom.com > > Rahul Aggarwal > Juniper Networks > 1194 North Mathilda Ave. > Sunnyvale, CA 94089 > Email: rahul@juniper.net > 10. Intellectual Property Statement > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might > be claimed to > pertain to the implementation or use of the technology > described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission > for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR > repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its > attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > Disclaimer of Validity > > This document and the information contained herein are > provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION > HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > Le Roux, Aggarwal [Page 7] > > > Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 > > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Copyright Statement > > Copyright (C) The Internet Society (2006). This document > is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Le Roux, Aggarwal [Page 8] > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|