Subject: Re: [Idr] Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Mar 2021 07:53:42 -0500

Ketan:

I'm pleased to see we have agreement on all issues except issues 1, 5, and
9.  With draft-06.txt, I consider those issues closed.  If you are agreed,
then I'll delete the text regarding those. 

On the issues remaining, 1, 5, and 9: 

Issue 1: reference to draft-ietf-bess-srv6-services 

You stated that "BESS BGP SRv6 draft is about extensions to BGP address
families that are unrelated to this BGP-LS specification",  

If this is true, why are you including this text in this draft?   If you
feel it is critical to the draft, then I will go back to the argument
regarding draft-ietf-bess-srv6-services. 

Issue 5:  Unclear text 

I reached out to an SR expert during this review process of this draft
because I felt this text was unclear the first time in
draft-ietf-idr-bgp-ls-segment-routing-ext-16. 

[KT] For the record, the text is identical for what we have out for
publication for BGP-LS for SR-MPLS :
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-
ext-16#section-2.2.2

I have re-read the section again this morning.  The sentence below

could be clarified by indicating which of the Endpoint behaviors in 

RFC8986 section 4 this applies to.   

Old text/The SRv6 LAN End.X SID TLV allows a node to announce SRv6 SID

corresponding to behaviors like END.X [RFC8986] for its adjacencies

to all other (i.e. non-DIS or non-DR) nodes attached to the LAN in a

single instance of the BGP-LS Link NLRI./

If you mean only to use this on IGP agencies, then please state which of the

SRv6 SID behaviors it applies to.   If you declare BGP adjacencies 

via direct connect out of scope at this point,  you can state this point.  

If the text exists in RFC8986, then you can simply refer to it. 

On issue 9, I'll review the list information to see if I can provide further
details. 

Cheers, Sue 

Original messages 

From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Monday, March 8, 2021 3:31 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt

Hi Sue and Haibo,

Thanks for your review. We've uploaded a new version of the draft to address
most of your comments below:

https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-srv6-ext-06.txt

Please check inline for detail responses.

From: Susan Hares <[email-masked]> 
Sent: 20 February 2021 01:37
To: [email-masked]
Cc: [email-masked]; Ketan Talaulikar (ketant)
<[email-masked]>
Subject: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt

Guarav, Ketan, Fils, Mach, Daniel, Bruno:  

First of all thank you for your hard work on refining
draft-ietf-idr-bgpls-srv6-ext-05.txt.  

I'm glad to have this draft in the SRv6 family. 

This shepherd report is a combination of my review and a review done by
Haibo Wang.   As you recall, I asked for SR-Reviews to review SR drafts in
addition to the document shepherds.   I've indicated Haibo's comments in my
review.  I appreciate his help in reviewing this IDR draft.  

I'm working this weekend in case you want me to review any changes before
the draft deadline on Monday. 

Cheers, Sue 

============

Issues are marked with levels: major or minor 

Resolution is marked as: Mandatory or recommended  

Issue #1: 

========

Location: Section 1:  paragraph 3, sentence

Issue:  Major

Change: Mandatory

Original Text: 

/BGP (I-D.ietf.bess-srv6-services)) has been extended to 

advertise some of these SRV6 SIDs and SRv6-related information./

Problem description: 

The reference to this bess draft means that you must support all the 

features within the draft. Specifically, if you are indicating support 

for the EVPN sections of this draft you are more likely to hit the 

issues described in section 4.9 of draft-ietf-idr-rfc7752bis-05.txt.   

[KT] The reference to the BGP SRv6 draft in BESS is informational only. It
is not related to section 4.9 of RFC7752-bis since that is applicable only
for link-state IGP protocols.

If you wish to keep this text, you have two options: 

Option 1) Replace RFC7752 references with RFC7752bis and make appropriate
changes 

Or 

Option 2) Keep dependency on RFC7752 and change the last paragraph of
section 10. 

For option 2, I provide you with sample text change below.  

This text is just a example. 

Old Text/The extensions, specified in this document, do not introduce any
new 

configuration or monitoring aspects in BGP or BGP-LS other than discussed

in [RFC7752]./

New text:/The extensions, specified in this document, do not introduce any
new 

