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-Louis, On Nov 6, 2006, at 9:58 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > 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... > Yes although the Path Error should be used as a trigger (probably faster than the running a additional BFD Session and less expensive) but this is a detail. > Also a flag could be defined in the LSP ATTRIBUTE object to > indicate whether protection by the immediately upstream LSR is > required or not... Yes or what is the Max Tolerable Rerouting delay (since in some cases adding N Hopes may be acceptable whereas in other cases M with M<<N is the maximum tolerable delay). Let's discuss this week. > >> 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!) Exactly (note that Tension is sometimes a good thing ... look at Blues music ;-)) > >> 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. We're in sync. > >> 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. > Yes (can't remember why I proposed this ;-)). At least we need a way to record the P2MP bypass tunnel type used at each 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 We may probably want to use the LSP-ATTRIBUTE object in both cases. > >> Or is partial protection simply not supported? > > This needs to be discuss. > OK let's try to find some time this week and go back to the list. > > 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... What about path states creation + routing convergence issues ... ? Thanks. JP. > >> >> 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
|
|