Re: [auth48] [AD] AUTH48: RFC-to-be 9514 <draft-ietf-idr-bgpls-srv6-ext-14> for your review

[Ketan Talaulikar <[e-mail]>]

Hi Madison,

Some comments on the changes made:

a) Sec 7.2
The BGP PeerNode SID and PeerSet SID *SIDs*

The "and" is required above.

b) The caption for Table 1 is not correct - perhaps it should be "Addition
to NLRI Types registry"


Please check inline below for responses.


On Mon, Nov 6, 2023 at 4:43 PM Madison Church <[e-mail]> wrote:

> Greetings,
>
> This is a friendly weekly reminder that this document awaits your
> attention.  Please review the document-specific questions and AUTH48
> announcement. Let us know if we can be of assistance as you begin the
> AUTH48 review process.
>
> The AUTH48 status page of this document is viewable at:
>   http://www.rfc-editor.org/auth48/rfc9514
>
> The AUTH48 FAQs are available at:
>   https://www.rfc-editor.org/faq/#auth48
>
> We look forward to hearing from you at your earliest convenience.
>
> Thank you,
> RFC Editor/mc
>
> > On Oct 30, 2023, at 7:08 PM, [e-mail] wrote:
> >
> > Authors and AD*,
> >
> > *AD, please see question #1 below.
> >
> > Authors, while reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> >
> >
> > 1) <!-- [rfced] *AD and authors, please let us know if the normative
> reference to
> > RFC 7752 should be updated to 7752bis (see
> > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/17/). Note
> > that 7752bis was previously approved and then put on hold by the AD, but
> > it is now back in EDIT state. If we update to reference 7752bis, both
> > this document and RFC-to-be 9513 will be published at the same time as
> > 7752bis.
>

KT> It is not necessary to update this reference. However, if RFC7752bis is
getting published "soon" then it does not harm to update.


> >
> > Note that this document makes allocations in the "BGP-LS NLRI Types" and
> > "BGP-LS NLRI and Attribute TLVs" registries.  The "BGP-LS NLRI and
> Attribute
> > TLVs" registry was called the "BGP-LS Node Descriptor, Link Descriptor,
> Prefix
> > Descriptor, and Attribute TLVs" registry in RFC 7752 and changed by
> > 7752bis. The name currently in the IANA registry is "BGP-LS NLRI and
> > Attribute TLVs". See
> >
> https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#node-descriptor-link-descriptor-prefix-descriptor-attribute-tlv
> .
> >
> > If you choose to retain the reference to RFC 7752, we will use the
> registry
> > name in that document ("BGP-LS Node Descriptor, Link Descriptor, Prefix
> > Descriptor, and Attribute TLVs"). If you choose to wait to publish at
> the same
> > time as 7752bis, we will use the updated name ("BGP-LS NLRI and Attribute
> > TLVs").
> > -->
>

KT> Please see my response to the previous comment.


> >
> >
> > 2) <!-- [rfced] Please note that the title of the document has been
> updated as
> > follows. Abbreviations have been expanded per Section 3.6 of RFC 7322
> > ("RFC Style Guide").
> >
> > Original:
> >  BGP Link State Extensions for SRv6
> >
> > Current:
> >  Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment
> Routing over IPv6 (SRv6)
> > -->
>

KT> Agree


> >
> >
> > 3) <!-- [rfced] Would it be helpful to clarity "a separate document"
> here? Is
> > this referring to a particular RFC?
> >
> > Original:
> >   The BGP-LS address-family solution for SRv6
> >   described in this document is similar to BGP-LS for SR for the MPLS
> >   data-plane defined in a separate document.
> > -->
>

KT> Yes, that separate document is RFC9085.


> >
> >
> > 4) <!-- [rfced] We see two instances each of the following phrases in
> this
> > document. May we update to one form for consistency?
> >
> > ...using Direct as the Protocol-ID
> > ...using Direct Protocol-ID
> > -->
>

KT> The first one seems better.