configuration, monitoring  or error handle aspects of BGP or BGP-LS other 

than those discussed in [RFC7752] and [RFC7752bis].  In some use cases

for topologies that might be used for draft-ietf-bess-srv6-services EVPN,

the error handling in [RFC7752bis] section 4.9 may be necessary to handle 

the combination of unreachable IGP nodes, BGP-LS with certain BGP Peer
topologies, 

and service requirements of VPN applications./  

[KT] The BESS BGP SRv6 draft is about extensions to BGP address families
that are unrelated to this BGP-LS specification.

===============================================================

Issue 2:  

Location: Section 3.1, page 6, figure 2

What changes:  Addition to field to clearly show Reserved fields

Issue: minor  

Change: Recommended 

Problem: Text unclear without reserve word 

Old text/

     0                   1

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    | |O|                           |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

/

New text/

     0                   1

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    | |O|       Reserved            |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[KT] Ack

========================================= 

Issue 3:  

Location: Section 4.1, page 8, bullet beginning "Endpoint Behavior"

Issue: Major

Change: Mandatory 

Problem: section 9 is security considerations in 

[draft-ietf-spring-srv6-network-programming]

Perhaps you mean section 4 (SR EndPoint descriptions) or 

section 10.2 or 10.2.1 with the Initial registrations for

SRv6 Endpoint Behaviors.   

Old Text:

/End point Behavior: 2 octet field.  The Endpoint Behavior  code

Point for this SRV6 SID is defined in section 9.2 of

[I-D.ietf-spring-srv6-network-programming]

/

New Text /End point Behavior: 2 octet field.  The Endpoint Behavior  code

Point for this SRV6 SID is defined in section 10.2 of

[I-D.ietf-spring-srv6-network-programming]

/

[KT] Ack

=======================

Issue 4: 

Location: Section 4.2, figure 4, page 8

Type: minor 

Status: Recommended 

Old-Text/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P|         |

    +-+-+-+-+-+-+-+-+

/

New-Text/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P| Reserved|

    +-+-+-+-+-+-+-+-+

/

[KT] Ack

=============

Issue 5: 

Location: section 4.2, page 9, paragraph 1

Status: Major

Change: Mandatory to improve text  

Reviewers: [Haibo Wang and Susan Hares] 

 Old/Text chapter 4.2 SRv6 LAN End.X SID TLV.

   For a LAN interface, normally an IGP node only announces its

   adjacency to the IS-IS pseudo-node (or the equivalent OSPF DR).  The

   SRv6 LAN End.X SID TLV allows a node to announce SRv6 SID

   corresponding to behaviors like END.X

   [I-D.ietf-spring-srv6-network-programming] for its adjacencies to all

   other (i.e. non-DIS or non-DR) nodes attached to the LAN in a single

   instance of the BGP-LS Link NLRI.  Without this TLV, multiple BGP-LS

   Link NLRI would need to be originated for each additional adjacency

   in order to advertise the SRv6 End.X SID TLVs for these neighbor

   adjacencies.

/

[KT] For the record, the text is identical for what we have out for
publication for BGP-LS for SR-MPLS :
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-
ext-16#section-2.2.2

Hares Comments: This paragraph is unclear.  It needs to be rewritten. 

[WangHaibo] suggests a way to approach this text:  

1.  I suggest to first describe the behavior of the LAN End.X SID
explicitly, 

such as "each LAN End.X SID is used to specify the 

cross-connect to one adjacency node attached to the LAN". 

Then describe how to encode the LAN End.X SID TLVs with 

the Link NLRI corresponding to the adjacency to DIS or DR.

[KT] It is not the purpose of the BGP-LS specification to describe this and
hence we have reference to the individual IGP specifications in the very
next paragraph.

==========

Issue 6: 

Location: section 4.2., p. 10, bullet beginning EndPoint Behavior

Issue: Major 

Change: Mandatory

Problem: Section 9 is in the security section. 

If you mean section 10.2, then the text change would be

Old Text/section 9.2 of [I-D.ietf-spring-srv6-network-programming]

New text/section 10.2 of [I-D.ietf-spring-srv6-network-programming]/

[KT] Ack

