Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

"Acee Lindem (acee)" <acee@cisco.com> Sat, 29 February 2020 20:53 UTC

Return-Path: <acee@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA143A1335; Sat, 29 Feb 2020 12:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=BoEToQaW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vUY7mkv8
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 XlM7DDaoV-_8; Sat, 29 Feb 2020 12:53:41 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7083A1331; Sat, 29 Feb 2020 12:53:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22244; q=dns/txt; s=iport; t=1583009621; x=1584219221; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dHAbF1LmiYnudMzkcCn6S/9s1VQ7PTauVZ5KM8FAe7U=; b=BoEToQaWgs2RxL/P/5VU6IQUNSNBuGkR7T8N3tQ0YY/qNbMA6GsBV3vi g5UXTqafAqmhj+TbnsL5VMTvu3MdCuapFYSFqLpONUCkZdqVBDR7NZREE Kzqa5hvBHMHcnF6IRhAIuUyTKL3E8oynnO4v5l4H2Xi4BGGQxRc0sGhUk o=;
IronPort-PHdr: 9a23:Qerj3BLUo5yUTtV7ytmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1kAgMQSkRYnBZuMAkD2BPXrdCc9Ws9FUQwt8g==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BOAQA3zlpe/4UNJK1cCRoBAQEBAQEBAQEDAQEBAREBAQECAgEBAQGBewKBUlAFbFggBAsqhBSDRgOKZoxCjjKBQoEQA1QJAQEBDAEBJQgCBAEBgSsBgxQCF4FzJDgTAgMBAQsBAQUBAQECAQUEbYVWDEIWAYULAgEDDgQREQwBASMUAQ8CAQgOBAgCJgICAh8RFQIOAgQBDQUigwQBgkoDLgEOox8CgTmIYnWBMoJ/AQEFhR0NC4IMAwaBDioBjCQaggCBEAEnIIJNPoIbSQICGoEMAw4sFxWCZTKCLJBlhhSJZ45JMkQKgjySMIQ2HIJJiB+QSY5ygU2JXZAgAgQCBAUCDgEBBYFpIoFYcBVlAYJBUBgNjh0MF4NQhRSFQXQCAQGBJYpNhWwBAQ
X-IronPort-AV: E=Sophos;i="5.70,501,1574121600"; d="scan'208";a="718887657"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Feb 2020 20:53:39 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 01TKrd2I024175 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 29 Feb 2020 20:53:39 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 29 Feb 2020 14:53:38 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 29 Feb 2020 14:53:38 -0600
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 29 Feb 2020 15:53:38 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JnXOF3ARPkO/+NWwN6yOWVEqGz+PYnV068F7Yp2wwcMATd3hlu+PzBYinozwUtkCak0QvpoYYUJs3KG1k/QH8WjDGY5sr85YO0q4YQ+4jfb6/kxsswU7HjtHASUF2BfR8DarRy118pza5dhdJJOkigw0M26qCp5WPCI+rcxLksx1u2SqMI4Y0PxqQWSjiqm0fwlFOLkOVLqpXT1GLuOdKxvm2A8uKcJ4O1ki8EiLtCqBBml1jlpDrwW9OzUblSiegTuFQHHeH8l3kkc7iEHHkVuJH45A3kbROF4ntKcPnJAoCnlfvAbRoaTeBbsD9nG51JzxnwzWEWVULbei3/rqRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=dHAbF1LmiYnudMzkcCn6S/9s1VQ7PTauVZ5KM8FAe7U=; b=DLy614U6Y4hWh0XBCznK0qUhL/0iAL/lN+8x3U8SA55KXuNjqDauRTfnfCFFzSgxM6/+FSJD2Xo2CRKbXWVNQhE5Nw2FKDjsuFk4K9FZyeLFadxJnaueVnvk6OuprbxbD3L4jdSPfL/QCC/qWTnyGKnaNV4tkbPRBCUgX3kgl4dh+mgyZLpN7CODDY0+xLti9ZmoimXkdVSyJjoFUZmXthEIEfgKh47Es/X5J/j/tMacFT7aBWoGmFyIBUHI8oLGNpoBzha0rFbRq/9sSnE7fqYbEjYaCtid9jdnzbS0XdJjk74P9xEuNzcjRSK1rq8A+X7knVCC09MI3tYvD+m54A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dHAbF1LmiYnudMzkcCn6S/9s1VQ7PTauVZ5KM8FAe7U=; b=vUY7mkv86bD+Goc5BZEd9lpSd6/hUDWgXCb1eE+9eAGZ3L/n17RvUsJgN4KLeMUY0pLURDTLb1RIJFGNNgkXOQHmiuQWzfPTT2CwHHEHRaEQO+qJAo2qtAURHtW7PSqdezJq452acDlG8CKMAVdYVQ4edXEUvoRC4mBIPZ83LP0=
Received: from BN8PR11MB3794.namprd11.prod.outlook.com (2603:10b6:408:8f::13) by BN8PR11MB3602.namprd11.prod.outlook.com (2603:10b6:408:8e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Sat, 29 Feb 2020 20:53:37 +0000
Received: from BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::d939:a6fb:475:cddd]) by BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::d939:a6fb:475:cddd%4]) with mapi id 15.20.2772.018; Sat, 29 Feb 2020 20:53:37 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-isis-mpls-elc@ietf.org" <draft-ietf-isis-mpls-elc@ietf.org>
CC: "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: AD Review of draft-ietf-isis-mpls-elc-10
Thread-Index: AQHV7r06T6BhkMr+fU+/YzWEzoNHEagyU1GA
Date: Sat, 29 Feb 2020 20:53:36 +0000
Message-ID: <AB73A142-A297-41E8-9FF3-4F092F0F0AC9@cisco.com>
References: <CAMMESsyMkZgpU69GyL8TpwPS7EoO2rxTHWREOwEz7pNRFtNEJw@mail.gmail.com>
In-Reply-To: <CAMMESsyMkZgpU69GyL8TpwPS7EoO2rxTHWREOwEz7pNRFtNEJw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [2001:420:c0c4:1007::3c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be4b5c5b-902a-42bc-b1b8-08d7bd5972bc
x-ms-traffictypediagnostic: BN8PR11MB3602:
x-microsoft-antispam-prvs: <BN8PR11MB3602B718CB3AD72870DFCBA3C2E90@BN8PR11MB3602.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 03283976A6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(366004)(39860400002)(199004)(189003)(2616005)(5660300002)(186003)(30864003)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(71200400001)(66574012)(6512007)(6486002)(33656002)(36756003)(8936002)(81156014)(8676002)(81166006)(2906002)(966005)(478600001)(4326008)(91956017)(316002)(6506007)(110136005)(54906003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3602; H:BN8PR11MB3794.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bd8Mse+QODKdAQMg8b4T5OkTcfEzd0gskbPWgsrEjD+Pi08x7DxEp3ys/uIePip4dgA7cBcF8ryKsGgmH8P1BXLhvj3ZUDJ8lstM+mcx3Q2InCjKfWHDzGJibVeWtQ5pypXkP9hnSCFo40Q3BuX1PrgWQMaAGWBk9nEunqXMDcSGiq1LN/NLYBZ+xT9j6Lra1SoJ6pj4sua4nGCTjhiQILWqF0HALctiD0OOM7AysyrBQJbZPIV1vUYD/gshCSVijl6BNea/R9LYyoYU/oqATyLVJGgqrsEk5b5ZC8yZhhuhBYKMYLGOifrtNTx+HQNSg7lMY77XWizxtFR5SD5lRo781233ERXPhy7B9yzgmPX+EkvZQND3E/QjNsIwgr19ZJfiN8VpRv6xfwVWZfDdGNggJcjRZvRYURMgN7im/SOpoBMG0jDSG1Vh1aivmHTaTKQ+j3hsloxEaBsj9tgJ7H092u4KOGOjZX/VHuJfOYloXzSAta8h8jdQaFjJbd008/WzlNzh/XieBVQUAnYmyw==
x-ms-exchange-antispam-messagedata: 4rsv3PInzcPKKnJvyfbwk8haFkv9yDq+bI+QnAlasDTVgDxxUq/OtVIevltWlkduaMmr98sNz1eDFxJtVE7W7P5c2AGsoScGfud4pW1Su0wZbyAubHJTaYR597ftuN2r0z6dbc3b/a7+l35PAEArDGEBV70MCgtLNean0KY3DhY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <84D6AD6851C57143B025B804474F8FA8@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: be4b5c5b-902a-42bc-b1b8-08d7bd5972bc
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2020 20:53:36.9972 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: giGWqSYQqJN88k4NoX0FJbbjRbQPk0AS3cbeJvP/eddN9B0JWeT+0cFacR2s6w+R
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3602
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ONRjhS8ztyMvPUl653cMrir2qxE>
Subject: Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Feb 2020 20:53:44 -0000

Authors Dearest,

Please update all the out-of-date references and the copyright date to 2020. This will resolve the Nits. 

https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-isis-mpls-elc-10.txt

Thanks,
Acee (speaking as document shepherd) 

On 2/29/20, 12:00 AM, "Alvaro Retana" <aretana.ietf@gmail.com> wrote:

    Dear authors:
    
    This is my review of draft-ietf-isis-mpls-elc-10.  I reviewed this
    document alongside draft-ietf-ospf-mpls-elc-12, so many comments are
    the same/similar.  Thank you for the work in both of them!
    
    Besides the in-line comments, I want to point out here that this
    specification is incomplete.  It needs to have (1) a formal
    description of the new MSD-Type (similar to §5/rfc8491), and (2) a
    discussion of the interaction with the BMI-MSD.
    
    I will progress both documents together, so I will wait for both of
    them to address my comments before starting their IETF LC.
    
    Thanks!!
    
    Alvaro.
    
    
    [Line numbers from idnits.]
    
    ...
    18	Abstract
    
    20	   Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
    21	   balance traffic flows using Entropy Labels (EL).  An ingress Label
    22	   Switching Router (LSR) cannot insert ELs for packets going into a
    23	   given Label Switched Path (LSP) unless an egress LSR has indicated
    24	   via signaling that it has the capability to process ELs, referred to
    25	   as Entropy Label Capability (ELC), on that tunnel.  In addition, it
    26	   would be useful for ingress LSRs to know each LSR's capability for
    27	   reading the maximum label stack depth and performing EL-based load-
    28	   balancing, referred to as Entropy Readable Label Depth (ERLD).  This
    29	   document defines a mechanism to signal these two capabilities using
    30	   IS-IS.  These mechanisms are particularly useful, where label
    31	   advertisements are done via protocols like IS-IS.
    
    [nit] s/as Entropy Label Capability/as the Entropy Label Capability
    
    [minor] "protocols like IS-IS"  That last sentence sounds as if there
    were other options; for example advertise labels with OSPF and then
    use the extensions here.  It's just a minor point, but I think that
    maybe that last sentence is not needed.
    
    
    ...
    81	1.  Introduction
    
    83	   [RFC6790] describes a method to load-balance Multiprotocol Label
    84	   Switching (MPLS) traffic flows using Entropy Labels (EL).  "The Use
    85	   of Entropy Labels in MPLS Forwarding" [RFC6790] introduces the
    86	   concept of Entropy Label Capability (ELC) and defines the signalings
    87	   of this capability via MPLS signaling protocols.  Recently,
    88	   mechanisms have been defined to signal labels via link-state Interior
    89	   Gateway Protocols (IGP) such as IS-IS
    90	   [I-D.ietf-isis-segment-routing-extensions].  In such scenarios, the
    91	   defined signaling mechanisms are inadequate.  This draft defines a
    92	   mechanism to signal the ELC using IS-IS.  This mechanism is useful
    93	   when the label advertisement is also done via IS-IS.
    
    [nit] s/"The Use of Entropy Labels in MPLS Forwarding" [RFC6790]/It also
    
    [nit] s/signalings/signaling
    
    [nit] "In such scenarios, the defined signaling mechanisms are
    inadequate." Take this sentence out: the rest of the paragraph is
    enough.
    
    
    95	   In addition, in the cases where LSPs are used for whatever reasons
    96	   (e.g., SR-MPLS [I-D.ietf-spring-segment-routing-mpls]), it would be
    97	   useful for ingress LSRs to know each intermediate LSR's capability of
    98	   reading the maximum label stack depth and performing EL-based load-
    99	   balancing.  This capability, referred to as Entropy Readable Label
    100	   Depth (ERLD) as defined in [I-D.ietf-mpls-spring-entropy-label] may
    101	   be used by ingress LSRs to determine the position of the EL label in
    102	   the stack, and whether it's necessary to insert multiple ELs at
    103	   different positions in the label stack.
    
    [nit] s/in the cases where LSPs are used for whatever reasons/in cases
    where LSPs are used
    
    
    105	2.  Terminology
    
    107	   This memo makes use of the terms defined in [RFC6790], [RFC4971] and
    108	   [I-D.ietf-mpls-spring-entropy-label].
    
    [minor] I'm not sure why rfc4971 is referenced here; what terminology
    is needed from it?
    
    
    ...
    116	3.  Advertising ELC Using IS-IS
    
    118	   Even though ELC is a property of the node, in some cases it is
    119	   advantageous to associate and advertise the ELC with a prefix.  In a
    120	   multi-area network, routers may not know the identity of the prefix
    121	   originator in a remote area, or may not know the capabilities of such
    122	   originator.  Similarly in a multi-domain network, the identity of the
    123	   prefix originator and its capabilities may not be known to the
    124	   ingress LSR.
    
    [minor] Is there a difference that are you trying to highlight between
    multi-area and multi-domain?  The last two sentences seem redundant to
    me; using "domain" should be enough.
    
    
    126	   One bit of the "Bit Values for Prefix Attribute Flags Sub-TLV"
    127	   registry defined in [RFC7794] (Bit 3 is desired) is to be assigned by
    128	   the IANA for the ELC.  If a router has multiple line cards, the
    129	   router MUST NOT announce the ELC for any prefixes that are locally
    130	   attached unless all of its line-cards are capable of processing ELs.
    131	   If a router supports ELs on all of its line-cards, it SHOULD set the
    132	   ELC for every local host prefix it advertises in IS-IS.
    
    [major] The first sentence is not needed because IANA has already
    assigned the bit, and any requests should be in the IANA
    Considerations section.  Perhaps change to something like:
    
          Bit 3 in the Prefix Attribute Flags [RFC7794] is used as the ECL Flag
          (E-flag), as shown in Figure 1.
    
    
    [major] From a general router architecture point of view, I understand
    what you mean by line-card.  But, strictly speaking from a
    specification point of view, what is a line-card?  Would using
    "interface" instead be an acceptable generalization?
    
    
    [minor] Is there a difference between "prefixes that are locally
    attached" and a "local host prefix"?  Are all locally-attached
    prefixes host prefixes (/32 or /128)?
    
    
    [major] "it SHOULD set the ELC for every local host prefix"  If ELs
    are supported in all the interfaces, when would a router not set the
    ELC?  IOW, why is "MUST" not used instead of "SHOULD"?
    
    
    [major/related] The last two sentences seem to be redundant -- I think
    that only the second one is needed; suggestion (assuming my
    interpretation of the questions above):
    
       If a router supports ELs on all of its interfaces, it MUST set the E-flag
       (ELC Flag) for every local prefix it advertises.
    
    
    134	          0 1 2 3 4 5 6 7...
    135	         +-+-+-+-+-+-+-+-+...
    136	         |X|R|N|E|        ...
    137	         +-+-+-+-+-+-+-+-+...
    138	               Figure 1: Prefix Attribute Flags
    
    140	               E-flag: ELC Flag (Bit 3)
    141	                   Set for local host prefix of the originating node
    142	                   if it supports ELC.
    
    [nit] Justify the description in line with the text (move it to the left).
    
    
    144	   When a router leaks a prefix between two levels (upwards or
    145	   downwards), it MUST preserve the ELC signaling for this prefix.
    
    [nit] Going up is not really leaking. ;-)
    
    [minor] An Informative reference to rfc5302 would be nice.
    
    Suggestion>
    
       When a router distributes a prefix between two levels [RFC5302] it MUST
       preserve the E-flag setting.
    
    
    147	   When redistributing a prefix between two IS-IS protocol instances or
    148	   redistributing from another protocol to an IS-IS protocol instance, a
    149	   router SHOULD preserve the ELC signaling for that prefix.  The exact
    150	   mechanism used to exchange ELC between protocol instances running on
    151	   an ASBR is outside of the scope of this document and is
    152	   implementation specific.
    
    [minor] s/ELC signaling/ELC setting
    
    [nit] Please expand ASBR.
    
    [nit] s/ and is implementation specific./.
    
    
    154	4.  Acknowledgements
    
    [major] Move this section to just before the References.
    
    
    ...
    161	5.  Advertising ERLD Using IS-IS
    
    [major] draft-ietf-mpls-spring-entropy-label says that "To advertise
    an ERLD value, a SPRING router:  MUST be entropy label capable".  This
    requirement must be translated to this document so that the ERLD is
    only advertised if the ELC is also advertised.  I'm assuming that the
    ERLD should be ignored if the ELC is not advertised -- but that should
    be explicitly defined as well.  If the ELC is advertised, but the ERLD
    isn't, what value should be assumed, 0?
    
    
    163	   A new MSD-type of the Node MSD ((Maximum SID Depth) sub-TLV
    164	   [RFC8491], called ERLD is defined to advertise the ERLD of a given
    165	   router.  As shown in Figure 2, it is formatted as described in
    166	   [RFC8491] with a new MSD-Type code to be assigned by IANA (the type
    167	   code of 2 is desired) and the Value field is set to the ERLD in the
    168	   range between 0 to 255.  The scope of the advertisement depends on
    169	   the application.  If a router has multiple line-cards with different
    170	   capabilities of reading the maximum label stack depth, the router
    171	   MUST advertise the smallest one.
    
    [minor] "new MSD-type...called ERLD is defined to advertise the ERLD"
    I suggest that you call the new MSD ERLD-MSD, to differentiate ERLD
    from ERLD. ;-)
    
    
    [major] s/a new MSD-Type code to be assigned by IANA (the type code of
    2 is desired)/the MSD-Type set to 2
    IANA already assigned.
    
    [minor] s/Value/MSD-Value
    
    
    ...
    180	   When the ERLD MSD-Type is received in the Link MSD Sub-TLV, it MUST
    181	   be ignored.
    
    [nit] s/When the/If the
    
    
    183	6.  Signaling ELC and ERLD in BGP-LS
    ...
    188	   The ELC Flag included in the Prefix Attribute Flags sub-TLV, as
    189	   defined in Section 3, is advertised using the Prefix Attribute Flags
    190	   TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute as
    191	   defined in section 2.3.2 of
    192	   [I-D.ietf-idr-bgp-ls-segment-routing-ext].
    
    [nit] Suggestion>
    
       The ELC is advertised using the Prefix Attribute Flags TLV as defined in
       [I-D.ietf-idr-bgp-ls-segment-routing-ext].
    
    194	   The ERLD MSD-type introduced for IS-IS in Section 5 is advertised
    195	   using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as
    196	   defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-msd].
    
    [nit] Suggestion>
    
       The ERLD-MSD is advertised using the Node MSD TLV as defined in
       [I-D.ietf-idr-bgp-ls-segment-routing-msd].
    
    
    198	7.  IANA Considerations
    
    200	   IANA is requested to allocate the E-bit (bit position 3 is desired)
    201	   from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry.
    
    203	   IANA is requested to allocate a MSD type (the type code of 2 is
    204	   desired) from the "IGP MSD Types" registry for ERLD.
    
    [major] IANA has already assigned the values.  Suggestion>
    
       Early allocation has been done by IANA for this document as follows:
    
       - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV registry has
       been assigned to the ELC Flag.  IANA is asked to update the registry to
       reflect the name used in this document: ECL Flag (E-flag).
    
       - Type 2 in the IGP MSD-Types registry has been assigned for the ERLD-MSD.
       IANA is asked to update the registry to reflect the name used in this
       document: ERLD-MSD.
    
    
    206	8.  Security Considerations
    
    208	   The security considerations as described in [RFC4971] nd
    209	   [I-D.ietf-mpls-spring-entropy-label] are applicable to this document.
    
    [minor] Why?  Also, I think that some of the other references should
    be added here.  Suggestion:
    
       This document specifies the ability to advertise additional node
       capabilities using IS-IS and BGP-LS.  As such, the security considerations
       as described in [RFC4971], [RFC7752], [RFC7794], [RFC8491],
       [I-D.ietf-idr-bgp-ls-segment-routing-ext],
       [I-D.ietf-idr-bgp-ls-segment-routing-msd] and
       [I-D.ietf-mpls-spring-entropy-label] are applicable to this document.
    
    
    211	   Incorrectly setting the E flag (ELC capable) (during origination,
    212	   leaking or redistribution) may lead to black-holing of the traffic on
    213	   the egress node.
    
    [minor] s/E flag (ELC capable)/E flag
    
    [minor] s/during origination, leaking or redistribution/during
    origination or redistribution
    
    
    [major] "...may lead to black-holing of the traffic on the egress
    node."  I'm not sure I understand how, but the ELC advertisement
    should be accompanied by the ERLD-MSD -- see my questions at the
    beginning of §5.
    
    
    215	   Incorrectly setting of the ERLD value may lead to poor load-balancing
    216	   of the traffic.
    
    [minor] "may lead to poor load-balancing"  If the ERLD is low, then
    the traffic may not be load balanced at all...that is not "poor", it
    is "0".
    
    
    ...
    244	10.1.  Normative References
    ...
    259	   [I-D.ietf-mpls-spring-entropy-label]
    260	              Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
    261	              Shakir, R., and J. Tantsura, "Entropy label for SPRING
    262	              tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in
    263	              progress), July 2018.
    
    == Outdated reference: draft-ietf-mpls-spring-entropy-label has been
       published as RFC 8662
    
    
    265	   [I-D.ietf-spring-segment-routing-mpls]
    266	              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
    267	              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
    268	              data plane", draft-ietf-spring-segment-routing-mpls-22
    269	              (work in progress), May 2019.
    
    == Outdated reference: draft-ietf-spring-segment-routing-mpls has been
       published as RFC 8660
    
    [minor] This reference can be Informative.
    
    
    ...
    276	   [RFC4971]  Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
    277	              "Intermediate System to Intermediate System (IS-IS)
    278	              Extensions for Advertising Router Information", RFC 4971,
    279	              DOI 10.17487/RFC4971, July 2007,
    280	              <https://www.rfc-editor.org/info/rfc4971>.
    
    ** Obsolete normative reference: RFC 4971
    ** Replace with rfc7981
    
    
    ...
    307	10.2.  Informative References
    
    309	   [I-D.ietf-isis-segment-routing-extensions]
    310	              Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
    311	              Gredler, H., and B. Decraene, "IS-IS Extensions for
    312	              Segment Routing", draft-ietf-isis-segment-routing-
    313	              extensions-25 (work in progress), May 2019.
    
    == Outdated reference: draft-ietf-isis-segment-routing-extensions has been
       published as RFC 8667