Re: [Isis-wg] 答复: 答复: 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 25 December 2017 22:50 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1D1200F3; Mon, 25 Dec 2017 14:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 nLmxDqdch9It; Mon, 25 Dec 2017 14:50:52 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 69E55120713; Mon, 25 Dec 2017 14:50:52 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id t196so31185334iof.0; Mon, 25 Dec 2017 14:50:52 -0800 (PST)
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=7NiQhaEVOWz07ypDSBIY3EBCmQ9YRyCYPV9MJLixmdk=; b=u7iWsJqeKFdJFhUw1VPKNVY1/YSZ7S5SbeuFPq/HZBofoAoPJGwlmCBpbQYw/Z9j1N lYNcaa8Hb10QboulrNrXEifn3dDXu2k9CtHjPs6J7EomT8Ro3gokatTyAIE8kr9sSp/r KToeyx1jwpV3i0EDLAEHnJl2bzaeuGlgDUK4tI0pmv1wGwQx+VdWskJ14/br0zFFcQmM aBMtSfnjB8T7DyI5qCu45EOWE6Kewox+RF14HPJwkeo6bWuwYQtd378xlsrPCNMWEWe5 /ywnmT26OtNzAXxC75tspwxphsPc+SLSjH//xVtNCOqv2Hqs2D+B8+D7yuHe/eq2s8qO A5eA==
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=7NiQhaEVOWz07ypDSBIY3EBCmQ9YRyCYPV9MJLixmdk=; b=WjqB8XkB6Fxs/MIy6xHq7UQCOUrDdUukqDhn3CZ07mhlcn4UH5IZpxP/4BWxbfCvVg rW2NtKX8S+p/R33BzkNLK8ZF/NOBS8wXAGXsAvJwYizfHKhWR/mdbFSRfaN0BTpPnaAw 4Mbk5JcyvO1IEtmIyl4qizcgk+RvDsfwM4FgCt3nkQX/dXkyZG4pc/6RsSeBEkAt/K29 //aZK4lX0D1J4oMOBHoAxTgj7V8tbVbt2mS/pSmXZtqr68ngojfYkX4FYLzOqaWnr6bQ MSu0UmnPWoI43Q4ALUkUctjYEoNjdfOTGRkTeCbXx+61txjzLqHJjGFMOpcZjuHPsGIq dW2A==
X-Gm-Message-State: AKGB3mItz3fnerjR2xImL/N8+exzmvqtgu+LCyLe2lZVFmwJ/Oni6KCm UvUAXZwnxXPuu4RGT6taPEznHn/z
X-Google-Smtp-Source: ACJfBosS1e1onMCS/HMyp5rQbLG7ikGpV+/x3vdVG5ByXNt4g8iM0B9hvk/0zu3DLwesMd4yUluGzA==
X-Received: by 10.107.132.24 with SMTP id g24mr31541749iod.151.1514242251301; Mon, 25 Dec 2017 14:50:51 -0800 (PST)
Received: from [192.168.0.111] (47-36-65-40.dhcp.reno.nv.charter.com. [47.36.65.40]) by smtp.gmail.com with ESMTPSA id d3sm8530343itf.1.2017.12.25.14.50.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Dec 2017 14:50:50 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-D7374DDD-BF6A-47AB-8A82-2BC2D071FF3A
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (15C153)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304AEDDC@NKGEML515-MBX.china.huawei.com>
Date: Mon, 25 Dec 2017 14:50:49 -0800
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Christian Hopps <chopps@chopps.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>, "draft-ietf-isis-segment-routing-msd@ietf.org" <draft-ietf-isis-segment-routing-msd@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <B17E3B51-7936-476E-A621-969376BF5F10@gmail.com>
References: <254873F7-39C8-461F-B69F-8B68842181E3@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7900@NKGEML515-MBS.china.huawei.com> <CAFAzdPW1YVOUwmipVLWKnGwN3=WFBq7CiY2wzGJYXpGOhRCF3Q@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304ADD4F@NKGEML515-MBX.china.huawei.com> <CAFAzdPVuDq40A=xJ+7XZpev9b62gUiGrCYVPLSK+9eWH5ZC9OQ@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304AEDDC@NKGEML515-MBX.china.huawei.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/XP6u1xUux9bqo-Aw1GcPx2bMcKQ>
Subject: Re: [Isis-wg] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIFdHIExhc3Qg?= =?utf-8?q?Call_for_draft-ietf-isis-segment-routing-msd-07?=
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Dec 2017 22:50:57 -0000

Xiaohu,

Thanks for your comments, I’ll add text clarifying link SID disposition semantics.

Regards,
Jeff