> >
> >
> > 5) <!-- [rfced] Should "and using" here be updated to either "using" or
> "and uses"?
> >
> > Original:
> >   The SRv6 information pertaining to a node is advertised via the BGP-
> >   LS Node NLRI and using the BGP-LS Attribute TLVs as follows:
> >   ...
> >   The SRv6 information pertaining to a link is advertised via the BGP-
> >   LS Link NLRI and using the BGP-LS Attribute TLVs as follows:
> >   ...
> >   The SRv6 information pertaining to a prefix is advertised via the
> >   BGP-LS Prefix NLRI and using the BGP-LS Attribute TLVs as follows:
> >
> > Perhaps ("using"):
> >   The SRv6 information pertaining to a node is advertised via the BGP-
> >   LS Node NLRI using the BGP-LS Attribute TLVs as follows:
> >   ...
> >   The SRv6 information pertaining to a link is advertised via the BGP-
> >   LS Link NLRI using the BGP-LS Attribute TLVs as follows:
> >   ...
> >   The SRv6 information pertaining to a prefix is advertised via the
> >   BGP-LS Prefix NLRI using the BGP-LS Attribute TLVs as follows:
> >
> > Or ("and uses"):
> >   The SRv6 information pertaining to a node is advertised via the BGP-
> >   LS Node NLRI and uses the BGP-LS Attribute TLVs as follows:
> >   ...
> >   The SRv6 information pertaining to a link is advertised via the BGP-
> >   LS Link NLRI and uses the BGP-LS Attribute TLVs as follows:
> >   ...
> >   The SRv6 information pertaining to a prefix is advertised via the
> >   BGP-LS Prefix NLRI and uses the BGP-LS Attribute TLVs as follows:
> > -->
>

KT> Your suggestion with "using" is more appropriate.


> >
> >
> > 6) <!-- [rfced] Please clarify "are identical as specified" here. Is the
> meaning
> > that the new MSD types in this document have the same description and
> > semantics as the MSD types defined in
> > [I-D.ietf-lsr-isis-srv6-extensions]? Note that this sentence appears
> > twice in the document.
> >
> > Original:
> >   The description and semantics of these new MSD-
> >   types for BGP-LS are identical as specified in
> >   [I-D.ietf-lsr-isis-srv6-extensions].
> >
> > Perhaps:
> >   The description and semantics of these new MSD-
> >   types for BGP-LS are identical to those specified in
> >   [RFC9352].
> > -->
>

KT> Agree with your proposal.


> >
> >
> > 7) <!-- [rfced] Please clarify "for IGPs, direct, and static
> configuration" here.
> >
> > Original:
> >   *  Local Node Descriptors TLV: set of Node Descriptor TLVs for the
> >      local node, as defined in [RFC7752] for IGPs, direct, and static
> >      configuration or as defined in [RFC9086] for BGP protocol.
> >
> > Perhaps:
> >   Local Node Descriptors TLV:  Set of Node Descriptor TLVs for the
> >      local node as defined in [RFC7752] for IGPs, the Direct Protocol-ID,
> >      and the Static configuration Protocol-ID or as defined in [RFC9086]
> for BGP.
> > -->
>

KT> Agree with your proposal.


> >
> >
> > 8) <!-- [rfced] How may we update this text for clarity?
> >
> > Original:
> >   For SRv6 SIDs corresponding to BGP EPE and when advertising SRv6 SID
> >   using Direct Protocol-ID, none are defined currently and they MUST
> >   be set to 0 when originated and ignored on receipt.
> >
> > Perhaps:
> >   No flags are currently defined for SRv6 SIDs corresponding to BGP EPE
> >   or for advertisement of a SRv6 SID using the Direct Protocol-ID. Flags
> MUST
> >   be set to 0 when originated and ignored on receipt.
> > -->
>

KT> Agree with your proposal.


> >
> >
> > 9) <!-- [rfced] We have updated "SET" to "set" at the end of this
> > sentence. Please let us know any objections.
> >
> > Original:
> >   For SRv6 BGP EPE Peer Set SID,
> >   multiple instances of this TLV (one for each peer in the "peer set")
> >   are associated with the SRv6 SID and the S-Flag is SET.
> > -->
>

KT> Agree.


> >
> >
> > 10) <!-- [rfced] Section 9.2: FYI - We have updated the name of the
> registry in
> > this section to "BGP-LS NLRI and Attribute TLVs" to match the title
> > currently in the IANA registry (renamed per
> > draft-ietf-idr-rfc7752bis). Depending on the response to our question #1,
> > we will either use the name of the registry per RFC 7752 ("BGP-LS Node
> > Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs") or
> > the name per draft-ietf-idr-rfc7752bis ("BGP-LS NLRI and Attribute
> TLVs").
> >
> > Link to registry:
> https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#node-descriptor-link-descriptor-prefix-descriptor-attribute-tlv
> > -->
>

KT> Please refer to my response to the first point.


> >
> >
> > 11) <!-- [rfced] Please confirm that "set up to routers" is correct. Or
> should
> > this be updated to "set up for routers" ("for" instead of "to")? Also, is
> > the capitaliation of "Link-State" correct?
> >
> > Original:
> >   BGP peering sessions for
> >   address-families other than Link-State may be set up to routers
> >   outside the SR domain.
> > -->
>

KT> "set up to" is correct and the capitalization is correct as well.


> >
> >
> > 12) <!-- [rfced] Terminology
> >
> > a) We note inconsistencies in the terms below throughout the text. Should
> > either the closed or open form be used consistently? Or should "PeerSet"
> and
> > "PeerNode" be used when followed by "SID", and then "Peer Set" and "Peer
> Node"
> > be used elsewhere? We see "PeerSet SID" in RFCs 8402 and 9086, and we see
> > "PeerNode SID" in RFC 9086.
> >
> > PeerSet vs. Peer Set
> >
> > PeerNode vs. Peer Node
>

