Subject: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-isis-segment-routing-extensions-24: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 14 May 2019 04:58:03 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-isis-segment-routing-extensions-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few comments/questions:

1) For both the Prefix Segment Identifier and the Adjacency Segment Identifier
sub-TLV it is not fully clear to me what the value field is used for when the
V-Flag is set. Can you further elaborate this in the draft or provide a
respective pointer?

2) The F-Flag in Adjacency Segment Identifier sub-TLV and SID/Label Binding TLV
is only one bit. I'm not expecting a new version of IP any time soon, however,
maybe completely different address families could be useful as well. Not sure
if only 1 bit is future-proof...?

3) Would it make sense to also discuss any risk of leaking information (e.g.
about the network topology) in the security consideration section?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 14 May 2019 16:12:27 +0000

Mirja -

Thanx for the review.
Responses inline.

> -----Original Message-----
> From: Mirja Kühlewind via Datatracker <[email-masked]>
> Sent: Tuesday, May 14, 2019 4:58 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Christian Hopps
> <[email-masked]>; Uma Chunduri <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-isis-segment-routing-
> extensions-24: (with COMMENT)
> 
[Les:] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-24#section-2.1.1.1 defines this.

> if only 1 bit is future-proof...?
[Les:] This is a very forward looking comment. :-)

Seriously, if a new version of IP is invented there will be a LOT of protocol work required to support it. It is also not a given that MPLS would be supported for such a new IP version - so it isn't at all a given that these extensions (however modified) would apply.
Also, changing the encoding now would be problematic for existing deployments (of which there are many) and I think we would have a hard time defining what an extensible encoding would be.

I like to think we can deal with this when the time comes.
Sound OK?
 
> about the network topology) in the security consideration section?

[Les:] Prefix leaking is an established practice in IS-IS dating back to RFC 1195,  extended by RFC 5302, and not modified by this document.
Note that the Security section already discusses the advertisement of information used to program the MPLS forwarding plane - which covers the additional sub-TLV information which would accompany leaked prefixes.

    Les

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 14 May 2019 18:34:36 +0200

Hi Les,

Please see inline.

> On 14. May 2019, at 18:12, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Mirja -
> 
> Thanx for the review.
> Responses inline.
> 

I was assuming that it is defined somewhere. Maybe putting a ref in the doc that points at this draft could be good.
> Seriously, if a new version of IP is invented there will be a LOT of protocol work required to support it. It is also not a given that MPLS would be supported for such a new IP version - so it isn'…

I’m actually not sure because many protocols that need to cover IPv4 and IPv6 have already a longer field (or alternative would need a new extension for any new protocol anyway)…

> Also, changing the encoding now would be problematic for existing deployments (of which there are many) and I think we would have a hard time defining what an extensible encoding would be.

I was assuming this answer already, so…
> I like to think we can deal with this when the time comes.

… I guess it’s fine.

> Note that the Security section already discusses the advertisement of information used to program the MPLS forwarding plane - which covers the additional sub-TLV information which would accompany l…

Adding a few sentences and pointers to the RFC you just listed could still be good!

Mirja

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 14 May 2019 16:46:16 +0000

Mirja -

Inline.

> From: Mirja Kuehlewind <[email-masked]>
> Sent: Tuesday, May 14, 2019 9:35 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: The IESG <[email-masked]>; draft-ietf-isis-segment-routing-
> [email-masked]; Christian Hopps <[email-masked]>; Uma Chunduri
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-isis-segment-
> routing-extensions-24: (with COMMENT)
> 
> Hi Les,
> 
> Please see inline.
> 
> > [Les:] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-
> extensions-24#section-2.1.1.1 defines this.
> 

[Les:] There are multiple references to this section in the document. Please search for them.

> >
> >> 2) The F-Flag in Adjacency Segment Identifier sub-TLV and SID/Label
> Binding
> >> TLV
> > Seriously, if a new version of IP is invented there will be a LOT of protocol
> work required to support it. It is also not a given that MPLS would be
> supported for such a new IP version - so it isn't at all a given that these
> extensions (however modified) would apply.
> 
> I’m actually not sure because many protocols that need to cover IPv4 and
> IPv6 have already a longer field (or alternative would need a new extension
> for any new protocol anyway)…
> 
> > Also, changing the encoding now would be problematic for existing
> deployments (of which there are many) and I think we would have a hard
> time defining what an extensible encoding would be.
> 
> > [Les:] Prefix leaking is an established practice in IS-IS dating back to RFC
> 1195,  extended by RFC 5302, and not modified by this document.
> > Note that the Security section already discusses the advertisement of
> information used to program the MPLS forwarding plane - which covers the
> additional sub-TLV information which would accompany leaked prefixes.
> 

