search

ietf-wg-idr / draft-ietf-idr-bgp-ct

1 stars 2 forks source link

CT-WGLC-OPS-DIR Review #31

Closed suehares closed 8 months ago

suehares commented 10 months ago

Author: Bo Wu Link: https://mailarchive.ietf.org/arch/msg/idr/ny5WOEcJwsqpI4YqUExBECKXfMQ/ Status: Not Ready Version: draft-ietf-idr-bgp-ct-12 Bo Wu: 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

suehares commented 10 months ago

Response from Kaliraj: Link: https://mailarchive.ietf.org/arch/msg/idr/_v1TrCzsnihuUxxdL2lub4KiZcI/ Hi Bo Wu,

Apologies for the delay in response.

We have gone thru your comments, and reorganized few of the sections. Please take a look at draft version 14.

https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html

Further please find some responses inline. KV>

In below response, secX.Y_v12 means: section X.Y in draft version 12 secX.Y_v14 means: section X.Y in draft version 14

Thanks Kaliraj 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: [Kaliraj-R1]: We created section sec10_v14https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html#section-10 as suggested and collected the subsections relating to RD management, label allocation mode etc. under it.

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. [Kaliraj-R1] As suggested, moved sec7.9_v12https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-12.html#section-7.9 subsection to sec11_v14https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html#section-11 (Deployment considerations). [Kaliraj-R1] sec7.10_v12https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-12.html#section-7.10 actually talks about how best-effort routes can be carried in BGP CT family. As part of that, it talks about color management of the best-effort transport-class. So I think it is part of core procedures.

And Section 13 Deployment Consideration seems also mentions the transport class/color namespace. [Kaliraj-R1] I thought about whether “Operation and Management considerations” and “Deployment consideration” sections need to be merged. It appears better to keep them separate. Sec 10 and 11 in draft-v14. Please take a look what you think.

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 [Kaliraj-R1] I think, sec7.11_v12https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-12.html#section-7.11 is part of core procedures, because it describes how to unambiguously identify the effective-color of a nexthop, when color can exist at various places on a BGP route. Sec7.12_v12https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-12.html#section-7.12 is also important to state here because it is a new procedure of how flowspec routes can redirect traffic. So left these in core procedures.

3） Sub-section that applies: Section 8. Scaling Considerations, Section 9. OAM Considerations, Section 13. Deployment Considerations.

[Kalira-R1j] OAM is moved into sec10_v14https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html#section-10 as suggested. But left ‘Scaling consisderations’ as separate section, since I think that’s different from Operations.

  1. 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. [Kaliraj-R1] the hyperlink pointed to sec 4 in TEAS-NS. Clarified text to mention that. Pls see sec12_v14https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html#section-12 . Also, changed TSC to NSC as suggested. Thanks for pointing this out.

  2. 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?

[Kaliraj-R1] IPv6 section is different from SRv6 section. This was added based on pre-review comments from rtg-dir. This section describes how BGP CT procedures work in a network with IPv6 control plane and IPv6 data traffic. To avoid confusion, I removed reference of SRv6 from sec7.12_v14https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html#section-7.12 and confined it to MPLS-forwarding, since sec7.13_v14https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html#section-7.13 talks about SRv6-forwarding. Also, moved these two sections to protocol procedures, since they specify how core-procedures work for these scenarios.

  1. “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?

[Kaliraj-R1] Color community is indeed re-used. Mapping Community is just a “role”, not a new type of community. Both Color-community and Transport-RT community play the role of a mapping-community. Any BGP community can play this role actually. Clarified this in sec sec5.1_v14https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-14.html#section-5.1.

[Kalirja-R1] Please let me know if a call would help to discuss any remaining concerns. Thanks.

suehares commented 10 months ago

Action items from Shepherd • Confirm resolution of changes to the following 4 sections: o Manageability o Section 10 o Section 11 • Confirm that SRv6 issues and community confusion has been resolve.

kalirajv commented 8 months ago

Closing: https://mailarchive.ietf.org/arch/msg/idr/ArItOzwcA4EA1Q_EuNm6KMorh_0/