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
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
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
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
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
On 12/29/14
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:
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
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
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
Rob,
Pls see inline..
Rgds
Shraddha
-Original Message-
From: Rob Shakir [mailto:r...@rob.sh]
Sent: Monday, December 29, 2014 2:38 PM
To: Peter Psenak; Shraddha Hegde
Cc: draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
On 29 Dec 2014, at 09:33, Shraddha Hegde shrad...@juniper.net wrote:
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.
There is nothing
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
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
13 matches
Mail list logo
