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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> 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
> does not require any additional signaling (other than the regular IGP)
> 
> Wording seems misleading leaving out IPv4.
> 
> Gyan Mishra
> Verizon Communications
> Phone: [phone]
> 
>> On Wed, May 15, 2019 at 1:02 AM Les Ginsberg (ginsberg) <[e-mail]> 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. 
>> 
>> 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
>> 
>> > -----Original Message-----
>> > From: Lsr <[e-mail]> On Behalf Of Gyan Mishra
>> > Sent: Tuesday, May 14, 2019 7:09 PM
>> > To: Mirja Kühlewind <[e-mail]>
>> > Cc: [e-mail]; Christian Hopps
>> > <[e-mail]>; [e-mail];
>> > [e-mail]; [e-mail]; The IESG <[e-mail]>;
>> > [e-mail]
>> > Subject: Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-isis-segment-
>> > routing-extensions-24: (with COMMENT)
>> > 
>> > 
>> > 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: [phone]
>> > 
>> > Sent from my iPhone
>> > 
>> > > On May 14, 2019, at 7:58 AM, Mirja Kühlewind via Datatracker
>> > <[e-mail]> wrote:
>> > >
>> > > 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?
>> > >
>> > >
>> > > _______________________________________________
>> > > Lsr mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/lsr
>> > 
>> > _______________________________________________
>> > Lsr mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/lsr
> -- 
> 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
>