Subject: Re: [bess] RtgDir Early review: draft-ietf-bess-datacenter-gateway.txt

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Aug 2020 18:18:53 +0100

Hi Ravi,

I’m doing housekeeping on this draft and find your review. It looks like we didn’t respond – sorry.

Many thanks for the careful review. 

Comments are in line…

Intended Status: Standards track (but is it the right one? Should this be informational instead, since no new encodings are explicitly specified)

Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

1. Draft track: does this need to be "standards track”? No new encodings are specified, even though there are requests for new IANA code-points.

AF> The document asks for a code point from the “BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for which the registration policy for this registry is Standards Action. So we have to be a Standards Track document.

2. Section 3:

          a. Auto-discovery: setting the route-target to SR-ID: how to avoid conflicts in regards to route-target settings: some may represent the SR ID and other represent non-SR constructs? Some text in that regard would be helpful.

AF> These are not VPN routes so there shouldn’t be any conflict. But I think your question might be about what happens if other RTs need to be present on the same advertisement. And the answer is, “just do it”.

          b. The draft would do well to explicitly state what happens if the GWs in a given domain end up getting configured with different SR IDs.

AF> We will add a little text.  Basically they would not auto-discover each other and a receiver would just get the best route with only the advertising node’s tunnel encapsulation information.

          c. Is there a specific reason why neither the format for the SR tunnel TLV is listed nor a pointer given to a pre-existing definition in another doc?

AF> We will add a reference to  <https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-15#section-2> https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-15#section-2

3. Section. 5: could use an example with reference to figure 1.

AF> Yup. Several people have asked for examples. We’ll add a pointer to  <https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-05> https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-05 section 7.

4. Section 6: would be useful to describe, or provide pointer to section in the tunnel-encaps draft, stating logic for picking a specific encapsulation for a given packet.

AF> The advertising node can include anything defined in either the Tunnel Encapsulation draft or any other subsequent drafts.  As indicated above, we are just defining new wrappers.

Best,

Adrian