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

From: Pushpasis Sarkar <[email-masked]>
Date: Sun, 4 Jan 2015 16:51:07 +0000

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)" <[email-masked]> 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:[email-masked]]
>Sent: Friday, January 02, 2015 10:54 AM
>To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak);
>[email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked]
>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:[email-masked]]
>Sent: Friday, January 02, 2015 10:06 PM
>To: Peter Psenak (ppsenak); Shraddha Hegde;
>[email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked]
>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;
>[email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked]
>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:[email-masked]] On Behalf Of Shraddha Hegde
>> Sent: Monday, December 29, 2014 10:12 PM
>> To: Peter Psenak (ppsenak);
>> [email-masked];
>> [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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:[email-masked]]
>> Sent: Monday, December 29, 2014 4:35 PM
>> To: Shraddha Hegde;
>> [email-masked];
>> [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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:[email-masked]]
>>> Sent: Monday, December 29, 2014 2:26 PM
>>> To: Shraddha Hegde;
>>> [email-masked];
>>> [email-masked]
>>> Cc: [email-masked]; [email-masked]
>>> 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:[email-masked]]
>>>> Sent: Monday, December 29, 2014 2:02 PM
>>>> To: Shraddha Hegde;
>>>> [email-masked];
>>>> [email-masked]
>>>> Cc: [email-masked]; [email-masked]
>>>> 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:[email-masked]]
>>>>> Sent: Monday, December 29, 2014 1:49 PM
>>>>> To: Shraddha Hegde;
>>>>> [email-masked];
>>>>> [email-masked]
>>>>> Cc: [email-masked]; [email-masked]
>>>>> 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:[email-masked]]
>>>>>> Sent: Monday, December 29, 2014 1:35 PM
>>>>>> To: Shraddha Hegde;
>>>>>> [email-masked];
>>>>>> [email-masked]
>>>>>> Cc: [email-masked]; [email-masked]
>>>>>> 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
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>> .
>>>>>
>>>>
>>>> .
>>>>
>>>
>>> .
>>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>> .
>>
>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 4 Jan 2015 22:07:19 +0000

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.

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.

   Les

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]] 
Sent: Sunday, January 04, 2015 8:51 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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)" <[email-masked]> 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
>
>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"
>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.
>
>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
>
>
>> 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).
>> 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
>>
>>> 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.
>>
>> 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.
>>> 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.
>>
>>> 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.
>>>
>>>protection for the prefix on other routers. What if there is no 
>>>backup available on a certain node along the path?
>>>
>>>> <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.
>>>>> 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
>>>>>
>>>>>
>>>>>> 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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 5 Jan 2015 04:34:01 +0000

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)" <[email-masked]> 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

>To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak);
>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
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 5 Jan 2015 05:27:21 +0000

Les,

I agree with the point you made that the requirement of not protecting certain services can be met today using the
LFA-manageability draft. Deploying the solution using LFA manageability requires that the 

1. Services be represented by different prefixes
2. Come up with a policy that makes sure no backup path is downloaded for the prefix
3. Configure  the policy in each node in the network.
4. Repeat the process whenever a new service with similar characteristic comes up

The advantage of having an unprotected path to each node is the ease of deployment.
LFA-manageability has its own advantage of fine tuning the backup paths and I am not denying that.
I am trying to say that for certain use-cases it is easy to have unprotected paths in the network for each node
And use those path for services that need such paths.

If someone wants to simply have a unprotected path for certain node and use it for all the services
Which don't need protection, that flexibility should be available in the protocol. 
That is the reason I am saying that we should have "No protection" flag in the prefix-SID.

Rgds
Shraddha	

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Monday, January 05, 2015 3:37 AM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Pushpasis -

I don't agree.

   Les

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, January 04, 2015 8:51 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

Thanks
-Pushpasis

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 5 Jan 2015 05:53:18 +0000

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

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.

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:[email-masked]] 
Sent: Sunday, January 04, 2015 8:34 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

