Early Review of draft-ietf-idr-bgp-ct-12
review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03-00

Request Review of draft-ietf-idr-bgp-ct
Requested revision No specific revision (document currently at 39)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2023-07-21
Requested 2023-06-26
Requested by Susan Hares
Authors Kaliraj Vairavakkalai , Natrajan Venkataraman
I-D last updated 2025-03-14 (Latest revision 2025-02-28)
Completed reviews Rtgdir Early review of -18 by Jonathan Hardwick (diff)
Secdir Early review of -18 by Magnus Nyström (diff)
Opsdir Early review of -19 by Bo Wu (diff)
Secdir Early review of -19 by Magnus Nyström (diff)
Tsvart Early review of -27 by Olivier Bonaventure (diff)
Secdir Early review of -30 by Magnus Nyström (diff)
Rtgdir Early review of -09 by Mohamed Boucadair (diff)
Opsdir Early review of -12 by Bo Wu (diff)
Genart IETF Last Call review of -35 by Reese Enghardt (diff)
Comments 
The IDR WG is doing a WG LC in parallel (6/26 to 7/24). 
You may find reading the discussion helpful. 

Security reviews should consider whether enough security text exists to describe the normal deployment as a "walled garden".  It is also important to know if something goes outside the "walled-garden". 

This is an experimental draft because we have two similar methods with no clear consensus.  Please review this with the depth of review of a proposed standard.
Assignment Reviewer Bo Wu
State Completed
Request Early review on draft-ietf-idr-bgp-ct by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/Y5iv4v8pwHrmastZZbnd_CxFrx0
Reviewed revision 12 (document currently at 39)
Result Not ready
Completed 2023-08-03
review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03-00
Hi,

Thanks for the draft.

I am the assigned Ops reviewer to conduct an "early" review of this draft.

This draft proposes a new BGP address family ((AFI/SAFIs, 1/76, 2/76)) and new
Transport Class Route Target extended community, that enables the advertisement
of underlay routes with identified classes. And the new CT address family
follows the RFC 8277 mechanism to allocate MPLS labels to the underlay routes.

Here are my comments:

1.      It is suggested to define a section on Operations and Manageability
Considerations to facilitate understanding on this aspect. 1）      Management
Consideration as a sub-section: It seems that sections 7.9 to 7.10 explains the
management of name space. E.g., the management of RT, RD, and Transport Class
name space in sections 7.9 and 7.10 are described. And Section 13 Deployment
Consideration seems also mentions the transport class/color namespace. 2）     
Interoperability Consideration as a sub-section: 7.11 and 7.12 explains
interoperability with the existing BGP protocol, which does not seem to be the
focus of the BGP CT protocol procedure 3）      Sub-section that applies:
Section 8. Scaling Considerations, Section 9. OAM Considerations, Section 13.
Deployment Considerations.

2.      Section 10 Applicability to Network Slicing
It is recommended to clarify which specific section of TEAS-NS is related to
Transport Class? In addition, it is recommended that the term be used with the
TEAS-NS, for example, a TSC is defined as a Network Slice Controller in the
TEAS-NS.

3.      Section 11 SRv6 Support
Section 13.4. Applicability to IPv6 also mentions SRv6. It is recommended that
these two sections be combined. Given that SRv6 is defined separately, should
Sections 3 and 12 also indicate that it applies only to MPLS?

4.     “Community” usage confusion
Overall impression. Transport Class Route Target extended community is
introduced in this draft, but mapping community and color community are also
mentioned in many places. It is better to explain why color community is not
reused? Also to clarify that Transport Class Route Target extended community
not limited to BGP CT family?

Thanks,
Bo Wu