[Les:] I'll give it some thought. Security review has yet to happen - so I am sure there will some additional comments. :-)

   Les

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 May 2019 22:09:13 -0400

I noticed in the intro that IPv4 is not mentioned just IPv6 and mpls.  Was that on purpose.

   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths within IGP topologies by encoding paths as sequences of
   topological sub-paths, called "segments".  These segments are
   advertised by the link-state routing protocols (IS-IS and OSPF).
   Prefix segments represent an ECMP-aware shortest-path to a prefix (or
   a node), as per the state of the IGP topology.  Adjacency segments
   represent a hop over a specific adjacency between two nodes in the
   IGP.  A prefix segment is typically a multi-hop path while an
   adjacency segment, in most of the cases, is a one-hop path.  SR’s
   control-plane can be applied to both IPv6 and MPLS data-planes, and
   does not require any additional signaling (other than the regular
   IGP).  For example, when used in MPLS networks, SR paths do not
   require any LDP or RSVP-TE signaling.  Still, SR can interoperate in
   the presence of LSPs established with RSVP or LDP.

Gyan Mishra 
Verizon Communications 
Phone: 301 502-1347

Sent from my iPhone

> On May 14, 2019, at 7:58 AM, Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 May 2019 22:23:21 -0400

With SR is PHP P flag really necessary as that was used in with mpls historically to offload the ultimate hop router from having to pop all labels within the label stack but with high end routers these days the legacy PHP does not provide any cpu processing gains and with LDP has resulted in issues with QOS exp scheduling bits lost in cases where a remark was done on ingress the topmost exp bits are not copied to the bottom of stack mpls vpn labels thus loss of Critical PHB scheduling. 

Workaround had been to enable explicit null or use qos groups internal markings to keep the marking intact on the topmost.

If the P-flag is not set then any upstream neighbor of the Prefix-
      SID originator MUST pop the Prefix-SID.  This is equivalent to the
      penultimate hop popping mechanism used in the MPLS dataplane which
      improves performance of the ultimate hop.  MPLS EXP bits of the
      Prefix-SID are not preserved to the ultimate hop (the Prefix-SID
      being removed).  If the P-flag is unset the received E-flag is
      ignored.

Gyan Mishra
Verizon Communications 
Phone: 301 502-1347

Sent from my iPhone

> On May 14, 2019, at 10:09 PM, Gyan Mishra <[email-masked]> wrote:
> 
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 15 May 2019 05:02:46 +0000

Gyan -

The paragraph you cut and pasted is providing a short overview of Segment Routing, which can be used on two different data planes - IPv6 and MPLS. 

The introduction goes on to say:

"This draft describes the necessary IS-IS extensions that need to be
   introduced for Segment Routing operating on an MPLS data-plane."

An MPLS dataplane supports forwarding of both IPv4 and IPv6 packets - and the document makes that clear throughout.

Extensions for IS-IS to support Segment Routing over an IPv6 dataplane are described in https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/ .

   Les

> From: Lsr <[email-masked]> On Behalf Of Gyan Mishra
> Sent: Tuesday, May 14, 2019 7:09 PM
> To: Mirja Kühlewind <[email-masked]>
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; The IESG <[email-masked]>;
> [email-masked]
> Subject: Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-isis-segment-
> Binding TLV

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 15 May 2019 05:25:04 +0000

Gyan -

I grant that UHP may not be widely used in deployments - but as it is a supported option when using MPLS we saw no reason to eliminate support for it in the signaling.
Being able to support it does not require folks to deploy it of course.

   Les

