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

From: JP Vasseur <[email-masked]>
Date: Fri, 3 Nov 2006 08:22:18 -0500

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.
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 ?
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.
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)).
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
* 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.  
Or is partial protection simply not supported?

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.

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.

    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.

    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)

    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

    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

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: "Zafar Ali \(zali\)" <[email-masked]>
Date: Thu, 9 Nov 2006 15:52:49 -0500

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 1:21 PM
> To: LE ROUX Jean-Louis RD-CORE-LAN
> Cc: [email-masked]
> Subject: RE: [mpls] RE: Comments on 
> On Thu, 9 Nov 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> 
> > Hi Kireeti,
> >
> > Please see in-line
> 
> Thanks for your comments.
> 
> > The approach sounds actually a bit surprising to me: The 
> IETF worked 
> > on P2P FRR node protection, it has been implemented, 
> deployed, SPs are 
> > happy with this feature. And now you want to step back as P2MP node 
> > protection may be a bit more complex...
> 
> Well, I had the same opinion for p2p; in retrospect, I wish I 
> had raised the point then.  P2MP just makes this a bit more complex.
> 
> But, to repeat, I'm not against node protection.  I just want 
> validation from SPs that the additional complexity etc. of 
> node protection is required.  You said yes; Mazen said no.  
> Others have yet to speak.  

Really, and we closed the P2MP RSVP-TE requirement document and moved it
to an RFC status without hearing SP-es! 

The requirement document for P2MP LSP
(http://www.ietf.org/rfc/rfc4461.txt?number=4461) states node protection
as a requirement. You can play with the wording in the RFC but it does
state the requirement for supporting options in RFC 4090. 

IMO bandwidth inefficiency of P2P backup tunnels for node protection for
P2MP LSP-es is a major limitation. In this respect, I am in favor of
this document. 

Thanks

Regards... Zafar 

> If SPs were to themselves step 
> back and reconsider how they really want to protect nodes, 
> that would be a bonus.
> 
> Finally, this is not a call for consensus, just a request for 
> information.  Whether or not we work on this depends on the 
> WG chairs, which I am not :-)
> 
> Kireeti.
> -------
>

---

From: "Greg Mirsky" <[email-masked]>
Date: Mon, 13 Nov 2006 12:29:31 -0800

Dear Zafar,
though section 4.6 in RFC 4461 says that for P2MP TE LSP "... solutions
MUST provide fast protection mechanisms similar to those specified in
[RFC4090] ..." I can not find that any specific protection mode,
facility backup in node protection mode in particular, being explicitly
required. Would you agree to statement that an implementation that
supports subset of protection mechanisms defined in RFC 4090 for the
P2MP TE LSP does not violate quoted above requirement?

Regards,
Greg

-----Original Message-----
From: Zafar Ali (zali) [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 12:53 PM
To: Kireeti Kompella; LE ROUX Jean-Louis RD-CORE-LAN
Cc: [email-masked]
Subject: RE: [mpls] RE: Comments on

Thanks

Regards... Zafar

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 13 Nov 2006 21:57:03 +0100

Hi Greg,

> though section 4.6 in RFC 4461 says that for P2MP TE LSP "... 
> solutions MUST provide fast protection mechanisms similar to 
> those specified in [RFC4090] ..."

With this statement we (RFC4461 authors) actually mean that both link protection and node protection are required.

You can read this statement differently:
1: RFC4090 defines procedures for link protection and node protection.
2: RFC4461 states that the solution MUST provide mechanisms similar to 4090.

>From 1 and 2 we deduce that the solution MUST provide node protection.

Thanks,

JL

> -----Message d'origine-----
> De : Greg Mirsky [mailto:[email-masked]] 
> Envoyé : lundi 13 novembre 2006 21:30
> À : Zafar Ali (zali); Kireeti Kompella; LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]
> Objet : RE: [mpls] RE: Comments on 
> though section 4.6 in RFC 4461 says that for P2MP TE LSP "... 
> solutions MUST provide fast protection mechanisms similar to 
> those specified in [RFC4090] ..." I can not find that any 
> specific protection mode, facility backup in node protection 
> mode in particular, being explicitly required. Would you 
> agree to statement that an implementation that supports 
> subset of protection mechanisms defined in RFC 4090 for the 
> > Well, I had the same opinion for p2p; in retrospect, I wish I had 
> > raised the point then.  P2MP just makes this a bit more complex.
> > 
> > validation from SPs that the additional complexity etc. of node 
> > protection is required.  You said yes; Mazen said no.
> Really, and we closed the P2MP RSVP-TE requirement document 
> and moved it to an RFC status without hearing SP-es! 
> 
> (http://www.ietf.org/rfc/rfc4461.txt?number=4461) states node 
> protection as a requirement. You can play with the wording in 
> the RFC but it does state the requirement for supporting 
> options in RFC 4090. 
> 
> IMO bandwidth inefficiency of P2P backup tunnels for node 
> protection for P2MP LSP-es is a major limitation. In this 
> respect, I am in favor of this document. 
> 
> Thanks
> 
> Regards... Zafar 
> 
> that would 
> > be a bonus.

---

From: "Greg Mirsky" <[email-masked]>
Date: Mon, 13 Nov 2006 13:09:26 -0800

Hi Jean-Louis,
thank you for the clarification. I agree that supporting both protection methods is critical. But the 4090 defines link and node protection for both one-to-one and facility backup. If a solution provides node protection for a detour only would it be compliant with 4461?

Regards,
Greg

-----Original Message-----
From: LE ROUX Jean-Louis RD-CORE-LAN [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 12:57 PM
To: Greg Mirsky; Zafar Ali (zali); Kireeti Kompella
Cc: [email-masked]
Subject: RE: [mpls] RE: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

Hi Greg,

Thanks,

JL