Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

From: "Susan Hares" <[email-masked]>
Date: Sun, 1 Nov 2020 22:25:07 -0500

This begins an IPR call and a 2 week WG LC for 

draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1 to 11/16/2020) 

You can access the draft at: 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/

This draft focus on the BGP-LS support for SRv6. 

Spring has proposed the SRv6 support in RFC8402 

(see section 3.1.3 for mechanisms and section 8.2 for 

Security considerations).  

There are two implementations: Cisco and GoBGP 

You can see the implementation report at: 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implemen
tations

In your responses, please consider the following questions: 

a) Is the SRv6 technology ready for deployment or 

are there known issues? 

b) Will SRv6 provide valuable support for 

deployments of BGP-LS in support of source routing 

(aka spring)? 

c) Is this draft ready for publication? 

If you know of additional implementations, please send

a note to the idr chairs with the information or 

respond to this email. 

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 2 Nov 2020 04:51:15 +0000

Hi Sue,

I am not aware of any IPR other than the one already disclosed on this draft and I support the progression of this draft towards publication as a co-author.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: 02 November 2020 08:55
To: [email-masked]
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

There are two implementations: Cisco and GoBGP
You can see the implementation report at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

Cheers, Susan Hares

---

From: Gaurav Dawra <[email-masked]>
Date: Sun, 1 Nov 2020 21:45:32 -0800

Support

Sent from my iPhone

> On Nov 1, 2020, at 7:25 PM, Susan Hares <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Mach Chen <[email-masked]>
Date: Mon, 2 Nov 2020 09:26:59 +0000

Hi Sue,

I am not aware of any IPR that applies to this document.

BTW, I think the document is ready for publication. I just edited the wiki page and added status information of another implementation.

Best regards,
Mach

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 11:25 AM
To: [email-masked]
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 2 Nov 2020 12:57:39 +0000

Hi Sue, IDR WG,
I support publication of the document. Note that the URL below is for the flex-algo BGP-LS draft.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Sunday, November 1, 2020 at 10:26 PM
To: IDR List <[email-masked]>
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 2 Nov 2020 11:29:12 -0500

Acee:

Thank you  for noting that the URL is incorrect.   The correct URL is at:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext/

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 2, 2020 7:58 AM
To: Susan Hares; [email-masked]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Sue, IDR WG, 

Thanks,

Acee

are there known issues? 

(aka spring)? 

respond to this email. 

Cheers, Susan Hares

---

From: Gaurav Dawra <[email-masked]>
Date: Mon, 2 Nov 2020 22:51:51 -0800

Sending again...

Support as author and not aware of any IPR

Gaurav
LinkedIn 

Sent from my iPhone

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 3 Nov 2020 07:03:07 +0000

Hi Sue,

I support publication  of this document as contributor and I am not aware of any IPR that applies to this document.

Thanks,
Shunwan

Cheers, Susan Hares

---

From: Lizhenbin <[email-masked]>
Date: Tue, 3 Nov 2020 07:36:57 +0000

Hi All,

I support the WG LC of the draft. There have been multiple implementations and the draft is well written.

Best Regards,

Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745<tel:+86-13651017745>/+968-91797068
Email: [email-masked]<mailto:[email-masked]>

