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

Peter Psenak <ppsenak@cisco.com> Fri, 20 March 2020 10:04 UTC

Return-Path: <ppsenak@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 C2B3A3A079A; Fri, 20 Mar 2020 03:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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
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 HsbpBthh7Hgq; Fri, 20 Mar 2020 03:04:45 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F25E3A0797; Fri, 20 Mar 2020 03:04:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6465; q=dns/txt; s=iport; t=1584698685; x=1585908285; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=W4d3EHoxYmnV6m0AB6ZcukqVByGVQxgcBiA6d8HLmgg=; b=f2HKf1BuzIQy6wbtMZZPX4pxOs52fIY/WDbnYH8bieM2t2je34BUFAVR /0JS6DeAczpEsZORkWRQccfH1BeD8LmvgEZQ3WgBa6AYZFrgpbpNOgXhJ axHEW9VxdEURcu6/hAUzafa/TnSk8UGNL5mCNE+VhglRr60stPj7hmfjb U=;
X-IronPort-AV: E=Sophos;i="5.72,284,1580774400"; d="scan'208";a="22280619"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2020 10:04:40 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 02KA4boE020791; Fri, 20 Mar 2020 10:04:39 GMT
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-isis-mpls-elc@ietf.org" <draft-ietf-isis-mpls-elc@ietf.org>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
References: <CAMMESsyMkZgpU69GyL8TpwPS7EoO2rxTHWREOwEz7pNRFtNEJw@mail.gmail.com> <6bd667d8-6957-894e-f11e-aa727065190c@cisco.com> <CAMMESsxwbv3aUvg_gR+Ssny=YkW3D2_6tVgDpJx9BGH_Mrdh=A@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <0d9b6c73-d309-d2ee-15e0-722df9c32629@cisco.com>
Date: Fri, 20 Mar 2020 11:04:36 +0100
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: <CAMMESsxwbv3aUvg_gR+Ssny=YkW3D2_6tVgDpJx9BGH_Mrdh=A@mail.gmail.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.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/hR5LLejBA8HrQgCKhWgWcr4n9Go>
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: Fri, 20 Mar 2020 10:04:51 -0000

Hi Alvaro,

please see inline (##PP2):

On 19/03/2020 22:48, Alvaro Retana wrote:
> On March 16, 2020 at 7:52:18 AM, Peter Psenak wrote:
> 
> 
> Peter:
> 
> Hi!
> 
>> Let's first close the ISIS ELC draft before starting to work on OSPF
>> one, as many comments are common and will be applicable to both ISIS and
>> OSPF variants.
> 
> Sure, that makes sense.
> 
>> Please see inline (##PP):
> 
> I replied to some of your comments inline as well.
> 
> The only change that I still want to see (based on your answers) is
> related to (at least) referencing rfc8662 in §5 (see below).
> 
> 
> Thanks!
> 
> Alvaro.
> 
> 
> ...
>>> 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.
>>
>> ##PP
>> Multi-area and multi-domain are two different cases. I believe it is
>> important to keep both in the text.
> 
> Ok...no big deal.  I mentioned it because this is the only place in
> the document where anything about area/domain is mentioned.  If there
> are important differences, then it might be useful for other readers
> to understand what that is.
> 
> 
> 
>>> 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] "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"?
>>
>> ##PP
>> advertising ELC is not a MUST. It's an optional information that the
>> originator should advertise, but if it is not, it is not going to break
>> anything really.
> 
> Yes, I understand that the advertisement of ELC is optional.
> 
> This document talks about the behavior when the advertisement is
> enabled (or configured or ...).  IOW, if a router is going to
> advertise, when would it not set the ELC?

##PP2
The text in draft says:

"If a router has multiple interfaces, the router MUST NOT announce the 
ELC for any local host prefixes unless all of its interfaces are capable 
of processing ELs."

So if there is at least 1 interface (LC really) that is not supporting 
ELC, the router would not send it.


> 
> 
> 
> ...
>>> 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?
>>
>>
>> ##PP
>> RFC8662 already set the rules on when the ERLD can be advertised and
>> that behavior is orthogonal to protocol which is being used to advertise
>> the ERLD/ELC.
>>
>> Same in terms of what should be assumed when the ELC is advertised, but
>> ERLD is not - has nothing to do with the advertising protocol - should
>> be specified in RFC8662
>>
>> I don't feel any of the above should be specified in the IGP ELC drafts.
> 
> Can you at least put a reference to rfc8662 somewhere in this section?
>   Something along the lines of "the considerations for advertising the
> ERLD are specified in rfc8662".

##PP2
done

> 
> 
> 
> 
>>> 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. ;-)
>>
>> ##PP
>> changed to:
>>
>> "A new MSD-type , called ERLD is defined to
>> advertise the ERLD of a given router"
> 
> It was just a minor point, but you didn't actually change anything. ;-)
> 
> The point was that the MSD-type and the ERLD have the same name, so if
> you just say "ERLD" it is not straight forward to figure out if you're
> talking about the ERLD or the MSD with the same name.

##PP2
my bad I pasted a wrong text in my email response. Here's what I have in 
the draft now:

"A new MSD-type <xref target="RFC8491"/>, called ERLD-MSD is defined to
advertise the ERLD of a given router. A MSD-Type code 2 has been 
assigned by IANA for EARLD-MSD. MSD-Value field is set to the ERLD in 
the range between 0 to 255."

Sounds good?

thanks,
Peter

> 
> 
> 
> ...
>>> 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".
>>
>> ##PP
>> would "lead to poor or no load-balancing" be good enough?
> 
> Yes.
> 
>