Re: [RTG-DIR] Rtgdir early review of draft-ietf-isis-mpls-elc-08

Peter Psenak <> Fri, 04 October 2019 11:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1B53120930; Fri, 4 Oct 2019 04:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e58lCineYPIa; Fri, 4 Oct 2019 04:14:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1235112092F; Fri, 4 Oct 2019 04:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6136; q=dns/txt; s=iport; t=1570187680; x=1571397280; h=from:subject:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=cUqU1ABbtwWMm5eU3vB5GRFSJzzYL48HIfnCpOkG15Y=; b=VYbkcE605pzYjAZvVJAsIz5mlKNzK7H29ErTS/DWIV2oJ8Zqf7/N0LLO 3w8XBrfVVthTdfFMyW+9qzF6os4J5Cz70stvUlPJ7EWV3Wm+nw3YiweQp zvkMOvV4G5iSHhcWRUcXDy9MgdSCy0rCFG92tGs8cSMvZybXEcdRT4XJT Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAABRJ5dd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBVgEBAQEBAQsBgwpTMioEhB6JAodsmyIJAQEBDiMMAQG?= =?us-ascii?q?EQAKCajcGDgIDCQEBBAEBAQIBBQRthS0MhUsBAQEBAgEjDwEFPAUFCwsSAgM?= =?us-ascii?q?BAgImAgJJBggGAQwIAQGDHgGBew8PrT91gTKETEFAgzKBSIEMKAGFFYcQgUA?= =?us-ascii?q?/gRABJ4JrPoJWCwEBAgEBgSmDQYJYBIx9AaA6gi2CL4RZi1aCNAYbgjpyhly?= =?us-ascii?q?EBYszjiuIIIxNhGyBaCOBWDMaCBsVGoMOCEcQFIpWhUE/AzABkW0BAQ?=
X-IronPort-AV: E=Sophos;i="5.67,256,1566864000"; d="scan'208";a="17620043"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2019 11:14:36 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id x94BEZNK030908; Fri, 4 Oct 2019 11:14:35 GMT
From: Peter Psenak <>
To: Dhruv Dhody <>,
References: <>
Message-ID: <>
Date: Fri, 4 Oct 2019 13:14:35 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-isis-mpls-elc-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Oct 2019 11:14:43 -0000

Hi Dhruv,

please see inline (##PP):

On 12/09/2019 12:06, Dhruv Dhody via Datatracker wrote:
> Reviewer: Dhruv Dhody
> Review result: Has Issues
> Subject: RtgDir Early review: draft-ietf-isis-mpls-elc-08
> Hello
> I have been selected to do a routing directorate “early” review of this draft.
> ​
> The routing directorate will, on request from the working group chair, perform
> an “early” review of a draft before it is submitted for publication to the
> IESG. The early review can be performed at any time during the draft’s lifetime
> as a working group document. The purpose of the early review depends on the
> stage that the document has reached.
> As this document is in working group last call, my focus for the review was to
> determine whether the document is ready to be published. Please consider my
> comments along with the other working group last call comments.
> For more information about the Routing Directorate, please see
> ​
> Document: draft-ietf-isis-mpls-elc-08
> Reviewer: Dhruv Dhody
> Review Date: 12-09-2019
> Intended Status: Standards Track
> Summary: I have some minor concerns about this document that I think should be
> resolved before it is submitted to the IESG.
> The draft is focused and straightforward, the reader needs to be aware of
> RFC6790 and draft-ietf-mpls-spring-entropy-label beforehand. I have reviewed
> this and the OSPF I-D together and you will find similar comments for both I-Ds.
> Minor
> *****
> (1) Could you mark that the codepoints mentioned in the draft are early
> allocated by IANA? Currently it says the value are desired. I also suggest
> following change in Section 7 (IANA Considerations) -
> OLD:
>     IANA is requested to allocate the E-bit (bit position 3 is desired)
>     from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry.
>     IANA is requested to allocate a MSD type (the type code of 2 is
>     desired) from the "IGP MSD Types" registry for ERLD.
> NEW:
>     IANA is requested to confirm the early allocation of the E-bit (Bit
>     position 3) in the "Bit Values for Prefix Attribute Flags Sub-TLV"
>     registry.
>     IANA is requested to confirm the early allocation of the ERLD (type
>     code of 2) in the "IGP MSD Types" registry.

I'm not sure above is necessary, given that the above text would change
eventually to simply say which code points have been allocated.

> (2) Section 3 talks about ERLD in Node MSD sub-TLV. But what happens if one
> receives ERLD in the Link MSD sub-TLV? As per my understanding this is not
> allowed, better to add normative text for the case then.

added a sentence

> Also we have this text in draft-ietf-mpls-spring-entropy-label -
>     In a distributed switching architecture, each linecard may have a
>     different capability in terms of ERLD.  For simplicity, an
>     implementation MAY use the minimum ERLD of all linecards as the ERLD
>     value for the system.
>     There may also be a case where a router has a fast switching path
>     (handled by an ASIC or network processor) and a slow switching path
>     (handled by a CPU) with a different ERLD for each switching path.
>     Again, for simplicity's sake, an implementation MAY use the minimum
>     ERLD as the ERLD value for the system.
>     The drawback of using a single ERLD for a system lower than the
>     capability of one or more specific component is that it may increase
>     the number of ELI/ELs inserted.  This leads to an increase of the
>     label stack size and may have an impact on the capability of the
>     ingress node to push this label stack.
> If we are deviating from this and opting for the node (marked 'MAY' above) as
> the only possibility, we need to handle this properly. Maybe check with
> chairs/AD on this!

A remote router introducing the EL may not always know the LC/interface 
over which the traffic he sends is received on the remote node. So I 
don't really see much of the value advertising ERLD per link.

Sure, chairs/AD will have their chance during the review :)

> (3) Section 4, can we add some more description on what the 'E' flags means, in
> the similar style of other flags
> []


> (4) Section 8, suggest to also add one sentence for the impact of advertising
> incorrect ERLD. If there isn't any, that can also be stated.


> Nits
> ****
> (1) Suggested ordering of sections - ..ELC/ERLD/BGP-LS/ACK..  [matching between


>(2) Section 2, add [I-D.ietf-mpls-spring-entropy-label] for
> terminology reference 


>(3) Section 3, Add reference to
> draft-ietf-mpls-spring-entropy-label for the definition and usage of ERLD 

The Introduction section has:

"This capability, referred to as Entropy Readable Label
    Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] "

> (4)
> Section 6,
>     The ERLD MSD-type introduced for IS-IS in Section 3 is advertised
>     using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as
>     defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext].
> I think you mean draft-ietf-idr-bgp-ls-segment-routing-msd here!

right, corrected it.

> Also, maybe change the title "BGP-LS Extension" as there is no 'extension'
> required, ELC/ERLD is BGP-LS would be automatically supported.

renamed to "Signaling ELC and ERLD in BGP-LS".

> (5) Expand MSD on first use.


> (6) The first figure is titled Figure 2!


> (7) Section 4, mark the figure as "Prefix Attribute Flags"


> (8) All references are marked Normative, please re-check if this is intentional.


> Thanks!
> Dhruv