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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
