Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)
draft-ietf-idr-bgpls-srv6-ext-14

[Ballot comment]
I apologize for my tardiness in clearing my DISCUSS. Thanks for your reply and update, this looks good. I have a couple of minor comments below, which don't require a document update unless you choose (the first is optional, the second is something I'm sure the RFCEd will catch).

## COMMENT

### Global

In many cases, you changed "derived" to "copied", in some others you left it "derived". I'm just observing this, I don't think it's a must-change, the definition you supplied in Section 2 and the change of "and" to "or" already makes the document clear enough. But it seemed worth pointing out.

### Section 4.2

"For a LAN interface, an IGP node announces ordinarily only its"

should be

"For a LAN interface, an IGP node ordinarily announces only its"

(reverse word order)

[Ballot comment]
Firstly, thanks for the document.

I support John's discuss with a suggestion/minor variation.

In the flags field - if running both ISIS and OSPFv3 - I would assume that there are two entries in LS for these protocols - if this is NOT the case - let me know
If this IS the case - then the wording should probably be changed to somethinglike:
  *  Flags: 2 octet field.  The flags are derived from the SRv6
      Capabilities sub-TLV/TLV of IS-IS (section 2 of
      [I-D.ietf-lsr-isis-srv6-extensions]) or OSPFv3 (section 2 of
      [I-D.ietf-lsr-ospfv3-srv6-extensions]), whichever is relevant.

This would apply anywhere in the document where the AND is used in similar context.

From reading John's discuss I believe this should address many of his concerns - but he can comment further.

[Ballot comment]
# GEN AD review of draft-ietf-idr-bgpls-srv6-ext-12

CC @larseggert

## Comments

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-lsr-isis-srv6-extensions-18`, but `-19` is the
latest available revision.

### Grammar/style

#### Section 5.1, paragraph 4
```
ibutes for the given SRv6 Locator. Currently none are defined. 6. SRv6 SID NL
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### Section 7.2, paragraph 14
```
egistry group as described in the sub-sections below. 9.1. BGP-LS NLRI-Types
                                  ^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 10, paragraph 3
```
sions is limited to consumers in a secure manner within this trusted SR domai
                              ^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

#### Section 10, paragraph 3
```
nts. The authors would also like to thanks Susan Hares for her shepherd revi
                                ^^^^^^^^^
```
Did you mean "to thank"?

#### Section 14.1, paragraph 3
```
interface even when the peering is setup using the interface IP addresses.
                                    ^^^^^
```
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-idr-bgpls-srv6-ext-12
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Susan Hares for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Timothy Winters, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-12-intdir-telechat-winters-2022-12-07/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 3.1

I second John's point on the lack of specification for the Flag field. This document does not specify how to interpret the values. It happens that the IS-IS and OSPFv3 specify a 16-bit value with currently the same semantic associated to the 16-bit but I fear that this is quite dangerous to have the *same* field specified in several documents. Strongly suggest creating a IANA registry for this 16-bit field shared by (at least) 3 IETF drafts.

The same comment applies to many other values in the document.

### Section 4.2

Suggest to replace the very specific "LAN" to the broader "broadcast link" ?

### Section 5.1

```
  As specified in [RFC8986], an SRv6 SID comprises Locator, Function
  and Argument parts.
```
Does the above text assume that *all* SIDs are network programming SIDs ? Suggest to qualify as in "a network programming SRv6 DIS"

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# Internet AD comments for draft-ietf-idr-bgpls-srv6-ext-12
CC @ekline

## Comments

### S7.1

* "Endpoint Behavior: 2 octet field.  The Endpoint Behavior code
  point for this SRv6 SID as defined in section 10.2 of [RFC8986]."

  Would it be more correct to say/add that support values are those from
  the "SRv6 Endpoint Behaviors" IANA registry (as established via section
  10.2 of RFC8986)?

[Ballot comment]
The shepherd writeup says:

--
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure. Yes
--

...but the ones it lists are drafts aimed at the Standards Track.  Why are they "downward"?

I concur with Zahed's question about the number of authors.

Nice job on Section 9, which is typically one of my favorite places to complain lately.

[Ballot comment]
Thanks for working on this specification. I haven't noticed TSV related issue in my reviews.

I have two minor comments/observations -

*  First the number of authors, I understand editor has been updating the document communicating with other authors listed. I was wondering if we have that active editor then why can't we more the other authors to contributor section. Has this been discussed in the WG as a potential option?

* Section 4.2 : The length of this TLV is variable, I think it would be more clear if there is a description of why this length is variable, even if there are obvious reasons.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-idr-bgpls-srv6-ext-12
CC @jgscudder

### Global, field definitions are unclear throughout

I have a problem with how several different fields are defined. For example, in Section 3.1, the description of the flags field says,

```
  *  Flags: 2 octet field.  The flags are derived from the SRv6
      Capabilities sub-TLV/TLV of IS-IS (section 2 of
      [I-D.ietf-lsr-isis-srv6-extensions]) and OSPFv3 (section 2 of
      [I-D.ietf-lsr-ospfv3-srv6-extensions]).
```
There are two problems here: "derived", and "and". On consideration, I think "and" is the more serious, although it wasn't what initially caught my attention.

