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

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 Mar 2018 11:40:46 -0500

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, 

2)      Are there any technical issues with this draft? 

3)      Is this draft is ready for publication? 

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

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

Susan Hares

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Mar 2018 16:56:41 +0000

Unsurprisingly, as a contributor, I support this document and believe it is ready for publication.

Thanks,
Acee

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, March 7, 2018 at 11:41 AM
To: IDR List <[email-masked]>
Subject: [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,

Susan Hares

---

From: Gaurav Dawra <[email-masked]>
Date: Wed, 7 Mar 2018 09:35:11 -0800

Support 

Sent from my iPhone

> On Mar 7, 2018, at 8:40 AM, Susan Hares <[email-masked]> wrote:
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 07 Mar 2018 09:51:28 -0800

Support as contributor 

Cheers,

Jeff

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, March 7, 2018 at 08:41
To: 'idr wg' <[email-masked]>
Subject: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Do you think BGP should carry these link state information regarding segment routing, 
Are there any technical issues with this draft? 
Is this draft is ready for publication? 

 

Susan Hares

_______________________________________________ Idr mailing list [email-masked] https://www.ietf.org/mailman/listinfo/idr

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 7 Mar 2018 19:44:33 +0000

Hello,

Support as a co-author/contributor. This draft has implementations that are shipping for some time now. I believe it is ready for publication.

Thanks,
Ketan

From: Susan Hares [mailto:[email-masked]]
Sent: 07 March 2018 22:11
To: 'idr wg' <[email-masked]>
Cc: 'Alvaro Retana' <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Subject: WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Susan Hares

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 7 Mar 2018 20:56:14 +0000

Support

BGP-LS is a key element of routing deployments today - and Segment Routing is a technology which is deployed and adoption is increasing. It is therefore obvious that BGP should carry this information.

I have followed/reviewed this draft over its multiple revisions and I believe it is mature and ready for publication.

   Les

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, March 07, 2018 8:41 AM
To: 'idr wg' <[email-masked]>
Subject: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Susan Hares

---

From: stefano previdi <[email-masked]>
Date: Thu, 8 Mar 2018 08:01:59 +0100

> On Mar 7, 2018, at 5:40 PM, Susan Hares <[email-masked]> wrote:
> 

yes.

> 2)      Are there any technical issues with this draft? 

no.

> 3)      Is this draft is ready for publication? 

yes.

Thanks.
s.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Mar 2018 10:36:06 +0100

Hello Susan,

> ​1​
> )      Do you think BGP should carry these link state information
> regarding segment routing,
>
> ​If BGP already has been extended ​to carry link state information by RFC
7752 there is no question if it should be extended to also carry SR
information. The answer is clearly - Yes.

/* Said this IMHO RFC 7752 itself is a mistake on its own ... BGP is a
great p2mp transport of routing information and information discussed is
used primarily in p2p fashion. So allowing RFC 7752 to go forward just to
reuse BGP transport and sessions to carry link state information only delays
  us to work and widely deploy much proper alternative transport(s) for
those kind of information. */

> 2)      Are there any technical issues with this draft?
​Don't think so. ​

> 3)      Is this draft is ready for publication?
​Yes.

Cheers,
Robert.​

---

From: Tony Li <[email-masked]>
Date: Thu, 8 Mar 2018 08:09:33 -0800

What he said.

T

> On Mar 8, 2018, at 1:36 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hello Susan,
> 
> ​1​)      Do you think BGP should carry these link state information regarding segment routing,
> 
> ​If BGP already has been extended ​to carry link state information by RFC 7752 there is no question if it should be extended to also carry SR information. The answer is clearly - Yes. 
> 
> /* Said this IMHO RFC 7752 itself is a mistake on its own ... BGP is a great p2mp transport of routing information and information discussed is used primarily in p2p fashion. So allowing RFC 7752 to go forward just to reuse BGP transport and sessions to carry link state information only delays  us to work and widely deploy much proper alternative transport(s) for those kind of information. */
> 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
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 8 Mar 2018 18:18:10 +0000

Support.

--
Uma C.

Susan Hares

---

From: Mohan Nanduri <[email-masked]>
Date: Fri, 9 Mar 2018 16:15:20 -0500

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

-No

-Yes

Cheers,
-Mohan

---

From: "Dhanendra Jain (dhjain)" <[email-masked]>
Date: Sun, 11 Mar 2018 16:23:13 +0000

Support.

  1.  Do you think BGP should carry these link state information regarding segment routing
Yes.

  1.  Are there any technical issues with this draft?
Don’t think so.

  1.  Is this draft is ready for publication?
Yes.

Thanks,
Dhanendra.

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, March 7, 2018 at 8:41 AM
To: 'idr wg' <[email-masked]>
Subject: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

  1.  Do you think BGP should carry these link state information regarding segment routing,
  2.  Are there any technical issues with this draft?
  3.  Is this draft is ready for publication?

Susan Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 15 Mar 2018 19:07:35 -0400

> 1)      Do you think BGP should carry these link state information regarding

I do.

