Hi Cheng, to my understanding the definition of an SR Policy (draft-ietf-spring-segment-routing-policy) is correct.
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. 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. And btw, just a detail, your description is a bit misleading: in BGP also the segment list 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 > SID list1 > 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
