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

[Benjamin Kaduk <[e-mail]>]

On Thu, May 21, 2020 at 12:16:44PM +0200, Peter Psenak wrote:
> Hi Benjamin,
> 
> thanks for review.
> 
> Please see inline (##PP) two responses to OSPF specific comments.
> 
> 
> On 20/05/2020 00:43, Benjamin Kaduk via Datatracker wrote:
> > 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"?
> 
> ##PP
> this has been already addressed based on previous comments. Latest text 
> is as follows:
> 
> "Multiprotocol Label Switching (MPLS) has defined a mechanism to 
> load-balance traffic flows using Entropy Labels (EL). An ingress Label
> Switching Router (LSR) cannot insert ELs for packets going into a given 
> Label Switched Path (LSP) unless an egress LSR has indicated via 
> signaling that it has the capability to process ELs, referred to as the 
> Entropy Label Capability (ELC), on that LSP. In addition, it would be 
> useful for ingress LSRs to know each LSR's capability for reading the 
> maximum label stack depth and performing EL-based load-balancing, 
> referred to as Entropy Readable Label Depth (ERLD). This document 
> defines a mechanism to signal these two capabilities using OSPFv2 and 
> OSPFv3 and BGP-LS."

Great; thanks!

> >     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/
> 
> ##PP
> right, I can add it as normative, or remove completely, or keep as 
> informative. Whatever you like :)

Keep it as-is seems simplest, then.  But thanks :)

-Ben