========

Issue 7: 

Location: section 4.2, figure 6 

Issue: Minor 

Problem: figure unclear without reserved words 

Change: Recommended 

Old text: /

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P|         |
    +-+-+-+-+-+-+-+-+

/

New text:/

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

[KT] Ack

========

Issue 8:  

Location: section 5.1, figure 8 

Issue: Minor 

Problem: figure unclear without reserved words 

Change: Recommended 

Old text: /

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |D|             |
    +-+-+-+-+-+-+-+-+

New text:/

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |D| Reserved    |
    +-+-+-+-+-+-+-+-+
 
[KT] Ack

======

Issue 9: 

Location: 2. SRv6 SID NLRI

Status: Major 

Changes: Some textual change is mandatory  

Problem: 

    [Wang Habio comments]

   Now the BGP EPE Peer Node info is advertised with SRv6 SID NLRI, it
cause[s] 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.  

[KT] I remember all of this has been discussed on the mailer a few times
already (and even offline) during the life of the document in the WG.

[Hares] Solution possibilities: 

a) provide text in section 6 prior to NLRI format 

b) create section in manageability section providing more details

If have questions on this request for clarifying information, 

send email to me, Haibo, or the list. 

[KT] I am not able to fully understand what is being asked here and I guess
we need further discussion. Is there some text that you have in mind that
you can propose?

=========

Issue 10:  

Status: Major

Change: Mandatory 

Location: 7.1, bullet point that starts "Endpoint Behavior"

Old text/section 9.2 of [I-D.ietf-spring-srv6-network-programming]/

New text / section 10.2 of [I-D.ietf-spring-srv6-network-programming]/

[KT] Ack

========

Issue 11: page 17, Figure 13 

Problem: reserved fields

Type: Minor

Status: Recommended 

Old Text/ 

Location: 

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P|         |

    +-+-+-+-+-+-+-+-+

            Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format

/

NewText/ 

Location: 

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P| Reserved|

    +-+-+-+-+-+-+-+-+

            Figure 13: SRv6 BGP Peer Node SID TLV Flags Format 

/

[KT] Ack

[Hares comment: Clearly specifying Reserved Fields in figure helps the
reader. 

[KT] Ack

[Wang Haibo comment:] 

   [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

[KT] We have flags in most TLVs and I don't see the point of prefixing the
TLV name with each of them.

==========

Location: Section 12:  Manageability section 

Praise: 

Thank you for mentioning the sematic or content checking is left to the
consumer of the BGP-LS information. 

============

Thanks,

Ketan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 12 Mar 2021 14:58:09 +0000

Hi Sue,

Please check inline below.

From: Susan Hares <[email-masked]>
Sent: 12 March 2021 18:24
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

Ketan:

I'm pleased to see we have agreement on all issues except issues 1, 5, and 9.  With draft-06.txt, I consider those issues closed.  If you are agreed, then I'll delete the text regarding those.

You stated that "BESS BGP SRv6 draft is about extensions to BGP address families that are unrelated to this BGP-LS specification",

If this is true, why are you including this text in this draft?   If you feel it is critical to the draft, then I will go back to the argument regarding draft-ietf-bess-srv6-services.
[KT] I will remove the informative reference to the BESS BGP SRv6 draft if that is going to help clear the confusion.

Issue 5:  Unclear text

I reached out to an SR expert during this review process of this draft because I felt this text was unclear the first time in draft-ietf-idr-bgp-ls-segment-routing-ext-16.

[KT] For the record, the text is identical for what we have out for publication for BGP-LS for SR-MPLS : https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.2.2

If you mean only to use this on IGP agencies, then please state which of the
SRv6 SID behaviors it applies to.   If you declare BGP adjacencies
via direct connect out of scope at this point,  you can state this point.
[KT] The SRv6 LAN End.X SID TLV is only applicable for IGPs. The RFC8986 behavior is the same End.X and the SID is advertised via SRv6 End.X SID TLV for adjacencies corresponding to the DIS (ISIS) or DR (OSPF) and using SRv6 LAN End.X SID TLV for other non-DIS/non-DR routers. This is specifically mentioned in Section 2 where all these TLVs are introduced briefly.

If the text exists in RFC8986, then you can simply refer to it.
[KT] RFC8986 does not get into IGP specifics and these aspects are covered by the respective IGP SRv6 specifications for which we already have the references.

On issue 9, I'll review the list information to see if I can provide further details.
[KT] Thanks - I will wait for the closure on this before posting the update.

Thanks,
Ketan

Cheers, Sue

Original messages
From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Monday, March 8, 2021 3:31 PM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt

Hi Sue and Haibo,

Thanks for your review. We've uploaded a new version of the draft to address most of your comments below:

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Sent: 20 February 2021 01:37
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Subject: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt

First of all thank you for your hard work on refining draft-ietf-idr-bgpls-srv6-ext-05.txt.
I'm glad to have this draft in the SRv6 family.

This shepherd report is a combination of my review and a review done by Haibo Wang.   As you recall, I asked for SR-Reviews to review SR drafts in addition to the document shepherds.   I've indicated Haibo's comments in my review.  I appreciate his help in reviewing this IDR draft.

I'm working this weekend in case you want me to review any changes before the draft deadline on Monday.

Cheers, Sue

============

Issue #1:
========

Original Text:

Problem description:
[KT] The reference to the BGP SRv6 draft in BESS is informational only. It is not related to section 4.9 of RFC7752-bis since that is applicable only for link-state IGP protocols.

Option 1) Replace RFC7752 references with RFC7752bis and make appropriate changes
Or
Option 2) Keep dependency on RFC7752 and change the last paragraph of section 10.

