Skip to main content

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 -05 by Matthew Bocci
Opsdir Early review of -05 by Nagendra Kumar Nainar
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.