Subject: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 19 May 2020 15:44:41 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As for other reviewers, many of my comments duplicate those for the OSPF
document; I expect that the analogous responses apply and am fine if
they only appear for one document's review.

Here, the question I have about normative language applies to the text
in Section 3:

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

The scenario in question is analogous to the OSPF cross-area case: is
the router propagating the prefix between ISIS levels required to
implement this document; is preservation of the flag value a new
requirement from this document vs. a preexisting property; and is this
document trying to make normative requirements of devices that don't
implement this document?

Likewise, the ASBR case for cross-protocol redistribution seems to
rather inherently require understanding the semantics of the flags being
translated.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

Should we add a sentence at the end of the last paragraph about how
"this document defines a mechanism to signal the ERLD using IS-IS"?

   In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be

side note(?): I don't know that SR-MPLS is so popular so as to be
privileged as the only example given for LSP usage.  If we instead
talked about using IGPs to signal labels, this selection would seem less
surprising to me.

Section 3

   unless all of its interfaces are capable of processing ELs.  If a
   router supports ELs on all of its interfaces, it SHOULD set the ELC
   for every local host prefix it advertises in IS-IS.

Do we want to say anything about (not) advertising the ELC for other
prefixes?

Section 4

I agree with Roman's comment about code 2 vs TBD2.

   ERLD in the range between 0 to 255.  The scope of the advertisement
   depends on the application.  If a router has multiple interfaces with

Just to check: w.r.t. "scope", both this document and the OSPF one only
define usage of this MSD type at the scope of a single node, right?  (I
don't see a particular reason to preclude using it at a different
scope.)

Section 6

      - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV
      registry has been assigned to the ELC Flag.  IANA is asked to

Is there an "IS-IS" in the name of this registry?

Section 7

Should we say anything about considerations for redistributing ELC/ERLD
information at the ASBR with respect to exposing "internal information"
to external parties?

   This document specifies the ability to advertise additional node
   capabilities using IS-IS and BGP-LS.  As such, the security
   considerations as described in [RFC7981], [RFC7752], [RFC7794],
   [RFC8491], [RFC8662], [I-D.ietf-idr-bgp-ls-segment-routing-ext] and