发件人：Susan Hares <[email-masked]>
收件人：idr <[email-masked]>
时 间：2020-11-02 11:25:58
主 题：[Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 3 Nov 2020 08:44:27 +0000

Hi Authors,

I have several comments on this draft:

1. In the introduction:
I believe “Segment Identifier (SID) is often used as a shorter reference for "SRv6 Segment". ”  is not correct.

2. In section 3.1:
The O-bit has dependency on I-D.ietf-6man-spring-srv6-oam. IMO, this cannot pass the LC before ietf-6man-spring-srv6-oam.
And is there any other flag?

3. There are several use of “A SRv6 SID” in the draft. I think it should be “An SRv6 SID”.

4. In section 8:
You introduced the SID Structure TLV only with the format. It seems interesting.
I would like to see more text on this. For example, what’s the usage, how to deal with it, what’s the fault process.

Thanks,
Tianran

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, November 3, 2020 12:29 AM
To: 'Acee Lindem (acee)' <acee=[email-masked]>; [email-masked]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Acee:

Sue

From: Idr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 2, 2020 7:58 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Sue, IDR WG,

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 1, 2020 at 10:26 PM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 3 Nov 2020 10:54:25 +0000

Hi Tianran,

Please check inline below.

From: Idr <[email-masked]> On Behalf Of Tianran Zhou
Sent: 03 November 2020 14:14
To: Susan Hares <[email-masked]>; 'Acee Lindem (acee)' <acee=[email-masked]>; [email-masked]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Authors,

1. In the introduction:

[KT] RFC8402 says “A segment is often referred to by its Segment Identifier (SID).” – I will update to use similar text.

2. In section 3.1:
The O-bit has dependency on I-D.ietf-6man-spring-srv6-oam. IMO, this cannot pass the LC before ietf-6man-spring-srv6-oam.
[KT] FYI - draft-ietf-6man-spring-srv6-oam has completed WGLC in 6man WG and is awaiting shepherd write-up. There is no such dependency.

And is there any other flag?
[KT] No other at this time.

[KT] Ack – will fix.

4. In section 8:
You introduced the SID Structure TLV only with the format. It seems interesting.
I would like to see more text on this. For example, what’s the usage, how to deal with it, what’s the fault process.
[KT] The usage of this BGP-LS extension like the base BGP-LS spec and all other extensions is to provide (rather convey) topology information from the IGP to various applications like PCE or controllers. What and how those applications use the information for is outside the scope of BGP-LS. Also note that BGP-LS does not perform semantic validation of its TLVs. Please check https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-05#section-7.2.2 for further details.

Thanks,
Ketan

Thanks,
Tianran

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, November 3, 2020 12:29 AM
To: 'Acee Lindem (acee)' <acee=[email-masked]<mailto:acee=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Acee:

Sue

Hi Sue, IDR WG,

Cheers, Susan Hares

---

From: <[email-masked]>
Date: Tue, 3 Nov 2020 11:03:12 +0000

Hi Sue, WG

I’m not aware of non-disclosed IPR.
I support progressing this document.

--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 5:29 PM
To: 'Acee Lindem (acee)' <acee=[email-masked]>; [email-masked]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Acee:

Sue

Hi Sue, IDR WG,

Cheers, Susan Hares

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 3 Nov 2020 12:43:10 +0000

Hi Sue, All,

Support for publication.

See inline: GV>

GV> no comments

b) Will SRv6 provide valuable support for
deployments of BGP-LS in support of source routing
(aka spring)?
GV> no comments (This is an odd question)

c) Is this draft ready for publication?
GV> yes, ready for publication and the draft can implemented in code

G/

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 04:25
To: [email-masked]
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Clarence Filsfils (cfilsfil)" <[email-masked]>
Date: Tue, 3 Nov 2020 17:06:56 +0000

I am not aware of any IPR other than the one already declared on this draft.

Cheers,
Clarence

Cheers, Susan Hares

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 3 Nov 2020 21:28:45 +0000

Support.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Sunday, November 1, 2020 7:25 PM
To: [email-masked]
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 5 Nov 2020 10:23:21 +0000

Yes, support with comments and questions.

1.       Q: Last time we discussed that do we need to carry SRv6 Endpoint behavior TLV for END.X SID, I think the answer is no. This TLV is used for SRv6 SID NLRI only, correct? Just to double check.

2.       Q: if we meet an error in BGP-LS, do we have any error handling? Like in PCEP, we need to check the sum of lengths each part of SRv6 SID, if the length is larger than 128 bits, this is an error. But I don't see the error handling in BGP-LS extensions.  It may be good to add  some text of usage, processing and handling of TLVs. Current revision seems a little bit simple to me.

Yes.

Yes.

With comments.

Cheng

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 5 Nov 2020 11:04:32 +0000

Hi Cheng,

From: Idr <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: 05 November 2020 15:53
To: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

  1.  Q: Last time we discussed that do we need to carry SRv6 Endpoint behavior TLV for END.X SID, I think the answer is no. This TLV is used for SRv6 SID NLRI only, correct? Just to double check.
[KT] Yes, you are correct. The draft does say it is for SRv6 SID NLRI : https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-04#section-7.1

  1.  Q: if we meet an error in BGP-LS, do we have any error handling? Like in PCEP, we need to check the sum of lengths each part of SRv6 SID, if the length is larger than 128 bits, this is an error. But I don't see the error handling in BGP-LS extensions.  It may be good to add  some text of usage, processing and handling of TLVs. Current revision seems a little bit simple to me.
[KT] We do not perform semantic validation of TLVs in BGP-LS. Please see my response to another similar comment here : https://mailarchive.ietf.org/arch/msg/idr/CNcjA-nBd7IvUTKgllqdIu0mXEk/

Thanks,
Ketan

Yes.

Yes.

With comments.

Cheng

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 11:25 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 6 Nov 2020 02:03:50 +0000

Hi Ketan,

Many thanks for your reply. It addresses my comments.

Thanks,
Cheng

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Thursday, November 5, 2020 7:05 PM
To: Chengli (Cheng Li) <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Cheng,

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Chengli (Cheng Li)
Sent: 05 November 2020 15:53
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Thanks,
Ketan

Yes.

Yes.

