Subject: [mpls] RE: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 6 Nov 2006 15:58:40 +0100

Hi Jean-Philippe

Thanks a lot for these comments

Please see inline, 

> -----Message d'origine-----
> De : JP Vasseur [mailto:[email-masked]] 
> Envoyé : vendredi 3 novembre 2006 14:22
> À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
> Cc : [email-masked]
> 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: [email-masked]
> 
>     Rahul Aggarwal
>     Juniper Networks
>     1194 North Mathilda Ave.
>     Sunnyvale, CA 94089
>     Email: [email-masked]
> 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
>     [email-masked].
> 
>     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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: JP Vasseur <[email-masked]>
Date: Mon, 6 Nov 2006 21:10:32 -0500

Hi Jean-Louis,

On Nov 6, 2006, at 9:58 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> 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.

> 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 ;-))

> 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.

> 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.

> 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.

> This needs to be discuss.

OK let's try to find some time this week and go back to the list.

> 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.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 8 Nov 2006 11:55:32 -0800 (PST)

Hi Jean-Louis,

To re-iterate my comment in the WG, in general, node protection, 
whether for p2p or p2mp LSPs, is an order of magnitude less scalable 
than link protection.

I think we should step back at this point, and request SPs and others 
deploying MPLS networks to share with the WG: frequencies of link 
failures, node software failures (node recovers), node failures 
(requires manual intervention), and battery explosions, to give us a 
sense of the importance of continuing the work on node protection.

I realize that some of these figures may be sensitive, but even 
normalized numbers may be useful.

Kireeti.
-------

---

From: JP Vasseur <[email-masked]>
Date: Wed, 8 Nov 2006 16:00:59 -0500

Hi Kireeti,

thoughts in line

On Nov 8, 2006, at 2:55 PM, Kireeti Kompella wrote:

> whether for p2p or p2mp LSPs, is an order of magnitude less  
> scalable than link protection.
>

Ah well, starting some discussion on a definition of "scalability"  
may quickly become a cumbersome task. Node P undoubtedly requires  
more backup tunnels compared to link protection. Up to a point where  
the number of backup tunnels becomes unreasonable ? Looking a typical  
degree of connectivity, it does not look unreasonable especially with  
Bypass compared to the overall number of primary TE LSPs in most meshes.

> I think we should step back at this point, and request SPs and  
> others deploying MPLS networks to share with the WG: frequencies of  
> link failures, node software failures (node recovers), node  
> failures (requires manual intervention), and battery explosions, to  
> give us a sense of the importance of continuing the work on node  
> protection.
>

Probability of failures is one dimension, the impact in term of  
traffic disruption is another key dimension to take into account.  
Routers may rarely fail compared to links but the impact of such  
failures is usually considerably larger.

JP.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 8 Nov 2006 16:06:17 -0800 (PST)

On Wed, 8 Nov 2006, JP Vasseur wrote:

>> To re-iterate my comment in the WG, in general, node protection, whether 
>> for p2p or p2mp LSPs, is an order of magnitude less scalable than link 
>> protection.
>
> Ah well, starting some discussion on a definition of "scalability" may 
> quickly become a cumbersome task.

I have no intention of starting such a discussion.

> Node P undoubtedly requires more backup 
> tunnels compared to link protection.

That's all I said.  Thanks for agreeing.  Now can we get to the real 
point?

>> deploying MPLS networks to share with the WG: frequencies of link failures, 
>> node software failures (node recovers), node failures (requires manual 
>> intervention), and battery explosions, to give us a sense of the importance 
>> of continuing the work on node protection.

The idea is *not* to start a religious war, or to propose some 
solution or other.  The idea is to get a better understanding of 
failures that really happen in networks.

I would agree with you on another point: the impact (and other 
parameters, like duration, cost of recovery, etc.) are all interesting 
factors.  I'll take as much as SPs are willing to share.

Kireeti.
-------

---

From: <[email-masked]>
Date: Thu, 9 Nov 2006 11:48:39 -0500

Here at Cox, our BB is fully meshed with of TE LSPs between our
core-edge routers with link protection. Based on our history, we have
not seen a node failure yet.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Wednesday, November 08, 2006 2:56 PM
To: LE ROUX Jean-Louis RD-CORE-LAN
Cc: [email-masked]
Subject: Re: [mpls] RE: Comments on

Hi Jean-Louis,

Kireeti.
-------

---

From: "HEMIGE Venu" <[email-masked]>
Date: Thu, 9 Nov 2006 10:56:57 -0600

Hi Jean-Louis,

I agree with Kireeti that node protection is several degrees more
complex, definitely in the case of P2MP LSPs. However, I am not so sure
of the efficiency of even link protection for P2MP LSP traffic. The
bypass tunnel for a protected link may be established over another link
or set of links behind which there are leaves of the P2MP LSP. So when
the protected link fails, there would be two copies of the traffic
forwarded over such links. Isn't that also a concern very similar to
what you are trying to solve in this draft for node protection?

Regards,
-Venu

> Sent: Wednesday, November 08, 2006 11:56 AM

---

From: Ian Stanley <[email-masked]>
Date: Fri, 10 Nov 2006 07:22:04 +1100

All,

We at Telstra have the same arrangements as Cox in terms of redundancy for
our nodes and have not experienced a node failure as yet

Cheers
Ian

On 10/11/06 3:48 AM, "[email-masked]" <[email-masked]>
wrote:[email-masked]

> normalized numbers may be useful.

Regards,
Ian Stanley
National Manager
Architecture & Design
IP & Data
Core Networks | Engineering
02 9396 8508
0419 257221

---

From: JP Vasseur <[email-masked]>
Date: Thu, 9 Nov 2006 13:26:17 -0500

On Nov 8, 2006, at 7:06 PM, Kireeti Kompella wrote:

>> may quickly become a cumbersome task.
>

feeling better ;-)

>> Node P undoubtedly requires more backup tunnels compared to link  
>> protection.
>
> That's all I said.  Thanks for agreeing.

I agreed that Node P requires more backup, not to a point that we may  
have scalability issues.

> Now can we get to the real point?
>

Having this debate is just fine. Just one last thing ... if there's  
no issue, why not continue developing protocols supporting node P then ?

>>> others deploying MPLS networks to share with the WG: frequencies  
>>> of link failures, node software failures (node recovers), node  
>>> failures (requires manual intervention), and battery explosions,  
>>> to give us a sense of the importance of continuing the work on  
>>> node protection.
>
> parameters, like duration, cost of recovery, etc.) are all  
> interesting factors.  I'll take as much as SPs are willing to share.
>

Opinions/Feedback are indeed most welcome here.

Cheers,

JP.