Hi all, I just read the draft (draft-ietf-idr-bgp-ls-segment-routing-rld) due to the curiosity of the ERLD terminology. I have thought that this draft is just about a straightforward BGP-LS extension for the RLD concept as defined in draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc according to the draft name. However it isn't in fact. Maybe the draft name should have been *-erld rather than *-rld.
I have the following comments on this draft (draft-ietf-idr-bgp-ls-segment-routing-rld): 1) ERLD means Entropy capable Readable Label Depth as defined in this draft. However, it said "...A network node signalling an ERLD MUST support the ability to read the signalled number of labels before any action is done upon the packet..." I'm wondering what actions other than the EL-based LB action the "any action" could be since the ERLD has been tightly coupled with the EL-based LB mechanism. In contrast, the RLD as defined in the two IGP drafts is not tightly couple with the EL-based LB action. In other words, the RLD capability could be applicable to other use cases besides the EL-based LB. 2) It said "...In existing technology both ISIS [4] and OSPF [3] have proposed extensions to signal the RLD (Readable Label Depth) and ELC (Entropy Label Capability) of a node or link. " However, there is no extensions to signal the RLD and ELC of a link, if I remembered correctly as a co-author of the above two IGP drafts:) In fact, when the two IGP drafts were initially proposed, some guys does argue why not advertise ELC and RLD of the per-link granularity as well. After some discussion in IETF, a rough consensus had been reached that the advertisement of ELC and RLD at a per node granularity was good enough at that time. That's the reason why the two IGP drafts had not been extended to advertise ELC and RLD at a per link granularity therefore. Maybe we should reopen such discussion now? 3) It said "...if a network SDN controller is connected to the network through a BGP-LS session and not through ISIS or OSPF technology, then both RLD and ELC needs to be signaled in BGP-LS accordingly. This document describes the extension BGP-LS requires to transport the combination of RLD and ELC into according ERLD attributes for nodes and links..." I have not yet found any explanation about the motivation for advertising the combination of RLD and ELC into according ERLD attributes rather than advertising these two attributes separately. Would it be better to give any explanation about such motivation in the Problem Statement section? Best regards, Xiaohu > -----邮件原件----- > 发件人: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] > 发送时间: 2017年12月21日 12:16 > 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Christian Hopps; isis...@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 Xu, > > I am arguing the exact opposite of what you are saying. > > Let us leave ELC/ERLD aside since it is very limited to entropy label > use-case and > the proposed IGP/BGP-LS encoding is very specific to that. I am not sure if > this is > the time anymore to revisit that. > > The MSD proposal came later and I support is since I've found its use to be > much more widespread and the proposed IGP/BGP-LS protocol encoding to be > very efficient as an implementer of these protocols. Hence the request to not > restrict it to "writable" or "imposition" cases solely. It is also not just > about > "readability" - which by itself is pretty meaningless. Even ERLD is about > "reading" and then "doing *something specific* about it" as discussed in > ietf-spring-segment-routing-mpls. > > There is no second thoughts about the IGP ELC drafts and they are very useful > and necessary. Just to be clear there is *no functional or operational change* > that I am arguing for here. The discussion is purely on the way to handle > these > encodings and whether we can use the MSD mechanism in a generalized > manner. > > Thanks, > Ketan > > -----Original Message----- > From: Xuxiaohu [mailto:xuxia...@huawei.com] > Sent: 21 December 2017 08:10 > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Ketan Talaulikar (ketant) > <ket...@cisco.com>; Christian Hopps <cho...@chopps.org>; isis...@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 > > 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...@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...@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...@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...@ietf.org > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list > > isis...@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
