> On Oct 19, 2018, at 9:00 AM, Chengli (IP Technology Research) > <chengl...@huawei.com> wrote: > > 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.
[Stefano] see section 1 of draft-ietf-spring-segment-routing-policy as pointed out by Ketan. In BGP we do advertise a single path (that may have of course, multiple weighted segment lists). The receiver will add the paths received through BGP (for a given policy) and put them in the candidate path list for that policy with any other path that it could have received through other protocols. thanks. s. > > > 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