KT> We should follow RFC8402 and RFC9086.


> >
> >
> > b) This relates to the question above. The name of the TLV defined in
> Section
> > 7.2 is "SRv6 BGP Peer Node SID TLV". Should this be updated to "SRv6 BGP
> > PeerNode SID TLV" (with "PeerNode" rather than "Peer Node")? If so, we
> will
> > ask IANA to update the registry accordingly prior to publication.
> >
> > Link to registry:
> https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#srv6-bgp-epe-sid
> >


KT> Agree. Let us update as per the terminology in RFC8402/9086.


>
> >
> > c) May we update the instance of "peer sessions" in this sentence to
> "peering
> > sessions" to match usage elsewhere in the document?
> >
> > Original:
> >   ...therefore MAY be assigned to one or more
> >   End.X SIDs associated with BGP peer sessions.
>

KT> "peering sessions" is more appropriate.


> >
> >
> > d) FYI, we updated "SRv6 BGP EPE Peer Node SID TLV" to "SRv6 BGP Peer
> Node SID TLV"
> > (no "EPE") for consistency with the name used elswhere in the document.
> >
> > Original:
> >   *  The BGP EPE Peer Node context for a PeerNode SID, and the Peer Set
> >      context for a PeerSet SID [RFC8402] are advertised via the SRv6
> >      BGP EPE Peer Node SID TLV (Section 7.2),
> >


KT> Agree.


>
> >
> > e) FYI, we updated "OSPFv3 SRv6 LAN End.X sub-TLV" here to "OSPFv3
> > SRv6 LAN End.X SID sub-TLV" (with "SID") to match usage in Section 9.2 of
> > RFC-to-be 9513.
> >
> > Original:
> >   The information advertised via this TLV is derived from the IS-IS SRv6
> >   LAN End.X SID sub-TLV (section 8.2 of
> >   [I-D.ietf-lsr-isis-srv6-extensions]) or the OSPFv3 SRv6 LAN End.X
> >   sub-TLV (section 9.2 of [I-D.ietf-lsr-ospfv3-srv6-extensions]) in the
> >   case of IS-IS or OSPFv3 respectively.
> > -->
>

KT> Agree. "SID" is required in the name.


> >
> >
> > 13) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online
> > Style Guide
> > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and
> let
> > us know if any changes are needed. Note that our script did not flag any
> > words in particular, but this should still be reviewed as a best
> > practice.
> > -->
>

KT> Ack


> >
> >
> > 14) <!-- [rfced] FYI - Expansions for abbreviations have been added upon
> first use
> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> > expansion in the document carefully to ensure correctness.
> > -->
>

KT> Ack.

Thanks,
Ketan


