Hi Les,
I believe the idea is not to exclude any particular link, it's actually
much simpler - do not calculate backup for the prefix if the flag is set.
I'm still not quite sure how useful above is, but technically it is
possible.
thanks,
Peter
On 12/30/14 17:22 , Les Ginsberg (ginsberg) wrote:
Shraddha -
When performing a best path calculation whether a given link is in the set of
best paths (to be protectedED) or not (could be used as a protectING path) is a
function of the topology - not the link. If there is a topology change it is
quite likely that a given link will change from being a protectED link to being
a protectING link (or vice versa). So what you propose regarding node-SIDs
would not work.
In the use case you mention below if you don't want a certain class of traffic
to flow on a given link it requires a link attribute which is persistent across
topology changes. There are ways to do that - using Adj-SIDs is one of them.
But using node-SIDs in the way you propose is NOT.
Les
-----Original Message-----
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Monday, December 29, 2014 10:12 PM
To: Peter Psenak (ppsenak);
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions
Peter,
The requirement here is to get an un-protected path for services which do not
want to divert the traffic on protected path in any case.
can you give an example of such a service and a reasoning why such service
would want to avoid local protection along the path?
Heavy bandwidth services are potential candidates. The network is well planned
and well provisioned for primary path but same is not true for backup paths.
Diverting heavy bandwidth services along protection path can disrupt the other
services on that path, they are better-off un-protected so that an event in the
network Would result in disconnection and a retry for such services.
Rgds
Shraddha
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, December 29, 2014 4:35 PM
To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
Shraddha,
On 12/29/14 10:06 , Shraddha Hegde wrote:
Peter,
The requirement here is to get an un-protected path for services which do not
want to divert the traffic on protected path in any case.
can you give an example of such a service and a reasoning why such service
would want to avoid local protection along the path?
thanks,
Peter
So when the originator of node-sid signals un-protected path requirement, there
is always an unprotected path.
Regarding the protected path, it is the default behavior as it exists today.
You get protection if it's available otherwise you don't get protection.
In fact, you can have the new flag to say "NP flag" meaning non-protected flag
which can be set for the unprotected path.
By default it remains off and gives the behavior as it exists today.
Rgds
Shraddha
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, December 29, 2014 2:26 PM
To: Shraddha Hegde;
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions
Shraddha,
I do not see how an originator of the node-sid can mandate a protection for the
prefix on other routers. What if there is no backup available on a certain node
along the path?
The parallel with the B-flag in adj-sids is not right - in case of adj-sid the
originator has the knowledge about the local adjacency protection and as such
can signal it it it's LSA.
thanks,
Peter
On 12/29/14 09:47 , Shraddha Hegde wrote:
Peter,
Pls see inline.
Rgds
Shraddha
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, December 29, 2014 2:02 PM
To: Shraddha Hegde;
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions
Shraddha,
I do not see how an originator can set any flag regarding the protection of the
locally attached prefix.
<Shraddha> The originator advertises 2 node-sids. One with p flag set and the
other without the p-flag set.
It's all the routers on the path towards such prefix that need to deal with
the protection.
<Shraddha> The receiving nodes will download protected path for the
node-sid with p-flag set and download Unprotected path for the node-sid with
p-flag unset.
Signaling anything from the originator seems useless.
<Shraddha> For node-sids it's the others who need to build the forwarding
plane but it's only the originator who can signal which of
Sid need to be built with protection and which not.
Other routers on the path cannot signal this information.
With this you have two paths for the node. One is protected and the other is
unprotected. This meets the requirement of having an un-protected path.
It's very much in parallel to B-flag in adj-sids. It is similar to
advertising multiple adj-sids one with B-flag on and other with b-flag off , to
get protected and unprotected Adj-sids.
thanks,
Peter
On 12/29/14 09:26 , Shraddha Hegde wrote:
Yes.You are right.
Lets say a prefix sid has a flag "p flag". If this is on it means build a path
and provide protection.
If this is off it means build a path with no protection.
The receivers of the prefix-sid will build forwarding plane based on this flag.
The applications building the paths will either use prefix-sids with p flag on
or off based on the need of the service.
Rgds
Shraddha
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, December 29, 2014 1:49 PM
To: Shraddha Hegde;
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions
Shraddha,
the problem is that the node that is advertising the node-sid can not advertise
any data regarding the protection of such prefix, because the prefix is locally
attached.
thanks,
Peter
On 12/29/14 09:15 , Shraddha Hegde wrote:
Peter,
If there is a service which has to use un-protected path and while
building such a path if the node-sids Need to be used (one reason
could be label stack compression) , then there has to be unprotected node-sid
that this service can make use of.
Prefix -sids could also be used to represent different service
endpoints which makes it even more relevant to have A means of representing
unprotected paths.
Would be good to hear from others on this, especially operators.
Rgds
Shraddha
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, December 29, 2014 1:35 PM
To: Shraddha Hegde;
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions
Shraddha,
node-SID is advertised by the router for the prefix that is directly attached
to it. Protection for such local prefix does not mean much.
thanks,
Peter
On 12/24/14 11:57 , Shraddha Hegde wrote:
Authors,
We have a "backup flag" in adjacency sid to indicate whether the
label is protected or not.
Similarly. I think we need a flag in prefix-sid as well to
indicate whether the node-sid is to be protected or not.
Any thoughts on this?
Rgds
Shraddha
_______________________________________________
Isis-wg mailing list
isis...@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
.
.
.
.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
