Hi Xiaohu, Thanks for digging through the draft.
See inline: GV> > On 23 Dec 2017, at 09:40, Xuxiaohu <[email protected]> wrote: > > 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. > GV> This is exactly what I asked during the IETF100 IDR slot when I presented the updated work. The consensus was that signalling of a readable label depth has entropy as the dominant use-case scenario. This is now documented in: https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 <https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07>. Consensus from IETF100 IDR meeting was that ERLD is the way forward for BGP-LS based signalling, and that maybe this should also be the case for both ISIS and OSPF drafts (however, that is different discussion). I agree with IDR consensus and it seems the most pragmatic path forward. > 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? > GV> I have no intend to open up that discussion at all, as it seems a pragmatic consensus was reached. Steering seems to become more complex when link based ERLD is proposed and a potential set of different ERLDs are signalled due to capabilities of the line-card HW. If for https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 we just need node based ERLD, then I that is just fine. My personal opinion is that we need node ERLD for node for sure in BGP-LS, and that link ERLD is a nice to have. It seems relative easy and pragmatic to add both Link and node ERLD in current version of the BGP-LS ERLD document. > 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? > > GV> Yes, indeed, again that was reason again that the work was presented during IETF100 as I had some doubts myself. During IETF100 IDR meeting, I learned and was confirmed that ERLD is now in the SPRING entropy label draft and that hence ERLD is to be signalled for the most prominent use-case driving readable label depth signalling https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 <https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07>. I see no reason to open that discussion again, and current BGP-LS ERLD draft is inline the most dominant use-case scenario (Entropy based load-balancing). I could change the existing text to refer to https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 <https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07> and only mention ERLD (and no longer mention ELC/RLD at all) if IDR WG find that better? Brgds, G/ > Best regards, > Xiaohu > >> -----邮件原件----- >> 发件人: Ketan Talaulikar (ketant) [mailto:[email protected]] >> 发送时间: 2017年12月21日 12:16 >> 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Christian Hopps; [email protected] >> 抄送: [email protected]; [email protected] >> 主题: 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:[email protected]] >> Sent: 21 December 2017 08:10 >> To: Les Ginsberg (ginsberg) <[email protected]>; Ketan Talaulikar (ketant) >> <[email protected]>; Christian Hopps <[email protected]>; [email protected] >> Cc: [email protected]; [email protected] >> 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:[email protected]] 代表 Les Ginsberg >>> (ginsberg) >>> 发送时间: 2017年12月21日 4:02 >>> 收件人: Ketan Talaulikar (ketant); Christian Hopps; [email protected] >>> 抄送: [email protected]; [email protected] >>> 主题: 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 <[email protected]>; [email protected] >>>> Cc: [email protected]; [email protected] >>>> 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:[email protected]] On Behalf Of >>>> Christian Hopps >>>> Sent: 20 December 2017 14:03 >>>> To: [email protected] >>>> Cc: [email protected]; [email protected] >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ > Idr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/idr
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
