suehares
commented
4 months ago G3-11: (Section 2.5) - Review of -07 text changes
-07-status: Issue 11-a resolved Issue 11-b + 11-c are technical and need to be discussed. -08-status: Issues 11-b and 11-c are closed. 11-a reopened for a punctuation nit.
11-a: Punctuation nit. -08 text:/ A BGP color-aware route (E2, C1) with next hop N may be resolved over a color-aware route (N, C2): i.e. the local policy maps the resolution of C1 over a different color C2./ New text:/ A BGP color-aware route (E2, C1) with next hop N may be resolved over a color-aware route (N, C2): i.e., the local policy maps the resolution of C1 over a different color C2./
NIT is that "i.e." must be "i.e.".
11-b: -07-text:/
- Another example is, if no (N, C1) path is available, and the user has allowed resolution to fallback via C2/ New text:/
- Another example is: if no (N, C1) path is available and the user has allowed resolution to fall back to a C2 path. /
Question: Do you mean the C2 path? How does this match with
11-c The text is really improved, but this sentence still needs aid: 07-text: / In such a case, the ingress node resolves the received SRv6 SID over an IPv6 route for the intent-aware locator of the egress node for C1 or a summary route, provided by SRv6 Flex Algo or BGP CAR Type-2 route itself (e.g., Appendix C.2)./
07-new-text (proposed):/ In such a case, the ingress node resolves the received SRv6 SID over an IPv6 route for the intent-aware locator of the egress node for C1 or a summary route that includes the locator. This summary route may be provided by SRv6 Flex Algo or BGP CAR Type-2 route itself (e.g., Appendix C.2)./
Editorial Issues 11-20
G3-11 - Editorial - Section 2.5 BGP CAR Route Resolution
There are 3 parts to this editorial issues (11-a, 11-b, 11-c). In each case, it is important to clearly specify what "N" is, and what (N,C2) is.
Is "N" the BGP peer or is "N" the next hop or a prefix?
If "N" is next hop, then a possible text is:
11-a: Clarify what "N" is - Peer or Next Hop. Old Text:/ Local policy SHOULD provide additional control:
New text: If "N" is next hop / Local policy SHOULD provide additional control:
Old text:/
current text in section 8/ A BGP transport CAR speaker that supports packet forwarding lookup based on IPv6 prefix route (such as a BR) will set itself as next hop while advertising the route to peers. It will also install the IPv6 route into forwarding with the received next hop and/or encapsulation. /
#11-c - Section 2.5 Technical/Editorial - Route Resolution,
Old Text:/
The resolution of (N, C1) may be egress driven. In an SRv6 domain, node N selects and advertises an SRv6 SID from a locator for intent C1, with a BGP CAR route. In such a case, the ingress node resolves the SRv6 SID over a route for the intent aware locator of N or its summary provided by SRv6 Flex Algo or BGP CAR Type-2 route itself (e.g., Appendix C.2). / Problem: Here's the scenario: segments for SRv6 SID-1
ingress (node N2) ---------------------- egress (Node N)
The SID is just like a link between N1 and N2.
Resolves Next Hop N over link SRPM with SRV6 SID-1
It is unclear wht the text says. Do I understand the scenario? If so, the text needs to be improved.
G3-12 - section 2.5, resolution mapping
Old Text: /
New Text: /
G3-13 - Section 2.5, Editorial
Old text/ Route resolution via a different color C2 can be automated by attaching BGP Color Extended-Community C2 to CAR route (E2, C1), leveraging Automated steering as described in Section 8.4 of Segment Routing Policy Architecture [RFC9256] for BGP CAR routes. This mechanism is illustrated in section B.2. This mechanism SHOULD be supported./
New text: / Route resolution via a different color C2 can be automated by attaching BGP Color Extended-Community C2 (Color-EC C2) to CAR route (E2, C1), leveraging automated steering as described in Section 8.4 of Segment Routing Policy Architecture [RFC9256] for BGP CAR routes. The [RFC9256] mechanism uses the Extended Community defined in [RFC9012].
This mechanism is illustrated in section B.2. This mechanism SHOULD be supported. /
Problem: a) use Color-EC to help reader grasp which extended communmity, b) Clearly differentiate between procedures and editorial by breaking the paragraph into two parts.
G3-14 - Editorial, Section 2.5
Old Text:/ CAR Type-2 route is allowed to be without color for best effort. In this case, resolution is based on BGP next hop N, or when present, a best-effort SRv6 SID advertised by node N. /
Problem: The resolution is to a next hop of Node N, through the pathway of segments defined by SRv6 SID.
Suggested New Text:/ CAR Type-2 route is allowed to be without color for best effort. In this case, resolution is based on BGP next hop N either directly or through the SR path defined a best-effort SRv6 SID. /
G3-15 - Editorial, Section 2.6, paragraph 4, last sentence.
Old Text:/ If BGP CAR routes traverse across a discontinuity in the transport path for a given intent, a penalty is added in accumulated IGP metric (value set by user policy). For instance, when color C1 path is not available, and route resolves via color C2 path (e.g., Appendix A.3). /
New Text:/ If BGP CAR routes traverse across a discontinuity in the transport path for a given intent, a penalty is added in accumulated IGP metric (value set by user policy). For instance, when color C1 path is not available, and route resolves via color C2 path (see Appendix A.3 for an example). /
Problem: e.g. is unclear in the English text when you already used "For instance," English grammar.
G3-16 - Editorial, section 2.8, paragraph 1
Old Text:/ Let us assume a BGP CAR route (E2, C2) is signaled from B to A; two border routers of respectively domain 2 and domain 1. Let us assume that these two domains do not share the same color-to-intent mapping. Low-delay in domain 2 is color C2, while it is C1 in domain 1 (C1 <> C2). /
New Text:/ Let us assume a BGP CAR route (E2, C2) is signaled from B to A, the two border routers of respectively color domain 2 and color domain 1. Let us assume that these two color domains do not share the same color-to-intent mapping. Low-delay in domain 2 is color C2, while it is C1 in domain 1 (C1 <> C2). /
Why-1: English Grammar. A semi-colon is used when the two clauses provide parallel information. You do not have parallel information, but an augmentation in the text "two border routers of respectively domain 2 and domain 1."
Why-2: "two color domains" - The purpose is that you are crossing a color domian. Make this clear by adding the adjective.
G3-17 - Editorial, section 2.8 - "described" is better than illustrated.
Old text:/ The solution works as illustrated below: /
New text:/ The solution works as described below:/ /
G3-18 - Editorial, section 2.8 - clarify sending/receiving actions
Old text:/ The following procedures apply at a color domain boundary for BGP CAR routes, performed by route policy at the sending and/or receiving peer:
Control which routes are advertised to or accepted from a peer in a different color domain.
Attach LCM-EC if not present, or if present update the value to re-map the color as needed. This may be done by the advertising speaker or the receiving speaker as determined by the operator peering agreement.
/ New text:/ The following procedures apply at a color domain boundary for BGP CAR routes, performed by route policy at the sending and receiving peer:
Use local policy to control which routes are advertised to or accepted from a peer in a different color domain.
Attach LCM-EC if not present in the UPDATE message. If an LCM-EC is present in the UPDATE message the value to re-map the color as needed.
-This function may be done by the advertising BGP speaker or the receiving BGP speaker as determined by the operator peering agreement, and indicated by local policy on the BGP peers.
/
Reason: Clarity in "how to control" (via local policy) and clarity in what is being modified in the procedure.
G3-19 - Editorial, Section 2.9.1
Old Text:/
Type-Specific Key Fields: Depend on the NLRI type and of length indicated by the Key Length.
Type-Specific Non-Key Fields: optional and variable depending on the NLRI type. The NLRI definition allows for encoding of specific non-key information associated with the route (i.e. the key) as part of the NLRI for efficient packing of BGP updates. /
New Text:/
Type-Specific Key Fields: This exact definition of these fields depends on the NLRI type and of length indicated by the Key Length.
Type-Specific Non-Key Fields: These fields are optional and variable depending on the NLRI type. The NLRI definition allows for encoding of specific non-key information associated with the route as part of the NLRI for efficient packing of BGP updates.
/
Reason: For Clarity, the English sentence needs a specified subject rather than an implied subject (in the verb).
G3-20 - Editorial, Section 2.9.1, Clearly indicate procedures versus benefits:
Old text:/ It also helps make error handling more resilient and minimally disruptive as described in Section 2.11.
A route (NLRI) can carry more than one non-key TLV (of different types). This provides significant benefits such as signaling multiple encapsulations simultaneously for the same route, each with a different value (label/SID etc). This enables simpler, efficient migrations with low overhead :
avoids need for duplicate routes to signal different encapsulations
avoids need for separate control planes for distribution
preserves update packing (e.g. Appendix D)
The non-key portion of the NLRI MUST be omitted while carrying it within the MP_UNREACH_NLRI when withdrawing the route advertisement. /
New text:/ A route (NLRI) can carry more than one non-key TLV (of different types). See Section 2.11 for the error handling of multiple non-key TLVs.
The non-key portion of the NLRI MUST be omitted while carrying it within the MP_UNREACH_NLRI when withdrawing the route advertisement.
Benefits: The TLV formats in key and non-key fields helps make error handling more resilient and minimally disruptive as described in Section 2.11.
The ability of a route (NLRI) to carry more than one non-key TLV (of different types) provides significant benefits such as signaling multiple encapsulations simultaneously for the same route, each with a different value (label/SID etc). This enables simpler, efficient migrations with low overhead :
avoids need for duplicate routes to signal different encapsulations
avoids need for separate control planes for distribution
preserves update packing (e.g. Appendix D) /
Why: Clearly delineate between procedures versus benefits.