Subject: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 04 Dec 2018 19:44:04 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ospf-ospfv3-segment-routing-extensions-20: 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-ospfv3-segment-routing-extensions/

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

What is the extensibility model for the "AF" (address family) field in the
OSPFv3 Extended Prefix Range TLV?  That is, what do we need to say about
current implementations' behavior to allow future changes?  (I also a
little bit wonder if we really need a full eight bits, but that's basically
aesthetic.)

Some of the text in Section 8.1 (see the COMMENT section) reads like it
might have an "Updates" relationship with other documents, but I don't know
enough to be sure.  Hopefully we can have a conversation to clarify the
situation.

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

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.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 05 Dec 2018 09:53:20 +0100

Hi Benjamin,

please see inline:

> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/

I don't think OSPFv3 will ever support other then IPv6 or IPv4 AF. Also 
the text says:

"Prefix encoding for other address families is beyond the scope
  of this specification."

> enough to be sure.  Hopefully we can have a conversation to clarify the

please see my comments below.

this document describes OSPFv3 extension for SR with the MPLS data 
plane, not IPv6 data plane. And rfc8402 is referenced.

> discussed in the linked document.

  "prefix being assigned multiple SIDs" - that is not what we are doing 
here.

> 18.19/16, 18.20/16, and 18.21/16?

yes.

> Or am I constrained to be a subset of

I would thing that the example in section 16 is clear enough.

> currently 00 and 11, i.e., fully redundant?

I would rather not get into that discussion here.

> https://www.rfc-editor.org/materials/abbrev.expansion.txt).

ASBR is defined in terminology section.

> outermost label?  (Or am I super-confused about how this is supposed to

you can only POP the outmost label.

> reference in for them or not, given that I'm not a practitioner here.)

I can rename to "Traffic Class" if you insist.

> but I do want to make sure I'm understanding it properly.

your understanding is correct. There is also some more details in the 
next section.

> Prefix Range), but maybe there's a use case that I'm missing on first

the use case is when you need to advertise Prefix-SID for different 
Algorithms.

> (Probably off-topic: what's the use case for assigning the same Adj-SID to

load balancing of traffic over multiple links.

> Perhaps add DR to the terminology section (or expand on first usage)?

ok, will do.

> Is this considered to be Update-ing the behavior of another RFC?

no. All we say is that the LSA type in which the SID from SRMS is 
advertised does not need to match the route-type of the prefix for which 
the SID is adverised.

> provide a reference).  Or is it a new requirement (in which case Updates:

not sure I understand. NU-bit is defined in rfc5340. We are just reusing 
it here. I can add a reference to it.

> not a real problem, so I'm keeping it in the COMMENT section for now.)

right, I will remove the reference to section 5 and correct the text.

> Do we need a reference for 2-Way and FULL?

these are standard OSPF adjacency states.

> that this is not a case of codepoint squatting.

well, I guess what is important is that the IANA allocations has been made.

thanks,
Peter

> .

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 16 Dec 2018 23:53:59 -0600

Sorry for the slow reply -- you caught me right as I was leaving for
vacation.

> "Prefix encoding for other address families is beyond the scope

Perhaps it would be better encoded in a 1-bit field (rather than an 8-bit
one), then?  That would at least make the (lack of) semantics of the other
7 bits more clear, as the usual "MUST set to zero on transmit and ignore on
receipt".

> please see my comments below.

Okay.

> plane, not IPv6 data plane. And rfc8402 is referenced.

I understand the difference between OSPFv3 SR with MPLS vs. IPv6 data plane
(well, at least that there is a difference).  My point is that you say it
"will be specified in a separate document".  If there's an existing I-D
that is the start of this work, listing it as an informative reference
seems helpful to me.  (If there's not, perhaps "at a later date" would work
instead of "in a separate document".)

But of course this is a non-blocking comment, so feel free to ignore -- I
really don't mind.

>   "prefix being assigned multiple SIDs" - that is not what we are doing 

Hmm, I must have misspoke; sorry.  My point remains, though, that if I go to
I-D.ietf-spring-segment-routing-ldp-interop and search for "range", I will
not find anything to help me know which part of that document you are
talking about.  I would encourage some additional text to clarify how the
terminology used in this document relates to the terminology and work used
in the referenced document.

> I would thing that the example in section 16 is clear enough.

I generally prefer to describe the normative behavior in actual text
description instead of relying on examples to clarify the expected
behavior.  That said, this is a non-blocking comment, so feel free to
retain the current text.  If you did want to add something, I would
propose the strawman:

OLD:
   The range represents the contiguous set of prefixes with the same
   prefix length as specified by the Prefix Length field.  The set
   starts with the prefix that is specified by the Address Prefix field.
   The number of prefixes in the range is equal to the Range size.

NEW:
   The range represents the contiguous set of prefixes with the same
   prefix length as specified by the Prefix Length field.  The set
   starts with the prefix that is specified by the Address Prefix field and
   continues with the subsequent prefixes of the same length, forming a
   contiguous block of addresses.  Since the Range Size is not restricted to a
   power of two, this new block of addresses may not be describable using a
   single address prefix/length.  The number of prefixes in the range is
   equal to the Range size.

> I would rather not get into that discussion here.

That's fine, though even just noting the redundancy and that it exists for
[historical/...] reasons might help some readers understand more easily.

> ASBR is defined in terminology section.

Precisely; you can just use the abbreviation if you want and make the text
here shorter.

> you can only POP the outmost label.

Okay, thanks for confirming.

> I can rename to "Traffic Class" if you insist.

I do not insist; I'm just trying to understand the common
usage/conventions.

> load balancing of traffic over multiple links.

Thanks for helping me understand better (here and above).

> advertised does not need to match the route-type of the prefix for which 

Okay, thanks.

> it here. I can add a reference to it.

Thanks for the pointer.  I was wondering whether RFC5340 itself would
require the NU bit to be set in this situation -- from a quick skim, it
seems that it does not, so there's nothing to do here (other than add that
reference, if you want.)