With comments.

Cheng

Cheers, Susan Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 6 Nov 2020 02:50:03 +0000

Hi,

Yes, support with one question for clarification:

For SRv6 EPE, the Peer adjacency SID is advertised using SRv6 End.X SID TLV with BGP-LS Link NLRI, and this document says:

"The SRv6 End.X SID for the BGP Peer Adjacency indicates the cross-connect to a specific layer-3 link to the specific BGP session peer (neighbor)."

For the SRv6 EPE Peer Node SID, this document says:

"... the similar Peer Node and Peer Set functionality can be realized with SRv6 using the END.X behavior. The SRv6 BGP Peer Node SID TLV is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI corresponding to BGP protocol."

My question is: for a BGP peer established using direct interface address, does this require both a peer adj-SID with BGP-LS Link NLRI and a peer node SID in SRv6 SID NLRI be advertised?  While with the mechanism of SR-MPLS EPE, my understanding is in this case advertising only the peer node SID would be enough, the peer adj-SID is optional and may be used for a multi-hop session with multiple underlying layer-3 links.

Best regards,
Jie

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 6 Nov 2020 03:54:43 +0000

Hi Jie,

From: Idr <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: 06 November 2020 08:20
To: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi,

My question is: for a BGP peer established using direct interface address, does this require both a peer adj-SID with BGP-LS Link NLRI and a peer node SID in SRv6 SID NLRI be advertised?
[KT] Yes.

 While with the mechanism of SR-MPLS EPE, my understanding is in this case advertising only the peer node SID would be enough, the peer adj-SID is optional and may be used for a multi-hop session with multiple underlying layer-3 links.
[KT] The SR-MPLS BGP EPE specification does not mandate the advertisement of any SID. It simply describes how to advertise them. In that sense, all of them are optional and the use-case/application determines which ones are required. It is the same in case of SRv6 BGP EPE. The differences between the two are the following:

  *   In case of SR-MPLS, both Adjacency and Node SIDs are advertised using their own separate/different BGP-LS Link NLRIs - this happens because their link descriptors are different. Please check sec 4.1 and 4.2.
  *   In case of SRv6, it is also advertised via different NLRIs - the Adjacency SID using the Link NLRI since it represents a topological link similar to IGPs. And the Node SID using the SRv6 SID NLRI since it does not represent a topological link but instead a peering session (that may go over one or more topological links or in some cases with multi-hop multiple nodes).
Hope that clarifies.

Thanks,
Ketan

Best regards,
Jie

Cheers, Susan Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 6 Nov 2020 10:02:34 +0000

Hi Ketan,

Thanks for your clarification. Please find some further replies inline:

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Friday, November 6, 2020 11:55 AM
To: Dongjie (Jimmy) <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Jie,

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: 06 November 2020 08:20
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi,

 While with the mechanism of SR-MPLS EPE, my understanding is in this case advertising only the peer node SID would be enough, the peer adj-SID is optional and may be used for a multi-hop session with multiple underlying layer-3 links.
[KT] The SR-MPLS BGP EPE specification does not mandate the advertisement of any SID. It simply describes how to advertise them. In that sense, all of them are optional and the use-case/application determines which ones are required.

[Jie] Please find the below text quoted from draft-ietf-idr-bgpls-segment-routing-epe, in which the peer node SID MUST be instantiated, while the peer Adj SID and peer Set SID MAY be instantiated.

" The following BGP Peering SIDs need to be instantiated on a BGP
   router for each of its BGP peer sessions that are enabled for Egress
   Peer Engineering:

   o  One PeerNode SID MUST be instantiated to describe the BGP peer
      session.

   o  One or more PeerAdj SID MAY be instantiated corresponding to the
      underlying link(s) to the directly connected BGP peer session.

   o  A PeerSet SID MAY be instantiated and additionally associated and
      shared between one or more PeerNode SIDs or PeerAdj SIDs."

It is the same in case of SRv6 BGP EPE. The differences between the two are the following:
-          In case of SR-MPLS, both Adjacency and Node SIDs are advertised using their own separate/different BGP-LS Link NLRIs - this happens because their link descriptors are different. Please check sec 4.1 and 4.2.

[Jie] Based on the above text and the text in section 4.1, in case of SR-MPLS, the peer node SID and the associated link NLRI can provide the information about the BGP peer and the layer-3 link, thus still I'm not sure the peer adjacency SID with an additional link NLRI is needed. I agree their link descriptors are different, but in this case both link NLRIs are used to advertise the attributes of the same link.

-          In case of SRv6, it is also advertised via different NLRIs - the Adjacency SID using the Link NLRI since it represents a topological link similar to IGPs. And the Node SID using the SRv6 SID NLRI since it does not represent a topological link but instead a peering session (that may go over one or more topological links or in some cases with multi-hop multiple nodes).

