Xiaohu, Thanks for your comments, I’ll add text clarifying link SID disposition semantics.
Regards, Jeff > On Dec 24, 2017, at 23:33, Xuxiaohu <xuxia...@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.i...@gmail.com] > 发送时间: 2017年12月25日 14:43 > 收件人: Xuxiaohu > 抄送: Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); Christian Hopps; > isis-wg@ietf.org; isis-...@ietf.org; > draft-ietf-isis-segment-routing-...@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 <xuxia...@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.i...@gmail.com] > 发送时间: 2017年12月25日 10:10 > 收件人: Xuxiaohu > 抄送: Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); Christian Hopps; > isis-wg@ietf.org; isis-...@ietf.org; > draft-ietf-isis-segment-routing-...@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 <xuxia...@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.i...@gmail.com] > > 发送时间: 2017年12月23日 2:50 > > 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); Christian > > Hopps; isis-wg@ietf.org > > 抄送: isis-...@ietf.org; draft-ietf-isis-segment-routing-...@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 <xuxia...@huawei.com> > > Date: Thursday, December 21, 2017 at 16:42 > > To: Jeff Tantsura <jefftant.i...@gmail.com>, "Les Ginsberg (ginsberg)" > > <ginsb...@cisco.com>, "Ketan Talaulikar (ketant)" <ket...@cisco.com>, > > Christian Hopps <cho...@chopps.org>, "isis-wg@ietf.org" <isis-wg@ietf.org> > > Cc: "isis-...@ietf.org" <isis-...@ietf.org>, > > "draft-ietf-isis-segment-routing-...@ietf.org" > > <draft-ietf-isis-segment-routing-...@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.i...@gmail.com] > > > 发送时间: 2017年12月22日 5:22 > > > 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); > > Christian > > > Hopps; isis-wg@ietf.org > > > 抄送: isis-...@ietf.org; draft-ietf-isis-segment-routing-...@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 <xuxia...@huawei.com> > > > Date: Wednesday, December 20, 2017 at 18:40 > > > To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, "Ketan Talaulikar > > (ketant)" > > > <ket...@cisco.com>, Christian Hopps <cho...@chopps.org>, > > "isis-wg@ietf.org" > > > <isis-wg@ietf.org> > > > Cc: "isis-...@ietf.org" <isis-...@ietf.org>, > > > "draft-ietf-isis-segment-routing-...@ietf.org" > > > <draft-ietf-isis-segment-routing-...@ietf.org> > > > Subject: 答复: [Isis-wg] WG Last Call for > > draft-ietf-isis-segment-routing-msd-07 > > > Resent-From: <alias-boun...@ietf.org> > > > Resent-To: <jefftant.i...@gmail.com>, <uma.chund...@huawei.com>, > > > <aldrin.i...@gmail.com>, <ginsb...@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-boun...@ietf.org] 代表 Les > > Ginsberg > > > (ginsberg) > > > > 发送时间: 2017年12月21日 4:02 > > > > 收件人: Ketan Talaulikar (ketant); Christian Hopps; > > isis-wg@ietf.org > > > > 抄送: isis-...@ietf.org; > > draft-ietf-isis-segment-routing-...@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 <cho...@chopps.org>; isis-wg@ietf.org > > > > > Cc: isis-...@ietf.org; > > draft-ietf-isis-segment-routing-...@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-boun...@ietf.org] On Behalf Of > > Christian > > > > > Hopps > > > > > Sent: 20 December 2017 14:03 > > > > > To: isis-wg@ietf.org > > > > > Cc: isis-...@ietf.org; > > draft-ietf-isis-segment-routing-...@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 > > > > > > > > > > > >
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
