OSPFv3 Extensions for Segment Routing

Note: This ballot was opened for revision 18 and is now closed.

Alvaro Retana Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-12-05 for -20)
I had the same comment as Alissa.

Alissa Cooper No Objection

Comment (2018-12-04 for -20)
Please use the RFC 8147 boilerplate rather than the RFC 2119 boilerplate.

(Spencer Dawkins) No Objection

Comment (2018-12-04 for -20)
The Introduction would have been much clearer for me if these paragraphs were much closer to the top of the section - they're at the bottom of the section now. 

  This draft describes the OSPFv3 extensions required for Segment
   Routing with MPLS data plane.

   Segment Routing architecture is described in [RFC8402].

   Segment Routing use cases are described in [RFC7855].

With that change, I'm not sure how much of the discussion in the Introduction would still be required, but do the right thing, of course. 

I'd make the same suggestion for the Abstract, 

  Segment Routing (SR) allows a flexible definition of end-to-end paths
   within IGP topologies by encoding paths as sequences of topological
   sub-paths, called "segments".  These segments are advertised by the
   link-state routing protocols (IS-IS and OSPF).

   This draft describes the OSPFv3 extensions required for Segment
   Routing with MPLS data plane.

if it was more than two paragraphs long ...

I am thinking that the reference 

  There are additional segment types, e.g., Binding SID defined in

would be more useful at the beginning of Section 3, because that's where you list the additional segment types, but the reference is back in the Introduction (with only one example of the segment types). 

I'm thinking the SHOULD in this text

  Existing security extensions as described in [RFC5340] and [RFC8362]
   apply to these segment routing extensions.  While OSPFv3 is under a
   single administrative domain, there can be deployments where
   potential attackers have access to one or more networks in the OSPFv3
   routing domain.  In these deployments, stronger authentication
   mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD
   be used.

is not an RFC 2119 SHOULD that describes interworking, so something like

   In these deployments, stronger authentication
   mechanisms such as those specified in [RFC4552] or [RFC7166] are

would be better, but if this IS a SHOULD, I'm curious why you wouldn't use stronger authentication mechanisms if they're needed. You might want to add guidance about that, so it's not confused with MUST (BUT WE KNOW YOU WON'T) as defined in https://tools.ietf.org/html/rfc6919#section-1. 

Is there another document that says things like 

  Implementations MUST assure that malformed TLV and Sub-TLV defined in
   this document are detected and do not provide a vulnerability for
   attackers to crash the OSPFv3 router or routing process.  Reception
   of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for
   further analysis.  Logging of malformed TLVs and Sub-TLVs SHOULD be
   rate-limited to prevent a Denial of Service (DoS) attack (distributed
   or otherwise) from overloading the OSPFv3 control plane.

? This doesn't seem very SR-specific, although I'm guessing. If there's a broader document, I don't object to including this guidance here, but adding a reference to a broader document might be useful.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-01-10)
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

   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

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

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

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

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.

Suresh Krishnan No Objection

Comment (2018-12-05 for -20)
* I share Benjamin's confusion regarding the prefix ranges and would like this to be clarified.

* For the address family, I do have a suggestion. There is an IANA registry for Address Family Numbers that can provide the extensibility needed. If future extensibility of this space is desired, this might be an option to consider.


Warren Kumari No Objection

Comment (2018-12-04 for -20)
Thanks to Joe Clarke for his OpsDir review: https://datatracker.ietf.org/doc/review-ietf-ospf-ospfv3-segment-routing-extensions-16-opsdir-lc-clarke-2018-10-26/ , and thank you authors for addressing them.

Mirja K├╝hlewind No Objection

Comment (2018-12-03 for -19)
Minor comments:
1) In intro: "...while an adjacency segment, in
   most cases, is a one-hop path."
Is that true, that in _most_ cases it is one hop? I though SR makes most sense in order to specify routers/hops that need to be visited, not matter how many hops are in between.

2) The contributor section has the following statement:
"The following people gave a substantial contribution to the content
   of this document and should be considered as co-authors:"
Should this section then not be called "Authors" instead?

Alexey Melnikov No Objection

Martin Vigoureux No Objection

Comment (2018-12-04 for -20)

thank you for this document.
I do have the usual IESG comment of suggesting to use RFC 8174 text for the requirement language, and also have a suggestion:
In section 7.2 you say:
      When the P-flag is not set, the Adj-SID MAY be persistent.  When
      the P-flag is set, the Adj-SID MUST be persistent.
Because we're in the LAN Adjacency section you may want to qualify the Adj-SID as being a LAN one.