Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

From: "John G. Scudder" <[email-masked]>
Date: Fri, 6 Apr 2018 14:17:20 -0400

Hi Authors (and WG),

Jeff raised two points during the WGLC:

> On Mar 15, 2018, at 7:07 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Minor comments as part of a re-read while waiting on my plane:
> RESERVED is not called out in its behavior.  Some place in the document
> should mention the usual "MUST be set to zero on send, SHOULD be ignored on
> receipt".  Otherwise, it's gibberish in, who knows what out when someone
> tries to use this field in the future.

I didn't see this one addressed. Authors, do you plan to update the draft to address the point? I didn't see any other points raised during the WGLC that would require an update.

> There are a number of TLV value fields that may be of variable lengths.  In
> many cases, those lengths are inherited from the underlying IGP documents.
> What is not documented is the behavior when the TLV is well formed but has
> unexpected length values.  Two simple examples:
> - Prefix Attribute Flag TLV; varies by IGP
> - Preference TLV; must be 1.
> 
> Do we treat this as malformed?  Do we ignore the sub-tlv?

This point was discussed between Jeff and Ketan on the list. It seems to me that it does bear further discussion, but that the issue doesn't need to be fixed in this draft nor to be blocking on the conclusion of the WGLC. Assuming the WG feels we should do better, the most obvious thing IMO would be a document that updates RFC 7752.

Finally, authors and contributors, we forgot to ask for the usual IPR declaration as part of the WGLC. If you could please take care of letting us know whether or not you are aware of any relevant IPR that has not been declared, that would help conclude the WGLC. (Right now there is no IPR declared, https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-idr-bgp-ls-segment-routing-ext)

Thanks,

--John

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 7 Apr 2018 09:36:51 +0000

Hi John,

I did respond and acknowledge the first point raised by Jeff below and I am waiting to hear about any other comments before publishing that update. I will now publish this update early next week.

On the second point, I agree that the point raise should be addressed by a separate document that updates RFC7752 and I will get back to the WG on this.

With regards to the IPR call, as a co-author, I am not aware of any IPR for this draft.

Thanks,
Ketan

From: John G. Scudder <[email-masked]>
Sent: 06 April 2018 23:47
To: [email-masked]
Cc: Hares Susan <[email-masked]>; idr wg <[email-masked]>; Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi Authors (and WG),

On Mar 15, 2018, at 7:07 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

--John

---

From: stefano previdi <[email-masked]>
Date: Mon, 9 Apr 2018 09:34:22 +0200

Hi John,

I’m not aware of any undisclosed IPR related to this draft.

Thanks.
s.

> On Apr 6, 2018, at 8:17 PM, John G. Scudder <[email-masked]> wrote:
> 
> Hi Authors (and WG),
>

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Apr 2018 14:21:29 +0200

hi john,

i am not aware of any undisclosed IPR.

thanks,

/hannes

> On 06.04.2018, at 20:17, John G. Scudder <[email-masked]> wrote:
> 
> Hi Authors (and WG),
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 10 Apr 2018 09:56:48 +0000

Hi John/All,

I've updated the 05 version of this draft which addresses Jeff's comment about the reserved field.

Thanks,
Ketan

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/

There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-05

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-05

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-ext-05

From: Ketan Talaulikar (ketant)
Sent: 07 April 2018 15:07
To: 'John G. Scudder' <[email-masked]>; [email-masked]
Cc: Hares Susan <[email-masked]>; idr wg <[email-masked]>; Jeffrey Haas <[email-masked]>
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi John,

Thanks,
Ketan

From: John G. Scudder <[email-masked]<mailto:[email-masked]>>
Sent: 06 April 2018 23:47
To: [email-masked]<mailto:[email-masked]>
Cc: Hares Susan <[email-masked]<mailto:[email-masked]>>; idr wg <[email-masked]<mailto:[email-masked]>>; Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi Authors (and WG),

Thanks,

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Apr 2018 10:22:25 -0400

> I've updated the 05 version of this draft which addresses Jeff's comment about the reserved field.

This addresses my comment. Thanks.

--  Jeff

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 11 Apr 2018 11:20:14 +0800

Hi, Susan and Authors of this draft:

Sorry to reply this LC so late.  The followings are my suggestions to this
draft based on the discussion related to the mail thread
https://mailarchive.ietf.org/arch/msg/idr/vSeflAMCMPL25N4nBOZu8yG19HA

Is it too late to response?  Please see the reply below in line.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Susan Hares [mailto:[email-masked]] 
发送时间: 2018年3月8日 0:41
收件人: 'idr wg'
主题: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7
to March 21)

