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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