[Jie] In my view the difference in SR-MPLS and SRv6 is due to the different treatment of the peer node SID and the peer adjacency SID. With SR-MPLS, the peer node SID and its link NLRI represents a topological inter-domain "link" or connectivity in BGP, and the peer adj-SID can be used to further describe the underlying layer-3 links when needed (e.g. multiple L3 links used for a BGP session on loopback addresses). While with SRv6, the peer adjacency SID is used to represent each inter-domain layer-3 link, and peer node SID is not used as topological information any more.

Both approaches could work in this case, while one concern is do we need to keep the capability of describing an inter-domain "link" at BGP level?

Best regards,
Jie

Hope that clarifies.

Thanks,
Ketan

Best regards,
Jie

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 7 Nov 2020 15:19:53 +0000

Hi Jie,

From: Dongjie (Jimmy) <[email-masked]>
Sent: 06 November 2020 15:33
To: Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Subject: RE: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Friday, November 6, 2020 11:55 AM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Jie,

Hi,

[KT2] I stand corrected.

[Jie] Based on the above text and the text in section 4.1, in case of SR-MPLS, the peer node SID and the associated link NLRI can provide the information about the BGP peer and the layer-3 link, thus still I'm not sure the peer adjacency SID with an additional link NLRI is needed. I agree their link descriptors are different, but in this case both link NLRIs are used to advertise the attributes of the same link.
[KT2] Yes, in that specific case, you are correct. However, that is not a generic statement. Please check https://tools.ietf.org/html/rfc8402#section-4.2 - the "interface/link" semantics are associated with the Peer Adjacency SID and not the Peer Node SID (very similar to IGP Node SID and IGP Adjacency SID).

[Jie] In my view the difference in SR-MPLS and SRv6 is due to the different treatment of the peer node SID and the peer adjacency SID.
[KT2] Yes. This is more clearly aligned with RFC8402.
With SR-MPLS, the peer node SID and its link NLRI represents a topological inter-domain "link" or connectivity in BGP, and the peer adj-SID can be used to further describe the underlying layer-3 links when needed (e.g. multiple L3 links used for a BGP session on loopback addresses). While with SRv6, the peer adjacency SID is used to represent each inter-domain layer-3 link, and peer node SID is not used as topological information any more.
[KT2] Please see my previous comment with references from RFC8402 where the BGP peering segments are defined.

Both approaches could work in this case, while one concern is do we need to keep the capability of describing an inter-domain "link" at BGP level?
[KT2] I am not sure that I understand. Can you please clarify?

Thanks,
Ketan

Best regards,
Jie

Hope that clarifies.

Thanks,
Ketan

Best regards,
Jie

Cheers, Susan Hares

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 10 Nov 2020 15:30:35 +0530

Hi Sue, WG,

The SRv6 work for BGP-LS is important and I support its publication. I
do have some comments which I hope will improve the I-D:

Major
- Regarding the various flag fields in the I-D. Should we redefine
them here or refer to the IGP documents? I see they match with
draft-ietf-lsr-isis-srv6-extensions. For the SR-MPLS draft (in
draft-ietf-idr-bgp-ls-segment-routing-ext) the approach was to use a
reference to the ISIS draft.

Minor
- Section 2, use of normative SHALL for the restatting the text coming
from RFC 7752 is incorrect.
- Section 2, add reference for "MSD types introduced for SRv6" in this
section (on first use).
- Section 2 provides a good summary; for ease of reader, can you add a
forward reference to sections where each of the TLV is defined in this
I-D?
- Section 2, 2nd last paragraph, should this be normative regarding
the different behaviour for underlying IGP and BGP-EPE?
- Section 4.1, need reference for IGP Algorithm Type registry
- Section 4.2, add the tag Neighbor ID in the figure as well to match the text
- Section 6, we should say Protocol-ID is from RFC 7752, of which the
following are applicable for SRV6.
- Section 10/11, is some text missing here? Section 10 says it is
structured as per RFC5706 and has nothing. Section 11 has Operational
Considerations saying nothing new here! Missing  Management
Considerations as per RFC 5706.
- For reserved fields we use a mix of MUST and SHOULD regarding
setting it to zero, better to use MUST in all instances.

Query
- What is the best practice for the term End.X: Expand to Layer-3
Cross-Connect on first use or put a reference to
draft-ietf-spring-srv6-network-programming? Or is it considered
well-known in the context to be used directly.
- Various MUST conditions in the draft, but no idea what happens when
they are not met. Is this the legacy issue with RFC7752 and we need to
wait for the RFC7752bis?

