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