> >
> >
> > Thank you.
> >
> > RFC Editor/mc/rv
> >
> >
> >
> > On Oct 30, 2023, at 5:05 PM, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2023/10/30
> >
> > RFC Author(s):
> > --------------
> >
> > Instructions for Completing AUTH48
> >
> > Your document has now entered AUTH48.  Once it has been reviewed and
> > approved by you and all coauthors, it will be published as an RFC.
> > If an author is no longer available, there are several remedies
> > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >
> > You and you coauthors are responsible for engaging other parties
> > (e.g., Contributors or Working Group) as necessary before providing
> > your approval.
> >
> > Planning your review
> > ---------------------
> >
> > Please review the following aspects of your document:
> >
> > *  RFC Editor questions
> >
> >  Please review and resolve any questions raised by the RFC Editor
> >  that have been included in the XML file as comments marked as
> >  follows:
> >
> >  <!-- [rfced] ... -->
> >
> >  These questions will also be sent in a subsequent email.
> >
> > *  Changes submitted by coauthors
> >
> >  Please ensure that you review any changes submitted by your
> >  coauthors.  We assume that if you do not speak up that you
> >  agree to changes submitted by your coauthors.
> >
> > *  Content
> >
> >  Please review the full content of the document, as this cannot
> >  change once the RFC is published.  Please pay particular attention to:
> >  - IANA considerations updates (if applicable)
> >  - contact information
> >  - references
> >
> > *  Copyright notices and legends
> >
> >  Please review the copyright notice and legends as defined in
> >  RFC 5378 and the Trust Legal Provisions
> >  (TLP – https://trustee.ietf.org/license-info/).
> >
> > *  Semantic markup
> >
> >  Please review the markup in the XML file to ensure that elements of
> >  content are correctly tagged.  For example, ensure that <sourcecode>
> >  and <artwork> are set correctly.  See details at
> >  <https://authors.ietf.org/rfcxml-vocabulary>.
> >
> > *  Formatted output
> >
> >  Please review the PDF, HTML, and TXT files to ensure that the
> >  formatted output, as generated from the markup in the XML file, is
> >  reasonable.  Please note that the TXT will have formatting
> >  limitations compared to the PDF and HTML.
> >
> >
> > Submitting changes
> > ------------------
> >
> > To submit changes, please reply to this email using ‘REPLY ALL’ as all
> > the parties CCed on this message need to see your changes. The parties
> > include:
> >
> >  *  your coauthors
> >
> >  *  [e-mail] (the RPC team)
> >
> >  *  other document participants, depending on the stream (e.g.,
> >     IETF Stream participants are your working group chairs, the
> >     responsible ADs, and the document shepherd).
> >
> >  *  [e-mail], which is a new archival mailing list
> >     to preserve AUTH48 conversations; it is not an active discussion
> >     list:
> >
> >    *  More info:
> >
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >
> >    *  The archive itself:
> >       https://mailarchive.ietf.org/arch/browse/auth48archive/
> >
> >    *  Note: If only absolutely necessary, you may temporarily opt out
> >       of the archiving of messages (e.g., to discuss a sensitive matter).
> >       If needed, please add a note at the top of the message that you
> >       have dropped the address. When the discussion is concluded,
> >       [e-mail] will be re-added to the CC list and
> >       its addition will be noted at the top of the message.
> >
> > You may submit your changes in one of two ways:
> >
> > An update to the provided XML file
> > — OR —
> > An explicit list of changes in this format
> >
> > Section # (or indicate Global)
> >
> > OLD:
> > old text
> >
> > NEW:
> > new text
> >
> > You do not need to reply with both an updated XML file and an explicit
> > list of changes, as either form is sufficient.
> >
> > We will ask a stream manager to review and approve any changes that seem
> > beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> > and technical changes.  Information about stream managers can be found
> in
> > the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >
> >
> > Approving for publication
> > --------------------------
> >
> > To approve your RFC for publication, please reply to this email stating
> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > as all the parties CCed on this message need to see your approval.
> >
> >
> > Files
> > -----
> >
> > The files are available here:
> >  https://www.rfc-editor.org/authors/rfc9514.xml
> >  https://www.rfc-editor.org/authors/rfc9514.html
> >  https://www.rfc-editor.org/authors/rfc9514.pdf
> >  https://www.rfc-editor.org/authors/rfc9514.txt
> >
> > Diff file of the text:
> >  https://www.rfc-editor.org/authors/rfc9514-diff.html
> >  https://www.rfc-editor.org/authors/rfc9514-rfcdiff.html (side by side)
> >
> > Alt-diff of the text (allows you to more easily view changes
> > where text has been deleted or moved):
> >  https://www.rfc-editor.org/authors/rfc9514-alt-diff.html
> >
> > Diff of the XML:
> >  https://www.rfc-editor.org/authors/rfc9514-xmldiff1.html
> >
> > The following files are provided to facilitate creation of your own
> > diff files of the XML.
> >
> > Initial XMLv3 created using XMLv2 as input:
> >  https://www.rfc-editor.org/authors/rfc9514.original.v2v3.xml
> >
> > XMLv3 file that is a best effort to capture v3-related format updates
> > only:
> >  https://www.rfc-editor.org/authors/rfc9514.form.xml
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >  https://www.rfc-editor.org/auth48/rfc9514
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9514 (draft-ietf-idr-bgpls-srv6-ext-14)
> >
> > Title            : BGP Link State Extensions for SRv6
> > Author(s)        : G. Dawra, C. Filsfils, K. Talaulikar, M. Chen, D.
> Bernier, B. Decraene
> > WG Chair(s)      : Susan Hares, Keyur Patel, Jeffrey Haas
> >
> > Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> >
> >
> >
>
>