> From: Gyan Mishra <[email-masked]>
> Sent: Tuesday, May 14, 2019 7:23 PM
> [email-masked]; Christian Hopps <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> With SR is PHP P flag really necessary as that was used in with mpls historically
> to offload the ultimate hop router from having to pop all labels within the
> label stack but with high end routers these days the legacy PHP does not
> provide any cpu processing gains and with LDP has resulted in issues with
> QOS exp scheduling bits lost in cases where a remark was done on ingress
> the topmost exp bits are not copied to the bottom of stack mpls vpn labels
> thus loss of Critical PHB scheduling.
> 
> Workaround had been to enable explicit null or use qos groups internal
> markings to keep the marking intact on the topmost.
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 16 May 2019 20:21:30 -0400

Understood.

Agreed it’s always nice to have options you had even in a legacy protocol I guess eventually mpls would become legacy but I think they both SR and mpls have their advantages and disadvantages but since most folks are familiar with PHP it makes sense to carry forward into SR features that exist in mpls today.

Thank you

Gyan

Sent from my iPhone

> On May 15, 2019, at 1:25 AM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Gyan -
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 17 May 2019 03:08:44 -0400

Les

I agree the document makes it clear throughout that then mpls dataplane
supports ipv4 and ipv6  however in the short Overview at the top I think it
should say the following:

SR’s control-plane can be applied to both IPv4 and IPv6 MPLS data-planes,
and
does not require any additional signaling (other than the regular IGP)

Wording seems misleading leaving out IPv4.

Gyan Mishra
Verizon Communications
Phone: 301 502-1347

On Wed, May 15, 2019 at 1:02 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Gyan -
>
> The paragraph you cut and pasted is providing a short overview of Segment
> Routing, which can be used on two different data planes - IPv6 and MPLS.
>
> An MPLS dataplane supports forwarding of both IPv4 and IPv6 packets - and
> the document makes that clear throughout.
>
> Extensions for IS-IS to support Segment Routing over an IPv6 dataplane are
> described in
> https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/ .
>
>    Les
>
> > I noticed in the intro that IPv4 is not mentioned just IPv6 and mpls.
> Was that
> > on purpose.
> >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > maybe completely different address families could be useful as well.
> Not
> > sure
-- 
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 18 May 2019 10:53:04 -0400

Les

I did some reading and research and lab testing of SR on CISCO XR nodes physical hardware and VIRL (virtual internet routing lab) and now I know why the top section says IPv6 and MPLS data planes.

So IPv6 data plans is native IPv6 source routed with segment instructions in the next header.

MPLS data plane is referring to SR-MPLS IPv4 and IPv6 address families using existing mpls infrastructure with segment stack for the SRGB idx prefix index and adjacency segments.

So from the top section now I understand the reason why IPv4 left out is SR supports native IPv6 data plane but not native non mpls IPv4 data planes.

Maybe some other verbiage would be good per what I mentioned here but if not now I understand why it says IPv6 and MPLS data planes.

Gyan

Sent from my iPhone

> On May 17, 2019, at 3:08 AM, Gyan Mishra <[email-masked]> wrote:
> 
> Les
> 
> I agree the document makes it clear throughout that then mpls dataplane supports ipv4 and ipv6  however in the short Overview at the top I think it should say the following:
> 
> SR’s control-plane can be applied to both IPv4 and IPv6 MPLS data-planes, and
>> On Wed, May 15, 2019 at 1:02 AM Les Ginsberg (ginsberg) <[email-masked]> wrote:
>> Gyan -
>>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 18 May 2019 11:50:55 -0400

Les

I have been reading through this tutorial on SR6 below which is really good.

https://www.segment-routing.net/images/srv6-intro-rev1d_for_PDF.pdf

So with SRV6 IPv6 data plane is essentially another underlay option to traditional using existing infrastructure for mpls “SR-MPLS” using SRV6 which with SRV6 it has the same PSP USP “mpls like” features using the Next header encoding of 128 bit segments prefix/function source routing.  So with SR6 you can have the same vpnv4 vpnv6 mpls services overlay on top of SR6 including even all MVPN profiles and VPWS and VPLS signaling overlays on top of SR6.

Is that correct??

So SR6 data plane is essentially another option for SP’s or enterprises building a new SP core use SP6 instead of SR-MPLS.

I am going to try simulate SR6 in CISCO VIRL virtual lab.  Hopefully it’s supported in XR 6.1.3.

Gyan
Sent from my iPhone

> On May 18, 2019, at 10:53 AM, Gyan Mishra <[email-masked]> wrote:
> 
> Les
>