Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> Mon, 12 January 2015 15:13 UTC

Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20721AC3AB; Mon, 12 Jan 2015 07:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.61
X-Spam-Level:
X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqOJYVCpO9Ka; Mon, 12 Jan 2015 07:13:16 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384F21AC39D; Mon, 12 Jan 2015 07:13:15 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1657D17BD56F; Mon, 12 Jan 2015 15:13:10 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t0CFDCdd013526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 16:13:12 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 16:13:12 +0100
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Rob Shakir <rjs@rob.sh>
Thread-Topic: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
Thread-Index: AQHQLj+19rH0/A1Xy0ObHnHUPdPr+5y8G+CAgAARysCAAB57gP//8qQAgABZPQA=
Date: Mon, 12 Jan 2015 15:13:12 +0000
Message-ID: <D0D9684F.11A85E%wim.henderickx@alcatel-lucent.com>
References: <D0CF6C5B.1B6DD%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA26EF@xmb-aln-x02.cisco.com> <D0D00E58.1B720%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA29A2@xmb-aln-x02.cisco.com> <D0D02765.1B76C%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA2A4F@xmb-aln-x02.cisco.com> <BY1PR0501MB13812B36C2020C3AC3072641D5580@BY1PR0501MB1381.namprd05.prod.outlook.com> <F3ADE4747C9E124B89F0ED2180CC814F4EEA4F1A@xmb-aln-x02.cisco.com> <28823_1420641858_54AD4642_28823_8441_1_9E32478DFA9976438E7A22F69B08FF920C765C15@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1868F3A4-A4E2-4504-A749-582305FA31B4@rob.sh> <18651_1421050415_54B3822F_18651_14831_1_9E32478DFA9976438E7A22F69B08FF920C76D265@OPEXCLILM34.corporate.adroot.infra.ftgroup> <53C29892C857584299CBF5D05346208A0EB01975@PEXCVZYM11.corporate.adroot.infra.ftgroup> <21149_1421052896_54B38BE0_21149_1085_1_86923dca-49c3-4745-881c-116ec27cb9f2@OPEXCLILH02.corporate.adroot.infra.ftgroup> <D0D9633B.11A80B%wim.henderickx@alcatel-lucent.com> <13987_1421060024_54B3A7B8_13987_19542_1_3b33983a-7671-4df1-a1ac-52b83d8162a0@OPEXCLILH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <13987_1421060024_54B3A7B8_13987_19542_1_3b33983a-7671-4df1-a1ac-52b83d8162a0@OPEXCLILH02.corporate.adroot.infra.ftgroup>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C2107E7835282C4E956E55376EDF387C@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Fe8LrcR1VvZT5KLv9BEMPGmzfgg>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-segment-routing-extensions@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" <draft-ietf-isis-segment-routing-extensions@tools.ietf.org>
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 15:13:24 -0000

I understand that certain vendors will not easily accommodate this, so I
understand we need a solution like you suggest or support a combination of
Adj-SID/Node-SID based on where you want to avoid the rerouting.

On 12/01/15 11:53, "stephane.litkowski@orange.com"
<stephane.litkowski@orange.com> wrote:

