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

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 25 December 2017 02:10 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 6C289124C27; Sun, 24 Dec 2017 18:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 5SyN0_Gsx4f6; Sun, 24 Dec 2017 18:10:02 -0800 (PST)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 1CF8B1241FC; Sun, 24 Dec 2017 18:10:02 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id x129so29740906iod.13; Sun, 24 Dec 2017 18:10:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uaR1pbnFzfjIkjhr3kmM3Tz4TiWBp7eKWfjDHdXNYfc=; b=ck4n1kCy/0ZGbZiG31RHVQmbi5Qcj6i/s1je/DPLKfvawJvDULDzLMN5TZ0wHwRx9L Mc8rEXBfv/kWkmU4uArS7cEmztZDs7BAGYnl/SX9nvy3GmEbuUjqwtR3pzJkeEZjriuj 5Y3J8pp9RPOK1PUygTLl+4c7ZuMeoJFKl4E8P01xiyunjd+pwI6cCSPhsjckVQSsHrcL 6QhmpSxcdTwBhFUt1AEFeMfzRyfMectSVL4lwU8R8qWVrt9boVxH0aCH99Sn5frTQIIt p+bZ34U4LQ/wGYMVGNoUJIWFWo6XNr/fvs9860Iycuzw8/bdsQwJH2MgNQOEtnNEG49a K7AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uaR1pbnFzfjIkjhr3kmM3Tz4TiWBp7eKWfjDHdXNYfc=; b=QAWe5oN+8zBO8y9UP/DBj5BSQupP4A+SpQ0yIgIiAAyZdbVXv4m6GWeoRdjsFeFZog aoYVcmz/9HktAQc9OPcMKUt44AkqrMSr8KjJTPM8uGgLZcN51kda+vdJ4AST8s284lF2 PtvXOs/Hfqt1W4BNH+eHxf1C4DnRhTPmAuywPNl4kMAinl/qqS/jSOsG39YAAVbhiRf9 1olLiFTgRNUnveFSANCRl2MovmsFQLPuHCVsOXybQ7z1ySNliG7hwXU+Hq9oPwi7eD0r iydN+IAi19vCYgFJFseSPmNfwrKZM5kZ7BK9tUgrNfQdDqr+GXOfM0Iw06nGCxoXDId2 +CgA==
X-Gm-Message-State: AKGB3mI3TTYn/YjbNuzyg1wkoKB16Htsh9IrO6ioZCl88xFxhZOZXYS2 1mKKgTNpqt+HQkoongaxSRDMOPDuAZZtK6rgWsk=
X-Google-Smtp-Source: ACJfBosDvenUADTY4zNhw+HtncEVdNSMIDwejG/8R73WfRbh8tXKxClIla9f1jejk8adhRyGcF2srwRjr42fJ8vUMV4=
X-Received: by 10.107.131.200 with SMTP id n69mr11434730ioi.36.1514167801220; Sun, 24 Dec 2017 18:10:01 -0800 (PST)
MIME-Version: 1.0
References: <254873F7-39C8-461F-B69F-8B68842181E3@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7900@NKGEML515-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7900@NKGEML515-MBS.china.huawei.com>
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Date: Mon, 25 Dec 2017 02:09:50 +0000
Message-ID: <CAFAzdPW1YVOUwmipVLWKnGwN3=WFBq7CiY2wzGJYXpGOhRCF3Q@mail.gmail.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
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-Type: multipart/alternative; boundary="001a113ecbbcec13d0056120a9ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/N_4567xZG48BeHokVVbXKvNLsfU>
Subject: Re: [Isis-wg] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBXRyBMYXN0IENhbGwgZm9y?= =?utf-8?q?_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 02:10:05 -0000

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
> >     >
> >     >
> >
> >
> >
>
>