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,

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

thanks,
Peter

On 17/12/2018 12:32 , Peter Psenak wrote:
> 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
>> .
>>
>
> .
>