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

Benjamin Kaduk <kaduk@mit.edu> Thu, 21 May 2020 19:41 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A663A0911; Thu, 21 May 2020 12:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3a-aASfWj530; Thu, 21 May 2020 12:41:23 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CDE3A0900; Thu, 21 May 2020 12:41:22 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04LJfF0x000531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 May 2020 15:41:17 -0400
Date: Thu, 21 May 2020 12:41:15 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Peter Psenak <ppsenak@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ospf-mpls-elc@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Acee Lindem <acee@cisco.com>, aretana.ietf@gmail.com
Message-ID: <20200521194115.GK58497@kduck.mit.edu>
References: <158992822966.6522.4643872233017159559@ietfa.amsl.com> <a52346b5-8e2c-3ef0-b6c8-c3ef041fa223@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a52346b5-8e2c-3ef0-b6c8-c3ef041fa223@cisco.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/pGruYMSUAy4XIPkt5oQKtkersFs>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-mpls-elc-13: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 19:41:26 -0000

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