Hi Stefano, Please see line.
Cheng -----Original Message----- From: stefano previdi [mailto:stef...@previdi.net] Sent: Friday, October 19, 2018 2:49 PM To: Chengli (IP Technology Research) <chengl...@huawei.com> Cc: draft-ietf-spring-segment-routing-pol...@ietf.org; draft-ietf-idr-segment-routing-te-pol...@ietf.org; SPRING WG List <spring@ietf.org>; Lizhenbin <lizhen...@huawei.com> Subject: Re: Question: Inconsistency of SR policy structure Hi Cheng, to my understanding the definition of an SR Policy (draft-ietf-spring-segment-routing-policy) is correct. [Cheng] Agree. An SR Policy may include different paths and each of these paths may be advertised in a different way (BGP, PCEP, static, ...). BGP extensions described in draft-ietf-idr-segment-routing-te-policy is one of the ways paths of a policy may be advertised. In other words, to my understanding at the time we wrote the BGP extensions, the SR Policy defined in draft-ietf-spring-segment-routing-policy is the set of all paths individually advertised in BGP, PCEP, etc. [Cheng] Agree. It may looks like a terminology issue but in fact, I don’t think so. Even if BGP (or PCEP) advertises a policy with a single path, it is still a valid SR Policy from the perspective of the advertiser. So the term “SR Policy” is valid no matter how many paths ended up in the policy after the receiver consolidated all of them. [Cheng] Agree. But the problem is. In BGP extensions, I am not sure the where is the candidate path. It seems like SR includes multiple SR path specified by SID lists. But in SR policy architecture document, the upper level of SID list is the candidate path. That makes me confused. And btw, just a detail, your description is a bit misleading: in BGP also the segment list is weighted. [Cheng] You are right. It is weighted. Hope this helps. s. > On Oct 19, 2018, at 8:23 AM, Chengli (IP Technology Research) > <chengl...@huawei.com> wrote: > > Hi authors, > > I am working on updating drafts of path segment extensions in BGP/BGP-LS: > · > https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distribution-00 > · > https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment-00 > > But I found the inconsistency of SR policy structure. > • In > https://tools.ietf.org/html//draft-ietf-spring-segment-routing-policy-01, the > SR policy’s structure looks like: > > SR policy POL1 <headend, color, endpoint> > Candidate-path CP1 <protocol-origin = 20, originator = > 100:1.1.1.1, discriminator = 1> > Preference 200 > Weight W1, SID-List1 <SID11...SID1i> > Weight W2, SID-List2 <SID21...SID2j> > Candidate-path CP2 <protocol-origin = 20, originator = > 100:2.2.2.2, discriminator = 2> > Preference 100 > Weight W3, SID-List3 <SID31...SID3i> > Weight W4, SID-List4 <SID41...SID4j> > > So the structure is : > SR Policy > Candidate-path p1 > Weighted SID-list1 > Weighted SID-list2 > Candidate-path p2 > Weighted SID-list3 > Weighted SID-list4 > > But in > https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04, SR > policy is described by following structure, > > SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> > Attributes: > Tunnel Encaps Attribute (23) > Tunnel Type: SR Policy > Binding SID > Preference > Priority > Policy Name > Explicit NULL Label Policy (ENLP) > Segment List > Weight > Segment > Segment > ... > ... > > The structure is, > SR Policy > Weighted SID list1 > Weighted SID list2 > > Where is the candidate-path? it seems like they are not aligned. > > Thanks, > Cheng _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