Regarding "derived": Normally when I think of something being "derived from" something else, I think of some derivation function, e.g. pressure can be derived from the volume of a confined gas according to Boyle's Law. Of course, the function can technically be the identity function, which appears to be what you mean here. There's a suggestion related to that in my second discuss point, below.

Regarding "and": As written (here and elsewhere), you're saying that the field comes from both places at once. That doesn't make sense on the face of it, and it led me down a rabbit hole I'll spare you the description of.

In the end, I guess how you arrived at your current text is probably by trying to capture that BGP-LS is a vessel to convey fields that originate in one of the IGPs, hence the fields aren't defined here and you don't want to write rules or semantics for them here. I think there are two basic changes you can make to your pattern that would address my concern.

First and less importantly, choose some verb other than "derive". "Copied" seems like the most precise, but something else could be proposed. (But again, see my second discuss point.)

Second, use "or", not "and", or a similar approach that accomplishes the same end.

Rewriting the example text according to this suggestion, we'd have something like,

```
  *  Flags: 2 octet field.  The flags are copied from the SRv6
      Capabilities sub-TLV/TLV of either IS-IS (section 2 of
      [I-D.ietf-lsr-isis-srv6-extensions]) or OSPFv3 (section 2 of
      [I-D.ietf-lsr-ospfv3-srv6-extensions]), depending on the
      source protocol.
```
I don't insist that you use this exact pattern, it's just an example of a minimal patch that addresses the issue, I don't claim it's the best fix. And TBH, if you made the other changes but left "copied" as "derived" I think it would have been clear enough in context. Indeed, I think just changing "and" to "or" could pass the smell test, especially if there's an introductory paragraph somewhere, setting up the pattern. (Again, see my second point.)

For some examples of how we've solved this for past BGP-LS specs, we can consider RFCs 8814 and 9085. In Section 2 of RFC 8814, it says, "When a BGP-LS speaker is originating the topology learnt via link-state routing protocols such as OSPF or IS-IS, the MSD information for the nodes and their links is sourced from the underlying extensions as defined in [RFC8476] and [RFC8491], respectively." Or, if we look at RFC 9085, you use "derived" but mostly in ways I find clear enough, for example, §2.3.5:

```
                                                          The
  information advertised in the Range TLV is derived from the SID/Label
  Binding TLV in the case of IS-IS and the OSPFv2/OSPFv3 Extended
  Prefix Range TLV in the case of OSPFv2/OSPFv3.
```
The use of "in the case of" makes it clear that there's only a single source for the field in any given instance. Or §2.1.1:

```
  The SID/Label TLV is used as a sub-TLV by the SR Capabilities
  (Section 2.1.2) and Segment Routing Local Block (SRLB)
  (Section 2.1.4) TLVs.  This information is derived from the protocol-
  specific advertisements.

  *  IS-IS, as defined by the SID/Label Sub-TLV in Section 2.3 of
      [RFC8667].

  *  OSPFv2/OSPFv3, as defined by the SID/Label Sub-TLV in Section 2.1
      of [RFC8665] and Section 3.1 of [RFC8666].
```
The use of "from the protocol-specific advertisements" makes it clear in context.

I'm not going to flag each instance of this pattern in my review, but ask that you do a global search for "derived". I've noted some other issues that won't be revealed by a search for "derived" in my COMMENT section.

(I notice that in Section 7.1 you have "The flags map to the IS-IS or OSPFv3..." -- which works just fine as far as I'm concerned.)

### Section 2

In the same vein, it also seems worth tightening up this paragraph from Section 2:

```
  When a BGP-LS router advertises topology information that it sources
  from the underlying link-state routing protocol (as described in
  [RFC7752]), then it maps the corresponding SRv6 information from the
  SRv6 extensions for IS-IS [I-D.ietf-lsr-isis-srv6-extensions] and
  OSPFv3 [I-D.ietf-lsr-ospfv3-srv6-extensions] protocols to their BGP-
  LS TLVs/sub-TLVs for all SRv6 capable nodes in that routing protocol
  domain.  When a BGP-LS router advertises topology information from
  the BGP routing protocol (e.g., for EPE), then it advertises the SRv6
  information from the local node alone.
```
Perhaps this could be made more specific, for example:

```
  In most cases, a BGP-LS router will advertise topology information it has
  sourced from an underlying link-state routing protocol, as described in
  [RFC7752]. In such cases, it will derive the corresponding SRv6 information
  from the SRv6 extensions for IS-IS [I-D.ietf-lsr-isis-srv6-extensions] or
  OSPFv3 [I-D.ietf-lsr-ospfv3-srv6-extensions], as applicable. In practice,
  this derivation comprises a simple copy of the relevant field into a field
  of the corresponding BGP-LS TLV/sub-TLV. This document defines an
  exception case where a BGP-LS router can originate topology information
  itself, for EPE. Such information is advertised only on behalf of the
  local router, in contrast to the usual [RFC7752] behavior of advertising
  information for an entire underlying IGP domain.
```
This rolls together a few of the windmills I've been tilting at, including supplying a small definition of "derives" to perhaps minimize rewriting in the rest of the document. (See also my second COMMENT.)

[Ballot comment]
## COMMENT

### Global, is RFC 7752 the right reference?

Since we have rfc7752bis in the final stages of preparation (thanks for your work on it!), is RFC 7752 the best reference for this document to cite?

### Section 1 isn't EPE the only case?

Related to my DISCUSS,

```
  This document describes extensions to BGP-LS to advertise the SRv6
  SIDs and other SRv6 information from all the SRv6 capable nodes in
  the IGP domain when sourced from link-state routing protocols and
  directly from individual SRv6 capable nodes (e.g. when sourced from
  BGP for EPE).
```
Are there any other concrete cases other than EPE, that the document defines, where the router sources data directly into BGP-LS? If not, consider rewriting to make the text exhaustive instead of exemplary, by removing the "e.g." or turning it into an "i.e.".

### Section 4.1 IS-IS and OSPFv3

Related to my DISCUSS point, here we have

```
  The SRv6 End.X SID TLV is used to advertise the SRv6 SIDs associated
  with an IGP Adjacency SID behavior that correspond to a point-to-
  point or point-to-multipoint link or adjacency of the node running
  the IS-IS and OSPFv3 protocols.
```
That should be "the IS-IS or OSPFv3 protocol", I think, since generally, a node won't be running both at the same time. (Noted here since searching for "derived" won't find it.)

