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

Gyan Mishra <hayabusagsm@gmail.com> Sat, 18 May 2019 15:51 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCBF120233; Sat, 18 May 2019 08:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7m_QLEYxv5F; Sat, 18 May 2019 08:50:58 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949F0120320; Sat, 18 May 2019 08:50:58 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id x8so2625332vsx.13; Sat, 18 May 2019 08:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QR85Xh+BIifvbBcpTV9kJOn0J1eRXESi8tz5YJeys2Q=; b=di79wcgqpyUdM2ew7BMoGqXbkzmKHdxoPEUVycVZL7Pn/x6oSE5eP7LU7cF0x07s2n ISdUeJYlu3ZpbMWEWDHAU5YZc/1yfIwWo2yS/ptxjlupKmtv3eYwI4qXnLbrJ4s8tI+h BnKxonm6YMaW+BRY4ljuHj7MkjgyI8LykqwBEMDeLUNEMK6+fcqACOIaaM3dE3L5M7FH NIziB9696oaKV0lidO0Fr9stchl8mJYgXR4XqyRdhSaB9Jrub/P/qUJwartbzHXOt6ir JT1SLwNffSuOiwgAoNiv00HywNucMF5QIqVrSa9z7jUoqGzP/brnjy2RHksJSIsBGo+o HAdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QR85Xh+BIifvbBcpTV9kJOn0J1eRXESi8tz5YJeys2Q=; b=XDTmgxW35RYjk1rGkfGA+RDE5hAwSQaWC3KQieFBvwrPSNUOcy28M/fFlNWSW/4NpX 2dEjbSE+Yh6HPY4qHzWSOj5k260RRP78G1MoaIuV3HE+/QezcuWid01JafsfeTQTgRw4 4CokDq6iRB3AexG3Ppfg/RmCzXVvNfK325pApLNodx/KJj+GxYClkljosahwWg7droFd tTjsMyk2kUzhNfuRYu33dhtjlPMEJZ/PxWBArL+aiKDke6psUSHwf1PVqIfDt0DwU4zS ntLhlJVcEaZuub3MZGln8K68FdZxZ2b+KGnWZ3vmsFfT+Iga2kqoL+VjPtN7QEQGZ0Sb Fspw==
X-Gm-Message-State: APjAAAX6qhhClLU3tB7GYuZEjQaXd/wHSa+JRAmcoxxw1h3Fithtl7fs kI0ab/dOyKknjjYHHxL2OLpqMlDc
X-Google-Smtp-Source: APXvYqwtwIp+RTLnBR6nH5/4QIkTinD1Cq4+WO2sxQfcbZ16O1iMBo8cjZff+uW+/CBfF4dvda0I+A==
X-Received: by 2002:a67:330f:: with SMTP id z15mr982382vsz.12.1558194657168; Sat, 18 May 2019 08:50:57 -0700 (PDT)
Received: from ?IPv6:2600:1006:b052:78f0:71f4:40fb:64d7:1c02? ([2600:1006:b052:78f0:71f4:40fb:64d7:1c02]) by smtp.gmail.com with ESMTPSA id v141sm15391734vsc.8.2019.05.18.08.50.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 May 2019 08:50:56 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-9D026CCA-3BCC-4CA0-B6D3-F234405370F5"
Mime-Version: 1.0 (1.0)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <1AE0E748-F3EB-4C49-A0C3-FA24C8363FAC@gmail.com>
Date: Sat, 18 May 2019 11:50:55 -0400
Cc: Christian Hopps <chopps@chopps.org>, Mirja Kühlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "draft-ietf-isis-segment-routing-extensions@ietf.org" <draft-ietf-isis-segment-routing-extensions@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "uma.chunduri@huawei.com" <uma.chunduri@huawei.com>
Content-Transfer-Encoding: 7bit
Message-Id: <9EAE7D91-0675-4AB3-B909-708894433265@gmail.com>
References: <155783508360.25110.5307127543766994337.idtracker@ietfa.amsl.com> <A3CECE1B-E987-4796-A79A-9D411C42F9D7@gmail.com> <BYAPR11MB36387938B1713D0355DC9129C1090@BYAPR11MB3638.namprd11.prod.outlook.com> <CABNhwV3QiNxCyA270KfocdPu9jS-Bgi2316MnRnL1f9E0DuPrg@mail.gmail.com> <1AE0E748-F3EB-4C49-A0C3-FA24C8363FAC@gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6PBr7aBLpyVwVNU47gMop1C7Mrs>
Subject: Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-isis-segment-routing-extensions-24: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 May 2019 15:51:02 -0000

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 <hayabusagsm@gmail.com> wrote:
> 
> 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 <hayabusagsm@gmail.com> 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: 301 502-1347
>> 
>>> On Wed, May 15, 2019 at 1:02 AM Les Ginsberg (ginsberg) <ginsberg@cisco.com> 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 <lsr-bounces@ietf.org> On Behalf Of Gyan Mishra
>>> > Sent: Tuesday, May 14, 2019 7:09 PM
>>> > To: Mirja Kühlewind <ietf@kuehlewind.net>
>>> > Cc: draft-ietf-isis-segment-routing-extensions@ietf.org; Christian Hopps
>>> > <chopps@chopps.org>; uma.chunduri@huawei.com;
>>> > aretana.ietf@gmail.com; lsr-chairs@ietf.org; The IESG <iesg@ietf.org>;
>>> > lsr@ietf.org
>>> > 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: 301 502-1347
>>> > 
>>> > Sent from my iPhone
>>> > 
>>> > > On May 14, 2019, at 7:58 AM, Mirja Kühlewind via Datatracker
>>> > <noreply@ietf.org> 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
>>> > > Lsr@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/lsr
>>> > 
>>> > _______________________________________________
>>> > Lsr mailing list
>>> > Lsr@ietf.org
>>> > 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
>>