RFC 8662's security considerations have a pretty hard dependency on RFC
6790's security considerations; it might be worth mentioning 6790
directly in this list as well.

   [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this
   document.

Could we also have a brief note that the normal IS-IS authentication
mechanisms serve to protect the ELC/ERLD information?

   Incorrectly setting the E flag during origination, propagation or
   redistribution may lead to black-holing of the traffic on the egress
   node.

This is what happens when the E flag should not be set but is
erroneously set.  Should we also say what happens if we should set the E
flag but erroneously clear it (e.g., that poor or no load-balancing may
occur)?

Section 8

I do see the note in the shepherd writeup about the sixth author (thank
you!); if we're already breaking through the 5-author limit, did we
consider making those who "should be considered as co-authors" listed as
co-authors?

Section 10.1

Should we reference RFC 7981 from Section 4 as well?  Right now we seem
to only use it for the security considerations, which is not necessarily
enough to qualify it as a normative reference.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 21 May 2020 12:05:39 +0200

Benjamin,

thanks for review, please see inline (##PP):

> https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/

##PP
this is a new requirement and only applies to the routers that support 
this document. We are not making normative requirements of devices that 
don't implement this document, we cannot.

Maybe we can add that it only applies to the routers that supports this 
extension:

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

Would it work?

> rather inherently require understanding the semantics of the flags being

similarly to the above I can chnage to:

"When a router supporting this extension redistribute a prefix ..."

not sure I understand, how is described in the body of the document.

> talked about using IGPs to signal labels, this selection would seem less

this document describes the ELC/ERLD capability signaling for SR MPLS. 
For non SR MPLS cases, thee are existing mechanisms to learn ELC/ERLD.

I can replace the text with:

"In cases where SR is used with the MPLS Data Plane"

Would it work?

> Do we want to say anything about (not) advertising the ELC for other

Do we have to? I can add "MUST NOT set ELC with for any other prefix", 
but I find it unneeded.

> I agree with Roman's comment about code 2 vs TBD2.

that has been fixed already.

> don't see a particular reason to preclude using it at a different

the scope here means where the information will be flooded - area only 
or network wide. No such thing as a node scope.

> Is there an "IS-IS" in the name of this registry?

no the registry name is "Bit Values for Prefix Attribute Flags Sub-TLV".

> information at the ASBR with respect to exposing "internal information"

why would this be "internal information" and why redistribution would be 
"external party"? Redistribution between IGPs is predominantly done 
between IGPs under same administrative domain.

> directly in this list as well.

would not that be implicit when mentioning RFC 8662?

> mechanisms serve to protect the ELC/ERLD information?

do we need to repeat this every time we add a bit in the TLV?

> flag but erroneously clear it (e.g., that poor or no load-balancing may

yes, there is a text there already:

"Incorrectly setting of the ERLD value may lead to poor or no 
load-balancing of the traffic."

> consider making those who "should be considered as co-authors" listed as

I'm not fun of this 5 authors rule to be honest.

> enough to qualify it as a normative reference.

we reference RFC8491, which references RFC 7981. I don't see a need to 
reference RFC 7981 directly.

thanks,
Peter

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 21 May 2020 11:44:36 +0000

On May 21, 2020 at 6:05:41 AM, Peter Psenak wrote:

Peter:

Hi!

> ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."

You're right, we can only apply requirements to routers that support
this specification.  IOW, adding the clarification is not necessary.

My interpretation of Ben's question is two-fold:

(1) Would ISIS routers normally propagate the information to a
different level?  The ELC is a new prefix attribute flag -- are prefix
attributes always propagated (unchanged) to other levels?  If so, then
the requirement (MUST) is not needed.  My reading of rfc7794 is that
the propagation is optional...

(2) If the propagation is not automatic, and the L1L2 router doesn't
support this specification, then what are the drawbacks/failure
scenarios?  IOW, for multi-level operation is it a requirement that
the L1L2 support this specification?

Thanks!

Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 21 May 2020 14:15:37 +0200

Hi Alvaro,

> the propagation is optional...

depends on the attribute or a bit. Some are propagated some are not. 
That's why we are saying this one MUST be preserved.

> the L1L2 support this specification?

drawback are identical to what is mentioned in the Security 
Considerations section.

thanks,
Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 May 2020 12:38:56 -0700

Hi Peter,

> ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."

That would work, yes.
I think what bothers me about the current text is that it feels like a
global statement that holds universally everywhere (and as such would be
"scope overreach").  Even to say something like "ELC signaling MUST be
preserved when a router propagates a prefix between ISIS levels" (which is
superficially similar) does not bother me very much, since it presumes a
knowledge of what ELC signaling is (and thus, implementation of this
document) in a way that "unknown prefix attribute flag 3" does not.  That
is, we clearly (given your above explanation) don't expect the "unknown
prefix attribute flag 3" to get propagaged, and only when we know that it's
the ELC signalling does the requirement kick in, if that makes sense.

With respect to Alvaro's clarification, your answer for (1) makes sense;
thanks!  I think Alvaro has offered to help work out what (if any)
additional text we might want to be sure that the answer to (2) is clear in
the document.

> not sure I understand, how is described in the body of the document.

I think I maybe put a little more detail on the motivation for this
question in the OSPF document's comments.  Basically, it's about parity
between Abstract and Introduction -- the Introduction says clearly "this
draft defines a mechanism to signal the ELC using IS-IS", but there is not
an analogous statement about the ERLD signaling mechanism.  As such, it's
an editorial matter of style and you should feel free to ignore the comment
or do what you see fit.

> "In cases where SR is used with the MPLS Data Plane"

Sure, thanks.

> Do we have to? I can add "MUST NOT set ELC with for any other prefix", 

This is the "comment" section of the document, so no, you don't have to :)
I mostly ask because we give guidance on what to do for local host prefixes
but say nothing about the other case.  That could be taken to imply that we
don't know what guidance to give, even though someone skilled in the area
who thinks through what the mechanism is doing will come to the conclusion
that it makes no sense/is actively harmful to advertise the ELC for other
prefixes.

> or network wide. No such thing as a node scope.

Oops, sorry for misremembering that part, and thanks for the clarification.

> no the registry name is "Bit Values for Prefix Attribute Flags Sub-TLV".

Okay, thanks for confirming.

> between IGPs under same administrative domain.

I don't have any scenario in mind; I just wanted to check if there were any
significant considerations to mention.  It sounds like there aren't such
considerations, and thus nothing to mention.
> would not that be implicit when mentioning RFC 8662?

Yes; this is mostly a question of style.

> do we need to repeat this every time we add a bit in the TLV?

It's my preference, though not a strict need.

> load-balancing of the traffic."

I thought that was about the ERLD value, not the ELC indicator, but trust
you to know best.

> reference RFC 7981 directly.

Okay.

Thanks for the clarifications and updates!

-Ben

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 22 May 2020 14:59:34 +0000

On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote:

Peter:

Hi!

> additional text we might want to be sure that the answer to (2) is clear in

I think that #1 is where some clarification could be useful. :-)

I'm including both ISIS and OSPF suggestions below to consolidate the
discussion.

...
> That's why we are saying this one MUST be preserved.

Right.

For ISIS I think the current text is in line with the specification of
the other bits in rfc7794.  No changes are needed.

If anything, you may want to change the order of this sentence to
address Ben's comment:

OLD>

NEW>
   The ELC signaling MUST be preserved when a router propagates a prefix
   between ISIS levels ([RFC5302]).

[Similar for OSPF.]

I think that for OSPF it is not that simple...

For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix
Opaque LSA depends on the scope of the advertised prefixes", which I
assume means that for intra-area prefixes the scope will be
area-local...so the ABR wouldn't simply propagate it; it would have to
originate a new LSA.

Suggestion (Add to 3.1)>
   When an OSPFv2 Area Border Router (ABR) distributes information between
   connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA
   [RFC7684] including the received ELC setting.  If the received information
   is included in an LSA with an AS-wide scope, then the new LSA is not needed.

For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find
anything in rfc5340 saying that the received values should be copied
into the Inter-Area-Prefix-LSA (nor that they should not).

Suggestion (Add to 3.2)>
   When an OSPFv3 Area Border Router (ABR) distributes information between
   connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA
   MUST be the same as the received value.

> drawback are identical to what is mentioned in the Security

I think that text is ok.

Thanks!

Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 26 May 2020 10:26:24 +0200

Hi Alvaro,

please see inline (##PP)

>     between ISIS levels ([RFC5302]).

##PP
done.

> area-local...so the ABR wouldn't simply propagate it; it would have to

##PP
correct. It is always a new LSA that ABR needs to generate. Here it's 
actually two LSAs.

>     is included in an LSA with an AS-wide scope, then the new LSA is not needed.

Here's my suggestion for OSPFv2 ABR related text:

"The ELC signaling MUST be preserved when an OSPF Area Border Router 
(ABR) distributes information between connected areas. To do so, ABR 
MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including 
the received ELC setting."

Here's my suggested text for OSPFv2 ASBR case:

"When an OSPF Autonomous System Boundary Router (ASBR) redistributes a 
prefix from another instance of OSPF or from some other protocol, it 
SHOULD preserve the ELC signaling for the prefix if it exists. To do so, 
ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the 
ELC setting of the redistributed prefix. The flooding scope of the 
Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that 
ASBR originates as a result of the redistribution. The exact mechanism 
used to exchange ELC between protocol instances on the ASBR is outside
of the scope of this document."

>     MUST be the same as the received value.

Here's my suggestion for OSPFv3 ABR and ASBR:

"The ELC signaling MUST be preserved when an OSPFv3 Area Border Router 
(ABR) distributes information between connected areas. The setting of 
the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the 
Inter-Area-Prefix TLV [RFC8362], generated by ABR, MUST be the same as 
the value the ELC Flag associated with the prefix in the source area."

"When an OSPFv3 Autonomous System Boundary Router (ASBR) redistributes a 
prefix from another instance of OSPFv3 or from some other protocol, it 
SHOULD preserve the ELC signaling for the prefix if it exists. The 
setting of the ELC Flag in the AS-External-LSA [RFC5340] or in the 
External-Prefix TLV [RFC8362], generated by ASBR, MUST be the same as 
the value the ELC Flag associated with the prefix in the source domain.	 
The exact mechanism used to exchange ELC between protocol instances on 
the ASBR is outside of the scope of this document."

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 26 May 2020 10:58:50 +0200

Hi Ben,

please see inline (##PP2)

>> ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix."

##PP2
I have suggested some text to clarify ABR and ASBR behavior in my 
response to Alvaro. Please have a look if that is fine with you. I'm not 
going to add the "When a router supporting this extension", as this was 
not necessary according to Alvaro.

> an editorial matter of style and you should feel free to ignore the comment

##PP2
I added the below sentence:

"This document defines a mechanism to signal the ERLD using IS-IS"

Similar has been done to OSPF draft.

>> "In cases where SR is used with the MPLS Data Plane"

##PP2
  done.
> that it makes no sense/is actively harmful to advertise the ELC for other

##PP2
I would tend to leave it as it is.

> I thought that was about the ERLD value, not the ELC indicator, but trust

##PP2
sorry, you are right.

Regarding the "E flag being erroneously clear" - I would think that 
"Incorrectly setting the E flag " covers both cases of E bit being set 
when it should not be set and E bit not being set when it should be set.

What about this:

"Incorrectly setting the E flag during origination, propagation or 
redistribution may lead to poor or no load-balancing of the traffic or 
black-holing of the traffic on the egress node."

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 May 2020 11:49:13 +0000

Hi Alvaro, 

See inline. 

On 5/22/20, 10:59 AM, "Alvaro Retana" <[email-masked]> wrote:

    Peter:

    Hi!

    ...

    Right.

    OLD>

    NEW>

    [Similar for OSPF.]

I agree with the changes but have suggested alternate text. 

    Suggestion (Add to 3.1)>

I'd suggest:

      When an OSPFv2 Area Border Router (ABR) advertises prefix information between
      areas and ELC information is was advertised for the prefix in the source area, the
      ABR SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] propagating
      the prefix's source area setting. If the ELC setting, is also advertised in an OSPFv2
      Extended Prefix Opaque LSA with AS-wide scope, the additional LSA origination
      Is not needed. 

    Suggestion (Add to 3.2)>

I'd suggest:
      
      When an OSPFv3 Area Border Router (ABR) advertises information between
      areas, the setting of the ELC flag in the Inter-area-prefix-LSA MUST be the
      propagated unchanged. 

Thanks,
Acee

    I think that text is ok.

    Thanks!

    Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 26 May 2020 14:22:26 +0200

Hi Acee,

have you looked at the texts that I suggested in my response to Alvaro 
earlier today?

Please see inline:

>         is included in an LSA with an AS-wide scope, then the new LSA is not needed.

when would ABR do inter area propagation of what is advertised in AS 
scope LSA? I can not think of such a case.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 May 2020 13:58:28 +0000

Hi Peter, 

On 5/26/20, 8:22 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Acee,

I found it - let me reply to that Email.

Thanks,
Acee

    Please see inline:

    thanks,
    Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 May 2020 14:07:42 +0000

Hi Peter, 

This is in response to the previous Email on your suggested text. 

On 5/26/20, 4:26 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Alvaro,

    please see inline (##PP)

    ##PP
    done.

    ##PP

Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR MUST". 

Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with "that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent. 
Also, "originate Extended" with "originate an Extended". 

Same change - replace "connected areas" with "areas" and "by ABR" with "by an ABR". 

    the ASBR is outside of the scope of this document. 

Add "NSSA-LSA" as a case. Replace "by ASBR" with "by an ASBR" and "value the ELC" with "value of the ELC". 

Thanks,
Acee

    thanks,
    Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 26 May 2020 16:25:37 +0200

Hi Acee,

updated the text based on your comments.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 May 2020 14:28:19 +0000

Hi Peter, 
Thanks - hopefully this will more than satisfy Ben's discuss.
Acee

On 5/26/20, 10:25 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Acee,

    thanks,
    Peter

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 26 May 2020 08:03:17 -0700

Just for the record, I’m ok with the latest text.

Thanks!

Alvaro.

On May 26, 2020 at 10:25:38 AM, Peter Psenak ([email-masked]) wrote:

Hi Acee,

thanks,
Peter

On 26/05/2020 16:07, Acee Lindem (acee) wrote:
> Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with
"that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 30 May 2020 14:03:31 -0700

I think it will work for me as well -- thanks!

-Ben