> these are standard OSPF adjacency states.

Okay.  Sorry for my ignorance here (and throughout), and thank you again
for your patient explanations of the "basic concepts".

> well, I guess what is important is that the IANA allocations has been made.

Indeed.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 17 Dec 2018 00:08:51 -0600

>    single address prefix/length.  The number of prefixes in the range is

Ah, now I see the text proposed in response to Suresh's comments; that text
works for me, too.

-Benjamin

---

From: Peter Psenak <[email-masked]>
Date: Mon, 17 Dec 2018 12:32:51 +0100

Hi Benjamin,

please see inline (##PP):

> 7 bits more clear, as the usual "MUST set to zero on transmit and ignore on

##PP
it's too late now to change the encoding. This draft has several years 
of history and there are implementation shipping. Changing the encoding 
would cause the backward compatibility issues.

> in the referenced document.

##PP
range is not defined in I-D.ietf-spring-segment-routing-ldp-interop, 
it's the SRMS functionality that is defined there.
The range was defined for IGPs to optimize the encoding for SRMS 
advertisement - with thousands of prefixes the encoding would not scale 
if we advertise the individual SID for every prefix independently.

What about the following updated text in the OSPFv3 draft:

"In some cases it is useful to advertise attributes for a range of 
prefixes. The Segment Routing Mapping Server, which is described in 
<xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>, is an 
example of where SIDs for multiple prefixes can be advertised. To 
optimize such advertisement in case of multiple prefixes from a 
contiguous address range, OSPFv3 Extended Prefix Range TLV is defined."

> Precisely; you can just use the abbreviation if you want and make the text

##PP
done.

> I do not insist; I'm just trying to understand the common

##PP
it has been updated.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 Dec 2018 13:07:59 +0100

Hi Benjamin,

are you ok with my responses and proposed changed text for the range?

thanks,
Peter

On 17/12/2018 12:32 , Peter Psenak wrote:
>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Dec 2018 22:29:40 -0600

> > would cause the backward compatibility issues.

I didn't think I was suggesting changing the bits on the wire -- in an
8-octet field, we're encoding the values 0 and 1 as:

00000000
00000001

I'm proposing to change the eight bits to be specified as "the first seven
bits are always set to 0 but should be ignored on receipt; the eighth bit
represents the 0 or 1 value".  This makes it clear what needs to happen if
there's a need to use any of those seven bits (an Update to this document)
and also makes it more clear that there are not expected to be any
additional AFs defined anytime soon.

Could you help me understand what would be backward incompatible with this
proposal?

> > contiguous address range, OSPFv3 Extended Prefix Range TLV is defined."

That's a big help, at least for me; thanks!
I wonder if the first sentence would be better as "useful to advertise
attributes for many prefixes at once", but will definitely defer to your
judgement of that.

-Benjamin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 22 Dec 2018 14:34:37 +0000

Hi Ben, 

See inline. 

On 12/21/18, 11:29 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    
    00000000
    00000001

What would  this accomplish? This seems equivalent to supporting 0 or 1 for an 8 bit field. Are you trying to free up those bits for other purposes? We have other LSRs drafts and RFCs, e.g., RFC 7684, that use this 8-bit AF encoding and I see no value whatsoever in changing it. Please clear the DISCUSS.

Perhaps you should subscribed to the LSR list so that you can apply your protocol encoding expertise to our -00 drafts. Here is the link: 
    
    https://www.ietf.org/mailman/listinfo/lsr

Thanks,
Acee 

    
    
    -Benjamin

---

From: Peter Psenak <[email-masked]>
Date: Sat, 22 Dec 2018 16:53:53 +0100

Hi Benjamin,

> attributes for many prefixes at once", but will definitely defer to your

sure, I will word it that way.

thanks,
Peter