Re: [OSPF] [Idr] A comment regarding the relationship between RLD and ERLD

Gunter Van De Velde <guntervandeveldecc@icloud.com> Sat, 23 December 2017 20:07 UTC

Return-Path: <guntervandeveldecc@icloud.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F5612025C; Sat, 23 Dec 2017 12:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
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 jCZUdECN_wiW; Sat, 23 Dec 2017 12:07:49 -0800 (PST)
Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2371200F3; Sat, 23 Dec 2017 12:07:49 -0800 (PST)
Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P1F00600JR7NS00@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 20:07:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1514059668; bh=oB6mn4ivHya0wBcQaVYdbwjMxTU5JECQKTM7tUHprcY=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=E9WKQDGPkcLc9sz9Z437p+JzmDsSbihNau0dwwFW7V3icNZMPGwK4yn3pbXzd1al5 /WjnPvL67a04iXKLSN1KTevGh5sDePeXAodu85Y+MjQdLc4/iGZLQfz/0Yi6zh4u0e X8vLhsSwDFBWNiD8+29Tu//T0ToPqHYOMYmylFASuiHmUFOA8lc9f8nyGfVgoCvVDQ 2qDhMcJ8m3PlyQDJ7mtD/L9Vu5PVIoorMt27mRbFD2b/OHCuo3uTbMuySK2sfxR+ff FD1RE0VHGX/PSlfFWamkv52lxlJK092zTAYIDQyi71MuU5s3YXkzdYi6F4vXb7fbOg gn5Lw1lrwkDiw==
Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P1F001JRJWQIN30@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 20:07:43 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-23_12:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712230277
From: Gunter Van De Velde <guntervandeveldecc@icloud.com>
Message-id: <CF143D2E-A48B-4894-BDD7-2D3D144D0BEA@icloud.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD"
MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sat, 23 Dec 2017 21:07:38 +0100
In-reply-to: <AC35E22C-51A9-47DC-BF42-FBBF400ABC0F@gmail.com>
Cc: Xuxiaohu <xuxiaohu@huawei.com>, "idr@ietf.org" <idr@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> <CD0461BF-15A3-4C8C-95A7-D17CABCD67C2@icloud.com> <AC35E22C-51A9-47DC-BF42-FBBF400ABC0F@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/owgJjqPfd4yXuB0fVzPEpWk5HYg>
Subject: Re: [OSPF] [Idr] A comment regarding the relationship between RLD and ERLD
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Dec 2017 20:07:53 -0000

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.ietf@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 <guntervandeveldecc@icloud.com <mailto:guntervandeveldecc@icloud.com>> wrote:
> 
>> Hi Xiaohu,
>> 
>> Thanks for digging through the draft.
>> 
>> See inline: GV>
>> 
>>> On 23 Dec 2017, at 09:40, Xuxiaohu <xuxiaohu@huawei.com <mailto:xuxiaohu@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:ketant@cisco.com <mailto:ketant@cisco.com>]
>>>> 发送时间: 2017年12月21日 12:16
>>>> 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Christian Hopps; isis-wg@ietf.org <mailto:isis-wg@ietf.org>
>>>> 抄送: isis-ads@ietf.org <mailto:isis-ads@ietf.org>; draft-ietf-isis-segment-routing-msd@ietf.org <mailto:draft-ietf-isis-segment-routing-msd@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:xuxiaohu@huawei.com <mailto:xuxiaohu@huawei.com>]
>>>> Sent: 21 December 2017 08:10
>>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>; Ketan Talaulikar (ketant)
>>>> <ketant@cisco.com <mailto:ketant@cisco.com>>; Christian Hopps <chopps@chopps.org <mailto:chopps@chopps.org>>; isis-wg@ietf.org <mailto:isis-wg@ietf.org>
>>>> Cc: isis-ads@ietf.org <mailto:isis-ads@ietf.org>; draft-ietf-isis-segment-routing-msd@ietf.org <mailto:draft-ietf-isis-segment-routing-msd@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-bounces@ietf.org <mailto:isis-wg-bounces@ietf.org>] 代表 Les Ginsberg
>>>>> (ginsberg)
>>>>> 发送时间: 2017年12月21日 4:02
>>>>> 收件人: Ketan Talaulikar (ketant); Christian Hopps; isis-wg@ietf.org <mailto:isis-wg@ietf.org>
>>>>> 抄送: isis-ads@ietf.org <mailto:isis-ads@ietf.org>; draft-ietf-isis-segment-routing-msd@ietf.org <mailto: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 <mailto:chopps@chopps.org>>; isis-wg@ietf.org <mailto:isis-wg@ietf.org>
>>>>>> Cc: isis-ads@ietf.org <mailto:isis-ads@ietf.org>; draft-ietf-isis-segment-routing-msd@ietf.org <mailto: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 <mailto:isis-wg-bounces@ietf.org>] On Behalf Of
>>>>>> Christian Hopps
>>>>>> Sent: 20 December 2017 14:03
>>>>>> To: isis-wg@ietf.org <mailto:isis-wg@ietf.org>
>>>>>> Cc: isis-ads@ietf.org <mailto:isis-ads@ietf.org>; draft-ietf-isis-segment-routing-msd@ietf.org <mailto: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 <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-wg@ietf.org <mailto:Isis-wg@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
>>>>> 
>>>>> _______________________________________________
>>>>> Isis-wg mailing list
>>>>> Isis-wg@ietf.org <mailto:Isis-wg@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org <mailto:Idr@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>