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

[Alvaro Retana <[e-mail]>]

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?



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




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



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