This begins a 2 week WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04.
txt from March 7th to March 21.  During your discussion in the WG LC, please
indicate the following things: 

1)      Do you think BGP should carry these link state information regarding
segment routing, 

“Source Router Identifier (Source Router-ID) TLV” should be stripped off
this draft, because there are other situations(more general scenarios
besides SR) that requires the source router of the prefixes, as described in
https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/
and discussed in mail thread
https://mailarchive.ietf.org/arch/msg/idr/-T7U1yg8DmSdDmtyfqBgtnkO4I0

2)      Are there any technical issues with this draft? 

Some clarifications should be added in the following sections:

a) Regarding the usage of SID/Label sub-TLV:

“2.1.2 SR-Capabilities TLV”, “2.1.4 SR Local Block TLV” requires all the
presence of “SID/Label sub-TLV”.  It is more clear to indicate  this
“SID/Label sub-TLV” represent the base of the “Range Size”. 

b) Regarding the inconsistence definition among “ISIS/OSPF/OSPFv3/BGP-LS”
:

    “2.2.1 Adjacency SID”, “2.2.2 LAN Adjacency SID TLV”,”2.3.1
Prefix-SID TLV”

Note for “Length” field:   2-bytes “Reserved” filed should be added when
copying the corresponding fields from IS-IS protocol 

                c) Regarding the definition “Range TLV”:

                    if the “Length” filed is 4, how to detect the
existence of “sub-TLV?” 

                    Is it more clear to rename the “Range TLV” as
“Mapping-Range TLV”, so as to distinguish it from the previous “Range
filed” in  “2.1.2 SR-Capabilities TLV”?

                d) Regarding  the contents for “3. Procedures”:

                   Suggest to delete this section, because:

-------Contents in section 3.1, 3.2 has been mentioned in corresponding TLV
definition(section 2.3.1), there is no more new information in this section.

-------Contents in  section 3.3 and 3.4 should be merged with section 2.3.4
to eliminate the inconsistence arose in future when update parts of them.

3)      Is this draft is ready for publication? 

If the above issued is solved, it is ready for publication.

For your quick access to this draft, click on the link below: 

 

Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 11 Apr 2018 09:59:10 +0000

Hi Aijun,

Please check inline below in your email for responses. Do let me know if this addresses your comments and I will post the updates accordingly.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Aijun Wang
Sent: 11 April 2018 08:50
To: 'Susan Hares' <[email-masked]>; 'idr wg' <[email-masked]>
Subject: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Sorry to reply this LC so late.  The followings are my suggestions to this draft based on the discussion related to the mail thread https://mailarchive.ietf.org/arch/msg/idr/vSeflAMCMPL25N4nBOZu8yG19HA
Is it too late to response?  Please see the reply below in line.

Best Regards.

Aijun Wang

发件人: Susan Hares [mailto:[email-masked]]
发送时间: 2018年3月8日 0:41
收件人: 'idr wg'
主题: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

This begins a 2 week WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04.txt from March 7th to March 21.  During your discussion in the WG LC, please indicate the following things:

1)     Do you think BGP should carry these link state information regarding segment routing,
“Source Router Identifier (Source Router-ID) TLV” should be stripped off this draft, because there are other situations(more general scenarios besides SR) that requires the source router of the prefixes, as described in https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/ and discussed in mail thread https://mailarchive.ietf.org/arch/msg/idr/-T7U1yg8DmSdDmtyfqBgtnkO4I0
[KT] You are right that Source Router-ID TLV is not SR specific. SR was one of the key use-cases where this was felt this was necessary especially in ISIS (see rfc7794). The authors of the BGP-LS SR draft felt it was necessary to introduce and cover it as part of this draft given the use-cases. It has been part of this draft since many years and even before it was adopted by the WG. It has implementations and deployments. I would say you are too late in bringing forward such a comment at this stage. With regards to the inter-AS draft, you have seen the responses on the WG mailer as well as at London and I do not have anything further to add.

Some clarifications should be added in the following sections:
a) Regarding the usage of SID/Label sub-TLV:
“2.1.2 SR-Capabilities TLV”, “2.1.4 SR Local Block TLV” requires all the presence of “SID/Label sub-TLV”.  It is more clear to indicate  this “SID/Label sub-TLV” represent the base of the “Range Size”.
[KT] How about instead of “SID/Label sub-TLV (as defined in Section 2.1.1).” we change it to “SID/Label sub-TLV (as defined in Section 2.1.1) which encodes the first label in the range.”? Would this help clarify?

b) Regarding the inconsistence definition among “ISIS/OSPF/OSPFv3/BGP-LS” :
    “2.2.1 Adjacency SID”, “2.2.2 LAN Adjacency SID TLV”,”2.3.1 Prefix-SID TLV”