Authors, 

- 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

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

>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

>>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.
>>
>>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.
>>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"
>>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.
>>
>>>that an event in the network Would result in disconnection and a 
>>>retry for such services.
>>>
>>> Rgds
>>> Shraddha
>>>
>>>>> <Shraddha> The receiving nodes will download protected path for 
>>>>>the node-sid with p-flag set and download Unprotected path for the 
>>>>>                            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.
>>>>>
>>>>>>>directly attached to it. Protection for such local prefix does 
>>>>>>>not mean much.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Peter
>>>>>>>
>>>>>>>> We have a "backup flag" in adjacency sid to indicate whether 
>>>>>>>> the label is protected or not.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 5 Jan 2015 06:00:38 +0000

Shraddha -

Inline.

-----Original Message-----
From: Shraddha Hegde [mailto:[email-masked]] 
Sent: Sunday, January 04, 2015 9:27 PM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Les,

I agree with the point you made that the requirement of not protecting certain services can be met today using the LFA-manageability draft. 

[Les:] I did not say that. :-)

Deploying the solution using LFA manageability requires that the 

1. Services be represented by different prefixes 2. Come up with a policy that makes sure no backup path is downloaded for the prefix 3. Configure  the policy in each node in the network.
4. Repeat the process whenever a new service with similar characteristic comes up

[Les:] Please read my reply to Pushpasis. Having an unprotected path is no guarantee that traffic will not flow on what would have been the protectING path (if a node had installed one) after reconvergence. So your proposal only impacts traffic flow for a brief period.

   Les

LFA-manageability has its own advantage of fine tuning the backup paths and I am not denying that.
I am trying to say that for certain use-cases it is easy to have unprotected paths in the network for each node And use those path for services that need such paths.

If someone wants to simply have a unprotected path for certain node and use it for all the services Which don't need protection, that flexibility should be available in the protocol. 
That is the reason I am saying that we should have "No protection" flag in the prefix-SID.

Rgds
Shraddha	

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, January 05, 2015 3:37 AM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Pushpasis -

I don't agree.

   Les

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, January 04, 2015 8:51 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

Thanks
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 5 Jan 2015 06:13:30 +0000

Hi Les,

On 1/5/15, 11:23 AM, "Les Ginsberg (ginsberg)" <[email-masked]> 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
>
>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 :)

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

>
>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
>
>
>
>[email-masked]; Hannes Gredler
>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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 5 Jan 2015 06:16:35 +0000

Some typo correction inline..

On 1/5/15, 11:43 AM, "Pushpasis Sarkar" <[email-masked]> wrote:

>NP set to 0 and D2 with NP set to 1. Applications on route A that do not
>need B,

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 5 Jan 2015 06:37:10 +0000

Pushpasis -

Inline.

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]] 
Sent: Sunday, January 04, 2015 10:13 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
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)" <[email-masked]> wrote:

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

>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

>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
>
>
>
>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.
>cases(including L3VPN/6VPE etc) traffic should be carried using 
>node-sid without ŒNP‹flag set.
>
>Thanks and Regards,
>-Pushpasis
>
>>whether a particular prefix should be protected or not. A node-sid 
>>only dictates what (intermediate) node traffic should be sent to - not 
>>what
>node-sid or not. I think this opens up a lot many number of 
>possibilities on the ingress router and TE controller-based applications.
>
>>
>[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
>>
>>
>>running some CSPF on the SPRING topology. And not the IGP on ingress 
>>or transit routers.
>>
>>Thanks
>>-Pushpasis
>>
>>>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 
>>>>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
>>>>
>>>> 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
>>>>
>>>>>>     It's all the routers on the path towards such prefix that 
>>>>>>need to deal with the protection.
>>>>>> 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 
>>>>>>> Lets say a prefix sid has a flag "p flag". If this is on it 
>>>>>>>means build a path and provide protection.
>>>>>>> The receivers of the prefix-sid will build forwarding plane 
>>>>>>>based on this flag.
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>>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.
>>>>>>>>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 5 Jan 2015 08:48:44 +0000

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:[email-masked]] 
Sent: Monday, January 05, 2015 12:07 PM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Pushpasis -