Nits
- s/Segment Routing IPv6 (SRv6)/Segment Routing over IPv6 (SRv6)/
- Expand SR, NLRI, MSD, DR, DIS, on first use.

Thanks!
Dhruv

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 10 Nov 2020 11:25:08 +0000

Hi Dhruv,

Thanks for your thorough review and feedback/comments. Please check inline below.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 10 November 2020 15:31
To: Susan Hares <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Sue, WG,

The SRv6 work for BGP-LS is important and I support its publication. I do have some comments which I hope will improve the I-D:

Major
- Regarding the various flag fields in the I-D. Should we redefine them here or refer to the IGP documents? I see they match with draft-ietf-lsr-isis-srv6-extensions. For the SR-MPLS draft (in
draft-ietf-idr-bgp-ls-segment-routing-ext) the approach was to use a reference to the ISIS draft.
[KT] The base RFC7752 has had the odd convention of providing reference to ISIS specifications for TLVs even though the information was applicable to both IGPs. The draft-ietf-idr-bgp-ls-segment-routing-ext points to the respective ISIS, OSPFv2 and OSPFv3 specs for the flags field - it does not point alone to ISIS drafts. Traditionally, there have been minor variations between the IGPs causing the flags to be different for each IGPs in BGP-LS. We've received feedback from the consumer applications of BGP-LS information to abstract and provide a consistent data across IGPs (where possible). That is the reason why the flags are being defined in the BGP-LS specifications here. If we look at RFC7752, we've had a union of flags for TLVs like Node Flags Bits TLV and IGP Flags TLV.

Minor
- Section 2, use of normative SHALL for the restatting the text coming from RFC 7752 is incorrect.
[KT] Ack - will fix.

- Section 2, add reference for "MSD types introduced for SRv6" in this section (on first use).
[KT] Ack - will expand MSD.

- Section 2 provides a good summary; for ease of reader, can you add a forward reference to sections where each of the TLV is defined in this I-D?
[KT] This will result in each line of this summary pointing to at least one or two (if not more) forward references and IMHO will affect readability. The section headings themselves are organized based on the summary and so are forward references really necessary?

- Section 2, 2nd last paragraph, should this be normative regarding the different behaviour for underlying IGP and BGP-EPE?
[KT] I am not sure that I understand. Could you please clarify exactly what normative text is required here?

- Section 4.1, need reference for IGP Algorithm Type registry
[KT] The text already points to the IANA IGP Algorithm Type registry where there are references for the spec that is introducing the new algorithm types.

[KT] Ack

- Section 6, we should say Protocol-ID is from RFC 7752, of which the following are applicable for SRV6.
[KT] RFC7752 does not introduce BGP - it was introduced by the BGP EPE draft. So perhaps we can just refer to the IANA registry for Protocol IDs instead and remove the list from this section in the draft?

- Section 10/11, is some text missing here? Section 10 says it is structured as per RFC5706 and has nothing. Section 11 has Operational Considerations saying nothing new here! Missing  Management Considerations as per RFC 5706.
[KT] Ack - Section 10 and 11 should be removed since these aspects are derived from the base RFC7752. 

- For reserved fields we use a mix of MUST and SHOULD regarding setting it to zero, better to use MUST in all instances.
[KT] Ack - will fix this.

Query
- What is the best practice for the term End.X: Expand to Layer-3 Cross-Connect on first use or put a reference to draft-ietf-spring-srv6-network-programming? Or is it considered well-known in the context to be used directly.
[KT] While it is well-known in the context, I think you are right that a reference to draft-ietf-spring-srv6-network-programming would be good to have. 

- Various MUST conditions in the draft, but no idea what happens when they are not met. Is this the legacy issue with RFC7752 and we need to wait for the RFC7752bis?
[KT] Ack - the fault management clarifications are being introduced in RFC7752bis. In brief, BGP-LS does not perform semantic validation of the TLVs' contents.

Nits
- s/Segment Routing IPv6 (SRv6)/Segment Routing over IPv6 (SRv6)/
- Expand SR, NLRI, MSD, DR, DIS, on first use.
[KT] Ack - will fix this.

Thanks,
Ketan

Thanks!
Dhruv

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 10 Nov 2020 11:45:15 +0000

Hi Dhruv,

On your comment below:

I meant to say that Management Considerations section needs to be updated/fixed and the Operational Consideration section is not required since it inherits from the base BGP-LS spec.

I will post the update once the submission window re-opens.

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: 10 November 2020 16:55
To: Dhruv Dhody <[email-masked]>; Susan Hares <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: RE: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Dhruv,

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 10 November 2020 15:31
To: Susan Hares <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Sue, WG,

Major

Minor

- Section 4.1, need reference for IGP Algorithm Type registry [KT] The text already points to the IANA IGP Algorithm Type registry where there are references for the spec that is introducing the new algorithm types.

