Subject: Re: [Idr] [spring] Question: Inconsistency of SR policy structure

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 19 Oct 2018 06:51:57 +0000

+1

The draft-ietf-idr-segment-routing-te-policy has the following text in Sec 1 to explain this.

   While for simplicity we may write that BGP advertises an SR Policy,
   it has to be understood that BGP advertises a candidate path of an SR
   policy and that this SR Policy might have several other candidate
   paths provided via BGP (via an NLRI with a different distinguisher as
   defined in this document), PCEP, NETCONF or local policy
   configuration.

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]> On Behalf Of stefano previdi
Sent: 19 October 2018 12:19
To: Chengli (IP Technology Research) <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; [email-masked]; Robin <[email-masked]>
Subject: Re: [spring] 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.

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) <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: "Chengli (IP Technology Research)" <[email-masked]>
Date: Fri, 19 Oct 2018 07:30:29 +0000

Get! 

So actually, in draft-ietf-spring-segment-routing-policy, a SR policy is identified by the tuple <headend, color, endpoint>.

Within an SR policy, a candidate path has its distinguisher. So a Candidate can be identified by <headend, color, endpoint, distinguisher>.

In draft-ietf-idr-segment-routing-te-policy, an SR policy(Actually, it is a candidate path of an SR policy) can be identified by <Distinguisher, Policy-Color, Endpoint> .
Since the headed is the receiver, so no need to be added in the tuple. 

It makes sense. Good design!

Thanks for explanation. 

Cheng

-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Friday, October 19, 2018 2:52 PM
To: stefano previdi <[email-masked]>; Chengli (IP Technology Research) <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; [email-masked]; Lizhenbin <[email-masked]>; [email-masked]
Subject: RE: [spring] Question: Inconsistency of SR policy structure

+1

Thanks,
Ketan

-----Original Message-----
From: spring <[email-masked]> On Behalf Of stefano previdi
Sent: 19 October 2018 12:19
To: Chengli (IP Technology Research) <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; [email-masked]; Robin <[email-masked]>
Subject: Re: [spring] Question: Inconsistency of SR policy structure

Hi Cheng,

Hope this helps.
s.