### Section 4.2

Again related to DISCUSS point,

```
  *  Neighbor ID : 6 octets of Neighbor System-ID in IS-IS SRv6 LAN
      End.X SID TLV and 4 octets of Neighbor Router-id in the OSPFv3
      SRv6 LAN End.X SID TLV.
```
Should be "... or 4 octets," I think. Figure 3 gets this right, so regardless of the bigger picture it's worth changing just for consistency with the figure.

### Section 4.3

Again related.

```
  Each MSD-type is encoded in the BGP-LS Link MSD TLV as a one-octet
  type followed by a one-octet value as derived from the IS-IS and
  OSPFv3 Link MSD advertisements as specified in [RFC8814].
```
Debatable since you refer back to a single underlying spec, but I think "IS-IS or OSPFv3".

### Section 6.1

This looks like "the exception that proves the rule":

```
  When advertising the SRv6 SIDs from the IGPs, the SID information is
  derived from the SRv6 End SID sub-TLV of IS-IS (section 7.2 of
  [I-D.ietf-lsr-isis-srv6-extensions]) and OSPFv3 (section 8 of
  [I-D.ietf-lsr-ospfv3-srv6-extensions]).
```
That is to say, the "when advertising" part implies you might advertise information from other sources too, I guess the Protocol-ID field has the same implication since that also can take values OSPFv2, Direct, and Static. So then, if the source is NOT IS-IS or OSPFv3, where is the SID information derived from?

## NITS

### Section 4.2

```
  For a LAN interface, an IGP node announces normally only its
  adjacency to the IS-IS pseudo-node (or the equivalent OSPF DR).
```
I think that should be "normally announces". As written it expresses the implication that it announces other adjacencies abnormally. Maybe "ordinarily" would be better than "normally" since it doesn't carry the same risk of ambiguity.

```
                                                          Without this
  TLV, multiple BGP-LS Link NLRIs would need to be originated for each
  additional adjacency to advertise the SRv6 End.X SID TLVs for these
  neighbor adjacencies.
```
Do you mean "... would need to be originated, one for each additional adjacency, to advertise..."?

### Section 5.1

```
  on that node.  These Locators are advertised as BGP-LS Prefix NLRI
  objects along with the SRv6 Locator TLV in its BGP-LS Attribute.
```
"Each Locator is advertised as a BGP-LS Prefix NLRI object along with the SRv6 Locator TLV in its BGP-LS Attribute." (Agreement in number.)

### Section 7.2

```
      -  B-Flag: Backup Flag.  If set, the SID is eligible for
        protection using fast reroute (FRR).
```
I suggest "eligible to be protected" instead.

```
      -  Other bits are reserved for future use and MUST be set to 0 and
        ignored on receipt.
```
```
  *  Reserved: 2 octet field.  The value MUST be set to 0 and ignored
      on receipt.
```
For both these cases, I suggest "MUST be set to 0 when originated, and..."

### Section 8

```
  The sum of the LB Length, LN Length, Func.  Length, and Arg. Length
  MUST be less than or equal to 128.
```
I was a little surprised these don't have to total exactly 128 but I guess this is a deliberate choice and consistent with other specs? (Presumably, any leftover bits are don't-care.)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Note to IESG -- the shepherd has requested we move this to the December 15 agenda, I've opened a ticket for that purpose; you can consider this one off the December 1 agenda.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-bgpls-srv6-ext-10. If any part of this review is inaccurate, please let us know.

IANA has a minor question about the second action and a note about terminology.

