Hi Jeff, Correct. I referenced below to ‘dominant use cases being entropy” for a reason.
There is indeed use case regarding alternate marking using Synonymous Flow Labels and another one involving potential statistics marking using targeted labels. This understanding drove to question at IETF100 IDR meeting to go for either “ERLD” or “RLD/ELC” (or even additional capabilities signalled). The consensus at IDR@IETF100 was that dominant use-case is entropy and that ERLD is the logical info to signal in BGP-LS. I had/have no strong bias with going either way. I just am little dazzled that for some reason the discussion is opened up again now we had consensus. G/ > On 23 Dec 2017, at 20:09, Jeff Tantsura <jefftant.i...@gmail.com> wrote: > > Gunter, > > As I also said in Singapore - another interesting use case would be related > to statistics, without going into semantics, we might need another SID in the > stack to uniquely identify a tunnel (domain wide)that would result in a > counter hit. RLD is crucial here. > There would be some control plan implications on how to correlate local > counter name to domain wide tunnel identifier. Some YANG work as well > (streaming telemetry related). > > Happy Holidays everyone! > > Regards, > Jeff > > On Dec 23, 2017, at 01:25, Gunter Van De Velde <guntervandeveld...@icloud.com > <mailto:guntervandeveld...@icloud.com>> wrote: > >> Hi Xiaohu, >> >> Thanks for digging through the draft. >> >> See inline: GV> >> >>> On 23 Dec 2017, at 09:40, Xuxiaohu <xuxia...@huawei.com >>> <mailto:xuxia...@huawei.com>> 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 >> <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:ket...@cisco.com >>>> <mailto:ket...@cisco.com>] >>>> 发送时间: 2017年12月21日 12:16 >>>> 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Christian Hopps; isis...@ietf.org >>>> <mailto:isis...@ietf.org> >>>> 抄送: isis-...@ietf.org <mailto:isis-...@ietf.org>; >>>> draft-ietf-isis-segment-routing-...@ietf.org >>>> <mailto: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 <mailto:xuxia...@huawei.com>] >>>> Sent: 21 December 2017 08:10 >>>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com >>>> <mailto:ginsb...@cisco.com>>; Ketan Talaulikar (ketant) >>>> <ket...@cisco.com <mailto:ket...@cisco.com>>; Christian Hopps >>>> <cho...@chopps.org <mailto:cho...@chopps.org>>; isis...@ietf.org >>>> <mailto:isis...@ietf.org> >>>> Cc: isis-...@ietf.org <mailto:isis-...@ietf.org>; >>>> draft-ietf-isis-segment-routing-...@ietf.org >>>> <mailto: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 >>>> <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 >>>> <https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc>) >>>> and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc >>>> <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc>) ? >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> -----邮件原件----- >>>>> 发件人: Isis-wg [mailto:isis-wg-boun...@ietf.org >>>>> <mailto:isis-wg-boun...@ietf.org>] 代表 Les Ginsberg >>>>> (ginsberg) >>>>> 发送时间: 2017年12月21日 4:02 >>>>> 收件人: Ketan Talaulikar (ketant); Christian Hopps; isis...@ietf.org >>>>> <mailto:isis...@ietf.org> >>>>> 抄送: isis-...@ietf.org <mailto:isis-...@ietf.org>; >>>>> draft-ietf-isis-segment-routing-...@ietf.org >>>>> <mailto: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 <mailto:cho...@chopps.org>>; >>>>>> isis...@ietf.org <mailto:isis...@ietf.org> >>>>>> Cc: isis-...@ietf.org <mailto:isis-...@ietf.org>; >>>>>> draft-ietf-isis-segment-routing-...@ietf.org >>>>>> <mailto: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 >>>>>> <mailto:isis-wg-boun...@ietf.org>] On Behalf Of >>>>>> Christian Hopps >>>>>> Sent: 20 December 2017 14:03 >>>>>> To: isis...@ietf.org <mailto:isis...@ietf.org> >>>>>> Cc: isis-...@ietf.org <mailto:isis-...@ietf.org>; >>>>>> draft-ietf-isis-segment-routing-...@ietf.org >>>>>> <mailto: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 >>>>>> <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- >>>>>> <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 <mailto:isis...@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>> <https://www.ietf.org/mailman/listinfo/isis-wg> >>>>> >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> isis...@ietf.org <mailto:isis...@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>> <https://www.ietf.org/mailman/listinfo/isis-wg> >>> _______________________________________________ >>> Idr mailing list >>> i...@ietf.org <mailto:i...@ietf.org> >>> https://www.ietf.org/mailman/listinfo/idr >>> <https://www.ietf.org/mailman/listinfo/idr> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org <mailto:OSPF@ietf.org> >> https://www.ietf.org/mailman/listinfo/ospf >> <https://www.ietf.org/mailman/listinfo/ospf>
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
