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

From: Shraddha Hegde <[email-masked]>
Date: Wed, 24 Dec 2014 10:57:51 +0000

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Dec 2014 09:05:09 +0100

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
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 29 Dec 2014 08:15:09 +0000

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Dec 2014 09:19:04 +0100

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

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 29 Dec 2014 08:26:15 +0000

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.
>
> To: Shraddha Hegde; 
> [email-masked]; 
> [email-masked]
> Subject: Re: [Isis-wg] Mail regarding 
> draft-ietf-ospf-segment-routing-extensions
>
> Shraddha,
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Dec 2014 09:32:08 +0100

Shraddha,

I do not see how an originator can set any flag regarding the protection 
of the locally attached prefix. It's all the routers on the path towards 
such prefix that need to deal with the protection. Signaling anything 
from the originator seems useless.

thanks,
Peter

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 29 Dec 2014 08:47:17 +0000

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Dec 2014 09:56:29 +0100

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

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 29 Dec 2014 09:06:06 +0000

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

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

---

From: Rob Shakir <[email-masked]>
Date: Mon, 29 Dec 2014 09:07:59 +0000

Peter, Shraddha,

Primarily —  I don’t think that use of the ‘B’ flag in the Adj-SID implies that there MUST be a backup route installed, it merely indicates that the Adj-SID MAY be subject to re-routing (and hence strict placement on an adjacency may not be honoured during link failures).

For me, I’m unclear on what the practical use of not requesting backup for a {Node,Prefix}-SID could be — its very nature (“the shortest path to X” where X is a node/prefix) means that it is not well defined in terms of a route through the network, and hence is not well defined in terms of performance. This (to me) says that we cannot really rely on such a SID for performance-sensitive traffic, and hence must always be able to tolerate events such as FRR paths during protection.

The fact that AdjSID maps deterministically to a particular link, about which the calculating entity (PCE/iLER) can know details of, means that performance can be inferred - and hence strict affinity to that path (and/or failure when it is not available) is of utility.

Kind regards,
r.

> On 29 Dec 2014, at 08:56, Peter Psenak <[email-masked]> wrote:
> 
> Shraddha,
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 29 Dec 2014 09:33:29 +0000

Rob,

Pls see inline..

Rgds
Shraddha

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: Monday, December 29, 2014 2:38 PM
To: Peter Psenak; Shraddha Hegde
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Peter, Shraddha,

<Shraddha> Yes. I agree.

<Shraddha> It is likely that some application wants to use the node-sids when the strict path for performance sensitive traffic matches with that of the SPF  for some segments or for the entire path. 

Kind regards,
r.

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

---

From: Rob Shakir <[email-masked]>
Date: Mon, 29 Dec 2014 09:41:27 +0000

> On 29 Dec 2014, at 09:33, Shraddha Hegde <[email-masked]> wrote:
> 

There is nothing stopping it doing so, but it cannot deterministically say that the path will remain coherent with the one that it expects for multiple reasons:

1) Nodes along the path may select a subset of ECMPs, the performance of which may vary.
2) There may be topology changes (triggered by failure or not) which mean that the shortest-path may change.

Given that either of these can result in performance variance, it’s very likely (from a practical standpoint) that the traffic must be able to live with FRRs too - hence it being unclear to me that there’s a requirement for an ‘unprotected’ Node SID.

r.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 29 Dec 2014 10:12:20 +0000

Rob/Peter,

 I think today there are networks which run only on SPF paths and having a facility of "unprotected node-sid" is useful in my opinion 
Rather than not providing such a facility in the protocol at all.

I agree that if there is no sufficient interest on the list it can be dropped. 
I hope we can wait until the holiday season to get over to hear others opinion on this.

Rgds
Shraddha

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: Monday, December 29, 2014 3:11 PM
To: Shraddha Hegde
Cc: Peter Psenak; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

r.

---

From: Rob Shakir <[email-masked]>
Date: Mon, 29 Dec 2014 10:16:33 +0000

Shraddha,

Do you see deployments today where there are configured RSVP-TE FRR paths, but there are loose routed LSPs that request no FRR protection?

Such a datapoint would be interesting to figure out whether we currently have demand for this approach — but clearly this would not necessarily say anything about future requirements.

Cheers,
r.

> On 29 Dec 2014, at 10:12, Shraddha Hegde <[email-masked]> wrote:
> 
> Rob/Peter,
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 29 Dec 2014 12:04:53 +0100

Shraddha,

> 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

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 30 Dec 2014 06:11:32 +0000

Peter,

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

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 30 Dec 2014 16:22:01 +0000

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,

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,

thanks,
Peter

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf