Hi Dhananjaya,
The limitations you mention below does not exist when using RD. Let me explain:
RD is an ‘identifier of convenience’. Which means:
* We use it to avoid path-hiding during BGP route propagation, and to
identify the originator uniquely across the domain.
* And we can strip it when not required (in the transport-RIBs where they
are imported to), so that we can
* Do path-selection across IP-prefixes after stripping the RD, in order
to find the ECMP or alternate-paths, for PIC like scenarios. And
* Use the IP-prefix as the key for label-allocation, such that any churn
stays local.
So the limitations you note below do not exist when using RD. This is also
explained in the CT draft. (
https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-07#page-13
)
Also, such usage of RD is nothing new; e.g. it is common for BGP-VPN
implementations to strip RD and do path-selection on IP-prefixes in the VRF.
Using RT to populate transport-RIBs on the BNs nicely organizes the colored
transport-RIBs with transport-endpoints, our experience so far shows it is nice
for troubleshooting and analytics, among other things.
About precedence of mixing key and non-key values in NLRI, I’ll let the WG
decide whether we should avoid going further in that direction. I was just
noting that I think we should avoid adding more non-key fields to NLRI. How
much update-packing we may get in the real world by doing such
micro-optimizations is questionable; considering the routes may contain
distinct communities used to identify the originating-region and other such
operator policies.
Thanks
Kaliraj
From: Dhananjaya Rao (dhrao) <[email protected]>
Date: Thursday, March 25, 2021 at 1:11 PM
To: Kaliraj Vairavakkalai <[email protected]>,
[email protected]
<[email protected]>
Cc: [email protected] <[email protected]>, [email protected] <[email protected]>
Subject: Re: [Idr] Comments, review of - draft-dskc-bess-bgp-car-01 presentation
[External Email. Be cautious of content]
Hi Kaliraj,
Thank you for reviewing the BGP CAR draft and your comments. I am top posting
my responses for better readability since the comments were quite long ☺
1.
BGP CAR extends existing BGP-LU flat hop-by-hop routing semantics by adding
color-awareness to the NLRI. This approach addresses the requirement for
diverse color-aware paths using the simplest and most efficient design.
We find this simplicity beneficial both for an implementation and more
importantly for deployment.
2.
We don’t see a need for using L3VPN semantics with RD/RT and import/export at
every underlay hop.
While using RD may have been a convenience as you stated, it brings unnecessary
complexity and limitations.
A good example is the inability to achieve multipathing at an ingress BR (e.g.,
ABR3) within the local domain when two egress ABRs originate BGP routes for a
PE with different RDs. This leads to slower traffic convergence since an egress
ABR failure (e.g., ABR1) will need to be propagated across the domains all the
way to an ingress PE before that path stops getting used. It also causes
unnecessary churn across multiple domains. (See simplified topology below)
_ _ ---
ABR1 ---
PE1 –( _ _ ) --- ABR3 --|
|------- PE2
---
ABR2 ---
The CAR proposal does not have this limitation.
3.
From your comments, there appears to be a basic misunderstanding of the CAR
proposal and the presentation.
We refer to the solution architecture described in
[draft-ietf-spring-segment-routing-policy] as the deployed SR-TE solution. It
specifies a pull model <section 8.5, and also 5.2> for a PE (policy head-end)
to query SR-PCE and get a path with label-stack or SID-list in response. This
avoids the PE needing to learn any state for all remote PEs by default.
You seem to assume a narrow reference to [ietf-idr-segment-routing-te-policy]
which is not correct. The BGP-TE SAFI defined there is simply a means to enable
a controller to signal a path for a policy to a specific SR policy headend
using BGP instead of PCEP (see Section 2.3 of
[draft-ietf-spring-segment-routing-policy]).
BGP CAR is regular BGP distribution for hop-by-hop routing (ala BGP-LU), but
with color/intent-awareness. However, the data model defined for BGP CAR is
inherently consistent with the one defined for SR-policy regardless of protocol.
4.
Mixing key and non-key values in BGP NLRI is not new, it’s been there since
RFC3107 (label/label-stack) at least. Other SAFIs have had this too, for
example, EVPN. There are cases of both fixed and variable values.
In the CAR proposal, we added structured TLVs to support multiple values and
extensibility, instead of adding ad-hoc definitions and overloading of fields.
It reduces complexity and provides for consistent handling.
That said, as I mentioned during the presentation, we have received suggestions
for alternative encoding, and are evaluating them.
5.
Inherently, there is a variable degree of packing with BGP updates. That does
not mean one should break it by default.
Similarly, just because we are being fore sighted by defining an extensible
NLRI does not mean that it will invariably lead to a worst-case scenario ☺
Any extensions, such as new route-types that are proposed will go through WG
review which should ensure proper gatekeeping. Again, there is precedence for
this with other SAFIs.
And thank you for acknowledging that having route-types is acceptable.
6.
The CAR proposal does support domains with different color diversity. The
Appendix describes a few examples.
7.
I will defer responding to the specific use-case and filtering comments since
they are not yet specified in the draft. It will be much easier to discuss once
we post them. Just a quick comment that the proposal does not at all preclude
supporting anycast use-cases.
Thank you again for your patient review of the proposal and your feedback.
Regards,
-Dhananjaya
Hi CAR authors,
Thanks for the presentations in IDR and BESS meetings at IETF-110 last week.
We could not discuss in detail during the session because of time constraints.
So
sharing my comments to the mailing lists.
Starting with follow-up on what Ketan mentioned in the IDR meetecho chat,
regarding SRTE is pull model vs CAR is push model:
I wanted to clarify, that may not be accurate. SRTE is also push model. PCE
provides the ‘pull’ part, which SRTE responds to. So, I think the question
Linda was alluding to remains.
viz: Why do we need another SRTE like family, when we have SRTE already?
Further, following are my own thoughts on the CAR encoding proposal, and
challenges:
1/ The claim on better packing, and NLRI extensibility:
IMHO, micro-optimizing the NLRI wanting to support better packing introduces
complexity in
a different dimension. Mixing key and non-key values in the NLRI increases
implementation
complexity and hampers debuggability.
More-over, the claim of packing goes away when attributes like AIGP need to be
carried in the
CAR routes. Because AIGP value may be different for different EP:Color NLRIs,
those cannot be
packed.
One could suggest to put AIGP like attributes also into the NLRI to support
better packing.
But you can easily see where this leads us. Having per-NLRI attributes leads us
to the notion
of having “zero packing”. Because now everything is per-prefix. The SID, label,
SRv6-SID,
other attributes. Etc..
About carrying SRv6 SIDs per NLRI: not being able to share the same SRv6 SID
for different EP:C
NLRIs (i.e. per-prefix label/sid) may also be inefficient, it may cause huge
size BGP updates,
which may increase Control plane convergence time.
So, we need to be cautious. Having a kitchen sink NLRI that can have “anything”
could become a
reason to abuse the protocol in unforeseeable ways. IMHO, it is OK for a BGP
family to have a
typed NLRI as long as it avoids non-key fields.
2/ using Color in the NLRI as both “Identifier/Distinguisher” as well as the
“Route-Target” equivalent.
This tight-coupling has the problem that we cannot form Venn diagram of Colors
to support cases,
where core-network has more colors than access networks. Have the authors
considered such use-cases?
This also has the problem of not being able to strip color out, to do
path-selection on EP alone,
as is possible when using RD like distinguisher. When an Anycast EP-address is
present in multiple
domains, that don’t agree on the same color-namespace, such problems may become
evident. Albeit a
corner-case, not impossible to conceive in real world.
Also, it is worth noting that IDR has seen similar proposal in the past (BGP
LCU from Juniper) which
was not pursued further after self reflection on such considerations.
3/ Claim on wide SRTE deployment experience.
I would like to note that, SRTE has so far been used as a single BGP-hop
family, between
controller and BGP-speaker. And it has no deployment experience doing hop by
hop readvertisement
and carrying forwarding state thru the inter-domain networks. So applicability
of ‘SRTE
deployment experience’ in inter-domain BGP networks is questionable.
Comparing it to L3VPN/LU, which CT derives of – it is widely deployed in such a
role in inter-domain networks.
Authors of CT recognize the scaling challenges that Seamless-MPLS networks see
today on the transport-layer.
And have proposed multiple ways on how that can be dealt with. Some of those
mechanisms not only help CT,
but existing LU deployments as-well.
To me, re-using existing functionality, and start improving on the scaling
challenges seems like a better
approach, than re-inventing existing mechanisms, making them work functionally
and then coming to the scaling
part.
4/ Filter routes vs CAR routes.
Mechanisms of the Filter-routes is not clearly described yet in the draft.
But taking a guess, it could be either
* a new route-type in the same family? (more likely)
* OR, uses RTC family routes to provide filtering for CAR routes
If Filter routes are a separate RouteType in the same CAR family,
Please note that the Filter-routes need to be propagated in the opposite
direction
as the CAR transport-advertisements.
And learning from RTC mechanisms, the initial transport-route-advertisements
may need to wait for
EOR of Filter-routes. If those are just different route-types in same NLRI,
such EOR based
mechanisms cannot be employed, unless we introduce a per-route-type EOR
(EORT).
This also means that the rules for dealing with each route-type needs to be
specified separately,
In essence each route-type becomes a new family equivalent, with its own
distinct needs and rules.
This looks difficult to comprehend, implement, troubleshoot. Imagine
specifying both RTC and VPN
procedures in same bgp-family, carrying them in same RIBs.
This is just a thought experiment on why putting many different
functionalities in the same family as
different route-types may not necessarily make things ‘simple’.
Instead, following the age old principle of “doing one functionality well”.
That keeps things simple, IMHO.
If Filter-routes are just RTC family routes working on CAR routes,
That could be made to work for the case where the LCM community exists on the
route, but LCM community
doesn’t always exist on the route. It is only a special case. So it may not
work for the typical cases.
Finally, I feel the CAR draft proposes enough changes to basics of BGP, how BGP
NLRI encoding is done,
and is basically a Transport-layer family which intends to provide common
infrastructure that is used by
by all BGP Service-families.
So it may be more suitable for review by the IDR WG which deals with common
infrastructure pieces of BGP,
than the BESS WG which deals with BGP services. Request the WG chairs to
consider this.
Thanks,
Kaliraj
Juniper Business Use Only
Juniper Business Use Only
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
