Subject: [spring] SR Policy draft update and its spin off drafts

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 12 Jun 2018 14:06:42 +0000

Hello Chairs/WG,

Would like to inform that the draft-ietf-spring-segment-routing-policy-01 version has been posted earlier today with the focussed content as previously discussed on the mailing list.

At this point, the authors of the draft-filsfils-spring-sr-traffic-counters and draft-filsfils-spring-sr-policy-considerations would like to request for their adoption by the WG.

Given that the contents of these two drafts are entirely (almost verbatim) picked from the draft-filsfils-spring-segment-routing-policy-05 which was adopted by the WG, the text and topics covered in them are already familiar to the WG. While perhaps the expression of interest to work on these topics was conveyed as part of the adoption call on the combined version of that document, a more formal adoption request and call for these two drafts seems more appropriate.

Thanks,
Ketan (on behalf of co-authors of the two drafts)

-----Original Message-----
From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: 12 June 2018 10:16
To: [email-masked]
Cc: [email-masked]
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

        Title           : Segment Routing Policy Architecture
        Authors         : Clarence Filsfils
                          Siva Sivabalan
                          Daniel Voyer
                          Alex Bogdanov
                          Paul Mattes
	Filename        : draft-ietf-spring-segment-routing-policy-01.txt
	Pages           : 33
	Date            : 2018-06-11

Abstract:
   Segment Routing (SR) allows a headend node to steer a packet flow
   along any path.  Intermediate per-flow states are eliminated thanks
   to source routing.  The headend node steers a flow into an SR Policy.
   The header of a packet steered in an SR Policy is augmented with an
   ordered list of segments associated with that SR Policy.  This
   document details the concepts of SR Policy and steering into an SR
   Policy.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-01
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-01

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: Przemyslaw Krol <[email-masked]>
Date: Tue, 12 Jun 2018 08:33:48 -0700

Hi Ketan, Authors

4 <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-01#section-4>.
Segment Types

  However, the SID-List itself
   can be specified using different segment-descriptor *types* and the
   following are currently defined:

   *Type 1*: SR-MPLS Label:
Additionally,
         reserved labels like explicit-null or in general any MPLS label
         may also be used.  e.g. *this type* can be used to specify a
         label representation which maps to an optical transport path on
         a packet transport node.  *This type* does not require the
         headend to perform SID resolution.

I assume 'this type' in SR-MPLS section really means 'reserved labels'
whereas 'type' in section 4 introduction means segment types. Wouldn't it
be more obvious to explicitly mention that 'Reserved labels' don't require
resolution (contrary to Type 1: SR-MPLS unreserved labels)?
Same probably applies to Type 2.

Also, it may not be worth the hassle, but it seems throughout the
document there is no consistency in terms of policy representation:

<color, endpoint>

vs

<endpoint, color>

thanks,
pk

On Tue, Jun 12, 2018 at 7:08 AM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> Hello Chairs/WG,
>
> Would like to inform that the draft-ietf-spring-segment-routing-policy-01
> version has been posted earlier today with the focussed content as
> previously discussed on the mailing list.
>
> At this point, the authors of the
> draft-filsfils-spring-sr-traffic-counters and
> draft-filsfils-spring-sr-policy-considerations would like to request for
> their adoption by the WG.
>
> Given that the contents of these two drafts are entirely (almost verbatim)
> picked from the draft-filsfils-spring-segment-routing-policy-05 which was
> adopted by the WG, the text and topics covered in them are already familiar
> to the WG. While perhaps the expression of interest to work on these topics
> was conveyed as part of the adoption call on the combined version of that
> document, a more formal adoption request and call for these two drafts
> seems more appropriate.
>
> Thanks,
> Subject: [spring] I-D Action:
> draft-ietf-spring-segment-routing-policy-01.txt
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>

-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [email-masked]

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 12 Jun 2018 15:56:20 +0000

Hi PK,

The term “this type” in that block actually means “Type 1” and not just reserved labels. When the SR/MPLS label is specified directly then no resolution is required. When the Segment is described with parameters (e.g. type 3 where the prefix address needs to be resolved to its Prefix SID label).

The tuple should be <color,endpoint> as specified in Sec 2.1 and thanks for catching this miss. Will fix it in the next rev.

Thanks,
Ketan

From: Przemyslaw Krol <pkrol=[email-masked]>
Sent: 12 June 2018 21:04
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] SR Policy draft update and its spin off drafts

Hi Ketan, Authors

4<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-01#section-4>.  Segment Types
  However, the SID-List itself
   can be specified using different segment-descriptor types and the
   following are currently defined:

   Type 1: SR-MPLS Label:
