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

Peter Psenak <ppsenak@cisco.com> Tue, 08 January 2019 08:14 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE72130DE5; Tue, 8 Jan 2019 00:14:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwSsPi3olZcx; Tue, 8 Jan 2019 00:13:56 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08B81271FF; Tue, 8 Jan 2019 00:13:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21456; q=dns/txt; s=iport; t=1546935236; x=1548144836; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=QA2fAXdMBxtMXNt1qT3XvYcFVjeJ35oGz13VnEWCeUQ=; b=kdNBjKRu8gjptA6LFrp4yY3XFTn2CQ8OI3qcuUxLsO0AKoUKAePPPv2n I/wc/sQZjAXlSmLBcmtZYLeXoZ7mzynzbzXXmStAOPlIyI6UnpekL8YAh pCPpVTuDf2Zx/5Qf1lkODmbXKXFmOhKS3o6WJXyTrOc0p5NARZZyixvyi 0=;
X-IronPort-AV: E=Sophos;i="5.56,453,1539648000"; d="scan'208";a="9252345"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2019 08:13:53 +0000
Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x088DqUL031571; Tue, 8 Jan 2019 08:13:53 GMT
To: "Acee Lindem (acee)" <acee@cisco.com>, Benjamin Kaduk <kaduk@mit.edu>
References: <154398144445.4943.7198735398003216566.idtracker@ietfa.amsl.com> <5C079200.1030701@cisco.com> <20181217055358.GC94620@kduck.kaduk.org> <69190220-4994-f9c9-4adf-5016abf3a39b@cisco.com> <03e6354b-c606-fc4a-bbf2-3d59fa1cb774@cisco.com> <20181222042939.GW94620@kduck.kaduk.org> <8D31ADF0-FA83-4B23-805E-76145BF914C1@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" <draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <f3dff5f1-434c-431d-15a3-5fa7462f5572@cisco.com>
Date: Tue, 8 Jan 2019 09:13:52 +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: <8D31ADF0-FA83-4B23-805E-76145BF914C1@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7mRyCnaW2dXj22SN98xWfgLgf3Q>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 08:14:01 -0000

Hi Benjamin,

please see inline:


On 22/12/2018 15:34 , Acee Lindem (acee) wrote:
> Hi Ben,
>
> See inline.
>
> ´╗┐On 12/21/18, 11:29 PM, "Benjamin Kaduk" <kaduk@mit.edu>; wrote:
>
>     On Thu, Dec 20, 2018 at 01:07:59PM +0100, Peter Psenak wrote:
>     > 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.
>
>     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.

currently the draft only supports 0 and 1. It says:

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

Given that we have other RFCs where 8-bit field is used for AF, can we 
leave it as we have it please?

thanks,
Peter

>
> 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
>
>
>     Could you help me understand what would be backward incompatible with this
>     proposal?
>
>     > >>
>     > >>>>
>     > >>>> 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."
>
>     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
>
>     > >>
>     > >>>>
>     > >>>> 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
>     > >> .
>     > >>
>     > >
>     > > .
>     > >
>     >
>
>