Re: [auth48] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review

[Alanna Paloma <[e-mail]>]

Hi Ketan and Robert,

We have updated our files accordingly.

We will await approval from Gaurav before asking IANA to update their registry accordingly. 
When the IANA update is complete, we will move forward with the publication process.

For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9252

The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9252.xml
https://www.rfc-editor.org/authors/rfc9252.txt
https://www.rfc-editor.org/authors/rfc9252.html
https://www.rfc-editor.org/authors/rfc9252.pdf

The relevant diff files have been posted here:
https://www.rfc-editor.org/authors/rfc9252-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9252-auth48diff.html (AUTH48 changes)
https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last version to this one)
https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html (last version to this one side by side)

Thank you,
RFC Editor/ap

> On Jun 24, 2022, at 12:35 PM, Robert Raszuk <[e-mail]> wrote:
> 
> Well since you opened that bxo Kentn, 
> 
> VRF does not stand as an abbreviation for "VPN Routing and Forwarding table - that is incorrect. 
> 
> VRF table == Virtual Routing and Forwarding table. 
> 
> With that the brackets are not needed and the entire description already deserves an errata :) 
> 
> Thx,
> R.
> 
> On Fri, Jun 24, 2022 at 6:30 PM Ketan Talaulikar <[e-mail]> wrote:
> Hi Alanna,
> 
> A Minor nit came to my attention in Sec 1
> OLD: End.DT (table look up in VPN Routing and Forwarding (VRF))
> NEW: End.DT (look up in VPN Routing and Forwarding (VRF) table)
> 
> Thanks,
> Ketan
> 
> 
> On Tue, Jun 21, 2022 at 11:58 PM Alanna Paloma <[e-mail]> wrote:
> Bruno, Jorge, Ketan, and Shunwan,
> 
> Thank you for your replies. Your approvals have been noted on the AUTH48 status page. 
> 
>  https://www.rfc-editor.org/auth48/rfc9252
> 
> Once we have received approvals from Gaurav and Robert, we will ask IANA to update
> their registry accordingly. After the IANA updates are complete, we will move forward
> with the publication process.
> 
> Thank you,
> RFC Editor/ap
> 
> > On Jun 21, 2022, at 5:10 AM, [e-mail] wrote:
> > 
> > Hi Alanna, RFC Editor,
> > 
> > I approve latest version.
> > 
> > Thank you
> > --Bruno
> > 
> > 
> > Orange Restricted
> > 
> > -----Original Message-----
> > From: Alanna Paloma <[e-mail]> 
> > Sent: Monday, June 20, 2022 11:41 PM
> > To: Andrew Alston - IETF <[e-mail]>
> > Cc: Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]>; Ketan Talaulikar <[e-mail]>; DECRAENE Bruno INNOV/NET <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Bocci, Matthew (Nokia - GB) <[e-mail]>; [e-mail]
> > Subject: Re: AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review
> > 
> > Hi Andrew,
> > 
> > Thank you for your reply. Your approval has been noted on the AUTH48 status page. 
> > 
> >  https://www.rfc-editor.org/auth48/rfc9252
> > 
> > We will await further word from the authors regarding updates and/or approvals 
> > prior to moving forward in the publication process. 
> > 
> > Thank you,
> > RFC Editor/ap
> > 
> >> On Jun 20, 2022, at 11:23 AM, Andrew Alston - IETF <[e-mail]> wrote:
> >> 
> >> I’m ok with the changes to 3.1 and and the addition in section 2.
> >> 
> >> Thanks
> >> 
> >> Andrew
> >> 
> >> 
> >> From: Alanna Paloma <[e-mail]> 
> >> Sent: Monday, June 20, 2022 8:22 PM
> >> To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]>; Ketan Talaulikar <[e-mail]>; Andrew Alston - IETF <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Bocci, Matthew (Nokia - GB) <[e-mail]>; [e-mail]
> >> Subject: Re: [AD] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review
> >> 
> >> Ketan, Jorge, and *Andrew (AD),
> >> 
> >> *Andrew (AD) - Please review and approve the change from “SHOULD” to “MUST” in 
> >> Section 3.1, as well as the addition of “Layer 2 services” in Section 2. 
> >> 
> >> https://www.rfc-editor.org/authors/rfc9252-ad-diff.html
> >> 
> >> Ketan and Jorge - Thank you for your replies. We have updated accordingly. 
> >> 
> >> FYI, we removed the following reference from the References section as its only
> >> occurrence was replaced with [RFC9012] in Section 1 per Ketan's request.
> >> 
> >> [BGP-SR-POLICY]
> >> Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
> >> P., Jain, D., and S. Lin, "Advertising Segment Routing
> >> Policies in BGP", Work in Progress, Internet-Draft, draft-
> >> ietf-idr-segment-routing-te-policy-17, 14 April 2022,
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
> >> segment-routing-te-policy-17>.
> >> 
> >> The files have been posted here (please refresh):
> >> https://www.rfc-editor.org/authors/rfc9252.xml
> >> https://www.rfc-editor.org/authors/rfc9252.txt
> >> https://www.rfc-editor.org/authors/rfc9252.html
> >> https://www.rfc-editor.org/authors/rfc9252.pdf
> >> 
> >> The relevant diff files have been posted here:
> >> https://www.rfc-editor.org/authors/rfc9252-diff.html (comprehensive diff)
> >> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html (AUTH48 changes)
> >> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last version to this one)
> >> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html (last version to this one side by side)
> >> 
> >> For the AUTH48 status of this document, please see:
> >> https://www.rfc-editor.org/auth48/rfc9252
> >> 
> >> Thank you,
> >> RFC Editor/ap
> >> 
> >>> On Jun 17, 2022, at 11:17 AM, Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]> wrote:
> >>> 
> >>> Hi Alanna,
> >>> 
> >>> I discussed offline with Ketan and we decided to modify a little bit (for clarity) the second change that he suggested in his last email:
> >>> 
> >>> 
> >>> For all occurrences in sections 6.1.1, 6.1.2, 6.2 (two occurrences), 6.2.1, 6.2.2 (two occurrences) and 6.5 
> >>> 
> >>> OLD: it is set to the Implicit NULL value. In either case, the value is set in the 24 bits (e.g., as 0x000030 in the case of Implicit NULL).
> >>> NEW: it is set to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is set in the 24 bits.
> >>> 
> >>> 
> >>> Please let us know if you have questions.
> >>> Thank you.
> >>> Jorge
> >>> 
> >>> 
> >>> From: Ketan Talaulikar <[e-mail]>
> >>> Date: Friday, June 17, 2022 at 1:32 PM
> >>> To: Alanna Paloma <[e-mail]>
> >>> Cc: [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, Rabadan, Jorge (Nokia - US/Sunnyvale) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>,[e-mail] <[e-mail]>
> >>> Subject: Re: [AD] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review
> >>> 
> >>> Hi Alanna,
> >>> 
> >>> There are 2 further changes based on the discussion below about the original "high order 20 bits" error.
> >>> 
> >>> https://mailarchive.ietf.org/arch/msg/bess/VN3_pFg5CbB337SQYFKDubR_EQM/
> >>> 
> >>> In sec 3.2.1
> >>> 
> >>> OLD: SRv6 SID value and put into high order bits of the MPLS Label field.
> >>> NEW: SRv6 SID value and encoded in the MPLS Label field.
> >>> 
> >>> For all occurrences in sections 6.1.1, 6.1.2, 6.2 (two occurrences), 6.2.1, 6.2.2 (two occurrences) and 6.5 
> >>> 
> >>> OLD: it is set to the Implicit NULL value. In either case, the value is set in the 24 bits (e.g., as 0x000030 in the case of Implicit NULL).
> >>> NEW: it is set to the Implicit NULL value (i.e., as 0x000030). In either case, the value is set in the 24 bits.
> >>> 
> >>> Thanks,
> >>> Ketan
> >>> 
> >>> 
> >>> On Fri, Jun 17, 2022 at 6:13 AM Alanna Paloma <[e-mail]> wrote:
> >>> Hi Ketan,
> >>> 
> >>> Thank you for your reply. We updated the files as requested and have
> >>> a couple of follow-up questions.
> >>> 
> >>> 1) This suggested text needs further updating as the either/or relationship 
> >>> is not parallel. Please review and let us know if option A or B reflects the
> >>> intended meaning. 
> >>> 
> >>> Suggested text:
> >>> To achieve efficient packing, this document allows 1) the encoding of
> >>> the SRv6 Service SID as a whole in either the SRv6 Services TLVs, or
> >>> 2) the encoding of only the common part of the SRv6 SID (e.g., Locator)
> >>> in the SRv6 Services TLVs and the encoding of the variable
> >>> (e.g., Function or Argument parts) in the existing label fields
> >>> specific to that service encoding.
> >>> 
> >>> Perhaps (Moved “either” after allows):
> >>> A) To achieve efficient packing, this document allows either 1) the encoding of
> >>> the SRv6 Service SID as a whole in the SRv6 Services TLVs or
> >>> 2) the encoding of only the common part of the SRv6 SID (e.g., Locator)
> >>> in the SRv6 Services TLVs and the encoding of the variable
> >>> (e.g., Function or Argument parts) in the existing label fields
> >>> specific to that service encoding.
> >>> 
> >>> Or (Removed “either”):
> >>> B) To achieve efficient packing, this document allows 1) the encoding of
> >>> the SRv6 Service SID as a whole in the SRv6 Services TLVs or
> >>> 2) the encoding of only the common part of the SRv6 SID (e.g., Locator)
> >>> in the SRv6 Services TLVs and the encoding of the variable
> >>> (e.g., Function or Argument parts) in the existing label fields
> >>> specific to that service encoding.
> >>> 
> >>> 2) Regarding the terminology, we have not made any changes to the terms 
> >>> where you replied “Depends on the usage”. If any further updates are required 
> >>> for these, please let us know.
> >>> 
> >>> The files have been posted here (please refresh):
> >>> https://www.rfc-editor.org/authors/rfc9252.xml
> >>> https://www.rfc-editor.org/authors/rfc9252.txt
> >>> https://www.rfc-editor.org/authors/rfc9252.html
> >>> https://www.rfc-editor.org/authors/rfc9252.pdf
> >>> 
> >>> The relevant diff files have been posted here:
> >>> https://www.rfc-editor.org/authors/rfc9252-diff.html (comprehensive diff)
> >>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html (AUTH48 changes)
> >>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last version to this one)
> >>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last version to this one side by side)
> >>> 
> >>> Please review the document carefully and contact us with any further
> >>> updates you may have. Note that we do not make changes once a
> >>> document is published as an RFC.
> >>> 
> >>> We will await approvals from each author and the AD prior to moving 
> >>> this document forward in the publication process.
> >>> 
> >>> For the AUTH48 status of this document, please see:
> >>> https://www.rfc-editor.org/auth48/rfc9252
> >>> 
> >>> Thank you,
> >>> RFC Editor/ap
> >>> 
> >>>> On Jun 16, 2022, at 7:55 AM, Ketan Talaulikar <[e-mail]> wrote:
> >>>> 
> >>>> Hi Alanna,
> >>>> 
> >>>> Thanks for resending and please check inline below for responses.
> >>>> 
> >>>> 
> >>>> On Thu, Jun 16, 2022 at 6:45 AM Alanna Paloma <[e-mail]> wrote:
> >>>> Hi Ketan,
> >>>> 
> >>>> The remaining unanswered queries are listed below.
> >>>> 
> >>>> Additionally, they can be seen in the XML file as comments marked as: <!-- [rfced] ... —>
> >>>> 
> >>>> https://www.rfc-editor.org/authors/rfc9252.xml
> >>>> 
> >>>> 
> >>>> 1) <!--[rfced] We notice that the Abstract and Introduction use
> >>>> "SRv6-based BGP services" but the title and short title across
> >>>> the header in the pdf use "SRv6 BGP-based Overlay
> >>>> Services". Should the titles be updated per Option A or B below, 
> >>>> or should the text in the Abstract and Introduction be updated 
> >>>> to reflect "SRv6 BGP-based Overlay Services" for consistency?
> >>>> 
> >>>> Also note that the abbreviations in the title have been expanded 
> >>>> per Section 3.6 of RFC 7332 ("RFC Style Guide"). Please review.
> >>>> 
> >>>> Original:
> >>>> SRv6 BGP based Overlay Services
> >>>> 
> >>>> Perhaps:
> >>>> A) 
> >>>> Title: BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
> >>>> Short title: SRv6-Based BGP Overlay Services
> >>>> 
> >>>> or 
> >>>> 
> >>>> B) 
> >>>> Title: Segment Routing over IPv6 (SRv6) Overlay Services Based on BGP
> >>>> Short Title: SRv6 BGP-Based Overlay Services
> >>>> -->
> >>>> 
> >>>> KT> (A) is more appropriate.
> >>>> 
> >>>> 
> >>>> 
> >>>> 2) <!--[rfced] In this sentence, does "them" refer to "mechanisms" or "a variable
> >>>> part"? Please review and let us know how to update.
> >>>> 
> >>>> Original:
> >>>> Section 4 describes mechanisms for signaling of the SRv6 Service SID
> >>>> by transposing a variable part of the SRv6 SID value and carrying
> >>>> them in existing MPLS label fields to achieve more efficient packing
> >>>> of those service prefix NLRIs in BGP update messages.
> >>>> 
> >>>> Perhaps:
> >>>> A) (if referring to "mechanisms"):
> >>>> Section 4 describes mechanisms for the signaling of the SRv6 Service
> >>>> SID by transposing a variable part of the SRv6 SID value and carrying
> >>>> the mechanism in existing MPLS label fields to achieve more efficient
> >>>> packing of those service prefix NLRIs in BGP update messages.
> >>>> Or
> >>>> 
> >>>> B) (if referring to "a variable part"): 
> >>>> Section 4 describes mechanisms for the signaling of the SRv6 Service
> >>>> SID by transposing a variable part of the SRv6 SID value and carrying
> >>>> the variable part in existing MPLS label fields to achieve more efficient
> >>>> packing of those service prefix NLRIs in BGP update messages.
> >>>> -->
> >>>> 
> >>>> KT> (B) is correct. Wouldn't "and carrying this variable part" be better?
> >>>> 
> >>>> 
> >>>> 
> >>>> 3) <!--[rfced] This sentence is a bit tough to read. Please review the
> >>>> suggested text and let us know if this is agreeable or if you
> >>>> prefer otherwise.
> >>>> 
> >>>> Original:
> >>>> To achieve efficient packing, this document allows the encoding of
> >>>> the SRv6 Service SID either as a whole in the SRv6 Services TLVs or
> >>>> the encoding of only the common part of the SRv6 SID (e.g., Locator)
> >>>> in the SRv6 Services TLVs and encoding the variable (e.g., Function
> >>>> or Argument parts) in the existing label fields specific to that
> >>>> service encoding.
> >>>> 
> >>>> Perhaps:
> >>>> To achieve efficient packing, this document allows 1) the encoding of
> >>>> the SRv6 Service SID as a whole in either the SRv6 Services TLVs or
> >>>> the encoding of only the common part of the SRv6 SID (e.g., Locator)
> >>>> in the SRv6 Services TLVs and 2) the encoding of the variable 
> >>>> (e.g., Function or Argument parts) in the existing label fields 
> >>>> specific to that service encoding.
> >>>> -->
> >>>> 
> >>>> 
> >>>> KT> I get your point. I think the following conveys the correct meaning:
> >>>> 
> >>>> To achieve efficient packing, this document allows 1) the encoding of
> >>>> the SRv6 Service SID as a whole in either the SRv6 Services TLVs, or
> >>>> 2) the encoding of only the common part of the SRv6 SID (e.g., Locator)
> >>>> in the SRv6 Services TLVs and the encoding of the variable
> >>>> (e.g., Function or Argument parts) in the existing label fields
> >>>> specific to that service encoding.
> >>>> 
> >>>> 
> >>>> 5) <!--[rfced] We note that RFC 8950 includes "IPv4 VPN Unicast over IPv6
> >>>> Core" and "IPv4 VPN Multicast over IPv6 Core". Is "IPv4 VPN over
> >>>> IPv6 Core" okay as is, or should it be updated to reflect either
> >>>> of these forms?
> >>>> 
> >>>> Original:
> >>>> The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
> >>>> Over IPv6 Core defined in [RFC8950].
> >>>> 
> >>>> Perhaps:
> >>>> A) The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
> >>>> unicast over IPv6 core defined in [RFC8950].
> >>>> 
> >>>> Or
> >>>> 
> >>>> B) The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
> >>>> multicast over IPv6 core defined in [RFC8950]. 
> >>>> -->
> >>>> 
> >>>> KT> (A) is correct.
> >>>> 
> >>>> 
> >>>> 
> >>>> 6) <!--[rfced] The following text mentions where Route Types 1,2,3,5,6,7,
> >>>> and 8 are defined, but it does not mention where Route Type 4 is
> >>>> defined. Is this intentional, or would you like to include a
> >>>> citation where Route Type 4 is defined? If so, please
> >>>> provide that reference.
> >>>> 
> >>>> Original:
> >>>> [RFC7432] defines Route
> >>>> Types 1, 2, and 3 which carry prefixes and MPLS Label fields; the
> >>>> Label fields have a specific use for MPLS encapsulation of EVPN
> >>>> traffic. Route Type 5 carrying MPLS label information (and thus
> >>>> encapsulation information) for EVPN is defined in [RFC9136]. Route
> >>>> Types 6, 7, and 8 are defined in [I-D.ietf-bess-evpn-igmp-mld-proxy].
> >>>> --> 
> >>>> 
> >>>> KT> The Route Type 4 is defined in RFC7432 (https://www.rfc-editor.org/rfc/rfc7432.html#section-7.4). We don't need to refer to it and hence citation is also not required. This is because that route type advertisement is unchanged from the base spec RFC7432. The original text is therefore intentional.
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> 7) <!--[rfced] May we update this sentence from "point-to-point
> >>>> services ID" to "point-to-point service IDs"?
> >>>> 
> >>>> Original:
> >>>> EVPN Route Type 1 is also used in EVPN-
> >>>> VPWS as well as in EVPN flexible cross-connect; mainly used to
> >>>> advertise point-to-point services ID.
> >>>> 
> >>>> Perhaps:
> >>>> EVPN Route Type 1 is also used in EVPN-
> >>>> VPWS as well as in EVPN-flexible cross-connect, mainly to
> >>>> advertise point-to-point service IDs.
> >>>> -->
> >>>> 
> >>>> KT> Ack. Your suggestion above is better than the original.
> >>>> 
> >>>> 
> >>>> 
> >>>> 8) <!--[rfced] We have included some specific information about the IANA
> >>>> text below (mainly FYIs). In addition to reviewing those changes, please
> >>>> review all of the IANA-related updates carefully and let us know
> >>>> if any further updates are needed.
> >>>> 
> >>>> A) FYI: For values 5 and 6, the Type names do not include "TLV" in the 
> >>>> "BGP Prefix-SID TLV Types" subregistry. We will ask IANA to add "TLV"
> >>>> to the subregistry accordingly.
> >>>> 
> >>>> Current (Table 1):
> >>>> | 5 | SRv6 L3 Service TLV | RFC 9252 |
> >>>> + - - - - - - - - - - - - - - - - - - - - +
> >>>> | 6 | SRv6 L2 Service TLV | RFC 9252 |
> >>>> 
> >>>> Current (IANA registry):
> >>>> | 5 | SRv6 L3 Service | RFC 9252 |
> >>>> + - - - - - - - - - - - - - - - - - - - - +
> >>>> | 6 | SRv6 L2 Service | RFC 9252 |
> >>>> 
> >>>> 
> >>>> KT> Ack
> >>>> 
> >>>> 
> >>>> B) FYI: The registration procedures in Tables 2 and 4 do not match IANA's
> >>>> registration procedures under the "SRv6 Service Sub-TLV Types" and
> >>>> "SRv6 Service Sub-Sub-TLV Types" subregistries. We updated these
> >>>> tables to match the registries by changing the "Value" and "Type"
> >>>> headings to "Range" and "Registration Procedures", respectively;
> >>>> moving the value "0" and its corresponding information to Tables 3
> >>>> and 5; and changing "Reserved" to "IETF Review" for value 255.
> >>>> 
> >>>> Original:
> >>>> Value Type
> >>>> - - - - - - - - - - - - - - - - - -
> >>>> 0 Reserved
> >>>> 0-127 IETF Review
> >>>> 128-254 First Come First Served
> >>>> 255 Reserved
> >>>> 
> >>>> Current (for Tables 2 and 4):
> >>>> Range Registration Procedures
> >>>> - - - - - - - - - - - - - - - - - -
> >>>> 0-127 IETF Review
> >>>> 128-254 First Come First Served
> >>>> 255 IETF Review
> >>>> 
> >>>> 
> >>>> KT> Ack
> >>>> 
> >>>> 
> >>>> C) FYI: Tables 3 and 5 have been updated to match the
> >>>> relevant IANA registries. Please review.
> >>>> -->
> >>>> 
> >>>> KT> Ack
> >>>> 
> >>>> 
> >>>> 
> >>>> 9) <!--[rfced] May we update "SRv6 SID Endpoint" to be "SRv6 Endpoint" to
> >>>> reflect usage throughout the document? 
> >>>> 
> >>>> Original:
> >>>> The SRv6 SID Endpoint behaviors implementing the services signalled
> >>>> in this document are defined in [RFC8986] and hence the security
> >>>> considerations of that document apply.
> >>>> 
> >>>> Perhaps:
> >>>> The SRv6 Endpoint behaviors implementing the services signaled
> >>>> in this document are defined in [RFC8986]; hence, the security
> >>>> considerations of that document apply.
> >>>> --> 
> >>>> 
> >>>> KT> Ack. Your suggested change is better than the original.
> >>>> 
> >>>> 
> >>>> 
> >>>> 10) <!-- [rfced] FYI: The following reference has been deleted from the
> >>>> References section as it was only mentioned within the
> >>>> Implementation Status section, which has been deleted per your
> >>>> request.
> >>>> 
> >>>> Removed:
> >>>> [I-D.matsushima-spring-srv6-deployment-status]
> >>>> Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman,
> >>>> K., and A. Dhamija, "SRv6 Implementation and Deployment
> >>>> Status", draft-matsushima-spring-srv6-deployment-status-13
> >>>> (work in progress), March 2022.
> >>>> -->
> >>>> 
> >>>> KT> Ack
> >>>> 
> >>>> 
> >>>> 
> >>>> 11) <!--[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> Looks good to me.
> >>>> 
> >>>> 
> >>>> 
> >>>> 12) <!--[rfced] Throughout the text, the following terminology appears to be used
> >>>> inconsistently. Please review these occurrences and let us know if/how they
> >>>> may be made consistent.
> >>>> 
> >>>> KT> In general, when referring to the name of a field, TLV/sub-TLV, SID, etc. we have used the capitalized versions. In other places, as "normal text", there should not be capitalization.
> >>>> 
> >>>> 
> >>>> - SRv6 Service vs. SRv6 service
> >>>> 
> >>>> KT> Depends on the usage
> >>>> 
> >>>> 
> >>>> - MPLS Label field vs. MPLS label field
> >>>> 
> >>>> KT> "MPLS Label field" since we are referring to the name of a field.
> >>>> 
> >>>> - Endpoint Behavior vs. Endpoint behavior vs. endpoint behavior
> >>>> 
> >>>> KT> I would think in almost all cases, "Endpoint Behavior" would be more appropriate - but please correct me.
> >>>> 
> >>>> - BGP Service vs. BGP service
> >>>> 
> >>>> KT> Depends on the usage
> >>>> 
> >>>> - Transposition Offset vs. transposition offset
> >>>> - Transposition Length vs. transposition length
> >>>> 
> >>>> KT> Depends on the usage.
> >>>> 
> >>>> - Transposition Scheme vs. transposition scheme
> >>>> 
> >>>> KT> The capitalized version was used because we are referring to the name of the scheme.
> >>>> 
> >>>> KT> There is an error in the draft that has been thankfully caught by a WG participant that we would like to fix. Please see the thread here:https://mailarchive.ietf.org/arch/msg/bess/puPdmGwKmmGMJaA_eW_vOM6Bk-k/ 
> >>>> 
> >>>> The following change is required in the following places:
> >>>> - 6.1.1 para 2
> >>>> - 6.1.2 para 2
> >>>> - 6.2 para 4 and 5
> >>>> - 6.2.1 para 1
> >>>> - 6.2.2 para 1 and 2
> >>>> - 6.5 para 4
> >>>> 
> >>>> OLD: the value is set in the high order 20 bits
> >>>> NEW: the value is set in the 24 bits
> >>>> 
> >>>> KT> Additionally, I would like to suggest the following editorial changes:
> >>>> 
> >>>> OLD: [SEGMENT-ROUTING-TE-POLICY]
> >>>> NEW: If this is going to be replaced by RFC number since it is also in the RFCed Q, then that is ok. If not, I would suggest [SEGMENT-ROUTING-POLICY].
> >>>> 
> >>>> OLD: [IDR-SEGMENT-ROUTING-TE-POLICY]
> >>>> NEW: [BGP-SR-POLICY]
> >>>> 
> >>>> OLD: [LSR-FLEX-ALGO]
> >>>> NEW: [IGP-FLEX-ALGO]
> >>>> 
> >>>> I am yet to do a full review pass and will do so once these updates have been incorporated on the full diff against the original text.
> >>>> 
> >>>> Thanks,
> >>>> Ketan
> >>>> 
> >>>> —>
> >>>> 
> >>>> Best regards,
> >>>> RFC Editor/ap
> >>>> 
> >>>>> On Jun 15, 2022, at 11:28 AM, Ketan Talaulikar <[e-mail]> wrote:
> >>>>> 
> >>>>> Hi Alanna,
> >>>>> 
> >>>>> For some reason, I am unable to locate your first email (the one with the questions?) in my mailbox. Could you please resend it?
> >>>>> 
> >>>>> Thanks,
> >>>>> Ketan
> >>>>> 
> >>>>> 
> >>>>> On Wed, Jun 15, 2022 at 5:28 AM Alanna Paloma <[e-mail]> wrote:
> >>>>> Authors and *Andrew (AD), 
> >>>>> 
> >>>>> *Andrew (AD) - Please review and approve the change from “SHOULD” to “MUST” in 
> >>>>> Section 3.1 in the diff file below. 
> >>>>> 
> >>>>> https://www.rfc-editor.org/authors/rfc9252-ad-diff.html
> >>>>> 
> >>>>> Authors - Thank you for your reply. We have updated as requested.
> >>>>> 
> >>>>> Note that Bruno’s response only answered query 4). Please review our previous mail 
> >>>>> (sent on June 10, 2022) to review and respond the the remaining queries.
> >>>>> 
> >>>>> The files have been posted here (please refresh):
> >>>>> https://www.rfc-editor.org/authors/rfc9252.txt
> >>>>> https://www.rfc-editor.org/authors/rfc9252.pdf
> >>>>> https://www.rfc-editor.org/authors/rfc9252.html
> >>>>> https://www.rfc-editor.org/authors/rfc9252.xml
> >>>>> 
> >>>>> The relevant diff files are posted here:
> >>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html (comprehensive diff)
> >>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html (all AUTH48 changes)
> >>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (htmlwdiff diff between last version and this)
> >>>>> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html (rfcdiff between last version and this)
> >>>>> 
> >>>>> Please review the document carefully as documents do not change once
> >>>>> published as RFCs.
> >>>>> 
> >>>>> We will await responses to our queries and any further changes you may have, as well as 
> >>>>> approvals from each author and the *AD prior to moving forward in the publication process.
> >>>>> 
> >>>>> Please see the AUTH48 status page for this document here:
> >>>>> https://www.rfc-editor.org/auth48/rfc9252
> >>>>> 
> >>>>> Thank you,
> >>>>> RFC Editor/ap
> >>>>> 
> >>>>>> On Jun 13, 2022, at 8:16 AM, [e-mail] wrote:
> >>>>>> 
> >>>>>> *Andrew, ADs, Ketan 1rst & 2nd questions are for you. And checking the 3rd would be safer. Thanks.
> >>>>>> 
> >>>>>> Hi RFC Editor, all,
> >>>>>> 
> >>>>>> Thanks for the work.
> >>>>>> I've reviewed the diff and the full text.
> >>>>>> Please find below some proposed changes.
> >>>>>> 
> >>>>>> ----
> >>>>>> §3.1
> >>>>>> In this doc, the semantic of all reserved fields are specified as MUST on the sender side, and MUST on the receiver side. (which is my personal preference, but I ignore if there is an IETF guideline on this) e.g. 
> >>>>>> " RESERVED1 (1 octet):
> >>>>>> This field MUST be set to 0 by the sender and ignored by the
> >>>>>> receiver."
> >>>>>> 
> >>>>>> 
> >>>>>> except the following text which is specified as SHOULD, MUST:
> >>>>>> 
> >>>>>> " SRv6 Service SID Flags (1 octet):
> >>>>>> This field encodes SRv6 Service SID Flags -- none are currently
> >>>>>> defined. It SHOULD be set to 0 by the sender and any unknown
> >>>>>> flags MUST be ignored by the receiver."
> >>>>>> 
> >>>>>> For consistency in this doc, I would propose
> >>>>>> OLD: SHOULD
> >>>>>> NEW: MUST
> >>>>>> 
> >>>>>> ----
> >>>>>> §5
> >>>>>> " For service over SRv6 core, the egress PE sets the next hop to one of its IPv6 addresses."
> >>>>>> 
> >>>>>> May be a personal preference, but I would prefer to make it explicit that "next hop" refers to the BGP Next Hop, as otherwise it would potentially be understood as the forwarding next hop of the egress PE (toward its CE), especially since the long previous paragraph refers to routing tables rather than BGP messages.
> >>>>>> 
> >>>>>> OLD: the egress PE sets the next hop
> >>>>>> NEW: the egress PE sets the BGP Next Hop
> >>>>>> 
> >>>>>> (next hop, next-hop, Next-Hop or whatever is usually used equally works for me)
> >>>>>> 
> >>>>>> 
> >>>>>> -------
> >>>>>> 
> >>>>>> §10.2
> >>>>>> " [IGMP-MLD-EVPN]
> >>>>>> Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
> >>>>>> A., and P. Mattes, "Segment Routing Policy Architecture",
> >>>>>> Work in Progress, Internet-Draft, draft-ietf-spring-
> >>>>>> segment-routing-policy-22, 22 March 2022,
> >>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
> >>>>>> segment-routing-policy-22>.
> >>>>>> "
> >>>>>> 
> >>>>>> The name of the reference seems (extremely) misleading to me. I would assume a typo
> >>>>>> OLD: [IGMP-MLD-EVPN]
> >>>>>> NEW: [SEGMENT-ROUTING-TE-POLICY]
> >>>>>> 
> >>>>>> -------
> >>>>>> 
> >>>>>> §2
> >>>>>> " TLV Type (1 octet):
> >>>>>> This field is assigned values from IANA's "BGP Prefix-SID TLV
> >>>>>> Types" subregistry."
> >>>>>> 
> >>>>>> The field can only contain a single value. So I'd propose
> >>>>>> 
> >>>>>> OLD: values
> >>>>>> NEW: a value
> >>>>>> 
> >>>>>> ----
> >>>>>> "Any unrecognized, received Sub-TLVs and Sub-Sub-TLVs MUST be removed."
> >>>>>> 
> >>>>>> Personally I would not put a comma. But English typo is definitely not my expertise. So totally up to you.
> >>>>>> 
> >>>>>> ----
> >>>>>> §3 
> >>>>>> "SRv6 Service Sub-TLV Type (1 octet):
> >>>>>> This field identifies the type of SRv6 service information. It is
> >>>>>> assigned values from IANA's "SRv6 Service Sub-TLV Types"
> >>>>>> subregistry."
> >>>>>> 
> >>>>>> The field can only contain a single value. So I'd propose
> >>>>>> 
> >>>>>> OLD: values
> >>>>>> NEW: a value
> >>>>>> -----
> >>>>>> 
> >>>>>> §3.2
> >>>>>> 
> >>>>>> SRv6 Service Data Sub-Sub-TLV Type (1 octet):
> >>>>>> This field identifies the type of Sub-Sub-TLV. It is assigned
> >>>>>> values from IANA's "SRv6 Service Data Sub-Sub-TLV Types"
> >>>>>> subregistry.
> >>>>>> 
> >>>>>> The field can only contain a single value. So I'd propose
> >>>>>> 
> >>>>>> OLD: values
> >>>>>> NEW: a value
> >>>>>> 
> >>>>>> ----
> >>>>>> §3.2.1
> >>>>>> 
> >>>>>> " While for an SRv6
> >>>>>> SID, where the FL is 24 bits and only the lower order 20 bits are
> >>>>>> transposed (e.g., due to the limit of the MPLS label field size), the
> >>>>>> transposition offset is set to 68 and the transposition length is set
> >>>>>> to 20."
> >>>>>> 
> >>>>>> I would not put the first comma. And I could rather use "for which" rather than "where"
> >>>>>> OLD: While for an SRv6 SID, where the FL is 24 bits
> >>>>>> NEW: While for an SRv6SID for which the FL is 24 bits
> >>>>>> 
> >>>>>> However English is not my first language, so totally up to you.
> >>>>>> 
> >>>>>> -----
> >>>>>> §5 
> >>>>>> 
> >>>>>> OLD: When the BGP route is received at an ingress PE is colored with a
> >>>>>> Color Extended Community and a valid SRv6 Policy is available, the
> >>>>>> steering for service flows is performed, as described in Section 8
> >>>>>> 
> >>>>>> 
> >>>>>> NEW: When the BGP route received at an ingress PE is colored with a
> >>>>>> Color Extended Community and a valid SRv6 Policy is available, the
> >>>>>> steering for service flows is performed as described in Section 8
> >>>>>> 
> >>>>>> i.e.
> >>>>>> :s/is received/received
> >>>>>> :s/is performed, as described/ is performed as described
> >>>>>> 
> >>>>>> --
> >>>>>> §6
> >>>>>> 
> >>>>>> Idem above. (except that the 2nd correction is already in place)
> >>>>>> 
> >>>>>> 
> >>>>>> Thank you,
> >>>>>> Regards,
> >>>>>> --Bruno
> >>>>>> 
> >>>>>> 
> >>>>>> Orange Restricted
> >>>>>> 
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail] <[e-mail]> 
> >>>>>> Sent: Friday, June 10, 2022 10:56 PM
> >>>>>> To: [e-mail]; [e-mail]; [e-mail]; DECRAENE Bruno INNOV/NET <[e-mail]>; [e-mail];[e-mail]
> >>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> >>>>>> Subject: AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review
> >>>>>> 
> >>>>>> *****IMPORTANT*****
> >>>>>> 
> >>>>>> Updated 2022/06/10
> >>>>>> 
> >>>>>> 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://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
> >>>>>> 
> >>>>>> * 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 CC’ed on this message need to see your approval.
> >>>>>> 
> >>>>>> 
> >>>>>> Files 
> >>>>>> -----
> >>>>>> 
> >>>>>> The files are available here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9252.xml
> >>>>>> https://www.rfc-editor.org/authors/rfc9252.html
> >>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf
> >>>>>> https://www.rfc-editor.org/authors/rfc9252.txt
> >>>>>> 
> >>>>>> Diff file of the text:
> >>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html
> >>>>>> https://www.rfc-editor.org/authors/rfc9252-rfcdiff.html (side by side)
> >>>>>> 
> >>>>>> Diff of the XML: 
> >>>>>> https://www.rfc-editor.org/authors/rfc9252-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/rfc9252.original.v2v3.xml 
> >>>>>> 
> >>>>>> XMLv3 file that is a best effort to capture v3-related format updates 
> >>>>>> only: 
> >>>>>> https://www.rfc-editor.org/authors/rfc9252.form.xml
> >>>>>> 
> >>>>>> 
> >>>>>> Tracking progress
> >>>>>> -----------------
> >>>>>> 
> >>>>>> The details of the AUTH48 status of your document are here:
> >>>>>> https://www.rfc-editor.org/auth48/rfc9252
> >>>>>> 
> >>>>>> Please let us know if you have any questions. 
> >>>>>> 
> >>>>>> Thank you for your cooperation,
> >>>>>> 
> >>>>>> RFC Editor
> >>>>>> 
> >>>>>> --------------------------------------
> >>>>>> RFC9252 (draft-ietf-bess-srv6-services-15)
> >>>>>> 
> >>>>>> Title : SRv6 BGP based Overlay Services
> >>>>>> Author(s) : G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. Decraene, S. Zhuang, J. Rabadan
> >>>>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski
> >>>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> >>>>>> 
> >>>>>> 
> >>>>>> _________________________________________________________________________________________________________________________
> >>>>>> 
> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >>>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>>>> 
> >>>>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
> >>>>>> they should not be distributed, used or copied without authorisation.
> >>>>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
> >>>>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> >>>>>> Thank you.
> >>>>>> 
> >>>>> 
> >>> 
> >> 
> > 
> > 
> > _________________________________________________________________________________________________________________________
> > 
> > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> > 
> > This message and its attachments may contain confidential or privileged information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> > Thank you.
> > 
> 
>