> 2)      Are there any technical issues with this draft? 

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.

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?

> 3)      Is this draft is ready for publication? 

Largely.

-- Jeff

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 16 Mar 2018 02:50:43 +0000

Hi Jeff,

Thanks for your review and please check inline below.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
Sent: 16 March 2018 04:38
To: Susan Hares <[email-masked]>
Cc: 'idr wg' <[email-masked]>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

I do.

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.
[KT] Thanks for catching this miss. I will fix this in the next revision.

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?
[KT] I believe this is clarified in the base BGP-LS spec (https://tools.ietf.org/html/rfc7752#section-6.2.2). Do we need to clarify/call out anything extra in this specific document? IMHO it would be rather complex for BGP implementation (e.g. transit routers which do not understand or consume all these TLVs) to do semantic checking on these large set of TLVs being introduced in BGP-LS. This is something that could be left to the actual consumer of the information (e.g. controllers/applications). When a specific sub-TLV is using a wrong length (or have some other semantic error), it could be ignored by the consumer. This would apply to BGP-LS in general and not a specific document/extension.

Largely.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 16 Mar 2018 09:50:23 -0400

Ketan,

On Fri, Mar 16, 2018 at 02:50:43AM +0000, Ketan Talaulikar (ketant) wrote:
> [KT] I believe this is clarified in the base BGP-LS spec
> (https://tools.ietf.org/html/rfc7752#section-6.2.2). Do we need to
> clarify/call out anything extra in this specific document? IMHO it would
> be rather complex for BGP implementation (e.g. transit routers which do
> not understand or consume all these TLVs) to do semantic checking on these
> large set of TLVs being introduced in BGP-LS. This is something that could
> be left to the actual consumer of the information (e.g.
> controllers/applications). When a specific sub-TLV is using a wrong length
> (or have some other semantic error), it could be ignored by the consumer.
> This would apply to BGP-LS in general and not a specific
> document/extension.

My interpretation of the above citation is "the PDU is syntactically well
formed".  The issue here is when it's semantically incorrect.

I agree with you that this is likely a more general BGP-LS issue, but don't
see appropriate guidance in the base spec either.

While your point is "let the consumers decide", sometimes those consumers
are simply deserializing the data directly into structures in BGP for
external consumption.  I.e., they are not opaque.  Thus, the semantic
validation has relevance in general.

Frankly, this has the possible feel of a attack vector on BGP-LS speakers.

-- Jeff

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 17 Mar 2018 05:59:23 +0000

Hi Jeff,

You are right that RFC7752 sec 6.2.2 covers what you describe as message being "syntactically well formed". The "semantic" validation part is perhaps not explained as well (please correct if I missed this).

If the semantic error is there with respect to NLRI descriptor TLVs then likely the NLRI becomes un-usable. If it is with an attribute TLV, then likely that specific attribute may be ignored or implementations may choose to ignore the entire NLRI.

Given the ever growing amount of information which is being propagated via BGP-LS, my recommendation would be for BGP speakers to handle them as opaque data (i.e. not do semantic checking on it) to the point where this information is handed over to the consumer (internal or external). Consider scenarios where BGP-LS information is relayed via one or more RRs or eBGP sessions - these intermediate hops may not even have the ability to understand/support the NRLIs/TLVs.

Semantic checking is best left to the point where the information is actually going to be consumed since that application (it could even be BGP itself) has the smarts to do this.

I am not sure I understand your point on this becoming an attack vector. And I assume that implementations that handle the PDUs in a robust and secure way.

In any case, I would look forward to inputs/comments from you and the WG on how the semantic checking can be handled and if this needs to be covered in specific BGP-LS drafts or we come up with something general.

Thanks,
Ketan

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: 16 March 2018 19:20
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)

Ketan,

On Fri, Mar 16, 2018 at 02:50:43AM +0000, Ketan Talaulikar (ketant) wrote:
> clarify/call out anything extra in this specific document? IMHO it 
> would be rather complex for BGP implementation (e.g. transit routers 
> which do not understand or consume all these TLVs) to do semantic 
> checking on these large set of TLVs being introduced in BGP-LS. This 
> is something that could be left to the actual consumer of the information (e.g.
> controllers/applications). When a specific sub-TLV is using a wrong 
> length (or have some other semantic error), it could be ignored by the consumer.

My interpretation of the above citation is "the PDU is syntactically well formed".  The issue here is when it's semantically incorrect.

I agree with you that this is likely a more general BGP-LS issue, but don't see appropriate guidance in the base spec either.

While your point is "let the consumers decide", sometimes those consumers are simply deserializing the data directly into structures in BGP for external consumption.  I.e., they are not opaque.  Thus, the semantic validation has relevance in general.

-- Jeff

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Mon, 26 Mar 2018 03:09:55 +0000

+1 (support)

From: Idr <[email-masked]> on behalf of "Dhanendra Jain (dhjain)" <[email-masked]>
Date: Sunday, March 11, 2018 at 4:23 PM
To: 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)

Support.

Thanks,
Dhanendra.

Susan Hares