ietf-wg-idr / draft-ietf-idr-bgp-car

0 stars 0 forks source link

F3-WG-Issue-3: Key Operational Differences between CAR and CT drafts #8

Closed sa1231-coder closed 8 months ago

sa1231-coder commented 1 year ago

F3-WG-Issue-3: Key Operational Differences between CAR and CT drafts (Bruno Decraene) • Bruno Decraene + Jeff Haas - Create common example topology (or topologies) for shared ANYCAST Service across multiple domains. This topology (or topologies) should include anycast endpoints, single-color domains, multiple-color domains, and non-agreeing color-domains. • CT - Based on the common example technology, add text to draft on shared ANYCAST Service.
• CT: In the introduction to Section 14, clarify what paradigm is used for scaling in CT. (One paradigm might be indirection and hierarchy). The text should include the following: o descriptions of how CT’s paradigms for indirection and hierarchy are used in the network’s transport and service topology, o descriptions should include unique RDs and same RDs in stable and changing topologies (e.g. routing churn). o how scaling is impacted by NLRI changes are handled in route withdraws, refreshes, and updates. • CT: Add description of procedures when IP address has collision, or with same RD. (See Bruno’s comments for details). • CAR - Based on common example topology add text to draft based on shared ANYCAST service. (Note: overlaps with F3-CAR-Issue-4.) • CAR: In the introduction to section 6, clarify what paradigm is used for scaling in CAR (e.g. indirection and hierarchy). This text should include the following: o descriptions of how CAR’s paradigms for indirection and hierarchy are used in the network’s transport and service topology, o how scaling is impacted by NLRI changes are handled in route withdraws, refreshes, and updates. • CAR: Section 2.5 provides two comments on route resolution that need to be clarified: o “When multiple resolutions are possible, the default preference should be: IGP Flex-Algo, SR Policy, RSVP-TE, BGP Car, [and] BGP-LU.”
 This description uses the word should which implies that local policy can interfere. This should be clarified.  This description does not include the inclusion of LCM or Extended-Color Community or Color in the Tunnel Attribute. o “Resolution may be automated using Color-EC as illustrated in Appendix B.2.” This comment does not provide a normative set of results for route resolution.
• CAR/CT – Should include discussion on impact on anycast endpoints, non-agreeing color-domains. • CAR: Add Discussion on Non-agreeing color-domains for Anycast endpoints to error handling and manageability section (section 10). This issue overlaps with F3-CAR-Issue-4 and F3-Wg-Issue-3a.

sa1231-coder commented 1 year ago

These are duplicate of earlier CAR issues being responded and text update take care of it.

More specifically,

suehares commented 1 year ago

Swadesh and DJ:

Unfortunately, you missed the first step. We need a common example so we can stop arguing about this topic. Are you willing to work with Jeff Haas and Bruno Decraene to set-up a common example?

Send me email if you are ready to work on a common example with Jeff Haas (IDR chair) and Bruno Decraene (Spring Chair). Joel Halpern (Spring chair) can also be enlisted if you need additional Spring advice.

Like you, I hope that the changes already made will be sufficient.

This issue must be left open until IDR Agrees upon a common example AND you check your text against that example.

suehares commented 1 year ago

Since we have not received any feedback on this comment. We will amend this issue to closing this issue after we receive early reviews by Jeff Haas, Bruno Decraene, and CT authors.

The purpose behind these reviews is to get early feedback on this document's text on deployment/operational issues prior to WG LC. It is not to compare or contrast with CT.

suehares commented 1 year ago

This is ready for external review.

dhrao1 commented 8 months ago

Presented and requested comments at multiple IDR sessions. No additional comments.