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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: 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-ospf-mpls-elc/



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

I have a question about the scope of some normative language, which may
or may not be problematic but I'm too ignorant of OSPF details to be
able to answer myself.  In Section 3 we say that:

   When an OSPF Area Border Router (ABR) distributes information between
   connected areas it MUST preserve the ELC setting.

My undesrtanding is that it's normal operation for an ABR to
distribution information about prefixes and such between areas, and in
particular that an ABR does not necessarily need to know the semantic
details of every bit of information being distributed in that fashion.
So, I am imagining a scenario where some routers in both areas
advertise/understand the ELC flag but the ABR between them does not
implement this spec.  What would happen in such a scenario?  If the ABR
is still expected to distribute the ELC setting without change, isn't
that just a core requirement from the respective OSPF specs, as opposed
to a new requirement imposed by this spec (which, in this scenario, the
ABR is not claiming to adhere to anyway)?

There is perhaps a similar question about the ASBR guidance, though when
doing cross-protocol signalling there is a more clear need for the ASBR
to understand the semantics of the flags it is redistributing (and it's
only a "SHOULD").


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

Section 1

The abstract is pretty explicit that "this draft defines" both ELC and
ERLD signaling capabilities, but this section only has a clear statement
for the ELC.  Should we put something at the end of the last paragraph
about "this document defines a mechanism to signal the ERLD using OSPFv2
and OSPFv3"?

   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

   If the router supports ELs on all of its interfaces, it SHOULD
   advertise the ELC with every local host prefix it advertises in OSPF.

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

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 OSPF and BGP-LS.  As such, the security
   considerations as described in [RFC5340], [RFC7770], [RFC7752],
   [RFC7684], [RFC8476], [RFC8662],

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-ext] and
   [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this
   document.

Could we also have a brief note that the (respective) OSPF security
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.2

It's slightly surprising to see the core OSPF protocols only listed as
informative, but I can see how they are to be considered "basic
specifications" in the vein of
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/