- Section 4.2, add the tag Neighbor ID in the figure as well to match the text [KT] Ack

Query

Nits

Thanks,
Ketan

Thanks!
Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 10 Nov 2020 19:20:41 +0530

Hi Ketan,

Thanks for a quick reply and taking my comments into consideration.

> [KT] The base RFC7752 has had the odd convention of providing reference to ISIS specifications for TLVs even though the information was applicable to both IGPs. The draft-ietf-idr-bgp-ls-segment-ro…

Few Observations -
- My main concern is to avoid re-definition and duplication; if you
don't want to point to the flag fields as done in
draft-ietf-idr-bgp-ls-segment-routing-ext, you can still point to the
meaning of each of the flags where they were originally defined
(unless there is any change in the context of BGP).
- BTW are you making a change in RFC7752bis to handle this concern? Is
it right to do this only for SRv6?

<snip>

> [KT] This will result in each line of this summary pointing to at least one or two (if not more) forward references and IMHO will affect readability. The section headings themselves are organized b…

The new RFC v3 format makes a pretty HTML rendering. Having a
forwarding reference allows a reader to use the reference links to
jump directly without looking at the ToC. IMHO it is useful, the
readability is a concern perhaps in plain text, but even there section
numbers help rather than looking for section headings.

> [KT] I am not sure that I understand. Could you please clarify exactly what normative text is required here?

I meant, think of using RFC2119 keywords - MUST/SHOULD etc.

> [KT] The text already points to the IANA IGP Algorithm Type registry where there are references for the spec that is introducing the new algorithm types.

A reference to RFC8665 is useful, as that is the place where this
registry is created.

> [KT] RFC7752 does not introduce BGP - it was introduced by the BGP EPE draft. So perhaps we can just refer to the IANA registry for Protocol IDs instead and remove the list from this section in the…

You can say something like -> the Protocol-ID registry was created by
[RFC7752] and then extended by other BGP-LS extensions. The following
values are valid in SRv6 -

<snip>

> [KT] Ack - the fault management clarifications are being introduced in RFC7752bis. In brief, BGP-LS does not perform semantic validation of the TLVs' contents.

Worth adding some text, I am sure directorate/AD reviews might have
the same concern.

Thanks!
Dhruv

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 11 Nov 2020 03:14:49 +0000

Hi Dhruv,

Please check inline below [KT2].

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: 10 November 2020 19:21
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Susan Hares <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

On Tue, Nov 10, 2020 at 4:55 PM Ketan Talaulikar (ketant) <[email-masked]> wrote:
> Subject: Re: [Idr] IPR call and WG LC for 
> draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)
>
> Hi Sue, WG,
>

Few Observations -
- My main concern is to avoid re-definition and duplication; if you don't want to point to the flag fields as done in draft-ietf-idr-bgp-ls-segment-routing-ext, you can still point to the meaning of each of the flags where they were originally defined (unless there is any change in the context of BGP).
[KT2] The flags for SR-MPLS and SRv6 are different and likely evolve differently. We do not wish to link them up together in the encoding.

- BTW are you making a change in RFC7752bis to handle this concern? Is it right to do this only for SRv6?
[KT2] This is not about base BGP-LS spec and hence not a topic for the RFC7752bis.

<snip>

> [KT] This will result in each line of this summary pointing to at least one or two (if not more) forward references and IMHO will affect readability. The section headings themselves are organized b…

The new RFC v3 format makes a pretty HTML rendering. Having a forwarding reference allows a reader to use the reference links to jump directly without looking at the ToC. IMHO it is useful, the readability is a concern perhaps in plain text, but even there section numbers help rather than looking for section headings.
[KT2] Sure. I will add those forward references 😊

I meant, think of using RFC2119 keywords - MUST/SHOULD etc.
[KT2] This document is just adding new information - the procedures for advertising info from IGP and BGP-EPE have been normatively defined in the base RFC7752 and BGP-EPE drafts.

> - Section 4.1, need reference for IGP Algorithm Type registry [KT] The 
> text already points to the IANA IGP Algorithm Type registry where there are references for the spec that is introducing the new algorithm types.
>

A reference to RFC8665 is useful, as that is the place where this registry is created.
[KT2] The algorithm was defined in RFC8402. RFC8665 only defined the registry for it. Now with Flexible Algorithms and potentially others getting added down the line, the pointer to the registry seems to make more sense to me.

> [KT] RFC7752 does not introduce BGP - it was introduced by the BGP EPE draft. So perhaps we can just refer to the IANA registry for Protocol IDs instead and remove the list from this section in the…

You can say something like -> the Protocol-ID registry was created by [RFC7752] and then extended by other BGP-LS extensions. The following values are valid in SRv6 -
[KT2] Ack - will update that and remove the references to the list.

