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

From: Peter Psenak <[email-masked]>
Date: Mon, 16 Mar 2020 12:52:16 +0100

Hi Alvaro,

thanks for your comments.

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.

Please see inline (##PP):

On 29/02/2020 06:00, Alvaro Retana 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 the Entropy Label Capability

##PP
done

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

##PP
removed last sentence

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

##PP
done
> 
> [nit] s/signalings/signaling

##PP
done

> 
> [nit] "In such scenarios, the defined signaling mechanisms are
> inadequate." Take this sentence out: the rest of the paragraph is
> enough.

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

##PP
done
> 
> 
> 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?

##PP
removed the reference to rfc4971

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

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

##PP
done

> 
> 
> [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?

##PP
change to interface
> 
> 
> [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)?

##PP
changed to "local host prefix"

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

> 
> 
> [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):

##PP
if we only keep the second sentence, the reader may not know what to do 
in case where some interfaces do not support ELC. I believe it is good 
to keep both.

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

##PP
done

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

##PP
ok, changed to "propagate".

> 
> [minor] An Informative reference to rfc5302 would be nice.

##PP
added.

> 
> Suggestion>
> 
>     When a router distributes a prefix between two levels [RFC5302] it MUST
>     preserve the E-flag setting.

##PP
I prefer:

"When a router propagates a prefix between ISIS levels [RFC5302], it 
MUST preserve the ELC signaling for this prefix."

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

##PP
we use "signaling" for the inter-area propagation, I would prefer to 
keep the same terminology for the redistribution.

> 
> [nit] Please expand ASBR.

##PP
done.

> 
> [nit] s/ and is implementation specific./.

##PP
done

> 
> 
> 154	4.  Acknowledgements
> 
> [major] Move this section to just before the References.

##PP
done

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

> 
> 
> 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 <xref target="RFC8491"/>, called ERLD is defined to
advertise the ERLD of a given router"
> 
> 
> [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.

##PP
done

> 
> [minor] s/Value/MSD-Value

##PP
done.

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

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

##PP
done

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

##PP
done

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

##PP
done

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

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

##PP

done

> 
> [minor] s/during origination, leaking or redistribution/during
> origination or redistribution

##PP
change to:

"during origination, propagation 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.

##PP
the text talks about the ELC flag only, not about ERLD. If the egress 
sets the E flag, while it is not capable of ELC processing the traffic 
could be dropped at egress PE - that's what the text says and it is correct.

It is not mandatory to advertise ERLD if the node is ELC capable. It is 
however not allowed to advertise ERLD if the node is not ELC capable by 
RFC8662.

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

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

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

##done

> 
> [minor] This reference can be Informative.

##PP
done

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

##PP
done

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

##PP
done

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 16 Mar 2020 14:29:57 +0000

Hi Alvaro - Thanks for the extensive review. 

Hi Peter - Thanks for the addressing all the comments. 

See one inline. 

On 3/16/20, 7:52 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Alvaro,

    

    ##PP
    done

    ##PP
    removed last sentence

    ##PP
    done
    
    ##PP
    done

    ##PP
    done
    
    ##PP
    done
    
    ##PP

    ##PP

I agree with Peter. It might be possible to combine these in one sentence but both case should be included. 

Thanks,
Acee

    ##PP
    done

    ##PP
    change to interface
    
    ##PP

    ##PP

    ##PP

    ##PP
    done

    ##PP

    ##PP
    added.

    ##PP
    I prefer:

    
    ##PP

    ##PP
    done.

    ##PP
    done

    ##PP
    done

    ##PP

    
    
    ##PP
    changed to:

    ##PP
    done

    ##PP
    done.

    ##PP
    done
    
    ##PP
    done

    ##PP
    done

    ##PP
    done

    ##PP
    done
    
    ##PP
    
    done

    ##PP
    change to:

    
    ##PP

    
    ##PP

    ##PP
    done
    
    ##done

    ##PP
    done

    ##PP
    done

    ##PP
    done

    thanks,
    Peter

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 19 Mar 2020 14:48:26 -0700

On March 16, 2020 at 7:52:18 AM, Peter Psenak wrote:

Peter:

Hi!

> one, as many comments are common and will be applicable to both ISIS and

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.

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

...
> originator should advertise, but if it is not, it is not going to break

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?

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

> "A new MSD-type , called ERLD is defined to

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.

...
> would "lead to poor or no load-balancing" be good enough?

Yes.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 20 Mar 2020 11:04:36 +0100

Hi Alvaro,

please see inline (##PP2):

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

> ERLD are specified in rfc8662".

##PP2
done

> 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

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 20 Mar 2020 03:13:52 -0700

> please see inline (##PP2):

We're good to go.

The only comment from the original review that you didn't reply to is this:

   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.

...but I'm assuming you're addressing it in the new text.  Pointing it
out just in case.

Thanks!!

Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 20 Mar 2020 11:22:36 +0100

Hi Alvaro,

>     interaction with the BMI-MSD.

sorry, I missed it.

Entropy Readable Label Depth is defined in rfc8662.

I have modified the text as foolows:

"A new MSD-type [RFC8491], called ERLD-MSD is defined to
advertise the ERLD [RFC8662] of a given router. A MSD-Type code 2
has been assigned by IANA for EARLD-MSD."

Would that be good enough?

thanks,
Peter

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 20 Mar 2020 03:59:02 -0700

On March 20, 2020 at 6:22:38 AM, Peter Psenak wrote:

...
> Would that be good enough?

Not quite.  According to rfc8662, when a new MSD is defined, the
document MUST indicate the meaning of the absence of the MSD
advertisement.  For example, it says this about the BMI-MSD: "The
absence of BMI-MSD advertisements indicates only that the advertising
node does not support advertisement of this capability."

Also, I need you to talk about the interaction between ERLD-MSD and
BMI-MSD.  If both are present, what should happen?  Should one take
precedence, should both be ignored, can they coexist without issues???

Thanks!

Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 20 Mar 2020 13:58:00 +0100

> node does not support advertisement of this capability."

ok, I  will add that.

> precedence, should both be ignored, can they coexist without issues???

how are BMI-MSD and EARLD-MSD related?

BMI-MSD signals the total number of MPLS labels that can be imposed.

EARLD-MSD - is defined as the number of labels a router can both:

    a.  Read in an MPLS packet received on its incoming interface(s)
        (starting from the top of the stack).

    b.  Use in its load-balancing function.

I don't really see why one would affect the other.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 20 Mar 2020 14:27:52 +0000

Hi Peter Alvaro, 

On 3/20/20, 8:58 AM, "Peter Psenak" <[email-masked]> wrote:

    ok, I  will add that.

    

    

I agree. BMI-MSD is an egress capability and ERLD-MSD is an ingress capability. While they may be related in the internal ASIC implementation, they are independent from a capability perspective. 

Thanks,
Acee

    thanks,
    Peter

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 20 Mar 2020 07:30:51 -0700

On March 20, 2020 at 10:27:55 AM, Acee Lindem wrote:

…
> I agree. BMI-MSD is an egress capability and ERLD-MSD is an ingress
> capability. While they may be related in the internal ASIC implementation,
> they are independent from a capability perspective.

Please write that then.

They don’t have to affect each other, if they don’t then that’s great!

Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 20 Mar 2020 15:34:58 +0100

Hi Alvaro,

>> they are independent from a capability perspective.

there are many MSDs defined already, are we going to write that the new 
MSD type is not interacting with any other MSD each time we define a new 
one?

For me it's implicit, if the text does not say anything, there is no 
interaction.

thanks,
Peter

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 20 Mar 2020 11:23:22 -0700

On March 20, 2020 at 10:34:59 AM, Peter Psenak wrote:

> MSD type is not interacting with any other MSD each time we define a new

Yes, when they could be related, we are.  More importantly, the reason
why the will not interact, which is what Acee’s text points to.

BTW, according to the registry there are only 2 MSDs defined:
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types

Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 23 Mar 2020 10:16:42 +0100

Hi Alavaro,

> why the will not interact, which is what Acee’s text points to.

honestly I do not see a reason to say that they do not interact. Because 
if I use your logic I would have to mention hundred other node 
capabilities that ERLD-MSD is not interacting with. My logic is that if 
something interacts it needs to be specified, if it does not, it does 
not need to be.

> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types

there are more defined for SRv6 - draft-ietf-lsr-isis-srv6-extensions-06.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Mar 2020 14:36:39 +0000

Hi Alvaro, 

On 3/23/20, 5:17 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Alavaro,

I agree. It seems like a slippery slope to specifically call out protocol elements which not related from a protocol standpoint. 

Thanks,
Acee

    
    thanks,
    Peter

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 23 Mar 2020 18:23:10 +0000

Ok…let’s move forward.  No need to add more text.

Alvaro.

On March 23, 2020 at 10:36:42 AM, Acee Lindem (acee) ([email-masked]) wrote:

Hi Alvaro,

Hi Alavaro,

I agree. It seems like a slippery slope to specifically call out protocol
elements which not related from a protocol standpoint.

Thanks,
Acee

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 24 Mar 2020 11:44:48 +0100

Hi Alvaro,

I posted a new version - draft-ietf-isis-mpls-elc-11. It should have all 
your inputs incorporated.

Please let me know if you are ok with it. Once it's approved from your 
side, I will update the OSPF draft.

thanks,
Peter

  On 23/03/2020 19:23, Alvaro Retana wrote:
> On March 23, 2020 at 10:36:42 AM, Acee Lindem (acee) ([email-masked] 
> <mailto:[email-masked]>) wrote:
> 
>> Hi Alvaro,
>>
>> On 3/23/20, 5:17 AM, "Peter Psenak" <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Alavaro,
>>
>> I agree. It seems like a slippery slope to specifically call out 
>> protocol elements which not related from a protocol standpoint.
>>
>> Thanks,
>> Acee
>>
>> >

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 24 Mar 2020 16:00:21 +0000

> side, I will update the OSPF draft.

Yes, it looks good to me.  I just have a couple of minor nits (below)
-- no need to address them right now, you can wait for other Last Call
comments.

Thanks!

Alvaro.

86	   Recently, mechanisms have been defined to signal labels via link-
87	   state Interior Gateway Protocols (IGP) such as IS-IS [RFC8660].  This

[minor] Wouldn't a better reference for this be rfc8667?

90	   In cases where LSPs are used for whatever reasons (e.g., SR-MPLS

[nit] s/LSPs are used for whatever reasons/LSPs are used

149	   assigned by IANA for EARLD-MSD.  MSD-Value field is set to the ERLD

[nit] s/MSD-Value field/The MSD-Value field

199	   considerations as described in [RFC4971], [RFC7752], [RFC7794],
200	   [RFC8491], [RFC7752], [RFC8662],

[nit] rfc7752 is listed twice

265	   [RFC4971]  Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,

[minor] Please take this out, and replace the references in the text
to point to rfc7981.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 24 Mar 2020 18:16:49 +0100

Hi Alvaro,

On 24/03/2020 17:00, Alvaro Retana wrote:
> Yes, it looks good to me.  

thanks for your patience.

> I just have a couple of minor nits (below)

done.

done

done.

done.

done.

thanks,
Peter