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.


From: Przemyslaw Krol <pkrol=40google....@dmarc.ietf.org>
Sent: 12 June 2018 21:04
To: Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: spring-cha...@ietf.org; spring@ietf.org
Subject: Re: [spring] SR Policy draft update and its spin off drafts

Hi Ketan, Authors

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


<endpoint, color>


On Tue, Jun 12, 2018 at 7:08 AM Ketan Talaulikar (ketant) 
<ketant=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> 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 

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

-----Original Message-----
From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On 
Behalf Of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Sent: 12 June 2018 10:16
To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
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 

        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

   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

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

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

Internet-Drafts are also available by anonymous FTP at:

spring mailing list

spring mailing list

Przemyslaw "PK" Krol |

 Strategic Network Engineer

ing | pk...@google.com<mailto:pk...@google.com>

spring mailing list

Reply via email to