[Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-23: (with COMMENT)
Benjamin Kaduk <firstname.lastname@example.org> Fri, 11 January 2019 01:50 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C06F212D84D; Thu, 10 Jan 2019 17:50:34 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Benjamin Kaduk <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, Acee Lindem <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Date: Thu, 10 Jan 2019 17:50:34 -0800
Subject: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-23: (with COMMENT)
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jan 2019 01:50:35 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-ospf-ospfv3-segment-routing-extensions-23: No Objection 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-ospfv3-segment-routing-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss point! [Original COMMENT section preserved unchanged below] Section 1 Is there a start of the separate document that covers SR with the IPv6 data plane that we could reference from here? Section 5 In some cases it is useful to advertise attributes for a range of prefixes. The Segment Routing Mapping Server, which is described in [I-D.ietf-spring-segment-routing-ldp-interop], is an example of where a single advertisement is needed to advertise SIDs for multiple prefixes from a contiguous address range. I note that the referenced document does not use the word "range" to describe the prefix being assigned multiple SIDs; it might be helpful to say a few more words about how the range of prefixes gets mapped to what is discussed in the linked document. I'm also not entirely sure how to construct the prefix range just given this format description. Suppose I have an IPv4 prefix of 18.18/16 and a range size of 4; my prefix length is 16 and the address prefix is encoded as 0x120120000. Am I then representing the four prefixes 18.18/16, 18.19/16, 18.20/16, and 18.21/16? Or am I constrained to be a subset of 18.18/18 (in which case I don't know what the actual distinct prefixes would be)? The examples in Section 6 suggests the former, but I would suggest stating this explictly, here. Section 6 Should there be any discussion of the historical or future reasons why V and L are separate flag bits, given that the only legal combinations are currently 00 and 11, i.e., fully redundant? It may not be necessary to expand ASBR on first usage here, since it's in the terminology section (and marked as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt). If the NP-Flag is not set, then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane. If the NP-flag is not set, then the received E-flag is ignored. Is it going to be clear that "pop" only applies when this Prefix-SID is the outermost label? (Or am I super-confused about how this is supposed to work?) A similar consideration may apply to the discussion of the NP flag as well. Also some redundantly expanded ABR and ASBR here as well. This is useful, e.g., when the originator of the Prefix- SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. Are we still supposed to call these the EXP bits after RFC 5462? (I had to look up what they were; not sure if this means that we should put a reference in for them or not, given that I'm not a practitioner here.) When the M-Flag is set, the NP-flag and the E-flag MUST be ignored on reception. Do I understand this correctly that this is because the mapping server may not know the needs of the individual routers, and if the routers had specific needs they should advertise the SIDs directly (which would take precedence over the mapping server's advertisement)? If so, given the following discussion, I wouldn't suggest adding any extra text about it, but I do want to make sure I'm understanding it properly. When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a starting SID/Label value. Am I remembering correctly that Prefix-SID can appear multiple times within OSPFv3 Extended Prefix Range? Then each Prefix-SID would be indicating a distinct range but adhering to the same parameters of the range that are indicated in the Extended Prefix Range TLV? This seems a little weird on the face of it (as opposed to a single Prefix-SID sub-TLV per Extended Prefix Range), but maybe there's a use case that I'm missing on first glance. Section 7.1 (Probably off-topic: what's the use case for assigning the same Adj-SID to different adjacencies?) Section 7.2 Perhaps add DR to the terminology section (or expand on first usage)? Section 8.1 When a Prefix-SID is advertised by the Mapping Server, which is indicated by the M-flag in the Prefix-SID Sub-TLV (Section 6), the route type as implied by the LSA type is ignored and the Prefix-SID is bound to the corresponding prefix independent of the route type. Is this considered to be Update-ing the behavior of another RFC? Advertisement of the Prefix-SID by the Mapping Server using an Inter- Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV [RFC8362] does not itself contribute to the prefix reachability. The NU-bit MUST be set in the PrefixOptions field of the LSA which is used by the Mapping Server to advertise SID or SID Range, which prevents the advertisement from contributing to prefix reachability. This MUST reads like it is restating an existing normative requirement from elsewhere (in which case we should probably just state it as fact and provide a reference). Or is it a new requirement (in which case Updates: might be in order)? Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between areas. Similar to propagation of prefixes between areas, an ABR only propagates the OSPFv3 Extended Prefix Range TLV that it considers to be the best from the set it received. The rules used to pick the best OSPFv3 Extended Prefix Range TLV are described in Section 5. I don't see any usage of "best" in Section 5; I do see direction to use the numerically smallest Instance ID when multiple Extended Prefix Range TLVs advertise *the exact same range*. But this in and of itself does not safisfy the claim here that there is guidance to pick a single best Extended Prefix Range TLV, so I'm left confused as to what's supposed to happen. Perhaps this was intended as a transition to Section 8.2 instead of referring back to Section 5 (especially considering that Section 8.1 is supposed to be intra-area but this topic is inter-area)? (This sort of dangling/unclear internal reference would normally be a DISCUSS, but it seems very likely this is just a stale section number and not a real problem, so I'm keeping it in the COMMENT section for now.) Section 8.4.1 Do we need a reference for 2-Way and FULL? Section 9 I would normally expect some text about "IANA has made permanent the following temporary allocations" or similar, so the reader can quickly tell that this is not a case of codepoint squatting.
- [Lsr] Benjamin Kaduk's No Objection on draft-ie... Benjamin Kaduk