<snip>

> [KT] Ack - the fault management clarifications are being introduced in RFC7752bis. In brief, BGP-LS does not perform semantic validation of the TLVs' contents.

Worth adding some text, I am sure directorate/AD reviews might have the same concern.
[KT2] Agree. Will add that text.

Thanks,
Ketan

Thanks!
Dhruv

> > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20
> > im
> > plementations
> >
> >
> >

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 11 Nov 2020 09:21:49 +0530

Hi Ketan,

> [KT2] The flags for SR-MPLS and SRv6 are different and likely evolve differently. We do not wish to link them up together in the encoding.

I never asked that. I was looking at
draft-ietf-idr-bgp-ls-segment-routing-ext as an example of how the
flags fields are described by pointing to the IGP documents. Further I
said that if you don't want to do that, then list the flags but for
the description/meaning of these flags point to the IGP documents.

This is a general practice we use to make sure there is a single
source of truth and avoid making mistakes in cut-copy-paste, further
if there is ever an errata or changes it is in a single place rather
than searching for the same text across our documents.

> [KT2] This is not about base BGP-LS spec and hence not a topic for the RFC7752bis.

Hmm, in your reply you said there is an issue with the convention in
RFC7752 and thus the question above. I am not asking for a change in
RFC7752bis but questioning the reasoning given by you.

Perhaps the guidance from the document shepherd would be the best
approach to make progress.

 <snip>

> [KT2] This document is just adding new information - the procedures for advertising info from IGP and BGP-EPE have been normatively defined in the base RFC7752 and BGP-EPE drafts.

Your current text is -

   When the BGP-LS router is advertising topology information that it
   sources from the underlying link-state routing protocol, 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 the BGP-LS router is advertising topology information from the
   BGP routing protocol [I-D.ietf-idr-bgpls-segment-routing-epe], then
   it advertises the SRv6 information from the local node alone (e.g.
   BGP EPE topology information or in the case of a data center network
   running BGP as the only routing protocol).

In my reading, the two "when" statements look like providing
conditions on when to apply the underlying procedure. If this is not
new information, perhaps rephrase them to say "As specified in
[REF],..."?

> [KT2] The algorithm was defined in RFC8402. RFC8665 only defined the registry for it. Now with Flexible Algorithms and potentially others getting added down the line, the pointer to the registry se…

The current text is -

Algorithm values are defined in the IGP Algorithm Type registry.

I find this lacking. Just mentioning the name of the registry with no
reference is not right, especially when the registry is not created in
this document (or in any IDR document). I find that the RFC that
created the registry is the easiest reference and that would be
RFC8665.
The use of RFC8402 reference would make sense if you add some
description to the meaning of the algorithm!

Thanks!
Dhruv

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 11 Nov 2020 09:20:30 +0000

Hi Dhruv,

Please check inline below [KT3]

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: 11 November 2020 09:22
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Susan Hares <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

I never asked that. I was looking at
draft-ietf-idr-bgp-ls-segment-routing-ext as an example of how the flags fields are described by pointing to the IGP documents. Further I said that if you don't want to do that, then list the flags but for the description/meaning of these flags point to the IGP documents.

This is a general practice we use to make sure there is a single source of truth and avoid making mistakes in cut-copy-paste, further if there is ever an errata or changes it is in a single place rather than searching for the same text across our documents.
[KT3] These flags are defined for BGP-LS encoding. I don't see the issue you describe. 

Hmm, in your reply you said there is an issue with the convention in
RFC7752 and thus the question above. I am not asking for a change in RFC7752bis but questioning the reasoning given by you.

Perhaps the guidance from the document shepherd would be the best approach to make progress.
[KT3] I am not sure that I understand your point here. Are you asking for changing the protocol encodings during this WGLC? 

 <snip>

Your current text is -

In my reading, the two "when" statements look like providing conditions on when to apply the underlying procedure. If this is not new information, perhaps rephrase them to say "As specified in [REF],..."?
[KT3] The first statement is base BGP-LS RFC7752. The second one already has the reference to the BGP-LS EPE.

> > - Section 4.1, need reference for IGP Algorithm Type registry [KT] 
> > The text already points to the IANA IGP Algorithm Type registry where there are references for the spec that is introducing the new algorithm types.
> >
>

The current text is -

I find this lacking. Just mentioning the name of the registry with no reference is not right, especially when the registry is not created in this document (or in any IDR document). I find that the RFC that created the registry is the easiest reference and that would be RFC8665.
[KT3] I disagree - it makes no sense to put a reference to OSPFv2 SR-MPLS extensions spec in here.
 