> On Dec 24, 2017, at 23:33, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> 
> Hi Jeff,
>  
> It seems that you have not yet understood my points or I have not yet understood your pointsJ
>  
> Anyway, if many of my questions have been addressed in the previous discussions, it seems that it’s not just me who have those doubts. Hence, wouldn’t it be better to add some related clarifications in the draft as well after the previous discussions?  Otherwise, when anybody else has the same or similar doubts someday, it seems inefficient to request him or her to dig in the mailing-list. No?
>  
> Xiaohu
>  
> 发件人: Jeff Tantsura [mailto:jefftant.ietf@gmail.com] 
> 发送时间: 2017年12月25日 14:43
> 收件人: Xuxiaohu
> 抄送: Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); Christian Hopps; isis-wg@ietf.org; isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
> 主题: Re: 答复: 答复: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
>  
> Hi Xiaohu,
> 
> No, you are missing the point. 
> It is not important whether SID imposition is done on ingress, egress, or anywhere else, what is important is what shows up on the wire when a packet leaves the node.
> 
> Please read the answers before asking other questions, many of your questions have been addressed in the previous discussions, search for them, before sending yet another email.
> 
> Thanks,
> Jeff
> On Sun, Dec 24, 2017 at 19:08 Xuxiaohu <xuxiaohu@huawei.com> wrote:
> Hi Jef,
>  
> If I understand your abstraction approach correctly, the MSD advertisement at per-link granularity makes sense in the case where the label stack is imposed on egress line-cards.  However, it makes little sense in the case where the label stack is imposed on ingress line-cards. In the multi-chassis system example as described in my previous email, what is the MSD value of the interface B advertised via IGP since that MSD value heavily depends on the incoming interface where the packet arrives. If that value is set to the minimum of all possible interfaces’ capability of maximum label stack imposition,  it’s almost no difference from the MSD of that node.
>  
> My question is: if the MSD advertisement at per-link granularity is so important, why not improve it so as to make it valuable in both cases? Otherwise, why not just advertise the MSD at per-node granularity which seems simpler?
>  
> Best regards,
> Xiaohu
>  
> 发件人: Jeff Tantsura [mailto:jefftant.ietf@gmail.com]
> 发送时间: 2017年12月25日 10:10
> 收件人: Xuxiaohu
> 抄送: Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); Christian Hopps; isis-wg@ietf.org; isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
> 主题: Re: 答复: 答复: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
>  
> Hi Xixiaohu,
> 
> In every case, it is what shows up when a packet leaves outgoing interface, by doing so we abstract the completely of SID imposition, that could be different on a single NPU vs a chassis vs a multi-chassis system.
> 
> Hope this clarifies.
> 
> Cheers,
> Jeff
> On Fri, Dec 22, 2017 at 20:33 Xuxiaohu <xuxiaohu@huawei.com> wrote:
> Hi Jeff,
> 
> As for per-link MSD information, I have the following comments:
> 
> 1) I wonder whether you have considered the implementation differences on the label stack imposition process among different vendors. More specially, some chooses to impose the label stack on ingress line-cards while others choose to impose the label stack on egress line-cards due to different tradeoffs. For example, when a packet arrives at interface A of linecard X while departuring from interface B of linecard Y, assume the MSD type 1 values of linecard A and B are different, which interface's MSD value should be taken into account when calculating a SR path. Does it require IGP or BGP-LS to be extended to advertise the manner of label stack imposition of a given node as well (i.e., imposition on ingress or egress linecard)?
> 
> 2) In the SID-binding case, if the incoming interface or outgoing interface for a given packet received by the Binding-SID anchor node is changed on the fly due to whatever reasons (e.g., FRR or ECMP ), how to deal with such case?
> 
> Best regards,
> Xiaohu
> 
> > -----邮件原件-----
> > 发件人: Jeff Tantsura [mailto:jefftant.ietf@gmail.com]
> > 发送时间: 2017年12月23日 2:50
> > 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); Christian
> > Hopps; isis-wg@ietf.org
> > 抄送: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
> > 主题: Re: 答复: 答复: [Isis-wg] WG Last Call for
> > draft-ietf-isis-segment-routing-msd-07
> >
> > Xiaohu,
> >
> > PCEP and ISIS(OSPF) are quite different in their functionality and not meant to
> > do the same thing. Wrt SR ecosystem, PCEP is optional, while IGP’s are
> > mandatory.
> > When it comes to a node capability, PCEP and IGP’s provide same information
> > and fully aligned, however more granular, per link information is only available
> > in IGPs, and this is as per design (not a bug).
> > PCEP SR draft (which I’m co-author of) will be last called soon, please make
> > sure you provide your comments to the PCE WG.
> >
> > The intention of this thread is to last call draft-ietf-isis-segment-routing-msd,
> > that has Type 1 defined and creates IANA registry for the future Types.
> > I’d appreciate your comments specifically to the draft, and if you have got any
> > technical objection, would be happy to address them.
> >
> > Thanks!
> >
> > Cheers,
> > Jeff
> >
> > -----Original Message-----
> > From: Xuxiaohu <xuxiaohu@huawei.com>
> > Date: Thursday, December 21, 2017 at 16:42
> > To: Jeff Tantsura <jefftant.ietf@gmail.com>om>, "Les Ginsberg (ginsberg)"
> > <ginsberg@cisco.com>om>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>om>,
> > Christian Hopps <chopps@chopps.org>rg>, "isis-wg@ietf.org" <isis-wg@ietf.org>
> > Cc: "isis-ads@ietf.org" <isis-ads@ietf.org>rg>,
> > "draft-ietf-isis-segment-routing-msd@ietf.org"
> > <draft-ietf-isis-segment-routing-msd@ietf.org>
> > Subject: 答复: 答复: [Isis-wg] WG Last Call for
> > draft-ietf-isis-segment-routing-msd-07
> >
> >     Jeff,
> >
> >     IMHO, the MSD or the MSD(type 1) just indicates a certain label imposition
> > capability which should be signaling-agnostic. More specially, the MSD or
> > MSD(type1) capability could be signaled via IGP, BGP or PCEP.
> >
> >     If the semantic of MSD (type 1) as defined in your IGP-MSD draft equals the
> > semantics of MSD as defined in PCEP-SR draft, I believe it'd better to iron out
> > such terminology inconsistency ASAP.
> >
> >     Best regards,
> >     Xiaohu
> >
> >     > -----邮件原件-----
> >     > 发件人: Jeff Tantsura [mailto:jefftant.ietf@gmail.com]
> >     > 发送时间: 2017年12月22日 5:22
> >     > 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Ketan Talaulikar (ketant);
> > Christian
> >     > Hopps; isis-wg@ietf.org
> >     > 抄送: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
> >     > 主题: Re: 答复: [Isis-wg] WG Last Call for
> > draft-ietf-isis-segment-routing-msd-07
> >     >
> >     > Xuxiaohu,
> >     >
> >     > To clarify:
> >     > The concept had been developed in both, in parallel, however PCEP
> >     > implementation is limited (node only, PCC in question has to have PCEP
> > sessions
> >     > with the PCE), and this is clearly stated in the draft – if MSD is known
> > from both
> >     > sources (PCEP and IGP/BGP-LS) the later takes precedence. IGP drafts are
> > the
> >     > source of truth when it comes to semantics definitions.
> >
> >
> >
> >     > Personally, I don’t see any confusion wrt name, all drafts have been
> > around for
> >     > quite some time, reviewed by many people, presented in academia and
> >     > networking events, noone was ever confused…
> >     >
> >     > I’m not sure about value of your proposal either, and I’d leave the
> > decision
> >     > what to use to people who are the consumers of the technology, those
> > who are
> >     > going to implement it (at least 3 MSD implementations are on their
> > ways).
> >     >
> >     > As the last point – we are not “considering” expanding, the draft is clear
> > about
> >     > the future extensions to come and encoding is done in a way to facilitate
> > such
> >     > extensions.
> >     > This is the working group last call for the draft, not a discussion whether
> > we
> >     > should proceed with the technology:
> >     > If you see any technical problems with the solution proposed – I’d be
> > the first
> >     > to listen to you and address them!
> >     >
> >     > Happy holidays!
> >     >
> >     > Cheers,
> >     > Jeff
> >     >
> >     > -----Original Message-----
> >     > From: Xuxiaohu <xuxiaohu@huawei.com>
> >     > Date: Wednesday, December 20, 2017 at 18:40
> >     > To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>om>, "Ketan Talaulikar
> > (ketant)"
> >     > <ketant@cisco.com>om>, Christian Hopps <chopps@chopps.org>rg>,
> > "isis-wg@ietf.org"
> >     > <isis-wg@ietf.org>
> >     > Cc: "isis-ads@ietf.org" <isis-ads@ietf.org>rg>,
> >     > "draft-ietf-isis-segment-routing-msd@ietf.org"
> >     > <draft-ietf-isis-segment-routing-msd@ietf.org>
> >     > Subject: 答复: [Isis-wg] WG Last Call for
> > draft-ietf-isis-segment-routing-msd-07
> >     > Resent-From: <alias-bounces@ietf.org>
> >     > Resent-To: <jefftant.ietf@gmail.com>om>, <uma.chunduri@huawei.com>om>,
> >     > <aldrin.ietf@gmail.com>om>, <ginsberg@cisco.com>
> >     > Resent-Date: Wed, 20 Dec 2017 18:40:16 -0800 (PST)
> >     >
> >     >     Hi Les,
> >     >
> >     >     If I understand it correctly, the MSD concept was originated from
> >     > (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7) as
> >     > described below:
> >     >
> >     >     "The "Maximum SID Depth" (1
> >     >        octet) field (MSD) specifies the maximum number of SIDs (MPLS
> > label
> >     >        stack depth in the context of this document) that a PCC is
> > capable of
> >     >        imposing on a packet."
> >     >
> >     >     Before considering expanding the semantics of the MSD concept as
> > defined
> >     > in the above PCE-SR draft, how about first considering renaming the
> > capability
> >     > of imposing the maximum number of labels so as to eliminate possible
> >     > confusions, e.g., Writable Label-stack Depth (WLD) as opposed to the
> > Readable
> >     > Label-stack Depth (RLD) as defined in
> >     > (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc) and
> >     > (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) ?
> >     >
> >     >     Best regards,
> >     >     Xiaohu
> >     >
> >     >     > -----邮件原件-----
> >     >     > 发件人: Isis-wg [mailto:isis-wg-bounces@ietf.org] 代表 Les
> > Ginsberg
> >     > (ginsberg)
> >     >     > 发送时间: 2017年12月21日 4:02
> >     >     > 收件人: Ketan Talaulikar (ketant); Christian Hopps;
> > isis-wg@ietf.org
> >     >     > 抄送: isis-ads@ietf.org;
> > draft-ietf-isis-segment-routing-msd@ietf.org
> >     >     > 主题: Re: [Isis-wg] WG Last Call for
> > draft-ietf-isis-segment-routing-msd-07
> >     >     >
> >     >     > Ketan -
> >     >     >
> >     >     > Thanx for the comments.
> >     >     > I think we do want to allow MSD support for values other than
> > imposition
> >     >     > values. We will revise the text so we are not restricted to only
> > imposition
> >     > cases.
> >     >     >
> >     >     >   Les
> >     >     >
> >     >     >
> >     >     > > -----Original Message-----
> >     >     > > From: Ketan Talaulikar (ketant)
> >     >     > > Sent: Wednesday, December 20, 2017 1:51 AM
> >     >     > > To: Christian Hopps <chopps@chopps.org>rg>; isis-wg@ietf.org
> >     >     > > Cc: isis-ads@ietf.org;
> > draft-ietf-isis-segment-routing-msd@ietf.org
> >     >     > > Subject: RE: [Isis-wg] WG Last Call for
> >     >     > > draft-ietf-isis-segment-routing-msd-07
> >     >     > >
> >     >     > > Hello,
> >     >     > >
> >     >     > > I support this document and would like to ask the authors and
> > WG to
> >     >     > > consider if we can expand the scope of this draft to not just
> >     >     > > "imposition" of the SID stack but also other similar limits related
> > to
> >     > other
> >     >     > actions (e.g.
> >     >     > > reading, processing, etc.). With Segment Routing, we are coming
> > across
> >     >     > > various actions that nodes need to do with the SID stack for
> > different
> >     >     > > purposes and IMHO it would be useful to extend the MSD ability
> > to
> >     >     > > cover those as they arise.
> >     >     > >
> >     >     > > Thanks,
> >     >     > > Ketan
> >     >     > >
> >     >     > > -----Original Message-----
> >     >     > > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of
> > Christian
> >     >     > > Hopps
> >     >     > > Sent: 20 December 2017 14:03
> >     >     > > To: isis-wg@ietf.org
> >     >     > > Cc: isis-ads@ietf.org;
> > draft-ietf-isis-segment-routing-msd@ietf.org
> >     >     > > Subject: [Isis-wg] WG Last Call for
> >     >     > > draft-ietf-isis-segment-routing-msd-07
> >     >     > >
> >     >     > >
> >     >     > > The authors have asked for and we are starting a WG Last Call on
> >     >     > >
> >     >     > >
> > https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
> >     >     > >
> >     >     > > which will last an extended 4 weeks to allow for year-end PTO
> > patterns.
> >     >     > >
> >     >     > > An IPR statement exists:
> >     >     > >
> >     >     > >
> >     >     > >
> > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-is
> >     >     > > is-
> >     >     > > segment-routing-msd
> >     >     > >
> >     >     > > Authors please reply to the list indicating whether you are aware
> > of
> >     >     > > any
> >     >     > > *new* IPR.
> >     >     > >
> >     >     > > Thanks,
> >     >     > > Chris.
> >     >     > >
> >     >     > > _______________________________________________
> >     >     > > Isis-wg mailing list
> >     >     > > Isis-wg@ietf.org
> >     >     > > https://www.ietf.org/mailman/listinfo/isis-wg
> >     >     >
> >     >     > _______________________________________________
> >     >     > Isis-wg mailing list
> >     >     > Isis-wg@ietf.org
> >     >     > https://www.ietf.org/mailman/listinfo/isis-wg
> >     >
> >     >
> >
> >
> >