NOTE: a collection of registries should be called a "registry group" rather than a "registry" (as in Section 9.3). A discrete set of registrations should be called a "registry" rather than a "sub-registry," unless you mean to indicate a relationship to another registry's registration(s).

First, in the BGP-LS NLRI-Types registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at

https://www.iana.org/assignments/bgp-ls-parameters/

the early registration for

Type: 4
NLRI Type: SRv6 SID NLRI
Reference: [ RFC-to-be ]

will have its reference changed to [ RFC-to-be ].

Second, in the BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry also on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

https://www.iana.org/assignments/bgp-ls-parameters/

the following early registrations:

+----------+----------------------------------------+
| TLV Code | Description |
| Point | |
+----------+----------------------------------------+
| 518 | SRv6 SID Information TLV |
| 1038 | SRv6 Capabilities TLV |
| 1106 | SRv6 End.X SID TLV |
| 1107 | IS-IS SRv6 LAN End.X SID TLV |
| 1108 | OSPFv3 SRv6 LAN End.X SID TLV |
| 1162 | SRv6 Locator TLV |
| 1250 | SRv6 Endpoint Behavior TLV |
| 1251 | SRv6 BGP Peer Node SID TLV |
| 1252 | SRv6 SID Structure TLV |
+----------+----------------------------------------+

will have their references changed to [ RFC-to-be ].

IANA QUESTION: most entries in this registry of TLVs don't include the string "TLV" in their description field. Can "TLV" be removed here?

Third, a new registry called the SRv6 BGP EPE SID Flags registry will be created at the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page:

https://www.iana.org/assignments/bgp-ls-parameters/

The allocation policy for the new registry will be Standards Action, as defined by [RFC8126].

There are initial registrations in the new registry as follows:

Bit Description Reference
-----+------------------------------+-------------------
0 Backup Flag (B-Flag) [ RFC-to-be ]
1 Set Flag (S-Flag) [ RFC-to-be ]
2 Persistent Flag (P-Flag) [ RFC-to-be ]
3-7 Unassigned

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Amanda Baber
IANA Operations Manager

The following Last Call announcement was sent out (ends 2022-10-31):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-idr-bgpls-srv6-ext@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Link State Extensions for SRv6) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP Link State Extensions for SRv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-31. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Segment Routing over IPv6 (SRv6) allows for a flexible definition of
  end-to-end paths within various topologies by encoding paths as
  sequences of topological or functional sub-paths, called "segments".
  These segments are advertised by various protocols such as BGP, IS-IS
  and OSPFv3.

  This document defines extensions to BGP Link-state (BGP-LS) to
  advertise SRv6 segments along with their behaviors and other
  attributes via BGP.  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3797/
  https://datatracker.ietf.org/ipr/4486/

Template date:  1 November 2019.
Date of Shepherd's report: 10/12/2022

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployment experience, standards person)
review so the shepherd is confident in reviews performed.

Why 6 authors:
This draft was created by the interaction of authors and implementers from
multiple companies. All 6 authors were key people in a joint meetings to create
the draft. Ketan (as editor) has taken on the challenge of interacting with
IETF folks and getting agreement.  Every time he revises the document,
he goes back to his co-authors to get agreement on text and
interoperability of features and language.  This seems to be inline with the
best practice of IETF.




Early reviews:
1) RTG-DIR: (Adrian Farrell (a past RTG AD)) status: Has issues.
Summary: The approach described in this document is consistent with the
body of BGP-LS work, but I think it is important to note that the
mechanism set out here differs slightly from the mechanism defined to
do similar function with SR-MPLS. This distinction is clearly made in
Appendix A. However, the WG chairs and AD will want to be sure that the
WG recognize this difference and are OK with having two slightly
different mechanisms running side by side.
https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-07-rtgdir-early-farrel-2021-05-29/

Shepherd's comments: 2 week confirmation on IDR WG issue (9/30/2022 to 10/13/2022)
https://mailarchive.ietf.org/arch/msg/idr/xzdrE3vOnPeYxhVg6hdq6ml3118/
[No issues raised from 9/30 to 10/13]
Shepherd closed the call:
https://mailarchive.ietf.org/arch/msg/idr/CbVorZnCvH16Msf6t5t8zqA7LT4/

2) OPS-DIR - awaiting assignment (Dan Romascanu (a past OPS-NM AD)) status: ready
Summary: Well written, but could use an abbreviation section that explains abbreviations in 4 associated documents.
Section 10 is quite rich in operator insight. 
review: https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-08-opsdir-early-romascanu-2021-06-24/

3) INT-DIR (reviewer: Jouni Korhonen - No response)
4) SEC-DIR (reviewer: Stephen Farrell (a past Security AD)) status: Ready
  Stephen indicated he no relevant knowledge regarding BGP-LS.


Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com
https://mailarchive.ietf.org/arch/msg/idr/T7chRoEcXFfk06jI_ilH-60dEG8

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com
Hani: https://mailarchive.ietf.org/arch/msg/idr/yudApGY7YHnbsKPL5aIbKYVzzVI/

Arjun Sreekantiah
arjunhrs@gmail.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Les Ginsberg (Cisco)
ginsberg@cisco.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 10/12/2022

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployment experience, standards person)
review so the shepherd is confident in reviews performed.

