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

Peter Psenak <> Thu, 20 December 2018 12:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44A68131128; Thu, 20 Dec 2018 04:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.565
X-Spam-Status: No, score=-14.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FFGz4VJFX4zf; Thu, 20 Dec 2018 04:08:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96ADC13112D; Thu, 20 Dec 2018 04:08:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=15903; q=dns/txt; s=iport; t=1545307683; x=1546517283; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PW+/lngGKW1UGd0+dOqP9ARBbtUt0Z3wv8cKfxyRBYI=; b=LxS1UuY7QZOZtQzfzauPHzBa69Td16QLr6ucgXfuHQ5LBTQqAW0/BjzR Qu2w3qrYWyQMfWrnqdgrAodeKpVeukiteUvIXZOk6iWKqA8YATGLLn4fr KMiSkdKkPBCvfVx5DHXb+zHakt6OjC/ehnzH5eqJ+PXDJVTF815N86ZH+ w=;
X-IronPort-AV: E=Sophos;i="5.56,376,1539648000"; d="scan'208";a="8992911"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 12:08:00 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id wBKC7xrt008491; Thu, 20 Dec 2018 12:08:00 GMT
To: Benjamin Kaduk <>
References: <> <> <> <>
Cc: The IESG <>,, Acee Lindem <>,,,
From: Peter Psenak <>
Message-ID: <>
Date: Thu, 20 Dec 2018 13:07:59 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Dec 2018 12:08:13 -0000

Hi Benjamin,

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


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
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>> The document, along with other ballot positions, can be found here:
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>> 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.
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>> 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
>>> 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
>> .
> .