[Isis-wg] 答复: 答复: 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07
Xuxiaohu <xuxiaohu@huawei.com> Sat, 23 December 2017 04:33 UTC
Return-Path: <xuxiaohu@huawei.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 8C97B124F57; Fri, 22 Dec 2017 20:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 DFJtmos3eD20; Fri, 22 Dec 2017 20:33:16 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECC9120713; Fri, 22 Dec 2017 20:33:15 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7D1A057BCDFE1; Sat, 23 Dec 2017 04:33:11 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 23 Dec 2017 04:33:02 +0000
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Sat, 23 Dec 2017 12:32:58 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>, "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>
CC: "isis-ads@ietf.org" <isis-ads@ietf.org>, "draft-ietf-isis-segment-routing-msd@ietf.org" <draft-ietf-isis-segment-routing-msd@ietf.org>
Thread-Topic: 答复: 答复: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
Thread-Index: AQHTe1XMhwSpkOVuXUa7H6XL3EUSVKNQUQMA
Date: Sat, 23 Dec 2017 04:32:58 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7900@NKGEML515-MBS.china.huawei.com>
References: <254873F7-39C8-461F-B69F-8B68842181E3@gmail.com>
In-Reply-To: <254873F7-39C8-461F-B69F-8B68842181E3@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.184.181]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/xeZQWSH9Pu6SeKOCpcQrOJArf5U>
Subject: [Isis-wg] 答复: 答复: 答复: WG Last 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: Sat, 23 Dec 2017 04:33:18 -0000
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>, "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> > Cc: "isis-ads@ietf.org" <isis-ads@ietf.org>, > "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>, "Ketan Talaulikar > (ketant)" > > <ketant@cisco.com>, Christian Hopps <chopps@chopps.org>, > "isis-wg@ietf.org" > > <isis-wg@ietf.org> > > Cc: "isis-ads@ietf.org" <isis-ads@ietf.org>, > > "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>, <uma.chunduri@huawei.com>, > > <aldrin.ietf@gmail.com>, <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>; 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 > > > > > > >
- Re: [Isis-wg] =?UTF-8?B?562U5aSN?=: =?UTF-8?B?IOe… Jeff Tantsura
- [Isis-wg] Regarding the relationship between MSD … Xuxiaohu
- [Isis-wg] 答复: 答复: 答复: WG Last Call for draft-ietf… Xuxiaohu
- Re: [Isis-wg] 答复: 答复: WG Last Call for draft-ietf… Jeff Tantsura
- Re: [Isis-wg] 答复: 答复: 答复: WG Last Call for draft-… Jeff Tantsura