>Very good point, in our case, today we have up to 15 strict hops for TE
>tunnels.
>When we will introduce interdomain, it will bring more.
>
>-----Original Message-----
>From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
>Sent: Monday, January 12, 2015 11:45
>To: LITKOWSKI Stephane SCE/IBNF; DECRAENE Bruno IMT/OLN; Rob Shakir
>Cc: ospf@ietf.org; spring@ietf.org;
>draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>isis-wg@ietf.org; 
>draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>Subject: Re: [OSPF] [Isis-wg] Mail regarding
>draft-ietf-ospf-segment-routing-extensions
>
>How many hops do we want to support in these scenario’s realistically?
>This might help in determining the options
>
>On 12/01/15 09:54, "stephane.litkowski@orange.com"
><stephane.litkowski@orange.com> wrote:
>
>>Hi Bruno,
>>
>>Using TTL may work or not. Backup path does not mean that you will
>>defacto have more hops. Metric of backup path could be higher but
>>number of hops equal or smaller.
>>
>>I created a new thread on SPRING WG list to discuss the different
>>options.
>>
>>Thanks !
>>
>>-----Original Message-----
>>From: DECRAENE Bruno IMT/OLN
>>Sent: Monday, January 12, 2015 09:49
>>To: LITKOWSKI Stephane SCE/IBNF; Rob Shakir
>>Cc: isis-wg@ietf.org;
>>draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>ospf@ietf.org; 
>>draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>Subject: RE: [OSPF] [Isis-wg] Mail regarding
>>draft-ietf-ospf-segment-routing-extensions
>>
>>Hi,
>>
>>2 cents inlined
>>
>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of >
>>> stephane.litkowski@orange.com
>>> 
>>> Hi,
>>> 
>>> After discussing a lot with Les offline, we almost found an agreement
>>> on the understanding of this use case and possible relationship with
>>> unprotected SIDs.
>>> Use case :
>>> 	Creation of a SR TE tunnel which is unprotected. Protection may be
>>> provided end to end using for example two disjoint paths.
>>> 	Controller based or ingress based tunnel setup.
>>> 
>>> It seems clear now that using ONLY unprotected SIDs does not solve
>>>the  issue as when a link fails, convergence will happen, and nodes
>>>that  are near the failure may reroute a NodeSID Algo 0 used within
>>>the TE  stack before Ingress or controller recomputes the new path
>>>fitting  constraints. So there may be transient situations where the
>>>path does not fit constraints anymore.
>>> Based on this, introducing "NON PROTECTED" NodeSID does not help in
>>>solving this transient situation.
>>> 
>>> Now, as I explained, IMO, it's possible to introduce end to end OAM
>>> on top on the SRTE to bring the LSP down as soon as there s something
>>> wrong on the path. A Holddown timer can be used to keep LSP down
>>> until convergence happens at Ingress or Controller. But introducing
>>> such OAM and holddown and coupled with relations with IGP may also be
>>> complex and there is a chance that it does not solve the issue. In
>>> case of protected NodeSID used, OAM will not work, because switchover
>>> time will be too small. Using OAM , defacto requires path with no
>>>protection.
>>> So unprotected SID+OAM may solve the use at the price of some
>>> complexity and possibly not solving 100% of the cases.
>>> 
>>> To conclude :
>>> We need to solve this use case and we need to find another elegant,
>>> simple and scalable solution for this.
>>> 
>>> Possible existing solutions :
>>> - Use Adj-SID only => does not sounds good as there will be an impact
>>> of stack depth => Path compression necessary
>>> - Use binding TLV and create some new Node-SID corresponding to a set
>>> of Adj-SID => This introduces more states within the network (how
>>> many
>>> ?)
>>> - Anything else ?
>>
>>Combining Adj-SID and Node-SID with a very restricted TTL (to expire on
>>the backup path) may be able to avoid IGP rerouting of this LSP.
>>
>>/Bruno
>>
>> 
>>> Best regards,
>>> 
>>> Stephane
>>> 
>>> 
>>> -----Original Message-----
>>> From: Rob Shakir [mailto:rjs@rob.sh]
>>> Sent: Thursday, January 08, 2015 10:52
>>> To: LITKOWSKI Stephane SCE/IBNF
>>> Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter
>>> Psenak (ppsenak);
>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>>> Gredler; ospf@ietf.org; isis-wg@ietf.org
>>> Subject: Re: [Isis-wg] [OSPF] Mail regarding
>>> draft-ietf-ospf-segment-routing- extensions
>>> 
>>> Stephane,
>>> 
>>> If we think about the “MUST NOT be protected” case that you mention.
>>> Let’s assume that we have a service that is performance sensitive,
>>> such that we want to take a particular path through the network - and
>>> that we use Node- SIDs like you say.
>>> 
>>> If we assume that the requirement is for A-B-C-D-E path below. The
>>> node SID for E points via C-D-E and hence is used for stack
>>> compression like you
>>> say:
>>> 
>>>       A -- B -- C -- D -- E
>>>                 |        /
>>>                 --- Q ---
>>> 
>>> In your envisaged behaviour, C does not protect the Node-SID for E.
>>> In the case of the C-D link failure, then the “preferred” behaviour
>>> is that C now drops traffic towards this destination. However, C does
>>> not remove the FIB entry for the Node-SID for E, it’s actually just
>>> now known via Q. At this point, A can forward with exactly the same
>>> stack, and the packet takes a new A-B- C-Q-E path, which is
>>> non-conformant with the performance requirement of the service.
>>> 
>>> In terms of what C does with its FIB, does it simply not use C-Q-E
>>> during the failure, but post-reconvergence use it anyway? If so, why
>>> not use C-Q-E during the failure - because the service is always
>>> going to non-conformant to the performance requirement?
>>> 
>>> With an Adj-SID, it makes sense, because essentially unless that
>>> adjacency is available, then there is no alternate path for the SID
>>> that will be taken - so traffic never hits a non-conformant path.
>>> 
>>> Practically, if I can’t tell a customer that the path taken will
>>>definitely be A-B- C-D-E, and it may rather go via C-Q-E at some point
>>>following convergence [until the head-end calculates that such a
>>>change had happened - either a link outage, or a metric change - and
>>>stops using the label stack], then there’s little problem of having
>>>the traffic go via C-Q-E during protection.
>>> 
>>> For the disjoint case, the consideration that one has to make is:
>>> 	* are alternative SPF paths for a particular Node-SID actually still
>>>conformant with the disjointness requirement? How many simultaneous
>>>failures does one require to violate constraints. For example, in a
>>>dual-plane core network, then if the requirement is disjointness at
>>>the IP level, then we may need to lose connectivity entirely within
>>>the plane before it is preferable to “hop” to another plane. In this
>>>case, using an alternative SPF path for the Node-SID is actually not a
>>>problem for disjointness.
>>> 	* does the application prefer losing an entire path to having some
>>>risk of the services being shared fate until the re-optimisation?
>>> 
>>> From the work that we’ve looked at thus far, I have not yet seen a
>>> case where I absolutely MUST NOT use an alternate shortest path for a
>>> Node-SID and hence don’t require protection at a practical level.
>>> 
>>> Stack depth is definitely going to be something that we need to
>>>consider - to me, where we have centralised controller - actions such
>>>as dynamically created forwarding-adjacency LSPs which allow
>>>“expansion” of one segment into a set of segments within the path are
>>>attractive as a solution where one needs to have explicit routing of
>>>traffic for TE purposes.
>>> 
>>> Does this make sense, or do you see the use case that we’re
>>> addressing here differently?
>>> 
>>> Cheers,
>>> r.
>>> 
>>> 
>>> > On 7 Jan 2015, at 09:44, stephane.litkowski@orange.com wrote:
>>> >
>>> > Hi,
>>> >
>>> > I'm coming into this long thread and I tried to read all the
>>> > exchange but I may be missed some lines :)
>>> >
>>> > But here is my opinion on this subject.
>>> > I think the point from Shradda is valuable in case of Traffic
>>> > Engineering with
>>> Segment Routing, especially with a central controller.
>>> >
>>> > Today in TE networks, we are selling some disjoints paths to
>>> > customer that
>>> MUST NOT be protected (SDH like services). It would be good to
>>> reproduce the same thing with SR-TE.
>>> >
>>> > Now, current encoding permits to advertise that a specific Adj-SID
>>> > is
>>> protected or not (as already mentioned, this does not say that a
>>> protection really exists ..., in case of LFA protection , there may
>>> be no FRR path for this adj-SID despite of the protection flag set).
>>> > We pretty know that it would not be possible in all case to use
>>> > only Adj-SID
>>> for a TE tunnel (due to label stack depth), so we need to introduce
>>> stack compression using SPT segments and node-SID.
>>> > So to reply on Rob's comment, on RSVP-TE tunnels with looses hops
>>> > that
>>> does not request protection : yes for RSVP, it does not make sense to
>>> me, but for SR, due to stack compression, it will be needed.
>>> >
>>> > If we look at a network, where TE is managed by a central
>>> > controller, how
>>> the controller can ensure that the node-SID used is protected or not
>>> (as for Adj-SID, I mean protection requested, not protection
>>> installed). I see two ways :
>>> > 	* Use two SIDs attached to the same prefix and add a flag to
>>> > prevent
>>> automatically all nodes to compute a protection for one of the SID.
>>> The flag does not really force nodes to compute a protection. Each
>>>node will still require local configuration for protection, but the
>>>flag will permit to exclude some prefixes for protection (overriding
>>>local policy).
>>> >
>>> > 	* Use two prefixes on each node , prefixes are marked with tags
>>> (admin-tags) : "protection tag" and "non protection tag". Each router
>>>is configured using LFA policies to not compute protection for
>>>prefixes having "non protection tag" AND add knowledge to the
>>>controller to use only "non protection tag" prefixes to compress non
>>>protected path.
>>> >
>>> >
>>> > Best Regards,
>>> >
>>> > Stephane
>>> >
>>> > -----Original Message-----
>>> > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les
>>> > Ginsberg (ginsberg)
>>> > Sent: Monday, January 05, 2015 16:59
>>> > To: Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak);
>>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>>> > Gredler
>>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>>> > Subject: Re: [Isis-wg] [OSPF] Mail regarding
>>> > draft-ietf-ospf-segment-routing-extensions
>>> >
>>> > Shraddha -
>>> >
>>> > As Jeff has already mentioned, the case you are concerned about can
>>> > be handled using LFA selection strategies discussed in
>>> > http://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/
>>> > And it is a far better solution since it allows the traffic of
>>> > interest to be
>>> protected => less traffic interruption.
>>> >
>>> >   Les
>>> >
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Shraddha Hegde [mailto:shraddha@juniper.net]
>>> > Sent: Monday, January 05, 2015 12:49 AM
>>> > To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak
>>> > (ppsenak); 
>>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>>> > Gredler
>>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>>> > Subject: RE: [OSPF] [Isis-wg] Mail regarding
>>> > draft-ietf-ospf-segment-routing-extensions
>>> >
>>> > Les,
>>> >
>>> > Pls consider a case when the post convergence path goes through a
>>> different node and is well provisioned.
>>> >
>>> > --------G-------
>>> > |                     |
>>> > A----B----C----D
>>> >        |       |
>>> >          E----F
>>> >
>>> > When the link between B & C goes down, we don’t want to divert the
>>> traffic via B-E-E-F-C because it is not well provisioned for the
>>>service.
>>> > The post convergence path is A-G-D which is well provisioned.
>>> > In this case it makes sense to simply avoid protection for the
>>> > service as the
>>> nature of the service is such that it can be disconnected and
>>> reconnected without impacting the end user of the service.
>>> >
>>> >
>>> > The post convergence paths need to be provisioned at least for one
>>> > failure
>>> if that is not the case then the service will remain down
>>> Irrespective of the technology used.
>>> >
>>> >
>>> > Rgds
>>> > Shraddha
>>> >
>>> > -----Original Message-----
>>> > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
>>> > Sent: Monday, January 05, 2015 12:07 PM
>>> > To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak);
>>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>>> > Gredler
>>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>>> > Subject: RE: [OSPF] [Isis-wg] Mail regarding
>>> > draft-ietf-ospf-segment-routing-extensions
>>> >
>>> > Pushpasis -
>>> >
>>> > Inline.
>>> >
>>> > -----Original Message-----
>>> > From: Pushpasis Sarkar [mailto:psarkar@juniper.net]
>>> > Sent: Sunday, January 04, 2015 10:13 PM
>>> > To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak
>>> > (ppsenak); 
>>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>>> > Gredler
>>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>>> > Subject: Re: [OSPF] [Isis-wg] Mail regarding
>>> > draft-ietf-ospf-segment-routing-extensions
>>> >
>>> > Hi Les,
>>> >
>>> >
>>> > On 1/5/15, 11:23 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
>>> wrote:
>>> >
>>> >> Pushpasis -
>>> >>
>>> >> The key point is that the proposal does not have any lasting
>>> >> impact on traffic flow. A simple topology should suffice to
>>>illustrate this.
>>> >>
>>> >>
>>> >> A----B----C----D
>>> >>         |       |
>>> >>         E----F
>>> >>
>>> >> (All links have the same cost)
>>> >>
>>> >> Suppose we wish to have traffic entering at A flow along the path
>>> >> A-B-C-D
>>> >> - but if the link B---C fails we do NOT want traffic to take the
>>> >> path B--E--F--C.
>>> >>
>>> >> You propose to have C advertise an address with two node-sids -
>>> >> one which allows protection - call it C(P) - and one which does
>>> >> NOT allow protection - call it C(NP).
>>> > [Pushpasis] No. My proposal is for D to advertise two node sids, D1
>>> > with NP
>>> set to 0 and D2 with NP set to 1. Applications on that do not need B,
>>> or C to protect the A-B-C-D path will use D2. B and C will not
>>> install backup paths for D2. Other apps can use D1 as they are
>>> supposed to do otherwise. Wether to protect D1 or not is a local
>>>decision of B and C.
>>> > Hope I could clarify enough :)
>>> >
>>> > [Les:] Whether we talk about C or D doesn’t matter. As you point
>>> > out
>>> below the issue you are concerned with is the FIB update time on the
>>> intermediate nodes relative to the recomputation on the ingress node.
>>> >
>>> >>
>>> >> If the label stack specifies C(NP) - then while the link B--C is
>>> >> UP everything works as desired (primary path to C(NP) on Node B is
>>> >> via link B-C).
>>> >> However, when the link B--C goes down, the network will reconverge
>>> >> and in a modest amount of time the new primary path to C(NP) on
>>> >> node B will be via link B-E.
>>> > [Pushpasis] Yes agreed. But only applications on A will be
>>> > injecting traffic
>>> using D2. Once the B-C link-down event reaches router A will stop
>>>injecting traffic using D2. A path re-compute will be triggered on A.
>>> Yes I agree that if B converges D2 (not FRR) before A re-compute,
>>>there is still chance that some small amount of traffic is sent over
>>>A-B-E-F-C-D.
>>> >
>>> > [Les:] Well yes - the key point is that you cannot guarantee the
>>> > timing of
>>> when B (for example) will reconverge relative to when the ingress
>>>node  A decides to reroute/drop the D2 traffic. Given that B is closer
>>>to  the failure it is quite likely that B will respond more quickly
>>>than A
>>> - and of course there are many other variables which could affect the
>>>relative response time of A and B. So the sole benefit of what you
>>>propose seems to be that in some cases you MIGHT not send as much
>>>traffic to D2 via the undesired links.
>>> >
>>> > At this point I think you would do well to look at the existing
>>> > solutions - as
>>> well as Jeff's post on this thread which provides an excellent
>>> framework for thinking about solutions. We do have ways of addressing
>>> this problem and doing so far more robustly than what you are
>>> proposing. The ROI for what you propose is quite low. For my part I
>>> don’t think what you propose is a good idea.
>>> >
>>> >    Les
>>> >
>>> >>
>>> >> The existence of C(NP) therefore only affects traffic flow during
>>> >> the reconvergence period i.e. if we assume B did NOT install a
>>> >> repair path for C(NP) traffic will be dropped only until a new
>>> >> primary path is calculated. I don’t see the value in this.
>>> >>
>>> >> As a (somewhat dangerous) aside, the functionality you are looking
>>> >> for is more akin to "not-via" as defined in RFC 6981 - though I am
>>> >> quick to add that I am NOT proposing to pursue that. :-) But
>>> >> reading that RFC might give you more insight into why simply
>>> >> setting "don't protect" for a prefix isn't useful for the purpose
>>>you have in mind.
>>> >>
>>> >>  Les
>>> >>
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Pushpasis Sarkar [mailto:psarkar@juniper.net]
>>> >> Sent: Sunday, January 04, 2015 8:34 PM
>>> >> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak
>>> >> (ppsenak); 
>>> >> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >> draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>>> >> Gredler
>>> >> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >> Subject: Re: [OSPF] [Isis-wg] Mail regarding
>>> >> draft-ietf-ospf-segment-routing-extensions
>>> >>
>>> >> Hi Les,
>>> >>
>>> >> Please find comments inline..
>>> >>
>>> >> Authors,
>>> >>
>>> >> Here is my proposal. Please let me know if this sounds reasonable
>>> >> or
>>>not.
>>> >>
>>> >> - A new ŒNo-Potection-Required¹ or ŒNP¹ flag be added to the
>>> >> Prefix-SID Sub-TLV/TLV. Setting this flag means none of the
>>> >> transit routers should try to protect this node-segment.
>>> >> - Let nodes advertise two node-sid-index each (per
>>> >> address-family), one without and one with ŒNP¹ flag set. For
>>> >> node-sid advertised with ŒNP¹ flag 0, routers same behave the same
>>> >> way as today. But when they receive a node-sid with ŒNP¹ flag set,
>>> >> they avoid/skip finding a backup for that segment.
>>> >> - Finally ingress servers or TE-applications may use these
>>> >> 'node-sids with NP-flag set¹ for use cases where it is better to
>>> >> drop traffic on topology outages rather than diverting it to some
>>> >> other paths. For such cases ingress router or TE-applications
>>> >> should look for node-sids with ŒNP¹ flag set and not the regular
>>> >> node-sids. For all other normal use cases(including L3VPN/6VPE
>>> >> etc) traffic should be carried using node-sid without ŒNP‹flag set.
>>> >>
>>> >> Thanks and Regards,
>>> >> -Pushpasis
>>> >>
>>> >> On 1/5/15, 3:37 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
>>> wrote:
>>> >>
>>> >>> Pushpasis -
>>> >>>
>>> >>> I don't agree.
>>> >>>
>>> >>> The use of one node-sid vs another has nothing whatever to do
>>> >>> with the request Shraddha has made i.e. should we introduce a
>>> >>> flag indicating whether a particular prefix should be protected or
>>>not.
>>> >>> A node-sid only dictates what (intermediate) node traffic should
>>> >>> be sent to - not what
>>> >>> link(s) are used to reach that node.
>>> >> [Pushpasis] This is not about which links to take. It is about
>>> >> wether transit routers should try to protect the node-segment to
>>> >> the this node-sid or not. I think this opens up a lot many number
>>> >> of possibilities on the ingress router and TE controller-based
>>>applications.
>>> >>
>>> >>>
>>> >>> Adjacency-sids have a different semantic - they identify the link
>>> >>> over which traffic is to be forwarded. Identifying an
>>> >>> adjacency-sid as unprotected means traffic will NEVER flow over a
>>>different link.
>>> >>> There is no equivalent behavior w a node-sid - which is what this
>>> >>> discussion has been about.
>>> >> [Pushpasis] I am not trying to draw a parallel between this new
>>> >> flag and the ŒB¹ flag in Adj-Sid SubTlv. Like said before
>>> >>
>>> >>>
>>> >>>  Les
>>> >>>
>>> >>>
>>> >>> -----Original Message-----
>>> >>> From: Pushpasis Sarkar [mailto:psarkar@juniper.net]
>>> >>> Sent: Sunday, January 04, 2015 8:51 AM
>>> >>> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak
>>> >>> (ppsenak); 
>>> >>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>> Subject: Re: [OSPF] [Isis-wg] Mail regarding
>>> >>> draft-ietf-ospf-segment-routing-extensions
>>> >>>
>>> >>> Hi Les,
>>> >>>
>>> >>> I think the requirement Shraddha is referring is about the choice
>>> >>> of exact node-sid to use while constructing the label-stack for a
>>> >>> explicit-LSP on the ingress router, which will be typically done
>>> >>> after running some CSPF on the SPRING topology. And not the IGP
>>> >>> on ingress or transit routers.
>>> >>>
>>> >>> Thanks
>>> >>> -Pushpasis
>>> >>>
>>> >>> On 1/3/15, 3:10 AM, "Les Ginsberg (ginsberg)"
>>> >>> <ginsberg@cisco.com>
>>> wrote:
>>> >>>
>>> >>>> Shraddha -
>>> >>>>
>>> >>>> IGPs today do NOT perform constraint based SPFs - so I don't
>>> >>>> know why you believe that the primary SPF will meet a set of
>>> >>>> constraints that an LFA calculation will not. In fact , it is
>>> >>>> the opposite which is true because implementations today do
>>> >>>> support preferences in choosing LFAs based on various configured
>>> >>>> policy - something which is NOT done for primary SPF.
>>> >>>>
>>> >>>> If you want a certain class of traffic to avoid a subset of the
>>> >>>> links in the topology then you need to have a way of identifying
>>> >>>> the links (NOT the node addresses) and a way of calculating a
>>> >>>> path which only uses the links which meet the constraints of
>>> >>>> that class of
>>> service.
>>> >>>> Identifying a particular prefix as protected or unprotected
>>> >>>> won't achieve that.
>>> >>>>
>>> >>>>  Les
>>> >>>>
>>> >>>> -----Original Message-----
>>> >>>> From: Shraddha Hegde [mailto:shraddha@juniper.net]
>>> >>>> Sent: Friday, January 02, 2015 10:54 AM
>>> >>>> To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak);
>>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>> Subject: RE: [Isis-wg] Mail regarding
>>> >>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>
>>> >>>> Hi Les/Peter,
>>> >>>>
>>> >>>>     When reconvergence happens, the primary path will be
>>> >>>> calculated based on all constriants.
>>> >>>> This is not true with the protection path.Protection path is
>>> >>>> calculated locally (LFA/RLFA)  and does not consider the
>>> >>>> characteristics of the services running on that path.
>>> >>>> It's easier for some services to pick the unprotected path when
>>> >>>> the nature of the service is that it can be restarted  when
>>> >>>> there is a disconnection.
>>> >>>>
>>> >>>> Rgds
>>> >>>> Shraddha
>>> >>>> -----Original Message-----
>>> >>>> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
>>> >>>> Sent: Friday, January 02, 2015 10:06 PM
>>> >>>> To: Peter Psenak (ppsenak); Shraddha Hegde;
>>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>> Subject: RE: [Isis-wg] Mail regarding
>>> >>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>
>>> >>>> Peter -
>>> >>>>
>>> >>>> The requirement Shraddha specified was to not allow a particular
>>> >>>> class of service ("heavy bandwidth services" was the example
>>> >>>> provided) to use certain links in the topology. My point is that
>>> >>>> advertising a flag for a given prefix which says "do not
>>> >>>> calculate a repair path for this prefix"
>>> >>>> does not help achieve this. Once the network reconverges
>>> >>>> following the failure of one of the links on which "heavy
>>>bandwidth services"
>>> >>>> is allowed/preferred it is quite likely that the new best path
>>> >>>> will be over a link on which "heavy bandwidth services" is NOT
>>> >>>> allowed/preferred. This will happen whether you have the new
>>> >>>> flag or not - so the flag will have no lasting effect. It would
>>> >>>> only affect traffic flow during the brief period during which
>>> >>>> the network is reconverging.
>>> >>>>
>>> >>>> I think you and I are actually in agreement - I am simply
>>> >>>> sending a stronger negative message - not only do I think the
>>> >>>> flag is not useful
>>> >>>> - I think it does not achieve the goal Shraddha has in mind.
>>> >>>>
>>> >>>>  Les
>>> >>>>
>>> >>>>
>>> >>>> -----Original Message-----
>>> >>>> From: Peter Psenak (ppsenak)
>>> >>>> Sent: Friday, January 02, 2015 12:18 AM
>>> >>>> To: Les Ginsberg (ginsberg); Shraddha Hegde;
>>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>> Subject: Re: [Isis-wg] Mail regarding
>>> >>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>
>>> >>>> Hi Les,
>>> >>>>
>>> >>>> I believe the idea is not to exclude any particular link, it's
>>> >>>> actually much simpler - do not calculate backup for the prefix
>>> >>>> if the flag is set.
>>> >>>>
>>> >>>> I'm still not quite sure how useful above is, but technically it
>>> >>>> is possible.
>>> >>>>
>>> >>>> thanks,
>>> >>>> Peter
>>> >>>>
>>> >>>> On 12/30/14 17:22 , Les Ginsberg (ginsberg) wrote:
>>> >>>>> Shraddha -
>>> >>>>>
>>> >>>>> When performing a best path calculation whether a given link is
>>> >>>>> in the set of best paths (to be protectedED) or not (could be
>>> >>>>> used as a protectING path) is a function of the topology - not
>>>the link.
>>> >>>>> If there is a topology change it is quite likely that a given
>>> >>>>> link will change from being a protectED link to being a
>>> >>>>> protectING link (or vice versa).
>>> >>>>> So what you propose regarding node-SIDs would not work.
>>> >>>>>
>>> >>>>> In the use case you mention below if you don't want a certain
>>> >>>>> class of traffic to flow on a given link it requires a link
>>> >>>>> attribute which is persistent across topology changes. There
>>> >>>>> are ways to do that - using Adj-SIDs is one of them. But using
>>> >>>>> node-SIDs in the way you propose is NOT.
>>> >>>>>
>>> >>>>>    Les
>>> >>>>>
>>> >>>>> -----Original Message-----
>>> >>>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Shraddha
>>> >>>>> Hegde
>>> >>>>> Sent: Monday, December 29, 2014 10:12 PM
>>> >>>>> To: Peter Psenak (ppsenak);
>>> >>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>>> Subject: Re: [OSPF] [Isis-wg] Mail regarding
>>> >>>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>>
>>> >>>>> Peter,
>>> >>>>>
>>> >>>>>> The requirement here is to get an un-protected path for
>>> >>>>>> services which do not want to divert the traffic on protected
>>>path in any case.
>>> >>>>>
>>> >>>>>> can you give an example of such a service and a reasoning why
>>> >>>>>> such service would want to avoid local protection along the
>>>path?
>>> >>>>>
>>> >>>>> Heavy bandwidth services are potential candidates.  The network
>>> >>>>> is well planned and well provisioned for primary path but same
>>> >>>>> is not true for backup paths.
>>> >>>>> Diverting heavy bandwidth services along protection path can
>>> >>>>> disrupt the other services on that path, they are better-off
>>> >>>>> un-protected so that an event in the network Would result in
>>> >>>>> disconnection and a retry for such services.
>>> >>>>>
>>> >>>>> Rgds
>>> >>>>> Shraddha
>>> >>>>>
>>> >>>>> -----Original Message-----
>>> >>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>> >>>>> Sent: Monday, December 29, 2014 4:35 PM
>>> >>>>> To: Shraddha Hegde;
>>> >>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>>> Subject: Re: [Isis-wg] Mail regarding
>>> >>>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>>
>>> >>>>> Shraddha,
>>> >>>>>
>>> >>>>> On 12/29/14 10:06 , Shraddha Hegde wrote:
>>> >>>>>> Peter,
>>> >>>>>>
>>> >>>>>> The requirement here is to get an un-protected path for
>>> >>>>>> services which do not want to divert the traffic on protected
>>>path in any case.
>>> >>>>>
>>> >>>>> can you give an example of such a service and a reasoning why
>>> >>>>> such service would want to avoid local protection along the path?
>>> >>>>>
>>> >>>>> thanks,
>>> >>>>> Peter
>>> >>>>>
>>> >>>>>> So when the originator of node-sid signals un-protected path
>>> >>>>>> requirement, there is always an unprotected path.
>>> >>>>>>
>>> >>>>>> Regarding the protected path, it is the default behavior as it
>>> >>>>>> exists today. You get protection if it's available otherwise
>>> >>>>>> you don't get protection.
>>> >>>>>>
>>> >>>>>> In fact, you can have the new flag to say "NP flag" meaning
>>> >>>>>> non-protected flag which can be set for the unprotected path.
>>> >>>>>> By default it remains off and gives the behavior as it exists
>>>today.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Rgds
>>> >>>>>> Shraddha
>>> >>>>>>
>>> >>>>>> -----Original Message-----
>>> >>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>> >>>>>> Sent: Monday, December 29, 2014 2:26 PM
>>> >>>>>> To: Shraddha Hegde;
>>> >>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>>>> Subject: Re: [Isis-wg] Mail regarding
>>> >>>>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>>>
>>> >>>>>> Shraddha,
>>> >>>>>>
>>> >>>>>> I do not see how an originator of the node-sid can mandate a
>>> >>>>>> protection for the prefix on other routers. What if there is
>>> >>>>>> no backup available on a certain node along the path?
>>> >>>>>>
>>> >>>>>> The parallel with the B-flag in adj-sids is not right - in
>>> >>>>>> case of adj-sid the originator has the knowledge about the
>>> >>>>>> local adjacency protection and as such can signal it it it's
>>>LSA.
>>> >>>>>>
>>> >>>>>> thanks,
>>> >>>>>> Peter
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On 12/29/14 09:47 , Shraddha Hegde wrote:
>>> >>>>>>> Peter,
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> Pls see inline.
>>> >>>>>>>
>>> >>>>>>> Rgds
>>> >>>>>>> Shraddha
>>> >>>>>>>
>>> >>>>>>> -----Original Message-----
>>> >>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>> >>>>>>> Sent: Monday, December 29, 2014 2:02 PM
>>> >>>>>>> To: Shraddha Hegde;
>>> >>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>>>>> Subject: Re: [Isis-wg] Mail regarding
>>> >>>>>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>>>>
>>> >>>>>>> Shraddha,
>>> >>>>>>>
>>> >>>>>>> I do not see how an originator can set any flag regarding the
>>> >>>>>>> protection of the locally attached prefix.
>>> >>>>>>> <Shraddha> The originator advertises 2 node-sids. One with p
>>> >>>>>>> flag set and the other without the p-flag set.
>>> >>>>>>>
>>> >>>>>>>    It's all the routers on the path towards such prefix that
>>> >>>>>>> need to deal with the protection.
>>> >>>>>>> <Shraddha> The receiving nodes will download protected path 
>>> >>>>>>> for the node-sid with p-flag set and download Unprotected 
>>> >>>>>>> path for the node-sid with p-flag unset.
>>> >>>>>>>
>>> >>>>>>> Signaling anything from the originator seems useless.
>>> >>>>>>> <Shraddha>  For node-sids it's the others who need to build 
>>> >>>>>>> the forwarding plane but it's only the originator who can
>>>signal which of
>>> >>>>>>>                           Sid need to be built with 
>>> >>>>>>> protection and which not. Other routers on the path cannot 
>>> >>>>>>> signal this information.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>>
>>> >>>>>>> With this you have two paths for the node. One is protected 
>>> >>>>>>> and the other is unprotected. This meets the requirement of 
>>> >>>>>>> having an un-protected path.
>>> >>>>>>>
>>> >>>>>>> It's very much in parallel to B-flag in adj-sids. It is 
>>> >>>>>>> similar to advertising multiple adj-sids one with B-flag on 
>>> >>>>>>> and other with b-flag off , to get protected and unprotected
>>>Adj-sids.
>>> >>>>>>>
>>> >>>>>>> thanks,
>>> >>>>>>> Peter
>>> >>>>>>>
>>> >>>>>>> On 12/29/14 09:26 , Shraddha Hegde wrote:
>>> >>>>>>>> Yes.You are right.
>>> >>>>>>>>
>>> >>>>>>>> Lets say a prefix sid has a flag "p flag". If this is on it 
>>> >>>>>>>> means build a path and provide protection.
>>> >>>>>>>> If this is off it means build a path with no protection.
>>> >>>>>>>> The receivers of the prefix-sid will build forwarding plane 
>>> >>>>>>>> based on this flag.
>>> >>>>>>>>
>>> >>>>>>>> The applications building the paths will either use 
>>> >>>>>>>> prefix-sids with p flag on or off based on the need of the
>>>service.
>>> >>>>>>>> Rgds
>>> >>>>>>>> Shraddha
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> -----Original Message-----
>>> >>>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>> >>>>>>>> Sent: Monday, December 29, 2014 1:49 PM
>>> >>>>>>>> To: Shraddha Hegde;
>>> >>>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>>>>>> Subject: Re: [Isis-wg] Mail regarding 
>>> >>>>>>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>>>>>
>>> >>>>>>>> Shraddha,
>>> >>>>>>>>
>>> >>>>>>>> the problem is that the node that is advertising the 
>>> >>>>>>>> node-sid can not advertise any data regarding the protection 
>>> >>>>>>>> of such prefix, because the prefix is locally attached.
>>> >>>>>>>>
>>> >>>>>>>> thanks,
>>> >>>>>>>> Peter
>>> >>>>>>>>
>>> >>>>>>>> On 12/29/14 09:15 , Shraddha Hegde wrote:
>>> >>>>>>>>> Peter,
>>> >>>>>>>>>
>>> >>>>>>>>> If there is a service which has to use un-protected path 
>>> >>>>>>>>> and while  building such a path if the node-sids Need to be 
>>> >>>>>>>>> used (one reason  could be label stack compression) , then 
>>> >>>>>>>>> there has to be unprotected node-sid that this service can 
>>> >>>>>>>>> make use
>>> of.
>>> >>>>>>>>>
>>> >>>>>>>>> Prefix -sids could also be used to represent different 
>>> >>>>>>>>> service endpoints which makes it even more relevant to have 
>>> >>>>>>>>> A means
>>> of
>>> >>>>>>>>> representing  unprotected paths.
>>> >>>>>>>>>
>>> >>>>>>>>> Would be good to hear from others on this, especially
>>>operators.
>>> >>>>>>>>>
>>> >>>>>>>>> Rgds
>>> >>>>>>>>> Shraddha
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> -----Original Message-----
>>> >>>>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>> >>>>>>>>> Sent: Monday, December 29, 2014 1:35 PM
>>> >>>>>>>>> To: Shraddha Hegde;
>>> >>>>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>>> >>>>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>>> >>>>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>>> >>>>>>>>> Subject: Re: [Isis-wg] Mail regarding 
>>> >>>>>>>>> draft-ietf-ospf-segment-routing-extensions
>>> >>>>>>>>>
>>> >>>>>>>>> Shraddha,
>>> >>>>>>>>>
>>> >>>>>>>>> node-SID is advertised by the router for the prefix that is 
>>> >>>>>>>>> directly attached to it. Protection for such local prefix 
>>> >>>>>>>>> does not mean much.
>>> >>>>>>>>>
>>> >>>>>>>>> thanks,
>>> >>>>>>>>> Peter
>>> >>>>>>>>>
>>> >>>>>>>>> On 12/24/14 11:57 , Shraddha Hegde wrote:
>>> >>>>>>>>>> Authors,
>>> >>>>>>>>>> We have a "backup flag" in adjacency sid to indicate 
>>> >>>>>>>>>> whether the label is protected or not.
>>> >>>>>>>>>> Similarly. I think we need a flag in prefix-sid as well to 
>>> >>>>>>>>>> indicate whether the node-sid is to be protected or not.
>>> >>>>>>>>>> Any thoughts on this?
>>> >>>>>>>>>> Rgds
>>> >>>>>>>>>> Shraddha
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> _______________________________________________
>>> >>>>>>>>>> Isis-wg mailing list
>>> >>>>>>>>>> Isis-wg@ietf.org
>>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>> >>>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> .
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> .
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>> .
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> .
>>> >>>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> OSPF mailing list
>>> >>>>> OSPF@ietf.org
>>> >>>>> https://www.ietf.org/mailman/listinfo/ospf
>>> >>>>> .
>>> >>>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> OSPF mailing list
>>> >>>> OSPF@ietf.org
>>> >>>> https://www.ietf.org/mailman/listinfo/ospf
>>> >>>
>>> >>
>>> >
>>> > _______________________________________________
>>> > Isis-wg mailing list
>>> > Isis-wg@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/isis-wg
>>> >
>>> >
>>> __________________________________________________________
>>> ____________
>>> > ___________________________________________________
>>> >
>>> > Ce message et ses pieces jointes peuvent contenir des informations 
>>> > confidentielles ou privilegiees et ne doivent donc pas etre 
>>> > diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>>> > ce message par erreur, veuillez le signaler a l'expediteur et le 
>>> > detruire ainsi que les
>>> pieces jointes. Les messages electroniques etant susceptibles 
>>> d'alteration, Orange decline toute responsabilite si ce message a ete 
>>> altere, deforme ou falsifie. Merci.
>>> >
>>> > This message and its attachments may contain confidential or 
>>> > privileged information that may be protected by law; they should 
>>> > not be
>>> distributed, used or copied without authorisation.
>>> > If you have received this email in error, please notify the sender 
>>> > and delete
>>> this message and its attachments.
>>> > As emails may be altered, Orange is not liable for messages that 
>>> > have been
>>> modified, changed or falsified.
>>> > Thank you.
>>> >
>>> > _______________________________________________
>>> > Isis-wg mailing list
>>> > Isis-wg@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/isis-wg
>>> 
>>> 
>>> __________________________________________________________
>>> __________________________________________________________
>>> _____
>>> 
>>> Ce message et ses pieces jointes peuvent contenir des informations  
>>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,  
>>>exploites ou copies sans autorisation. Si vous avez recu ce message  
>>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi  
>>>que les pieces jointes. Les messages electroniques etant susceptibles  
>>>d'alteration, Orange decline toute responsabilite si ce message a ete 
>>>altere, deforme ou falsifie. Merci.
>>> 
>>> This message and its attachments may contain confidential or 
>>> privileged information that may be protected by law; they should not 
>>> be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender 
>>> and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have 
>>> been modified, changed or falsified.
>>> Thank you.
>>> 
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>>_______________________________________________________________________
>>___ _______________________________________________
>>
>>Ce message et ses pieces jointes peuvent contenir des informations 
>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>>exploites ou copies sans autorisation. Si vous avez recu ce message par 
>>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que 
>>les pieces jointes. Les messages electroniques etant susceptibles 
>>d'alteration, Orange decline toute responsabilite si ce message a ete 
>>altere, deforme ou falsifie. Merci.
>>
>>This message and its attachments may contain confidential or privileged 
>>information that may be protected by law; they should not be 
>>distributed, used or copied without authorisation.
>>If you have received this email in error, please notify the sender and 
>>delete this message and its attachments.
>>As emails may be altered, Orange is not liable for messages that have 
>>been modified, changed or falsified.
>>Thank you.
>>
>>_______________________________________________
>>OSPF mailing list
>>OSPF@ietf.org
>>https://www.ietf.org/mailman/listinfo/ospf
>
>
>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations 
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme 
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged 
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and 
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have 
>been modified, changed or falsified.
>Thank you.
>