Note for “Length” field:   2-bytes “Reserved” filed should be added when copying the corresponding fields from IS-IS protocol
[KT] Now about for Length, we say for Adj-SID & Prefix-SID – “Variable, 7 or 8 depending on Label or Index encoding of the SID” and for LAN-Adj-SID we say “Variable. For ISIS it would be 13 or 14 depending on Label or Index encoding of the SID. For OSPF it would be 11 or 12 depending on Label or Index encoding of the SID.”

                c) Regarding the definition “Range TLV”:
                    if the “Length” filed is 4, how to detect the existence of “sub-TLV?”
[KT] You are right. The length should be variable since we have sub-TLVs and also the Prefix SID sub-TLV SHOULD be present to indicate the first label of the Range. I will correct this.

                    Is it more clear to rename the “Range TLV” as “Mapping-Range TLV”, so as to distinguish it from the previous “Range filed” in  “2.1.2 SR-Capabilities TLV”?
[KT] I am not sure if we should make this name change at this stage. I don’t see the confusion between the two TLVs. However, if there is WG consensus to make this change then I would do so.

                d) Regarding  the contents for “3. Procedures”:
                   Suggest to delete this section, because:
-------Contents in section 3.1, 3.2 has been mentioned in corresponding TLV definition(section 2.3.1), there is no more new information in this section.
[KT] OK will do.

-------Contents in  section 3.3 and 3.4 should be merged with section 2.3.4 to eliminate the inconsistence arose in future when update parts of them.
[KT] Sure, I will update it in that way too since it will be all info in one place for the reader.

Susan Hares

---

From: Aijun Wang <[email-masked]>
Date: Wed, 11 Apr 2018 19:33:49 +0800

Hi, Ketan:
I think the revised version is more clear.

Regarding the Source Router Identifier (Source Router-ID) TLV”, I think stripped it from the current draft did not influence the implementation on the device. We just reorganize the reference for this TLV, put it into the most suitable document for BGP-LS extension.
This TLV is more relevant to the Inter-AS situation and should be extended to cover all IGP scenarios, not just for ISIS in current document.
If possible, I can invite the author of this draft to be the co-authors of the BGP-LS inter-as extension draft.

Except this point, I fully agree with you the updates.

> 在 2018年4月11日，17:59，Ketan Talaulikar (ketant) <[email-masked]> 写道：
> 
> Hi Aijun,
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 11 Apr 2018 11:59:40 +0000

Hi Aijun,

Many thanks for your review comments and helping their closure.

I do not agree, however, with your point about the Source Router-ID TLV. This draft does allow the TLV to be also used for OSPF. It is definitely not specific to Inter-AS situation – it is quite pervasive with multiple use-cases including SR use-cases (allows determination of the originator node for the SR Prefix SID in inter-level leaking with ISIS).

It does not make any sense to me to take this TLV (that is implemented and deployed) out of this draft which is close to being sent to IESG in order to put it in the Inter-AS draft which is an individual draft and has many questions raised about it in the WG. Such instabilities and uncertainties do affect implementation and deployment.

In any case, I will leave it to the WG and chairs as well to respond to your proposal.

I’ve posted the 06 version of the draft with all your other comments addressed.

Thanks,
Ketan

https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-06

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-06

https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-ext-06

From: Aijun Wang <[email-masked]>
Sent: 11 April 2018 17:04
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Susan Hares <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi, Ketan:

在 2018年4月11日，17:59，Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> 写道：
Hi Aijun,

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Aijun Wang
Sent: 11 April 2018 08:50
To: 'Susan Hares' <[email-masked]<mailto:[email-masked]>>; 'idr wg' <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Best Regards.

Aijun Wang

Susan Hares

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Apr 2018 12:03:58 +0000

Hi Aijun, Sue,

As you fully know, I don’t agree that you need to even use the Source Router-ID TLV for your use case as the Local Node Descriptors identify the IGP router advertising the prefix in the IGP domain. Furthermore, your use case is somewhat limited to the topology in figure 1 of your draft where you have a controller with visibility of multiple ASes but there is no BGP between those ASes.

Thanks,
Acee

From: Idr <[email-masked]> on behalf of Aijun Wang <[email-masked]>
Date: Wednesday, April 11, 2018 at 7:35 AM
To: "Ketan Talaulikar (ketant)" <[email-masked]>
Cc: IDR List <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi, Ketan:

Thanks,
Ketan

Best Regards.

Aijun Wang

