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

Peter Psenak <ppsenak@cisco.com> Fri, 04 October 2019 11:14 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B53120930; Fri, 4 Oct 2019 04:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 e58lCineYPIa; Fri, 4 Oct 2019 04:14:41 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1235112092F; Fri, 4 Oct 2019 04:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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: A0BgAABRJ5dd/xbLJq1lGQEBAQEBAQEBAQEBAQwBAQEBAQGBVgEBAQEBAQsBgwpTMioEhB6JAodsmyIJAQEBDiMMAQGEQAKCajcGDgIDCQEBBAEBAQIBBQRthS0MhUsBAQEBAgEjDwEFPAUFCwsSAgMBAgImAgJJBggGAQwIAQGDHgGBew8PrT91gTKETEFAgzKBSIEMKAGFFYcQgUA/gRABJ4JrPoJWCwEBAgEBgSmDQYJYBIx9AaA6gi2CL4RZi1aCNAYbgjpyhlyEBYszjiuIIIxNhGyBaCOBWDMaCBsVGoMOCEcQFIpWhUE/AzABkW0BAQ
X-IronPort-AV: E=Sophos;i="5.67,256,1566864000"; d="scan'208";a="17620043"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2019 11:14:36 +0000
Received: from [10.60.140.50] (ams-ppsenak-nitro-ap.cisco.com [10.60.140.50]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x94BEZNK030908; Fri, 4 Oct 2019 11:14:35 GMT
From: Peter Psenak <ppsenak@cisco.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, rtg-dir@ietf.org
Cc: lsr@ietf.org, draft-ietf-isis-mpls-elc.all@ietf.org, ietf@ietf.org
References: <156828278097.16614.688259101169694148@ietfa.amsl.com>
Message-ID: <a3312094-de7e-f63f-ee5f-e903afdda461@cisco.com>
Date: Fri, 04 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: <156828278097.16614.688259101169694148@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.50, ams-ppsenak-nitro-ap.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/F8MlMeIZehfE9WS_XAvUkUWJGuI>
Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-isis-mpls-elc-08
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=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.
> ​https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
> 
> 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
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> 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.
> END


##PP
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.

##PP
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!

##PP
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
> [https://tools.ietf.org/html/rfc7794#section-2.1]

##PP
done

> 
> (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.

##PP
done

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

##PP
done

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

##PP
done

>(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!

##PP
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.

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

> 
> (5) Expand MSD on first use.

##PP
done.


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

##PP
fixed

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

##PP
done

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

##PP
done.

thanks,
Peter
> 
> Thanks!
> Dhruv
> 
> 
> 
>