Early Review of draft-ietf-idr-bgp-ct-srv6-03
review-ietf-idr-bgp-ct-srv6-03-tsvart-early-touch-2024-03-28-00
| Request | Review of | draft-ietf-idr-bgp-ct-srv6 |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | Early Review | |
| Team | Transport Area Review Team (tsvart) | |
| Deadline | 2024-03-28 | |
| Requested | 2024-03-12 | |
| Requested by | Susan Hares | |
| Authors | Kaliraj Vairavakkalai , Natrajan Venkataraman | |
| I-D last updated | 2024-03-28 | |
| Completed reviews |
Rtgdir Early review of -03
by Jonathan Hardwick
(diff)
Opsdir Early review of -03 by Nagendra Kumar Nainar (diff) Tsvart Early review of -03 by Dr. Joseph D. Touch (diff) |
|
| Comments |
RTG-DIR: Jon Hardwick worked on the draft-ietf-idr-bgp-ct-18 review. The draft-ietf-idr-bgp-ct-srv6-04 draft has been split from the draft-ietf-idr-bgp-ct draft.
It may be useful to have Jon if he feels comfortable with the SRv6 review.
OPS-DIR - Bo Wu did the review in July on drsaft-ietf-idr-bgp-ct-18. The draft-ietf-idr-bgp-ct-srv6-04 has been split from the draft-ietf-idr-bgp-ct draft. It may be useful for
him to do the review of this draft.
SEC-DIR—Intent (Color) could have security issues in this draft. Intent tracks service data (customer data) and places it over service quality tunnels. In one view, it is just more layering. In an alternate view, the color exposes some abstract qualities of the network. My understanding is that some people have questions SRv6 security.
It would be good to provide feedback that differentiates between the general security and the additional issues this draft presents.
TSV-DIR - Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels. Please consider the problems with tunnels in your review of this text.
|
|
| Assignment | Reviewer | Dr. Joseph D. Touch |
| State | Completed | |
| Request | Early review on draft-ietf-idr-bgp-ct-srv6 by Transport Area Review Team Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/tsv-art/SRAij72hL5k96QuE3GZQqX75eB0 | |
| Reviewed revision | 03 (document currently at 05) | |
| Result | Not ready | |
| Completed | 2024-03-28 |
review-ietf-idr-bgp-ct-srv6-03-tsvart-early-touch-2024-03-28-00
This document was reviewed as per the following request: TSV-DIR - Please look at this draft from the viewpoint of having intent (color) aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded over a set of intent (color) aware underlay of tunnels. Please consider the problems with tunnels in your review of this text. The document refers to these tunnels in a manner that appears consistent with draft-ietf-idr-bgp-ct. As a side note, it would be preferable for this document to refer to the terminology of this bgp-ct draft rather than repeating it, so it would be more clear which terms are introduced herein. Avoiding duplication also avoids the need to align the two sets of definitions upon publication. TSV-DIR area of concern appears to originate in the bgp-ct draft rather than herein. There are a variety of issues with tunnels not addressed in either document, many of which are described in draft-ietf-intarea-tunnels (though not refreshed, this remains an active INTAREA doc), notably the difference between tunnel path MTU, tunnel egress MTU, and overall path MTU of the tunneling service (which is dependent on the latter rather than the former), especially the difficulty in determining the tunnel path MTU. The way in which both documents refer to tunneling as (IMO) 'do a tunnel, whatever that involves' is a bit of a disconnect with the idea that these tunnels, when deployed, provide service assurances on which upper layers can plan. In particular, Section 4.1 of the bgp-ct doc gives some potentially relevant examples, but only for a subset of the tunneling technologies described in the definition. Both documents would benefit from a more precise definition of the tunnel technologies that have properties needed to support these methods. In particular, a tunnel cannot provide "transport class aware" services unless that can be assured by the layer over which the tunnel operates or by the tunnel protocol itself. E.g., a tunnel cannot provide guaranteed BW over a best-effort network, but a tunnel can create assured in-order delivery over an underlay without such ordering guarantees.