Inline.

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, January 04, 2015 10:13 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 5 Jan 2015 15:58:41 +0000

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:[email-masked]] 
Sent: Monday, January 05, 2015 12:49 AM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Les,

 --------G-------
|                     |
A----B----C----D
        |       |
          E----F

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:[email-masked]]
Sent: Monday, January 05, 2015 12:07 PM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Pushpasis -

Inline.

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, January 04, 2015 10:13 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

    Les

---

From: <[email-masked]>
Date: Wed, 7 Jan 2015 14:44:17 +0000

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, January 05, 2015 16:59
To: Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha -

   Les

-----Original Message-----
From: Shraddha Hegde [mailto:[email-masked]]
Sent: Monday, January 05, 2015 12:49 AM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Les,

 --------G-------
|                     |
A----B----C----D
        |       |
          E----F

Rgds
Shraddha

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, January 05, 2015 12:07 PM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Pushpasis -

Inline.

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, January 04, 2015 10:13 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler
Cc: [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

    Les

_________________________________________________________________________________________________________________________

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.

---

From: Rob Shakir <[email-masked]>
Date: Thu, 8 Jan 2015 04:52:07 -0500

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, [email-masked] wrote:
> 
> Hi,
>

---

From: <[email-masked]>
Date: Thu, 8 Jan 2015 11:12:24 +0000

-----Original Message-----
From: LITKOWSKI Stephane SCE/IBNF 
Sent: Thursday, January 08, 2015 12:10
To: 'Rob Shakir'
Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] [OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Rob, 

Please find inline comments

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]]
Sent: Thursday, January 08, 2015 10:52
To: LITKOWSKI Stephane SCE/IBNF
Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions

Stephane,

      A -- B -- C -- D -- E
                |        /
                --- Q ---

[SLI] Completely agree, but to prevent the transient period, you can use OAM on top to bring down the LSP at ingress and let it down until ingress or controller has converged an provided a new stack.

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.
[SLI] In case of architecture with disjoint path and end to end protection , local protection may prevent the end to end protection to be activated. 

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.
	[SLI] It's fine for dual plane network, but for flat networks with SRLG at transmission level, it's not so easy.

	* does the application prefer losing an entire path to having some risk of the services being shared fate until the re-optimisation? 
	[SLI] It's not the question here ... in case of disjoint path and end to end protection, yes , the application prefers to loose completely a path and switch to another. For some other applications where a single LSP is available, for sure, there is no issue with transient situations that are not completely optimal.

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.
[SLI] There is the case today with RSVP-TE, so for sure, use case applied to SR also.

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. 
[SLI] Yes that's an approach, but this will create more states in the network. Drawback or not, I don't know today.

Cheers,
r.

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 4 Jan 2015 22:54:30 +0000

Hi,

I¹ll try to address some of the questions discussed.

I think it would be really helpful to distinguish between transport and
service protection, as well as path (at ingress) vs node/link (local)
protection
Wrt manageability of LFA, it also applies to rLFA/TI-LFA - I¹d recommend
to look into draft-ietf-rtgwg-lfa-manageability which has recently
completed wglc in rtgwg.
As you could see and as Les has mentioned - it is LFA computation which
could include constrains and provide a backup path which meets particular
constrains and since it is per-prefix (in most implementations) traffic
towards different destinations could take different backup paths when
primary fails.

Let¹s leave multidomain path protection aside

Path protection - backup path is provided by an entity (CSPF/PCE) which
has full visibility within the domain it is calculated for. Usual
requirement for such path is that it has to be disjoined from the primary,
so failure of the primary path would not affect the backup path, it is up
to ingress node (local policy) to provide different backup paths for
different FEC¹s in case of failure of the primary path. The path could
have mix of node-sid and adj-sid depending on how the path is constructed.