Why 6 authors:
This draft was created by the interaction of authors and implementers from
multiple companies. The authors chose one represented per company and
moved all other authors to contributors.


Early reviews:
1) RTG-DIR: (Adrian Farrell (a past RTG AD)) status: Has issues.
Summary: The approach described in this document is consistent with the
body of BGP-LS work, but I think it is important to note that the
mechanism set out here differs slightly from the mechanism defined to
do similar function with SR-MPLS. This distinction is clearly made in
Appendix A. However, the WG chairs and AD will want to be sure that the
WG recognize this difference and are OK with having two slightly
different mechanisms running side by side.
https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-07-rtgdir-early-farrel-2021-05-29/

Shepherd's comments: 2 week confirmation on IDR WG issue (9/30/2022 to 10/13/2022)
https://mailarchive.ietf.org/arch/msg/idr/xzdrE3vOnPeYxhVg6hdq6ml3118/
[No issues raised from 9/30 to 10/13]
Shepherd closed the call:
https://mailarchive.ietf.org/arch/msg/idr/CbVorZnCvH16Msf6t5t8zqA7LT4/

2) OPS-DIR - awaiting assignment (Dan Romascanu (a past OPS-NM AD)) status: ready
Summary: Well written, but could use an abbreviation section that explains abbreviations in 4 associated documents.
Section 10 is quite rich in operator insight. 
review: https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-08-opsdir-early-romascanu-2021-06-24/

3) INT-DIR (reviewer: Jouni Korhonen - No response)
4) SEC-DIR (reviewer: Stephen Farrell (a past Security AD)) status: Ready
  Stephen indicated he no relevant knowledge regarding BGP-LS.


Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com
https://mailarchive.ietf.org/arch/msg/idr/T7chRoEcXFfk06jI_ilH-60dEG8

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com
Hani: https://mailarchive.ietf.org/arch/msg/idr/yudApGY7YHnbsKPL5aIbKYVzzVI/

Arjun Sreekantiah
arjunhrs@gmail.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Les Ginsberg (Cisco)
ginsberg@cisco.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 10/12/2022

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployment experience, standards person)
review so the shepherd is confident in reviews performed.

Why 6 authors:
This draft was created by the interaction of authors and implementers from
multiple companies. The authors chose one represented per company and
moved all other authors to contributors.


Early reviews:
1) RTG-DIR: (Adrian Farrell (a past RTG AD)) status: Has issues.
Summary: The approach described in this document is consistent with the
body of BGP-LS work, but I think it is important to note that the
mechanism set out here differs slightly from the mechanism defined to
do similar function with SR-MPLS. This distinction is clearly made in
Appendix A. However, the WG chairs and AD will want to be sure that the
WG recognize this difference and are OK with having two slightly
different mechanisms running side by side.
https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-07-rtgdir-early-farrel-2021-05-29/

Shepherd's comments: 2 week confirmation on IDR WG issue (9/30/2022 to 10/13/2022)
https://mailarchive.ietf.org/arch/msg/idr/xzdrE3vOnPeYxhVg6hdq6ml3118/
[No issues raised from 9/30 to 10/12]

2) OPS-DIR - awaiting assignment (Dan Romascanu (a past OPS-NM AD)) status: ready
Summary: Well written, but could use an abbreviation section that explains abbreviations in 4 associated documents.
Section 10 is quite rich in operator insight. 
review: https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-08-opsdir-early-romascanu-2021-06-24/

3) INT-DIR (reviewer: Jouni Korhonen - No response)
4) SEC-DIR (reviewer: Stephen Farrell (a past Security AD)) status: Ready
  Stephen indicated he no relevant knowledge regarding BGP-LS.


Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com
https://mailarchive.ietf.org/arch/msg/idr/T7chRoEcXFfk06jI_ilH-60dEG8

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com
Hani: https://mailarchive.ietf.org/arch/msg/idr/yudApGY7YHnbsKPL5aIbKYVzzVI/

Arjun Sreekantiah
arjunhrs@gmail.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Les Ginsberg (Cisco)
ginsberg@cisco.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 5/26/2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployment experience, standards person)
review so the shepherd is confident in reviews performed.

Why 6 authors:
This draft was created by the interaction of authors and implementers from
multiple companies. The authors chose one represented per company and
moved all other authors to contributors.


Early reviews:
1) RTG-DIR: (Adrian Farrell (a past RTG AD)) status: Has issues.
Summary: The approach described in this document is consistent with the
body of BGP-LS work, but I think it is important to note that the
mechanism set out here differs slightly from the mechanism defined to
do similar function with SR-MPLS. This distinction is clearly made in
Appendix A. However, the WG chairs and AD will want to be sure that the
WG recognize this difference and are OK with having two slightly
different mechanisms running side by side.
https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-07-rtgdir-early-farrel-2021-05-29/

Shepherd's comments: 2 week confirmation on IDR WG issue (9/30/2022 to 10/13/2022)
https://mailarchive.ietf.org/arch/msg/idr/xzdrE3vOnPeYxhVg6hdq6ml3118/

