> On Aug 25, 2016, at 4:41 AM, peng.sha...@zte.com.cn wrote: > > Stefano, > > see inline with [Deccan] > > Thanks > Deccan > > > > "Stefano Previdi (sprevidi)" <sprev...@cisco.com> > 2016-08-23 23:22 > > 收件人 > "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 > > > > > > 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. > > [Deccan] Yes, it is entirely possible to generate a segment list only > including segments with local meaning, such as adjacency segment list, > service segment list, etc., without any node segment. So it is not > appropriate to do recursive operation for local meaning segments by default. > There maybe other cases that I don't know. > > > 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. > > [Deccan] The above last point could be modified: > In despite V/L flag set or not, the value of the sid/label field in the > prefix-sid must always be a valid value. That is, for recursive use-case, it > is its own sid; for sharing use-case, it is the sharing sid. However, if the > received nodes don't know RECURSIVE flag, for sharing use-case, sid > conflicting will process; for recursive use-case, no recursion to be done.
so, it’s broken. > 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). > > [Deccan] Yes, the alternate method only allows to recurse to a router-id > address. But, don't you think router-id address is enough for any segment > list? absolutely not. Yu need to be able to recurse multiple prefixes to different addresses (all belonging to the same node). > Especially for an SR-TE path dynamic computed by CSPF, I think a > non-router-id address will have no chance to represent a node-segment. > However, the alternate method seems to be not much clean than SRRI method, > for the possible sid conflicting introduced in sharing use-case, from this > point, the SRRI method is good. CSPF is not the main use case here. > > 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. > > [Deccan] Ok, I have not got this point before. However, if router-id address > is enough, router-ID is not enough. > sid sharing seems to be not so much significant, do you think so? I think the srri method is the cleanest and safest option to provide both: . recursion of a prefix to a different sid . sharing the same sid among different prefixes without incurring well known backward-compatibility and conflicting issues. srri is a generic solution applicable to a variety of use cases. Thanks. s. > > 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