Local protection - as the name suggests - it is local to the node it
provide protection at, providing protection for a particular destination
is a local decision (same as done today for LFA), I don¹t see a need for a
flag local to the node.
Might you want particular destination not to be protected (or to be
protected over a particular backup) it is up to the node protection it
taking place at to do so(local).

Cheers,
Jeff

-----Original Message-----
From: "Les Ginsberg   (ginsberg)" <[email-masked]>
Date: Sunday, January 4, 2015 at 2:07 PM
To: Pushpasis Sarkar <[email-masked]>, Shraddha Hegde
<[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OSPF] [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions

---

From: Mitchell Erblich <[email-masked]>
Date: Sun, 4 Jan 2015 23:05:39 -0800

Les Ginsberg et al, , ,

	First, I only really monitor this alias, as I am a Kernel Engineer, 
	Thus, if I am a mile off track then please don’t stone me…

Summary:
	Isn’t this a local routing decision that needs to be made by router B..??? Or C in the reverse path? Then why do we need protection from B if the B-C link goes down?
	Can’t B just make a local routing decision especially if B is a DR (assuming OSPF), without notifying anyone… other than use me to get to routers “C” & “D”. Yes, assuming that no DR-others or systems reside off the routers E & F?  Yes, simple case…
	Then do you MUST know which path/link B is using?

	…
Detail:
	But, assuming that that B-C path has a high cost, or is a slow link, or overloaded, or over-subscribed, or equiv versus taking the path B-E-F-D, or taking NONE

	Then why not allow:

			Normally…
			* two paths exist and load can be balanced or  just one path preferred over the other path..
`			* a router can explicity specify the B-E-F-C path , say simply … pinging the path/links one hop at a time,, then why invalidate it just because of convergence?
		
			Allowing that both path’s to simultaneously exist,  aren’t you then 0’ering out the convergence time to switch and identify one path as primary..
				the assumption is that B makes the routing decision and doesn’t really have to advertise if a local route goes down… (say advertise its path to D as a worse case..)
																						Why worse case? don’t want the rexmit algors to kick in early..
			And we follow this logic then ,,, if one is primary whether the link of B-C or B-E-F-C or NONE COULD be a local routing decision made by B…
			No, I do not assume that the reverse path is identical to the forward path…

		So, the question to myself is whether and how B either transparently advertises its path to D, or whether it explicitly/implicity advertises one or BOTH paths.. on a multually exclusive…

		If a convergence is the deciding factor, and both alternative paths/routes flap, then aren’t you effectively preventing the route to router “D”  or think that you can reach D because of recv’ing pkts from D..
		Normally don’t advertise a route unless it is a stable route … Right?

		So, I would think a method is needed to allow router B, how/if it wishes to advertise its localized routes, but not force B to switch advertising and routing back a forth…

		Mitchell Erblich

---

From: <[email-masked]>
Date: Thu, 8 Jan 2015 11:09:42 +0000

Hi Rob, 

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: Thursday, January 08, 2015 10:52
To: LITKOWSKI Stephane SCE/IBNF
Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions

Stephane,

      A -- B -- C -- D -- E
                |        /
                --- Q ---

Cheers,
r.

> To: Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); 
> Subject: Re: [Isis-wg] [OSPF] Mail regarding 
> 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/
> To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak (ppsenak); 
> Subject: RE: [OSPF] [Isis-wg] Mail regarding 
> To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); 
> Subject: RE: [OSPF] [Isis-wg] Mail regarding 
>> 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
>> 
>> 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.
>> 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
>> 
>> 
>> 
>> - 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.
>> 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
>> 
>>> 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
>>> 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.
>>> 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
>>> 
>>>> 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.
>>>> advertising a flag for a given prefix which says "do not calculate 
>>>> a repair path for this prefix"
>>>> 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.
>>>> 
>>>>> 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).
>>>>> 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
>>>>> 
>>>>>> can you give an example of such a service and a reasoning why 
>>>>>> such service would want to avoid local protection 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
>>>>>> 
>>>>>> 
>>>>>>> <Shraddha> The originator advertises 2 node-sids. One with p 
>>>>>>> flag set and the other without the p-flag set.
>>>>>>> 
>>>>>>> the node-sid with p-flag set and download Unprotected path for 
>>>>>>> the node-sid with p-flag unset.
>>>>>>> 
>>>>>>> the other is unprotected. This meets the requirement of having 
>>>>>>> an un-protected path.
>>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>>>> (one reason  could be label stack compression) , then there 
>>>>>>>>> has to be unprotected node-sid that this service can make use of.
>>>>>>>>> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: <[email-masked]>
Date: Mon, 12 Jan 2015 08:13:34 +0000

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 ?

Best regards,

Stephane

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: Thursday, January 08, 2015 10:52
To: LITKOWSKI Stephane SCE/IBNF
Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak); [email-masked]; [email-masked]; Hannes Gredler; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] [OSPF] Mail regarding draft-ietf-ospf-segment-routing-extensions

Stephane,

      A -- B -- C -- D -- E
                |        /
                --- Q ---

Cheers,
r.

---

From: <[email-masked]>
Date: Mon, 12 Jan 2015 08:48:43 +0000

Hi,

2 cents inlined

> From: OSPF [mailto:[email-masked]] On Behalf Of > [email-masked]
> 
> 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.
> 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 :
> - 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

> Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter Psenak
> (ppsenak); [email-masked];
> [email-masked]; Hannes Gredler;
> [email-masked]; [email-masked]
> 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.
> 
> 	* 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.
> 
> > 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
> >
> > 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.
> > 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
> >
> > [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.
> > [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.
> >
> >>
> > [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
> >
> >>
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.

---

From: <[email-masked]>
Date: Mon, 12 Jan 2015 08:54:54 +0000

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: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi,

2 cents inlined

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

/Bruno

> Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter 
> Psenak (ppsenak); 
> [email-masked]; Hannes 
> Gredler; [email-masked]; [email-masked]
> 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.
> 
> 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.
> 
> > I'm coming into this long thread and I tried to read all the 
> > exchange but I may be missed some lines :)
> >
> MUST NOT be protected (SDH like services). It would be good to 
> reproduce the same thing with SR-TE.
> >
> 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).
> for a TE tunnel (due to label stack depth), so we need to introduce 
> stack compression using SPT segments and node-SID.
> 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.
> >
> 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 :
> 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).
> >
> (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
> >
> > As Jeff has already mentioned, the case you are concerned about can 
> > be handled using LFA selection strategies discussed in 
> > And it is a far better solution since it allows the traffic of 
> > interest to be
> protected => less traffic interruption.
> >
> >   Les
> >
> >
> >
> nature of the service is such that it can be disconnected and 
> reconnected without impacting the end user of the service.
> >
> >
> if that is not the case then the service will remain down Irrespective 
> of the technology used.
> >
> >
> > Rgds
> > Shraddha
> >
> >> - but if the link B---C fails we do NOT want traffic to take the 
> >> path B--E--F--C.
> >>
> >> which allows protection - call it C(P) - and one which does NOT 
> >> allow protection - call it C(NP).
> set to 0 and D2 with NP set to 1. Applications on that do not need B, 
> >> and in a modest amount of time the new primary path to C(NP) on 
> >> node B will be via link B-E.
> > 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.
> >
> 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.
> >
> 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.
> >>
> >> 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
> >>
> >>
> >>
> >> 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
> >>
> >>> 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
> >> [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.
> >>
> >>>
> >>> over which traffic is to be forwarded. Identifying an 
> >>> adjacency-sid as unprotected means traffic will NEVER flow over a different link.
> >> [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
> >>>
> >>>
> >>> I think the requirement Shraddha is referring is about the choice 
> >>> of exact node-sid to use while constructing the label-stack for a 
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>     When reconvergence happens, the primary path will be 
> >>>> calculated based on all constriants.
> >>>> 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
> >>>> 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 
> >>>> 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'm still not quite sure how useful above is, but technically it 
> >>>> is possible.
> >>>>
> >>>> thanks,
> >>>> Peter
> >>>>
> >>>>> 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).
> >>>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>>> 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.
> >>>>>
> >>>>>> exists today. You get protection if it's available otherwise 
> >>>>>> you don't get 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.
> >>>>>>>
> >>>>>>> <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
> >>>>>>> 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
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>> directly attached to it. Protection for such local prefix 
> >>>>>>>>> does not mean much.
> >>>>>>>>>
> >>>>>>>>> thanks,
> >>>>>>>>> Peter
> >>>>>>>>>
> >>>>>>>>>> We have a "backup flag" in adjacency sid to indicate 
> >>>>>>>>>> whether the label is protected or not.
> ____________
> > 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.
> >
> > 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.
> >
> 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.
> 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Mon, 12 Jan 2015 10:41:03 +0000

> From: LITKOWSKI Stephane SCE/IBNF > Sent: Monday, January 12, 2015 9:55 AM

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

That's the reason why I said that you may also need to use adj-SID in combination (in order to lock on the nominal path for the nodes where the backup path has the same number of hops).

For sure, you can always find or create a topology for which you may need multiple adj-SID.  Courtesy of RFC 6571, I picked its worst topology on that respect:

                                     P
                                    . .
                                  x.   .x+e
                                  .     .
                                 C1--c--C2
                                 |\   /|
                                  | \ / |
                              d/u |  \  | d/u
                                  | / \ |
                                  |/   \|
                                 A1--a--A2
                                  |\   /|
                                  | \ / |
                               d/u|  \  |d/u
                                  | / \ |
                                  |/   \|
                                 E1     E2

                            Figure 3: Full Mesh

P is destination in the “cloud”.

1)      Let’s assume that from C1 to P the backup path has more hops.

In such case, from E1 to P we have to add 1 Adj_SID and we have a 2 labels stack: A1C1, P

2)      Let’s assume that “P” is also in the edge and that the network is symmetric. i.e. P advertised by E1’ which is attached to the network just like E1. i.e. we have a C1’ and A1’ layers. That’s a pretty bad case since all layers of the network have 2 paths to the destination with the same number of hops but it’s still realistic.

In this specific case, we would only use Adj-SID; A1C1, C1C1’, C1’A1’, A1’P

/Bruno

> Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-ospf-segment-routing-<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-ietf-isis-segment-routing-<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

> Subject: RE: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-

> extensions

> > From: OSPF [mailto:[email-masked]] On Behalf Of >

> > [email-masked]<mailto:[email-masked]>

> > constraints. So there may be transient situations where the path does not

> fit constraints anymore.

> > We need to solve this use case and we need to find another elegant,

> > simple and scalable solution for this.

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

> > [email-masked]<mailto:[email-masked]>;

> > [email-masked]<mailto:[email-masked]>; Hannes

> > Gredler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > stops using the label stack], then there’s little problem of having the traffic

> go via C-Q-E during protection.

> > case, using an alternative SPF path for the Node-SID is actually not a

> problem for disjointness.

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

> > > On 7 Jan 2015, at 09:44, [email-masked]<mailto:[email-masked]> wrote:

> > > I think the point from Shradda is valuable in case of Traffic

> > > Engineering with

> > > Today in TE networks, we are selling some disjoints paths to

> > > customer that

> > > Now, current encoding permits to advertise that a specific Adj-SID

> > > is

> > > We pretty know that it would not be possible in all case to use only

> > > Adj-SID

> > > So to reply on Rob's comment, on RSVP-TE tunnels with looses hops

> > > that

> > > If we look at a network, where TE is managed by a central

> > > controller, how

> > >      * Use two SIDs attached to the same prefix and add a flag to

> > > prevent

> > flag will permit to exclude some prefixes for protection (overriding local

> policy).

> > controller to use only "non protection tag" prefixes to compress non

> protected path.

> > > From: Isis-wg [mailto:[email-masked]] On Behalf Of Les

> > > Ginsberg (ginsberg)

> > > [email-masked]<mailto:[email-masked]>;

> > > [email-masked]<mailto:[email-masked]>; Hannes

> > > Gredler

> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak

> > > (ppsenak);

> > > [email-masked]<mailto:[email-masked]>;

> > > [email-masked]<mailto:[email-masked]>; Hannes

> > > Gredler

> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > Pls consider a case when the post convergence path goes through a

> > different node and is well provisioned.

> > > In this case it makes sense to simply avoid protection for the

> > > service as the

> > > The post convergence paths need to be provisioned at least for one

> > > failure

> > > [email-masked]<mailto:[email-masked]>;

> > > [email-masked]<mailto:[email-masked]>; Hannes

> > > Gredler

> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > [email-masked]<mailto:[email-masked]>;

> > > [email-masked]<mailto:[email-masked]>; Hannes

> > > Gredler

> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > > On 1/5/15, 11:23 AM, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>

> > wrote:

> > >> Suppose we wish to have traffic entering at A flow along the path

> > >> A-B-C-D

> > > [Pushpasis] No. My proposal is for D to advertise two node sids, D1

> > > with NP

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

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

> > >> setting "don't protect" for a prefix isn't useful for the purpose you have

> in mind.

> > >> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak

> > >> (ppsenak);

> > >> [email-masked]<mailto:[email-masked]>;

> > >> [email-masked]<mailto:[email-masked]>; Hannes

> > >> Gredler

> > >> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >> Here is my proposal. Please let me know if this sounds reasonable or

> not.

> > >> On 1/5/15, 3:37 AM, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>

> > wrote:

> > >> of possibilities on the ingress router and TE controller-based

> applications.

> > >>> adjacency-sid as unprotected means traffic will NEVER flow over a

> different link.

> > >>> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak

> > >>> (ppsenak);

> > >>> [email-masked]<mailto:[email-masked]>;

> > >>> [email-masked]<mailto:[email-masked]>

> > >>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>> On 1/3/15, 3:10 AM, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>

> > wrote:

> > >>>> Identifying a particular prefix as protected or unprotected won't

> > >>>> achieve that.

> > >>>> [email-masked]<mailto:[email-masked]>;

> > >>>> [email-masked]<mailto:[email-masked]>

> > >>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>> [email-masked]<mailto:[email-masked]>;

> > >>>> [email-masked]<mailto:[email-masked]>

> > >>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>> following the failure of one of the links on which "heavy bandwidth

> services"

> > >>>> [email-masked]<mailto:[email-masked]>;

> > >>>> [email-masked]<mailto:[email-masked]>

> > >>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>> actually much simpler - do not calculate backup for the prefix if

> > >>>> the flag is set.

> > >>>>> used as a protectING path) is a function of the topology - not the

> link.

> > >>>>> From: OSPF [mailto:[email-masked]] On Behalf Of Shraddha

> > >>>>> Hegde

> > >>>>> [email-masked]<mailto:[email-masked]>;

> > >>>>> [email-masked]<mailto:[email-masked]>

> > >>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>>>> services which do not want to divert the traffic on protected path

> in any case.

> > >>>>> [email-masked]<mailto:[email-masked]>;

> > >>>>> [email-masked]<mailto:[email-masked]>

> > >>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>>>> services which do not want to divert the traffic on protected path

> in any case.

> > >>>>>> [email-masked]<mailto:[email-masked]>;

> > >>>>>> [email-masked]<mailto:[email-masked]>

> > >>>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>>>>> [email-masked]<mailto:[email-masked]>;

> > >>>>>>> [email-masked]<mailto:[email-masked]>

> > >>>>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>>>>> the forwarding plane but it's only the originator who can signal

> which of

> > >>>>>>> and which not. Other routers on the path cannot signal this

> > >>>>>>> information.

> > >>>>>>> and other with b-flag off , to get protected and unprotected Adj-

> sids.

> > >>>>>>>> prefix-sids with p flag on or off based on the need of the

> > >>>>>>>> [email-masked]<mailto:[email-masked]>;

> > >>>>>>>> [email-masked]<mailto:[email-masked]>

> > >>>>>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>>>>>>> Would be good to hear from others on this, especially

> operators.

> > >>>>>>>>> [email-masked]<mailto:[email-masked]>;

> > >>>>>>>>> [email-masked]<mailto:[email-masked]>

> > >>>>>>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > >>>>>>>>>> [email-masked]<mailto:[email-masked]>

> > >>>>> [email-masked]<mailto:[email-masked]>

> > >>>> [email-masked]<mailto:[email-masked]>

> > > [email-masked]<mailto:[email-masked]>

> > > be

> > > [email-masked]<mailto:[email-masked]>

> > d'alteration, Orange decline toute responsabilite si ce message a ete altere,

> deforme ou falsifie. Merci.

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

> > [email-masked]<mailto:[email-masked]>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 12 Jan 2015 10:44:31 +0000

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, "[email-masked]"
<[email-masked]> 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.
>
>Cc: [email-masked];
>[email-masked]; [email-masked];
>> [email-masked]
>> 
>> Hi,
>> 
>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
>> 
>> 
>__________________________________________________________________________
>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,
>information that may be protected by law;

---

From: <[email-masked]>
Date: Mon, 12 Jan 2015 10:53:40 +0000

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:[email-masked]] 
Sent: Monday, January 12, 2015 11:45
To: LITKOWSKI Stephane SCE/IBNF; DECRAENE Bruno IMT/OLN; Rob Shakir
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

On 12/01/15 09:54, "[email-masked]"
<[email-masked]> wrote:

>defacto have more hops. Metric of backup path could be higher but 
>number of hops equal or smaller.
>
>[email-masked]; 
>> 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.
>> 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.
>> 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.
>> 
>> not use C-Q-E during the failure - because the service is always 
>> going to non-conformant to the performance requirement?
>> 
>>stops using the label stack], then there’s little problem of having 
>>the traffic go via C-Q-E during protection.
>> 
>> protection really exists ..., in case of LFA protection , there may 
>> be no FRR path for this adj-SID despite of the protection flag set).
>> if that is not the case then the service will remain down 
>> >> 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
>> >>
>> >> 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).
>> 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.
>> >> 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).
>> 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
>> >> 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.
>> >> 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
>> >>
>> >>> 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.
>> >>> 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)" 
>> >>> <[email-masked]>
>> 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.
>> >>>>
>> >>>> path which only uses the links which meet the constraints of 
>> >>>> that class of
>> service.
>> >>>> the nature of the service is that it can be restarted  when 
>> >>>> there is a disconnection.
>> >>>>
>> >>>> Rgds
>> >>>> Shraddha
>> >>>> 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
>> >>>>> attribute which is persistent across topology changes. There 
>> >>>>> are ways to do that - using Adj-SIDs is one of them. But using 
>> >>>>>> 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
>> >>>>>>
>> >>>>>>
>> >>>>>>> for the node-sid with p-flag set and download Unprotected 
>> >>>>>>> path for the node-sid with p-flag unset.
>> >>>>>>>
>> >>>>>>>                           Sid need to be built with 
>> >>>>>>> protection and which not. Other routers on the path cannot 
>> >>>>>>> signal this information.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>>> 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
>> >>>>>>>>
>> >>>>>>>>> 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.
>> >>>>>>>>>
>> and delete this message and its attachments.
>_______________________________________________________________________
>___ _______________________________________________
>
>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 
>information that may be protected by law; they should not be

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 12 Jan 2015 15:13:12 +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, "[email-masked]"
<[email-masked]> wrote:

>Cc: [email-masked]; [email-masked];
>[email-masked];