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

Hi Ketan,

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

Thanks,

On Tue, Jun 12, 2018, 09:13 Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> 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=40google.com@dmarc.ietf.org>
> *Sent:* 12 June 2018 21:32
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* pkrol@google.com; spring@ietf.org; spring-chairs@ietf.org
> *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=
> 40cisco.com@dmarc.ietf.org> 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=40google.com@dmarc.ietf.org>
> *Sent:* 12 June 2018 21:04
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* spring-chairs@ietf.org; spring@ietf.org
> *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=
> 40cisco.com@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 appropriate.
>
> Thanks,
> Ketan (on behalf of co-authors of the two drafts)
>
> -----Original Message-----
> From: spring <spring-bounces@ietf.org> On Behalf Of
> internet-drafts@ietf.org
> Sent: 12 June 2018 10:16
> To: i-d-announce@ietf.org
> Cc: 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 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
> <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/ <ftp://ftp.ietf.org/internet-drafts/>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
>
>
> --
>
> Przemyslaw "PK" Krol |
>
>  Strategic Network Engineer
>
> ing | pkrol@google.com
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
>
>
> --
>
> Przemyslaw "PK" Krol |
>
>  Strategic Network Engineer
>
> ing | pkrol@google.com
>
>
>