Old Text/The extensions, specified in this document, do not introduce any new
configuration or monitoring aspects in BGP or BGP-LS other than discussed
in [RFC7752]./

New text:/The extensions, specified in this document, do not introduce any new
configuration, monitoring  or error handle aspects of BGP or BGP-LS other
than those discussed in [RFC7752] and [RFC7752bis].  In some use cases
for topologies that might be used for draft-ietf-bess-srv6-services EVPN,
the error handling in [RFC7752bis] section 4.9 may be necessary to handle
the combination of unreachable IGP nodes, BGP-LS with certain BGP Peer topologies,
and service requirements of VPN applications./
[KT] The BESS BGP SRv6 draft is about extensions to BGP address families that are unrelated to this BGP-LS specification.

Old text/
     0                   1

[KT] Ack

Issue 3:

Old Text:

[KT] Ack

=======================
Issue 4:

Old-Text/
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P|         |
    +-+-+-+-+-+-+-+-+
/

New-Text/
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+
/

[KT] Ack

=============
Issue 5:

[KT] For the record, the text is identical for what we have out for publication for BGP-LS for SR-MPLS : https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.2.2

Hares Comments: This paragraph is unclear.  It needs to be rewritten.
[WangHaibo] suggests a way to approach this text:
1.  I suggest to first describe the behavior of the LAN End.X SID explicitly,
such as "each LAN End.X SID is used to specify the
cross-connect to one adjacency node attached to the LAN".
Then describe how to encode the LAN End.X SID TLVs with
the Link NLRI corresponding to the adjacency to DIS or DR.
[KT] It is not the purpose of the BGP-LS specification to describe this and hence we have reference to the individual IGP specifications in the very next paragraph.

==========
Issue 6:

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P|         |

    +-+-+-+-+-+-+-+-+
/
New text:/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P| Reserved|

    +-+-+-+-+-+-+-+-+

[KT] Ack

========
Issue 8:

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |D|             |

    +-+-+-+-+-+-+-+-+
New text:/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |D| Reserved    |

    +-+-+-+-+-+-+-+-+

[KT] Ack

======
Issue 9:
Location: 2. SRv6 SID NLRI
Status: Major
Changes: Some textual change is mandatory
Problem:
    [Wang Habio comments]
   Now the BGP EPE Peer Node info is advertised with SRv6 SID NLRI, it cause[s] 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.
[KT] I remember all of this has been discussed on the mailer a few times already (and even offline) during the life of the document in the WG.

If have questions on this request for clarifying information,
send email to me, Haibo, or the list.
[KT] I am not able to fully understand what is being asked here and I guess we need further discussion. Is there some text that you have in mind that you can propose?

