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 14:53 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 5ADCD12004E; Sat, 18 May 2019 07:53:11 -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 y0zyJVCo8Pbk; Sat, 18 May 2019 07:53:08 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 1ADA712002E; Sat, 18 May 2019 07:53:08 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id o10so6453583vsp.12; Sat, 18 May 2019 07:53:07 -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=HtL7Sy6CICMCSUqqUqVgSGEyXYzYzpatqQdYRPHbiuc=; b=TUFlAyyg/L+xIweBdlnkd0C8vydfXBGd+3CCe2lBwa+xtW+uUgIo8jczNUHFVFwPu0 /9tQf4++E2S17elbGOhiC3SKYzYTzRPz5XxR8QtZVVKOro7FhhXpBR04q4IpzFrmpV9J Nf1txMHpWsEsV2zDP08j7PuW8+t5jAj4fXrK189IcgeFMsgGnMBfec/WGcbWg1Vurx3I KqutEgFCXDecV7L61siI9wa1VfeigeGBn9pkjWytNBE/c+JjkCa5hEQhMQc1iZ2UTj/7 kDzyXoEgmq+ESmJcZ73pWZu5WfjYTfPB2u6ePVs2uxcH1FrYykNp/G5YvSCW54NHDChG nqxQ==
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=HtL7Sy6CICMCSUqqUqVgSGEyXYzYzpatqQdYRPHbiuc=; b=jD2KCVJqciuO40qjRXK9qyQ/JagQzMQsBMe8lUjlqvfB3DwI+GmfE8A06/R0p9x89Q Zf61n3uz4RVOnSnEgKvyTSJihaQqapBX3XcFOJIA+dL4iCCMUi8QKxAyYnrYHg6Az1cy qNHdX9muMNtWxuMV4/DLJ7tMi9xhP1A4F7vxl5kE/OR9jSddX2yzT1KoJUuWzSxNACWN BX3qRRpy84gRDpJdqWGsG/q4qHROPlipnmcM9sjZarNWecqTa2epD6156pdM5Rijo4VY lIjM2xERODBa/2n0bFNzyB/r5KXOA1/MXXD/MvjZsK+xu8ZJxOlCntgzjj16Zs65QwrT EdTA==
X-Gm-Message-State: APjAAAVldZsdtuAmgjbmtRD6ib01/kywqhPeV1OoEE9BcCvnnUxoSxz8 JkJ1wJfoaAFJF3PU663Ac/W+GMLn
X-Google-Smtp-Source: APXvYqykgayZ8AVCd9+uxtFJGPrxSFzqNak/MnxnK0z9CCfg/1FkDeK98iGdT7Wxqdp6LUPjcrDXHA==
X-Received: by 2002:a67:b30b:: with SMTP id a11mr24693210vsm.86.1558191186765; Sat, 18 May 2019 07:53:06 -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 125sm3991080vkt.11.2019.05.18.07.53.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 May 2019 07:53:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-D8BCB2B7-98FB-4B66-B75D-69116AA753AF
Mime-Version: 1.0 (1.0)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <CABNhwV3QiNxCyA270KfocdPu9jS-Bgi2316MnRnL1f9E0DuPrg@mail.gmail.com>
Date: Sat, 18 May 2019 10:53:04 -0400
Cc: Christian Hopps <chopps@chopps.org>, =?utf-8?Q?Mirja_K=C3=BChlewind?= <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: <1AE0E748-F3EB-4C49-A0C3-FA24C8363FAC@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>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/kkG8f6KeFaSIr3Co5q9QWcNFIHs>
Subject: Re: [Lsr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-isis-segment-routing-extensions-24=3A_=28with_COMMENT=29?=
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 14:53:11 -0000

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>rg>; uma.chunduri@huawei.com;
>> > aretana.ietf@gmail.com; lsr-chairs@ietf.org; The IESG <iesg@ietf.org>rg>;
>> > 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
>