b) Regarding the inconsistence definition among “ISIS/OSPF/OSPFv3/BGP-LS” :
    “2.2.1 Adjacency SID”, “2.2.2 LAN Adjacency SID TLV”,”2..3.1 Prefix-SID TLV”
Note for “Length” field:   2-bytes “Reserved” filed should be added when copying the corresponding fields from IS-IS protocol
[KT] Now about for Length, we say for Adj-SID & Prefix-SID – “Variable, 7 or 8 depending on Label or Index encoding of the SID” and for LAN-Adj-SID we say “Variable. For ISIS it would be 13 or 14 depending on Label or Index encoding of the SID. For OSPF it would be 11 or 12 depending on Label or Index encoding of the SID.”

Susan Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 12 Apr 2018 11:20:19 +0800

Hi, Acee:

I prefer to strip the ambiguous definition of “2.3.3.  Source Router Identifier (Source Router-ID) TLV” from the current draft. The reasons are the followings:

1)       It has no relation to the SR technology.

2)       The main use case for this TLV that defined in RFC7794 is for the IS-IS redistribute between different levels

3)       There is no semantic description for the OSPF protocol(although it say ” The Source Router-ID TLV may be used to carry the OSPF Router-ID of the prefix originator.”)

4)       As you have pointed out, the “local node descriptors” associated with “prefix descriptors” can be used to identify the IGP router advertising the prefix, is this overlap with the “2.3.3.  Source Router Identifier (Source Router-ID) TLV” definition(as the LC document states: “The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the  originator of the Prefix.  For IS-IS protocol this is as defined in  [RFC7794].  The Source Router-ID TLV may be used to carry the OSPF  Router-ID of the prefix originator.”)?

For inter-as scenarios, the process to get the inter-as topology is similar no matter whether there is BGP between those ASes or not, although normally the BGP will run between different AS.  

Best Regards.

Aijun Wang

发件人: Acee Lindem (acee) [mailto:[email-masked]] 
发送时间: 2018年4月11日 20:04
收件人: Aijun Wang; Ketan Talaulikar (ketant)
抄送: idr wg; Susan Hares
主题: Re: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi Aijun, Sue, 

Thanks,
Acee

Hi, Ketan: 

 

在 2018年4月11日，17:59，Ketan Talaulikar (ketant) < <mailto:[email-masked]> [email-masked]> 写道：

Hi Aijun,

Thanks,

Ketan

From: Idr < <mailto:[email-masked]> [email-masked]> On Behalf Of Aijun Wang
Sent: 11 April 2018 08:50
To: 'Susan Hares' < <mailto:[email-masked]> [email-masked]>; 'idr wg' < <mailto:[email-masked]> [email-masked]>
Subject: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Sorry to reply this LC so late.  The followings are my suggestions to this draft based on the discussion related to the mail thread  <https://mailarchive.ietf.org/arch/msg/idr/vSeflAMCMPL25N4nBOZu8yG19HA> https://mailarchive.ietf.org/arch/msg/idr/vSeflAMCMPL25N4nBOZu8yG19HA

Best Regards.

Aijun Wang

发件人: Susan Hares [ <mailto:[email-masked]> mailto:[email-masked]] 
发送时间: 2018年3月8日 0:41
收件人: 'idr wg'
主题: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

“Source Router Identifier (Source Router-ID) TLV” should be stripped off this draft, because there are other situations(more general scenarios besides SR) that requires the source router of the prefixes, as described in  <https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/> https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/ and discussed in mail thread  <https://mailarchive.ietf.org/arch/msg/idr/-T7U1yg8DmSdDmtyfqBgtnkO4I0> https://mailarchive.ietf.org/arch/msg/idr/-T7U1yg8DmSdDmtyfqBgtnkO4I0

[KT] OK will do.

 <https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/

Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Apr 2018 14:16:50 +0000

Hi Aijun,

Regarding your point (1), I would suggest that you read https://tools.ietf.org/html/rfc7794 - the very introduction mentions the SR use-case.

That should make it crystal clear of the applicability of Source Router-ID and Prefix Attribute Flag TLVs in Segment Routing.

Thanks,
Ketan

From: Aijun Wang <[email-masked]>
Sent: 12 April 2018 08:50
To: Acee Lindem (acee) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: 'idr wg' <[email-masked]>; 'Susan Hares' <[email-masked]>
Subject: 答复: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi, Acee:

Best Regards.

Aijun Wang

Hi Aijun, Sue,

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Aijun Wang <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 11, 2018 at 7:35 AM
To: "Ketan Talaulikar (ketant)" <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] 答复: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Hi, Ketan:

Thanks,
Ketan

Best Regards.

Aijun Wang

Susan Hares