Re: [Idr] https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/27

[Jeffrey Haas <[e-mail]>]

Kaliraj,

I'm using my jet lag to work through the last bits of -ct review from my own
queue.  Sorry for the delays.  The remaining items are largely nits:


On Sat, Sep 23, 2023 at 12:33:37AM +0000, Kaliraj Vairavakkalai wrote:
> Figure 1, the "architecture" isn't really an architecture - it's an example topology leveraging multiple of the components.
> 
> KV> The intent is to explain the different constructs in the architecture using brief examples.

The issue is the label for figure 1.  Label it "example topology" or similar.

> "import processing" is used in a non-RFC 4271 normative fashion. What's intended here is processing of a route received by a bgp speaker and its interaction with import policy. I'd suggest that rather than do bgp-speak everywhere, "import processing" should be defined in the terminology section.
> 
> KV> ‘import processing’ means ‘receive side processing’. Added in Definitions section.
> 
> Issue, Section 5:
> "The first community on the route that matches a Mapping Community". "First community" isn't well defined in community processing procedures. Implementations tend to locally canonicalize the received set of communities and may internally re-order them without regard for the order of the routes as received in the PDU. What I believe is intended here is the first matching community according to the locally configured policy.
> 
> If there are multiple mapping communities on a route for whatever reason, this order may cause different nodes to take different mapping actions as part of their processing. Such behavior may lead to inconsistent routing within a domain. The document does state, "If a route contains more than one Mapping Community, it indicates that the route considers these distinct Mapping Communities as equivalent in Intent." There likely needs to be a caveat that intent equivalence needs be wary of consistent route selection across intents to avoid forwarding loops.
> 
> KV> Pls see ct-v16.sec-5.1 for clarified text.

The -17 text tries to point out "don't do that, it can go wrong":

: The first community on an overlay route that matches a Mapping Community of
: a locally configured Resolution Scheme is considered the effective Mapping
: Community for the route. The Resolution Scheme thus found is used when
: resolving the route's PNH. If a route contains more than one Mapping
: Community, it indicates that the route considers these distinct Mapping
: Communities as equivalent in Intent.

The text above remains and still has the ambiguity of what "first" means.

: If more than one distinct Mapping Communities on an overlay route map to
: multiple Resolution Schemes with dissimilar Intents at a receiving node, it
: is considered a configuration error. Operators should avoid such
: configuration errors when attaching mapping community on overlay routes.

This mostly covers consequence.  However, it's probably unclear to the
average BGP reader that two devices with the same set of extended
communities may differently choose "first".  The warning is thus "this can
go wrong" but less clear "because you have more than one".

My recommendation here is to say "Overlay routes SHOULD NOT contain more
than one Mapping Community.  Conflicting multiple Mapping Communities may
result in inconsistent route selection."

> Issue, Section 7.7:
> This section motivates the scenario where an ABR route reflector resets the nexthop locally. This isn't a common scenario, but it does happen and it's good to discuss it.
> 
> However, the mitigation as a "SHOULD provide a way to alter the tie breaking". Doing this inconsistently is likely to cause the problem described when executing this scenario. The remainder of the section offers operational mitigations.
> 
> My recommendation is if this scenario is expected to be common, it is necessary to discuss this as a MUST. Further the section should be called out as "changes to the BGP decision process" in its section name.
> 
> KV> Added section “Path selection change”, clarified ct-v16.sec-7 text. Leaving it as SHOULD, since other mechanisms to deal with this problem also exist.
> KV> The other mechanism ct-v16.sec-7.7.2.first-bullet (carefully chosing IGP metric) is what seems to be widely used today to handle this problem.

Note to the other idr-chairs: This is attempting to be a normative change
vs. the route reflection RFC motivated by a scenario in this draft.  

> Issue, Section 8.2:
> "An egress SN MAY advertise BGP CT route for RD:eSN with two Route Targets: transport-target:0: and a RT carrying :. Where TC is the Transport Class identifier, and eSN is the IP-address used by SN as BGP next hop in its service route advertisements."
> 
> RFC4684 and the eSN in question can accomplish IPv4 nexthops via RT-Constrain behavior.
> 
> IPv6 route targets in RT-Constrain is work IDR has adopted, but hasn't advanced - and the existing proposal is a matter of some controversy.
> 
> The citation of draft-zzhang-idr-bgp-rt-constrains-extension similarly bends the informative vs. normative discussion here.
> 
> KV> Actually here it is nothing more than a reference to the draft, saying this draft is working on how RTC is done for wide-RTs.
> KV> If this amount of referencing is also not allowed, then we lose recording results of valuable discussions and time
> KV> that WG has spent. These references are citing specific versions of these individual IDs. I feel it is OK to state
> KV> that some other drafts are working on this problem. Instead of completely removing the information from this draft.
> KV> Anyways, as stated in [Anchor1], will wait for collective guidance from IESG and Chairs.

I've left this one open, and have filed a separate github Issue on removing
the wide communities reference.

The issue noted here is that you're mingling "here is something that can
work" with "here are some theoretical things that may radically change
before publication".  It's our general experience that we should minimize
references, even informative, to mechanisms that haven't moved very far
along implementation or the standards path.

Things aren't "lost".  The mail list captures the details.  The purpose of
the standards documents are to be clear procedure. 

The additional two issues I flagged as part of this re-review:

https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/34
 Remove reference to non-defined wide communities route-target #34 

As above, wide communities doesn't define any route targets and the zzhang
draft covers general purpose filtering on community-like attributes - but
isn't far along in its work.

https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/33
 transport-target documentation #33 

This notes that use of transport class/target is inconsistent in the
document in places.

-- Jeff