2) OPS-DIR - awaiting assignment (Dan Romascanu (a past OPS-NM AD)) status: ready
Summary: Well written, but could use an abbreviation section that explains abbreviations in 4 associated documents.
Section 10 is quite rich in operator insight. 
review: https://datatracker.ietf.org/doc/review-ietf-idr-bgpls-srv6-ext-08-opsdir-early-romascanu-2021-06-24/

3) INT-DIR (reviewer: Jouni Korhonen - No response)
4) SEC-DIR (reviewer: Stephen Farrell (a past Security AD)) status: Ready
  Stephen indicated he no relevant knowledge regarding BGP-LS.


Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com
https://mailarchive.ietf.org/arch/msg/idr/T7chRoEcXFfk06jI_ilH-60dEG8

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com
Hani: https://mailarchive.ietf.org/arch/msg/idr/yudApGY7YHnbsKPL5aIbKYVzzVI/

Arjun Sreekantiah
arjunhrs@gmail.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Les Ginsberg (Cisco)
ginsberg@cisco.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 5/26/2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployer, standards person) review so the shepherd is confident in reviews performed.

1) RTG- DIR -  awaiting assignment (Tentatively Eric Gray)
2) OPS-DIR - awaiting assignment
3) INT-DIR - awaiting assignment.
4) SEC-DIR - awaiting assignment.

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com
https://mailarchive.ietf.org/arch/msg/idr/T7chRoEcXFfk06jI_ilH-60dEG8

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com
Hani: https://mailarchive.ietf.org/arch/msg/idr/yudApGY7YHnbsKPL5aIbKYVzzVI/

Arjun Sreekantiah
arjunhrs@gmail.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Les Ginsberg (Cisco)
ginsberg@cisco.com
Les: https://mailarchive.ietf.org/arch/msg/idr/F6A9Ep21DP59RJMjv06-NHaA4Bs

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 5/26/2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployer, standards person) review so the shepherd is confident in reviews performed.

1) RTG- DIR -  awaiting assignment (Tentatively Eric Gray)
2) OPS-DIR - awaiting assignment
3) INT-DIR - awaiting assignment.
4) SEC-DIR - awaiting assignment.

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com - missing

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com  (missing)

Arjun Sreekantiah  (missing)
arjunhrs@gmail.com

Les Ginsberg (Cisco) (missing)
ginsberg@cisco.com

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 5/26/2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployer, standards person) review so the shepherd is confident in reviews performed.

1) RTG- DIR -  awaiting assignment (Tentatively Eric Gray)
2) OPS-DIR - awaiting assignment
3) INT-DIR - awaiting assignment.
4) SEC-DIR - awaiting assignment.

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com - missing

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com  (missing)

Arjun Sreekantiah  (missing)
arjunhrs@gmail.com

Les Ginsberg (Cisco) (missing)
ginsberg@cisco.com

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 5/26/2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployer, standards person) review so the shepherd is confident in reviews performed.

1) RTG- DIR -  awaiting assignment (Tentatively Eric Gray)
2) OPS-DIR - awaiting assignment
3) INT-DIR - awaiting assignment.
4) SEC-DIR - awaiting assignment.

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, and SEC-DIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com - missing

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com  (missing)

Arjun Sreekantiah  (missing)
arjunhrs@gmail.com

Les Ginsberg (Cisco) (missing)
ginsberg@cisco.com

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 5/26/2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployer, standards person) review so the shepherd is confident in reviews performed.

1) RTG- DIR -  awaiting assignment (Tentatively Eric Gray)
2) OPS-DIR - awaiting assignment
3) INT-DIR - awaiting assignment.
4) SEC-DIR - awaiting assignment.

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR, SEC-EIR.
Reason: Key technology such as BGP-LS for SRV6 should be reviewed by as many eyes as possible.
I am confident in IDR reviews for BGP technology, but wider issues should be examined by Directorates.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:  (All Authors have given IPR,  Not all contributors)
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com - missing

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com  (missing)

Arjun Sreekantiah  (missing)
arjunhrs@gmail.com

Les Ginsberg (Cisco) (missing)
ginsberg@cisco.com

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.
Date of Shepherd's report: 5/26/2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021) 
BGP-LS for SRv6 is key technology so extra reviews were requested. 
Shepherd received targeted Haibo Wang (implementer, deployer, standards person) review so the shepherd is confident in reviews performed.

1) RTG- DIR -  awaiting assignment (Tentatively Eric Gray)
2) OPS-DIR - awaiting assignment
3) INT-DIR - awaiting assignment.
4) SEC-DIR - awaiting assignment.

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.
2) NITS review - no nits 
3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 

Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR. 

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text. 
SRv6 is important technology to variety of Carriers and Data Center support.
INT-DIR request is to validate the SRv6 given the tunnel technology. 

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

IPR statements from Authors:
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com - missing

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com  (missing)

Arjun Sreekantiah  (missing)
arjunhrs@gmail.com