=========
Issue 10:
Status: Major
Change: Mandatory

========

/
NewText/
Location:
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

[Hares comment: Clearly specifying Reserved Fields in figure helps the reader.
[KT] Ack

[Wang Haibo comment:]
   [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
[KT] We have flags in most TLVs and I don't see the point of prefixing the TLV name with each of them.

==========
Location: Section 12:  Manageability section
Praise:
Thank you for mentioning the sematic or content checking is left to the consumer of the BGP-LS information.
============

Thanks,
Ketan

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Mar 2021 11:34:48 -0500

Ketan: 

We'll consider item 1 closed, and you will delete the references to
draft-ietf-bess-srv6-services. 

Please review my response to issue 5.  I think I need to understand issue 5,
before I review the mail list for issues 9. 

We're getting closer. 

Sue 

From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Friday, March 12, 2021 9:58 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt -
update based on -06.txt 

Hi Sue,

Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt -
update based on -06.txt 

Ketan:

[KT] I will remove the informative reference to the BESS BGP SRv6 draft if
that is going to help clear the confusion.

Great - we'll consider this closed. 

Issue 5:  Unclear text 

[sue] Maybe a higher level question is key.  

Why did you say "like End.X"  rather than "End.X"? 

Were you implying another set of behaviors or just the one listed in section
2. 

[KT] The SRv6 LAN End.X SID TLV is only applicable for IGPs. 

[Sue] This was clear in the RFC8986 text. 

Hence - I'm trying to find what "like End.X" means. 

The RFC8986 behavior is the same End.X and the SID is advertised via SRv6
End.X SID TLV for adjacencies corresponding to the DIS (ISIS) or DR (OSPF)
and using SRv6 LAN End.X SID TLV for other non-DIS/non-DR routers. This is
specifically mentioned in Section 2 where all these TLVs are introduced
briefly.

[ok:  I begin to see you have the following specific use cases. 

   o  SRv6 SID of the IGP Adjacency SID or the BGP EPE Peer Adjacency

      SID [RFC8402] is advertised via SRv6 End.X SID TLV introduced in

      this document (Section 4.1)

   o  SRv6 SID of the IGP Adjacency SID to a non-Designated Router (DR)

      or non-Designated Intermediate-System (DIS) [RFC8402] is

      advertised via SRv6 LAN End.X SID TLV introduced in this document

      (Section 4.2)

   o  MSD types introduced for SRv6 are advertised (Section 4.3) using

      the Link MSD TLV specified in [RFC8814].

The phrase "like End.X" implies there are more.  

If these are the only phrases, then modify "like End.X" to "End.X" 

In section 4.1 

[KT] RFC8986 does not get into IGP specifics and these aspects are covered
by the respective IGP SRv6 specifications for which we already have the
references.

[sue] If you are just specifying "End.X", I can agree to this. 

Thanks,

Ketan 

Cheers, Sue 

Original messages 

Hi Sue and Haibo,

Cheers, Sue 

============

Issue #1: 

========

Issue:  Major

Change: Mandatory

Original Text: 

Problem description: 

Or 

in [RFC7752]./

Issue 2:  

Issue: minor  

Change: Recommended 

Old text/

     0                   1

    | |O|                           |

/

New text/

     0                   1

    | |O|       Reserved            |

 

[KT] Ack

Issue 3:  

Issue: Major

Change: Mandatory 

SRv6 Endpoint Behaviors.   

Old Text:

/

/

[KT] Ack

=======================

Issue 4: 

Type: minor 

Status: Recommended 

Old-Text/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P|         |

    +-+-+-+-+-+-+-+-+

/

New-Text/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P| Reserved|

    +-+-+-+-+-+-+-+-+

/

[KT] Ack

=============

Issue 5: 

Status: Major

   adjacencies.

/

==========

Issue 6: 

Issue: Major 

Change: Mandatory

[KT] Ack

========

Issue 7: 

Issue: Minor 

Change: Recommended 

Old text: /

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P|         |
    +-+-+-+-+-+-+-+-+

/

New text:/

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

[KT] Ack

========

Issue 8:  

Issue: Minor 

Change: Recommended 

Old text: /

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |D|             |
    +-+-+-+-+-+-+-+-+

New text:/

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |D| Reserved    |
    +-+-+-+-+-+-+-+-+
 
[KT] Ack

======

Issue 9: 

Status: Major 

Problem: 

    [Wang Habio comments]

=========

Issue 10:  

Status: Major

Change: Mandatory 

[KT] Ack

========

Problem: reserved fields

Type: Minor

Status: Recommended 

Old Text/ 

Location: 

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P|         |

    +-+-+-+-+-+-+-+-+

/

NewText/ 

Location: 

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P| Reserved|

    +-+-+-+-+-+-+-+-+

/

[KT] Ack

[KT] Ack

[Wang Haibo comment:] 

==========

Praise: 

============

Thanks,

Ketan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 12 Mar 2021 16:45:36 +0000

Hi Sue,

Please check inline below with [KT3]

Sent: 12 March 2021 22:05

Ketan:

We'll consider item 1 closed, and you will delete the references to draft-ietf-bess-srv6-services.
[KT3] Ack

Please review my response to issue 5.  I think I need to understand issue 5, before I review the mail list for issues 9.

We're getting closer.

Sue

Hi Sue,

To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Ketan:

Issue 5:  Unclear text

[sue] Maybe a higher level question is key.
Why did you say "like End.X"  rather than "End.X"?
Were you implying another set of behaviors or just the one listed in section 2.
[KT3] Since the TLV allows encoding of the behavior, and as described in section 2, it can be used to advertise SIDs with behaviors like End.X that are associated with the link. We have multiple variants of End.X behavior as indicated in https://datatracker.ietf.org/doc/html/rfc8986#section-10.2.2. Hope that clarifies.

Thanks,
Ketan

The RFC8986 behavior is the same End.X and the SID is advertised via SRv6 End.X SID TLV for adjacencies corresponding to the DIS (ISIS) or DR (OSPF) and using SRv6 LAN End.X SID TLV for other non-DIS/non-DR routers. This is specifically mentioned in Section 2 where all these TLVs are introduced briefly.

Thanks,
Ketan

Cheers, Sue

Original messages

Hi Sue and Haibo,

Cheers, Sue

============

Issue #1:
========

Original Text:

Problem description:

Old text/
     0                   1

[KT] Ack

Issue 3:

Old Text:

[KT] Ack

=======================
Issue 4:

Old-Text/
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P|         |
    +-+-+-+-+-+-+-+-+
/

New-Text/
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+
/

[KT] Ack

=============
Issue 5:

==========
Issue 6:

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P|         |

    +-+-+-+-+-+-+-+-+
/
New text:/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P| Reserved|

    +-+-+-+-+-+-+-+-+

[KT] Ack

========
Issue 8:

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |D|             |

    +-+-+-+-+-+-+-+-+
New text:/

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |D| Reserved    |

    +-+-+-+-+-+-+-+-+

[KT] Ack

======
Issue 9:

=========
Issue 10:
Status: Major
Change: Mandatory

========

/
NewText/
Location:
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

[Wang Haibo comment:]

==========

Thanks,
Ketan

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Mar 2021 12:25:14 -0500

Ketan: 

If you are using the IGP behavior with all of the behaviors listed in table
10.2.1 then the Haibo's comment applies, you must have text that indicates
how you will use the TLVs to handle these behaviors.  

Is there an LSR document that handles the same values?   If you could check
with Acee, to see if he has any ideas that might.  I'll check with Jeff,
Keyur, and Alvaro on this text as well.  

I think I need to clear issue 5 before I attack issue 9.   

I was hoping this was an editorial issue, but it is a bit more.  It is
better to clear the issue now before we put the draft on Alvaro's queue.  

Sue 

Sent: Friday, March 12, 2021 11:46 AM

Hi Sue,

Ketan: 

[KT3] Ack

We're getting closer. 

Sue 

Hi Sue,

Ketan:

Issue 5:  Unclear text 

[KT3] Since the TLV allows encoding of the behavior, and as described in
section 2, it can be used to advertise SIDs with behaviors like End.X that
are associated with the link. We have multiple variants of End.X behavior as
indicated in https://datatracker.ietf.org/doc/html/rfc8986#section-10.2.2.
Hope that clarifies. 

Thanks,

Ketan

      (Section 4.2)

In section 4.1 

Thanks,

Ketan 

Cheers, Sue 

Original messages 

Hi Sue and Haibo,

[snip] 

=============

Issue 5: 

Status: Major

   adjacencies.

/

==========

Snip 

======

Issue 9: 

Status: Major 

Problem: 

    [Wang Habio comments]

=========

Issue 10:  

Status: Major

Change: Mandatory 

[KT] Ack

========

Problem: reserved fields

Type: Minor

Status: Recommended 

Old Text/ 

Location: 

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P|         |

    +-+-+-+-+-+-+-+-+

/

NewText/ 

Location: 

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |B|S|P| Reserved|

    +-+-+-+-+-+-+-+-+

/

[KT] Ack

[KT] Ack

[Wang Haibo comment:] 

==========

Praise: 

============

Thanks,

Ketan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 12 Mar 2021 17:40:14 +0000

Hi Sue,

The corresponding IGP extensions are in https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

I will connect next week to perhaps better understand your comments.

Thanks,
Ketan

Sent: 12 March 2021 22:55

Ketan:

If you are using the IGP behavior with all of the behaviors listed in table 10.2.1 then the Haibo's comment applies, you must have text that indicates how you will use the TLVs to handle these behaviors.

Is there an LSR document that handles the same values?   If you could check with Acee, to see if he has any ideas that might.  I'll check with Jeff, Keyur, and Alvaro on this text as well.

I was hoping this was an editorial issue, but it is a bit more.  It is better to clear the issue now before we put the draft on Alvaro's queue.

Sue

Hi Sue,

Ketan:

We're getting closer.

Sue

Hi Sue,

Ketan:

Issue 5:  Unclear text

Thanks,
Ketan

Thanks,
Ketan

Cheers, Sue

Original messages

Hi Sue and Haibo,

==========

Snip
======
Issue 9:

=========
Issue 10:
Status: Major
Change: Mandatory

========

/
NewText/
Location:
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

[Wang Haibo comment:]

==========

Thanks,
Ketan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 25 Mar 2021 15:33:45 +0000

Hi Sue,

Thanks for the more detailed discussions over webex last week.

Summarizing here for the WG:

Issue 5 : we will clarify and cover all the End.X behavior variants

Issue 9 : this is really about some non-normative text to describe the differences between BGP EPE Peer Node & Set SID advertisements in SRv6 as opposed to SR-MPLS. I am not sure if the draft is an appropriate place to cover that since we've had those discussions on the IDR mailer in the past. However, as discussed, we will add text in the form of an appendix to summarize the discussion.

I will post an update of the draft with these changes as well as the resolution for Issue 1.

Thanks,
Ketan

From: Ketan Talaulikar (ketant)
Sent: 12 March 2021 23:10
To: Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt - update based on -06.txt

Hi Sue,

Thanks,
Ketan

Ketan:

Sue

Hi Sue,

Ketan:

We're getting closer.

Sue

Hi Sue,

Ketan:

Issue 5:  Unclear text

Thanks,
Ketan

Thanks,
Ketan

Cheers, Sue

Original messages

Hi Sue and Haibo,

==========

Snip
======
Issue 9:

=========
Issue 10:
Status: Major
Change: Mandatory

========

/
NewText/
Location:
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

[Wang Haibo comment:]

==========

Thanks,
Ketan

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 25 Mar 2021 15:52:05 +0000

The updated draft has just been posted : https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-07

Sent: 25 March 2021 21:04

Hi Sue,

Thanks,
Ketan

To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Sue,

Thanks,
Ketan

Ketan:

Sue

Hi Sue,

Ketan:

We're getting closer.

Sue

Hi Sue,

Ketan:

Issue 5:  Unclear text

Thanks,
Ketan

Thanks,
Ketan

Cheers, Sue

Original messages

Hi Sue and Haibo,

==========

Snip
======
Issue 9:

=========
Issue 10:
Status: Major
Change: Mandatory

========

/
NewText/
Location:
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

[Wang Haibo comment:]

==========

Thanks,
Ketan