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

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

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<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

---

From: stefano previdi <[email-masked]>
Date: Fri, 19 Oct 2018 08:48:55 +0200

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,
>  
> ·         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
>  
> 	• In https://tools.ietf.org/html//draft-ietf-spring-segment-routing-policy-01, the SR policy’s structure looks like:
>

---

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,

Hope this helps.
s.

> Where is the candidate-path?  it seems like they are not aligned.

_______________________________________________
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:00:16 +0000

Hi Stefano, 

Please see line.

Cheng

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

Hi Cheng,

[Cheng]  Agree.

[Cheng] Agree.

[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.

>                                 Weighted SID list1
>                                 Weighted SID list2

---

From: stefano previdi <[email-masked]>
Date: Fri, 19 Oct 2018 09:05:55 +0200

> On Oct 19, 2018, at 9:00 AM, Chengli (IP Technology Research) <[email-masked]> wrote:
> 
> Hi Stefano, 
> 
> Please see line.
> 
> Cheng
> 
> 

[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.

---

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.

---

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

Hi Stefano,

Yes, thanks for your reply.

Regards,
Cheng

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

[Stefano]

thanks.
s.