Les Ginsberg (Cisco) (missing)
ginsberg@cisco.com

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.
No objections in WG LC for Huawei and Cisco WG LC.
Recall during status reports (5/26 - 6/7)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft: (unclear timeline for advancement)
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15


(16) Will publication of this document change the status of any existing RFCs?

No changes to RFCs.  New work on BGP-LS for SRV6.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

All Allocation of the BGP-LS NLRI (section 9.1) and BGP-LS TLVs were assigned for early allocation.  These allocation are correct.

No new registries.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
No new regist ries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No XML, BNF, MIB, or Yang modules.  No review needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang module

Template date:  1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021)
1) RTG- DIR
2) OPS-DIR
3) INT-DIR

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.

2) NITS review - no nits 

3) IPR review
4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)

See input to shepherd's review:
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -  Clarifications made to -07
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment - Clarifications made to -07.txt

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format - clarifications made to -07.

If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
No broader review required. 
Early reviews requested for OPS-DIR, RTG-DIR, INT-DIR due to subject matter.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

No issues with current text.  SRv6 is important technology to variety of Carriers and Data Center support.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.

IPR statements:
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com  (missing)

Arjun Sreekantiah  (missing)
arjunhrs@gmail.com

Les Ginsberg (Cisco) (missing)
ginsberg@cisco.com

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Ran detailed IP-NITs - nothing found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional reviews

(13) Have all references within this document been identified as either normative or informative?
yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the plan for their completion?

WG draft:
I-D.ietf-lsr-ospfv3-srv6-extensions-02.txt

Submitted to IESG for publication:
draft-ietf-6man-spring-srv6-oam-10
draft-ietf-lsr-isis-srv6-extensions-15

Normative references in RFC editor's queue:
draft-ietf-idr-bgp-ls-segment-routing-ext
draft-ietf-idr-bgpls-segment-routing-epe


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Template date:  1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021)
1) RTG- DIR
2) OPS-DIR
3) INT-DIR

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.

2) NITS review

3) IPR review

4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)
Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment

  Now the BGP EPE Peer Node info is advertised with SRv6 SID NLRI, it cause some disadvantages compared to SR-MPLE EPE.
  First, the number of NLRIs needed for SRv6 EPE may be more than MPLS EPE. This is because the NLRI's key is SRv6 SID, but for one EPE Peer node, there may be multiple SIDs, such as End.x with PSP, End.x with USD etc.
  Second, with MPLS EPE, for a direct EBGP Peer, only one NLRI is needed to advertise the link and its Peer node SID, link attributes.
But with the current method for SRv6 EPE, at least two NLRIs are needed, one is the SRv6 SID NLRI for the Peer Node SID, the other is a Link NLRI with the End.X SID (the SID value may be the same while need to be advertised in different NLRIs) and link attributes..
  At current stage maybe it is not suitable to change the encoding, but I suggest to give more detail description about the behavior of advertising the SRv6 Peer node SID and the Peer adjacency SID with corresponding NLRIs for a direct peer and for a peer established on loopback. 

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format
  [comment]As Figure 13 is about the Flags of SRv6 BGP Peer Node SID TLV, its name may be changed to SRv6 BGP Peer Node SID TLV Flags Format


If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
If so, describe the review that took place.




(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.

IPR statements:
Guarav Dawra:
https://mailarchive.ietf.org/arch/msg/idr/U5R1MG8prEo38veJiDESvDvXcwE/

Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/yiMXjdo6L-S6NUm_IvDRJj0uVfI/

Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

Mach Chen
https://mailarchive.ietf.org/arch/msg/idr/QwxlRGM0_hywg3GmzJY7kl0x7Ng/

Daniel Bernier
https://mailarchive.ietf.org/arch/msg/idr/gA8PHisHofUyxGTjjTiMSsTfWOI/

Bruno Decraene
https://mailarchive.ietf.org/arch/msg/idr/bQoHczBPTYvJwD81BNnctYDWw-s/

Contributors:
James Uttaro
jul738@att.com

Hani Elmalky [Ericsson]
hani.elmalky@gmail.com  (missing)

Arjun Sreekantiah  (missing)
arjunhrs@gmail.com

Les Ginsberg (Cisco) (missing)
ginsberg@cisco.com

Shuwan Zhuang:
https://mailarchive.ietf.org/arch/msg/idr/c6v2XGu5L3dC5BT_Z2grLCMgPY8/

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG LC:
https://mailarchive.ietf.org/arch/msg/idr/pF1iR3OlaCBhCBxegoyP4P-dMRg/

Solid consensus with active comments

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Template date:  1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG LC occurred on 11/1/2020 to 11/16/2020). 
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?
There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:  (5/25/2021)
1) RTG- DIR
2) OPS-DIR
3) INT-DIR

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
https://mailarchive.ietf.org/arch/msg/idr/vn4v2sxI_5uLKGqY12JCCJN4MvU/

Version 7 addressed all the known issues.

2) NITS review

3) IPR review

4) Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)
Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment

  Now the BGP EPE Peer Node info is advertised with SRv6 SID NLRI, it cause some disadvantages compared to SR-MPLE EPE.
  First, the number of NLRIs needed for SRv6 EPE may be more than MPLS EPE. This is because the NLRI's key is SRv6 SID, but for one EPE Peer node, there may be multiple SIDs, such as End.x with PSP, End.x with USD etc.
  Second, with MPLS EPE, for a direct EBGP Peer, only one NLRI is needed to advertise the link and its Peer node SID, link attributes.
But with the current method for SRv6 EPE, at least two NLRIs are needed, one is the SRv6 SID NLRI for the Peer Node SID, the other is a Link NLRI with the End.X SID (the SID value may be the same while need to be advertised in different NLRIs) and link attributes..
  At current stage maybe it is not suitable to change the encoding, but I suggest to give more detail description about the behavior of advertising the SRv6 Peer node SID and the Peer adjacency SID with corresponding NLRIs for a direct peer and for a peer established on loopback. 

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format
  [comment]As Figure 13 is about the Flags of SRv6 BGP Peer Node SID TLV, its name may be changed to SRv6 BGP Peer Node SID TLV Flags Format


If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
If so, describe the review that took place.




(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

IPR disclosures:
Cisco: filed 10/1/2019
https://datatracker.ietf.org/ipr/3797/
Huawei: filed 11/13/2020
https://datatracker.ietf.org/ipr/4486/

Note:  Cisco IPR filed after adoption, but no concerns with
Note: Huawei IPR filed prior close of WG LC.

IPR statements:
Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/6nOFdInk1SNjJKdVNVsgUKOXdgQ/

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Template date:  1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?  BGP-LS additions to BGP.
Is this type of RFC indicated in the title page header?  yes

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt. 
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?

There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required
Early Reviews requested:
1) RTG- DIR
2) OPS-DIR
3) INT-DIR

Personnel:
Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana
IDR chairs:  Keyur Patel, Jeff Haas, Susan Hares

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Extensive review and discussion with authors on Text
2) NITS review
3) IPR review

Requested specific BGP-LS expert to review
Wanghaibo (Rainsword)
Summary of Comments from Haibo Wang:  Addressed by

1. chapter 4.2 SRv6 LAN End.X SID TLV  need clarifiications -
2. SRv6 SID NLRI - BGP EPE Peer node is advertised with SRv6 SID NLRI, can cause disadvantages to SR-MPLS.
  [comment

  Now the BGP EPE Peer Node info is advertised with SRv6 SID NLRI, it cause some disadvantages compared to SR-MPLE EPE.
  First, the number of NLRIs needed for SRv6 EPE may be more than MPLS EPE. This is because the NLRI's key is SRv6 SID, but for one EPE Peer node, there may be multiple SIDs, such as End.x with PSP, End.x with USD etc.
  Second, with MPLS EPE, for a direct EBGP Peer, only one NLRI is needed to advertise the link and its Peer node SID, link attributes.
But with the current method for SRv6 EPE, at least two NLRIs are needed, one is the SRv6 SID NLRI for the Peer Node SID, the other is a Link NLRI with the End.X SID (the SID value may be the same while need to be advertised in different NLRIs) and link attributes..
  At current stage maybe it is not suitable to change the encoding, but I suggest to give more detail description about the behavior of advertising the SRv6 Peer node SID and the Peer adjacency SID with corresponding NLRIs for a direct peer and for a peer established on loopback. 

3. Figure 12: SRv6 BGP Peer Node SID TLV Format 
  Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format
  [comment]As Figure 13 is about the Flags of SRv6 BGP Peer Node SID TLV, its name may be changed to SRv6 BGP Peer Node SID TLV Flags Format


If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
If so, describe the review that took place.




(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Template date:  1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Standards

Why is this the proper type of RFC?

Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  Segment Routing (SR) over IPv6 (SRv6) allows for a flexible
  definition of end-to-end paths within various topologies by encoding
  paths as sequences of topological or functional sub-paths, called
  "segments".  These segments are advertised by the various protocols
  such as BGP, IS-IS and OSPFv3.

  BGP Link-state (BGP-LS) address-family solution for SRv6 is similar
  to BGP-LS for SR for MPLS data-plane.  This draft defines extensions
  to the BGP-LS to advertise SRv6 Segments along with their behaviors
  and other attributes via BGP.

Working Group Summary:
WG support has strong for draft-ietf-idr-bgpls-srv6-ext-07.txt
This draft is a part of the BGP-LS work for SRv6. 
Four implementations of this draft exist (Cisco IOS-Xr, Huawei VRP, GoBGP, GoBMP)

Document Quality:

Are there existing implementations of the protocol?

There are 4 implementations of the protocol.  The specific details of the implementations can be found at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

MIB doctor review: None  required

Personnel:

Who is the Document Shepherd? Susan Hares
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.


If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Request for posting confirmation emailed to previous authors: Bruno Decraene , " daniel.bernier@bell.ca" , Ketan Talaulikar , Gaurav Dawra , Mach Chen , Clarence Filsfils

Request for posting confirmation emailed to previous authors: Bruno Decraene , " daniel.bernier@bell.ca" , Ketan Talaulikar , Gaurav Dawra , Mach Chen , Clarence Filsfils