Additionally,
         reserved labels like explicit-null or in general any MPLS label
         may also be used.  e.g. this type can be used to specify a
         label representation which maps to an optical transport path on
         a packet transport node.  This type does not require the
         headend to perform SID resolution.

I assume 'this type' in SR-MPLS section really means 'reserved labels' whereas 'type' in section 4 introduction means segment types. Wouldn't it be more obvious to explicitly mention that 'Reserved labels' don't require resolution (contrary to Type 1: SR-MPLS unreserved labels)?
Same probably applies to Type 2.

Also, it may not be worth the hassle, but it seems throughout the document there is no consistency in terms of policy representation:

<color, endpoint>

vs

<endpoint, color>

thanks,
pk

On Tue, Jun 12, 2018 at 7:08 AM Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>> wrote:
Hello Chairs/WG,

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 12 June 2018 10:16
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-01.txt

Abstract:

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-01
https://datatracker..ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-01<https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-01>

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

--
Przemyslaw "PK" Krol |

 Strategic Network Engineer

ing | [email-masked]<mailto:[email-masked]>

---

From: Przemyslaw Krol <[email-masked]>
Date: Tue, 12 Jun 2018 09:01:56 -0700

Hi Ketan,

> When the SR/MPLS label is specified directly then no resolution is
required.

Even if it's the top-most SID in the Segment List?
By saying resolution i mean Label -> next-hop interface as per section 5.1:
  o  The headend is unable to resolve the first SID into one or more
      outgoing interface(s) and next-hop(s).

thanks,

On Tue, Jun 12, 2018 at 8:56 AM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> Hi PK,
>
>
>
> The term “this type” in that block actually means “Type 1” and not just
> reserved labels. When the SR/MPLS label is specified directly then no
> resolution is required. When the Segment is described with parameters (e.g.
> type 3 where the prefix address needs to be resolved to its Prefix SID
> label).
>
>
>
> The tuple should be <color,endpoint> as specified in Sec 2.1 and thanks
> for catching this miss. Will fix it in the next rev.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Przemyslaw Krol <pkrol=[email-masked]>
> *Sent:* 12 June 2018 21:04
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [spring] SR Policy draft update and its spin off drafts
>
>
>
> Hi Ketan, Authors
>
>
> 4
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-01#section-4>.
> Segment Types
>
> https://datatracker..ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-01
> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-01>
>
> ing | [email-masked]

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 12 Jun 2018 16:13:09 +0000

Hi PK,

The text in Sec 4 for the type 1 & 2 talk about “SID resolution” which is what I explained below.

I believe you are talking about “path resolution” for a SID (e.g. in most cases for the first segment). This is described in Sec 5.1.

I would propose to use the terms “SID resolution” and “path resolution” where necessary to disambiguate these terms.

Thanks,
Ketan

From: Przemyslaw Krol <pkrol=[email-masked]>
Sent: 12 June 2018 21:32
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] SR Policy draft update and its spin off drafts

Hi Ketan,

> When the SR/MPLS label is specified directly then no resolution is required.

Even if it's the top-most SID in the Segment List?
By saying resolution i mean Label -> next-hop interface as per section 5..1:
  o  The headend is unable to resolve the first SID into one or more
      outgoing interface(s) and next-hop(s).

thanks,

On Tue, Jun 12, 2018 at 8:56 AM Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>> wrote:
Hi PK,

Thanks,
Ketan

From: Przemyslaw Krol <pkrol=[email-masked]<mailto:[email-masked]>>
Sent: 12 June 2018 21:04
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] SR Policy draft update and its spin off drafts

Hi Ketan, Authors

   Type 1: SR-MPLS Label:
Additionally,

<color, endpoint>

vs

<endpoint, color>

thanks,
pk

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 12 June 2018 10:16
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-01.txt

Abstract:

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp..ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>

--
Przemyslaw "PK" Krol |

--
Przemyslaw "PK" Krol |

---

From: Przemyslaw Krol <[email-masked]>
Date: Tue, 12 Jun 2018 09:21:55 -0700

Hi Ketan,

Indeed, such clear terminology distinction would make it less confusing.

Thanks,

On Tue, Jun 12, 2018, 09:13 Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> I believe you are talking about “path resolution” for a SID (e.g. in most
> cases for the first segment). This is described in Sec 5.1.
>
>
>
> I would propose to use the terms “SID resolution” and “path resolution”
> where necessary to disambiguate these terms.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *Sent:* 12 June 2018 21:32
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> ftp://ftp..ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>