The use of RFC8402 reference would make sense if you add some description to the meaning of the algorithm!
[KT3] OK. Will not add that reference since it does not make sense to describe all the current algorithms in this document.

Thanks,
Ketan 

Thanks!
Dhruv

> [RFC7752] and then extended by other BGP-LS extensions. The following values are valid in SRv6 - [KT2] Ack - will update that and remove the references to the list.
>
> <snip>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 11 Nov 2020 15:09:15 +0530

Hi Ketan,

Maybe we are not understanding each other. At this stage instead of
repeating myself and going in circles I would let the document
shepherd take the call for an issue that is editorial in nature.

Thanks!
Dhruv

---

From: "Richard Vallee (rvallee)" <[email-masked]>
Date: Wed, 11 Nov 2020 13:53:28 +0000

My answer is yes for questions a), b), c) below.

I support https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/ for WG LC adoption.

Thanks
Richard

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Sunday, November 1, 2020 at 10:25 PM
To: "[email-masked]" <[email-masked]>
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Nov 2020 20:02:43 +0000

Hi,

I believe this document is ready to move forward.
As per your question a) on SRv6 status, note that there has been a significant number of deployments. (draft-matsushima-spring-srv6-deployment-status-08)
Also I would like to note that there is an additional opensource implementation of this document, GoBMP, which does not seem to be listed in the wiki. (https://github.com/sbezverk/gobmp)

Thank you,
Pablo.

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: lunes, 2 de noviembre de 2020 4:25
To: [email-masked]
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 12 Nov 2020 16:44:21 -0500

Pablo: 

Would you mind updating the wiki with the information on GoBMP? 

You can use a datatracker ID to sign into the IDR wiki. 

If you have any trouble, please send me the link to information on GoBMP.

Thank you, Susan Hares 

From: Pablo Camarillo (pcamaril) [mailto:[email-masked]] 
Sent: Wednesday, November 11, 2020 3:03 PM
To: Susan Hares; [email-masked]
Subject: RE: [Idr] IPR call and WG LC for
draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi,

As per your question a) on SRv6 status, note that there has been a
significant number of deployments.
(draft-matsushima-spring-srv6-deployment-status-08)

Also I would like to note that there is an additional opensource
implementation of this document, GoBMP, which does not seem to be listed in
the wiki. (https://github.com/sbezverk/gobmp)

Thank you,

Pablo.

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: lunes, 2 de noviembre de 2020 4:25
To: [email-masked]
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt
(11/1/2020 to 11/16/2020)

 <https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/>
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/

<https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20impleme
ntations>
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implemen
tations

are there known issues? 

(aka spring)? 

respond to this email. 

Cheers, Susan Hares

---

From: "Krishna Muddenahally Ananthamurthy (kriswamy)" <[email-masked]>
Date: Fri, 13 Nov 2020 01:23:24 +0000

Support.

Thanks
Krishna

From: Idr <[email-masked]>
Date: Monday, November 2, 2020 at 8:30 AM
To: 'Acee Lindem (acee)' <acee=[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)
Acee:

Sue

Hi Sue, IDR WG,

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 13 Nov 2020 09:44:48 +0000

Thanks Pablo for updating the GoBMP support in the implementation report.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: 13 November 2020 03:14
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Pablo:

Thank you, Susan Hares

Hi,

Thank you,
Pablo.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: lunes, 2 de noviembre de 2020 4:25
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 15 Nov 2020 07:45:10 +0000

Hi Dhruv,

Once again, thanks for your thorough review and comments as also your clarifications. Based on our discussions, the draft has been updated (also including some nits and editorial changes pointed by others).

https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-05

Thanks,
Ketan

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: 11 November 2020 15:09
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Susan Hares <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

Maybe we are not understanding each other. At this stage instead of repeating myself and going in circles I would let the document shepherd take the call for an issue that is editorial in nature.

Thanks!
Dhruv

On Wed, Nov 11, 2020 at 2:50 PM Ketan Talaulikar (ketant) <[email-masked]> wrote:
> > You can say something like -> the Protocol-ID registry was created 
> > by [RFC7752] and then extended by other BGP-LS extensions. The following values are valid in SRv6 - [KT2] Ack - will update that and remove the references to the list.
> >
> > <snip>
> >
> > > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ex
> > > > t%
> > > > 20
> > > > im
> > > > plementations
> > > >
> > > >
> > > >

---

From: "Bernier, Daniel" <[email-masked]>
Date: Mon, 16 Nov 2020 13:37:19 +0000

I support  and an I am not aware of any IPRs

Dan B
Bell Canada

Cheers, Susan Hares

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 16 Nov 2020 16:56:58 +0000

Hi,

I have read the draft and supports the WGLC.

Thanks

Regards … Zafar

Cheers, Susan Hares