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

[Peter Psenak <[e-mail]>]

Hi Benjamin,

please see inline (##PP):

On 17/12/2018 06:53 , Benjamin Kaduk wrote:
> Sorry for the slow reply -- you caught me right as I was leaving for
> vacation.
>
> On Wed, Dec 05, 2018 at 09:53:20AM +0100, Peter Psenak wrote:
>> Hi Benjamin,
>>
>> please see inline:
>>
>> On 05/12/18 04:44 , Benjamin Kaduk wrote:
>>> 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.)
>>
>> 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."
>
> 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".

##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.

>
>>>
>>> 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.
>>
>> please see my comments below.
>
> Okay.
>
>>>
>>> ----------------------------------------------------------------------
>>> 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?
>>
>> this document describes OSPFv3 extension for SR with the MPLS data
>> 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.
>
>>>
>>> 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.
>>
>>   "prefix being assigned multiple SIDs" - that is not what we are doing
>> here.
>
> 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.

##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."

>
>>>
>>> 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?
>>
>> yes.
>>
>>> 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.
>>>
>>
>> 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.
>
>
>
>>
>>> 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?
>>
>> 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.
>
>>>
>>> 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).
>>
>> ASBR is defined in terminology section.
>
> Precisely; you can just use the abbreviation if you want and make the text
> here shorter.

##PP
done.

>
>>>
>>>     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?)
>>
>> you can only POP the outmost label.
>
> Okay, thanks for confirming.
>
>>>
>>> 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.)
>>
>> I can rename to "Traffic Class" if you insist.
>
> I do not insist; I'm just trying to understand the common
> usage/conventions.

##PP
it has been updated.

thanks,
Peter

>
>>>
>>>     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.
>>
>> your understanding is correct. There is also some more details in the
>> next section.
>>
>>>
>>>     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.
>>
>> the use case is when you need to advertise Prefix-SID for different
>> Algorithms.
>>
>>>
>>> Section 7.1
>>>
>>> (Probably off-topic: what's the use case for assigning the same Adj-SID to
>>> different adjacencies?)
>>
>> load balancing of traffic over multiple links.
>
> Thanks for helping me understand better (here and above).
>
>>>
>>> Section 7.2
>>>
>>> Perhaps add DR to the terminology section (or expand on first usage)?
>>
>> ok, will do.
>>
>>>
>>> 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?
>>
>> 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.
>
> Okay, thanks.
>
>>>
>>>     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)?
>>
>> not sure I understand. NU-bit is defined in rfc5340. We are just reusing
>> 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.)
>
>>>
>>>     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.)
>>
>> right, I will remove the reference to section 5 and correct the text.
>>
>>>
>>> Section 8.4.1
>>>
>>> Do we need a reference for 2-Way and FULL?
>>
>> 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".
>
>>>
>>> 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.
>>
>> well, I guess what is important is that the IANA allocations has been made.
>
> Indeed.
>
> -Benjamin
> .
>