Hi Deccan,
> On Aug 23, 2016, at 4:39 AM, peng.sha...@zte.com.cn wrote:
>
> Hi Stefano
>
> Sure, SRRI provided in this document can explicitly indicate a recursive
> operation (or relationship).
> But it maybe a default behavior to do recursive operation when an SR-NODE
> received remote prefix-sid with L/V flag set according to the documents
> already existed. For example,
> prefix reachability advertisement received:
> prefix (1.0.0.99/32)
> prefix-sid (30004), L/V flag set, //ISIS-SR
> "IPv4 Source Router ID" is 1.0.0.4 //rfc7794
> Then, prefix 1.0.0.9/32 can do recursion to prefix 1.0.0.4/32 by default.
there are other cases where V/L are used so I wouldn’t
bind these flags to the recursive behavior.
> If "default behavior" is not accepted, we can define a new RECURSIVE flag in
> Prefix-SID Sub-TLV.
if I understand your proposal, you could:
. attach the SourceRouterID (RFC7794) to the prefix
. attach a prefix-sid with:
. recursive flag set, which means the sid is to be
taken from the sourceRouterID
. optionally set the V/L flag and also a local label
. if no V/L flag are set, the value of the sid/label
field in the prefix-sid must be 0 on transmit and
ignored on receive.
I see at least 2 problems with that:
1. the value of the prefix-sid you’re going to advertise
will be misinterpreted by non-srri-capable nodes
(i.e.: nodes know knowing the recursive flag). I.e: The
value of the prefix sid would be either an explicit
null label either a 0-value index.
2. RFC7794 states that: the Router ID advertised is
always the Router ID of the IS-IS instance that
originated the advertisement.
This reduces the ability to use other addresses of the
node for recursion.
Bottom line, having a separate repository for the recursing
information is the safest and cleanest option which allows
better flexibility (i.e.: allowing to recurse to a
non-router-ID address) and which ensure backward
compatibility (i.e.: non-srri-nodes will simply ignore the
whole srri info and consider the prefix as it had no sid at
all).
> BTW, all we discussed is SID recursive but not sharing,
of course it is sharing. As defined in the draft, the
local label attached to the srri info it’s an optional
optimization. Without the local label, you will share the
same sid among multiple prefixes.
> even the first case in this draft is actually not SID sharing, otherwise it
> will be cared by draft-ietf-spring-conflict-resolution.
No, it is not a conflict. Having a dedicated srri
repository makes it clear.
s.
> Thanks
> Deccan
>
>
>
>
>
> "Stefano Previdi (sprevidi)" <sprev...@cisco.com>
> 2016-08-22 21:38
>
> 收件人
> "peng.sha...@zte.com.cn" <peng.sha...@zte.com.cn>,
> 抄送
> SPRING WG <spring@ietf.org>
> 主题
> Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
>
>
>
>
>
>
> > On Aug 9, 2016, at 5:55 AM, peng.sha...@zte.com.cn wrote:
> >
> > Other documents have already addressed this issue,
>
>
> I don’t think so. Can you point to these documents ?
>
>
> > for example, set L-flag of Prefix-SID Sub-TLV in
> > draft-ietf-isis-segment-routing-extensions-05 and contain IPv4 Source
> > Router ID in rfc7794.
>
>
> the L flag has the solely purpose of indicating the sid contains a local
> value. Typically it goes with the V flag that indicates a value (i.e.: local
> label).
>
> Nothing is mentioned regarding sharing the same sid among different services.
>
> s.
>
>
>
> >
> >
> > Thanks,
> >
> > Deccan
> >
> >
> >
> >
> >
> > [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
> > "John G. Scudder" <j...@juniper.net> Sun, 24 July 2016 12:54 UTCShow header
> > Dear WG,
> >
> > As we discussed at our meeting, working group adoption has been requested
> > for draft-filsfils-spring-sr-recursing-info. Please reply to the list with
> > your comments, including although not limited to whether or not you support
> > adoption. Non-authors are especially encouraged to comment.
> >
> > We will end the call on August 31, 2015.
> >
> > Authors, please indicate whether you are aware of any relevant IPR and if
> > so, whether it has been disclosed.
> >
> > Thanks,
> >
> > --Bruno and John
> >
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
