Re: [bess] Questions/concerns about BGP Color-Aware Routing (CAR)
Dhananjaya, Thanks for responding. Specific comments inline. Thanks & Regards, srihari… From: "Dhananjaya Rao (dhrao)" Date: Monday, 24 January 2022 at 1:21 AM To: Srihari Sangli , Idr , "bess@ietf.org" Subject: Re: Questions/concerns about BGP Color-Aware Routing (CAR) [External Email. Be cautious of content] Hello Srihari, Thank you for your review of the BGP CAR proposal and comments. My apologies for the delayed response. I’d like to mention that some of your comments are similar to ones made earlier by your colleague(s), and we’d responded to them with the necessary clarifications. However, I will attempt to address them again here. To reiterate, BGP-CAR is fundamentally an evolution of the BGP-LU paradigm. It extends a regular IP prefix with a color since the goal is to support intent specific routing to given network endpoint. It is operationally and procedurally consistent with BGP-LU. As such, its way simpler than forcing the IP-VPN paradigm into underlay routing as BGP-CT does which brings with it unnecessary overhead and suboptimal behaviors as we have commented before. Srihari> IP-VPN paradigm is well understood by most and deployed for years, not sure what suboptimal behavior you are commenting here. The objections you pose primarily target the extensibility we’ve defined as part of the BGP-CAR NLRI. But those are in some cases incorrect, and in other cases unfounded or even vague claims of complexity IMHO. I will try to clarify once more inline. That said, we’ll be glad to discuss any valid critiques and concrete suggestions for improvement. Since we are defining a new SAFI to accommodate the color specific NLRI, it is apropos to introduce a modern, extensible NLRI definition. Precisely because it’s a new SAFI that will be turned on in transport networks. The NLRI design not only addresses specific operational scenarios that we have come across efficiently, but also enables additional extensions to be accommodated in future, flexibly and efficiently. If the goal was to introduce no changes at all or to intentionally retrofit an existing SAFI, then BGP-LU alone could be deployed with a separate underlay IP assigned for each color or intent. There isn’t a need to do much more IMHO. Also, we once again respectfully disagree that the CAR NLRI definitions are a fundamental change to BGP. Plenty of existing BGP SAFIs have introduced similar extensions to NLRI – starting with BGP-LU for label/label-stack to EVPN with route-type specific definitions and BGP-LS with TLVs, to name a few. Srihari> If the Key/Non-Key is useful for future extension of BGP, then we should not include this for intent-aware routing application only. We can debate if the key/non-key structure as proposed is valid for general BGP extensions and evaluate from that perspective. Like I had mentioned before, we (IDR) has to review the information to be encoded into BGP attribute field vs these key/non-key field. Rather than make the CAR NLRI extensions hardwired, we are taking the opportunity to provide a structured definition with a route-type and TLVs for per-route data such as label, SID, prefix-SID etc. Not a fundamental change. And there are no rules in IDR that non-key info or TLVs are disallowed in a BGP NLRI. Fears regarding arbitrary misuse are misplaced since any definitions do go through IDR WG review. Please also see some of the specific clarifications inline (DR>>) From: Srihari Sangli Date: Tuesday, December 14, 2021 at 10:13 PM To: "draft-dskc-bess-bgp-...@ietf.org" , "i...@ietf.org" , "bess@ietf.org" Subject: Re: Questions/concerns about BGP Color-Aware Routing (CAR) Resent-From: Resent-To: , , , , , , , , , , Resent-Date: Tuesday, December 14, 2021 at 10:13 PM Hello, I am not sure if my email reached the authors and hence resending my email. I would like to know the comments from the authors of draft-dskc-bess-bgp-car draft. Thanks. Thanks & Regards, srihari… From: Srihari Sangli Date: Thursday, 18 November 2021 at 1:06 PM To: "draft-dskc-bess-bgp-...@ietf.org" , "i...@ietf.org" , "bess@ietf.org" Subject: Questions/concerns about BGP Color-Aware Routing (CAR) Hi, Folks: This is regarding draft-dskc-bess-bgp-car-03 . I have reviewed the previous presentations & discussions on IDR wg meetings and mailer. In preparation for the upcoming IDR interim, I am raising concerns about CAR proposal to establish end-to-end intent-aware paths. Can the authors of the draft respond to these. IMO BGP CAR is an overkill for what we need. Some of the proposed changes in CAR proposal look to me as pretty fundamental to BGP. While “any” protocol extensions are possible, IMHO we should review the trade-offs. I see the CAR authors are trying to solve the same problem that BGP Classful Transports aka BGP-CT solves in a different way. My obj
Re: [bess] Questions/concerns about BGP Color-Aware Routing (CAR)
Hello,
I am not sure if my email reached the authors and hence resending my email. I
would like to know the comments from the authors of draft-dskc-bess-bgp-car
draft. Thanks.
Thanks & Regards,
srihari…
From: Srihari Sangli
Date: Thursday, 18 November 2021 at 1:06 PM
To: "draft-dskc-bess-bgp-...@ietf.org" ,
"i...@ietf.org" , "bess@ietf.org"
Subject: Questions/concerns about BGP Color-Aware Routing (CAR)
Hi, Folks:
This is regarding draft-dskc-bess-bgp-car-03 . I have reviewed the previous
presentations & discussions on IDR wg meetings and mailer. In preparation for
the upcoming IDR interim, I am raising concerns about CAR proposal to establish
end-to-end intent-aware paths. Can the authors of the draft respond to these.
IMO BGP CAR is an overkill for what we need. Some of the proposed changes in
CAR proposal look to me as pretty fundamental to BGP. While “any” protocol
extensions are possible, IMHO we should review the trade-offs. I see the CAR
authors are trying to solve the same problem that BGP Classful Transports aka
BGP-CT solves in a different way. My objection is – while we want to provide
alternative solution to classful transports, we don’t want to take BGP protocol
constructs to orthogonal direction which is not good for both operators and
vendors.
Personally, when I compare BGP CAR to BGP-CT, the BGP-CT is a natural extension
of existing IP-VPN mechanism. I have not seen much discussion on what’s missing
in BGP-CT and I’m sure more discussions may lead to improvements (if any) in
that proposal. I propose we review BGP CT proposal and provide suggestions to
improve it. It seems better bang for buck than introducing new concepts in BGP
which seems suboptimal and complexity from protocol extensions.
Following is the list comments/objections (not a complete list) to the CAR
proposal. Please see below for more details.
1. Color ambiguity: As per details in section 2.9.3 and 2.8 of the draft,
the color represents the intent within the color domain (which can span across
IGP/AS domains) and as authors describe it, it is under a common
administration. I have following observations and objections related to this.
· The intent is present in two places : NLRI and attribute. This leads
confusion as to which one to believe.
· Even though we achieve some mapping across domains under common
“color” administration,
· For CAR NLRIs with LCM, implementation can become complicated to deal
with color present in NLRI and color present in LCM, the effective color can
vary from prefix to prefix and this may end up inefficient data storage and
prefix management.
· It also adds operational complexity for troubleshooting to trace the
routes and color across hops, multiple RRs and different domains. The operator
has to track the effective color, sometimes it will be the color in the NLRI,
and sometimes it may be in LCM, and it has to be tracked on a hop by hop basis
along the multi-domain path – thus making it impractical or very difficult to
track prefix and its effective color.
· One may end up with routes as below. These are two different prefixes
as the color is different. But LCM makes them comparable. So can they be
considered as multipaths ? Can either of the paths be used for route resolution
? If one has to be preferred over other route, what is the selection criteria
and why. The draft does not provide details:
Route1: Prefix:1.1.1.1, Color 100; attribute local-pref 10
Route2: Prefix:1.1.1.1, Color 200; attribute LCM 100, local-pref 20
· With ADD-PATH, multiple paths for the prefix {E,C} get advertised,
but the identity of the originator of the route will be lost. For
troubleshooting, it may be very useful to know who originated the route,
especially with color mapping across domains.
2. CAR NLRI encoding: In section 2.9 of the 03 version, the non-key
fields can have “Transitive” bit. This is going towards the attribute
definition way. While this may be a good idea to provide key and non-key
structure for managing prefixes, I am not sure if the added complexity would be
justified.
· This is going towards a mode where NLRI can become very big with many
objects can exist within NLRI as non-key fields. This may also lead to more
discussions when a new object is introduced as to should it be in
attribute-only or as non-key field only in NLRI or both, leading to
interoperable issues and misinterpretations. IMHO the use case does not mandate
or lead to such a big change in NLRI encoding.
· I understand that moving label from prefix SID to the NLRI may
improve packing, but it is not clear if there is a definite gain. Even if
there is some gain, the number of labeled routes in any network would be
relatively small thus making gain insignificant. We know that operators attach
communities to NLRIs that may bring i
[bess] Questions/concerns about BGP Color-Aware Routing (CAR)
Hi, Folks:
This is regarding draft-dskc-bess-bgp-car-03 . I have reviewed the previous
presentations & discussions on IDR wg meetings and mailer. In preparation for
the upcoming IDR interim, I am raising concerns about CAR proposal to establish
end-to-end intent-aware paths. Can the authors of the draft respond to these.
IMO BGP CAR is an overkill for what we need. Some of the proposed changes in
CAR proposal look to me as pretty fundamental to BGP. While “any” protocol
extensions are possible, IMHO we should review the trade-offs. I see the CAR
authors are trying to solve the same problem that BGP Classful Transports aka
BGP-CT solves in a different way. My objection is – while we want to provide
alternative solution to classful transports, we don’t want to take BGP protocol
constructs to orthogonal direction which is not good for both operators and
vendors.
Personally, when I compare BGP CAR to BGP-CT, the BGP-CT is a natural extension
of existing IP-VPN mechanism. I have not seen much discussion on what’s missing
in BGP-CT and I’m sure more discussions may lead to improvements (if any) in
that proposal. I propose we review BGP CT proposal and provide suggestions to
improve it. It seems better bang for buck than introducing new concepts in BGP
which seems suboptimal and complexity from protocol extensions.
Following is the list comments/objections (not a complete list) to the CAR
proposal. Please see below for more details.
1. Color ambiguity: As per details in section 2.9.3 and 2.8 of the draft,
the color represents the intent within the color domain (which can span across
IGP/AS domains) and as authors describe it, it is under a common
administration. I have following observations and objections related to this.
* The intent is present in two places : NLRI and attribute. This leads
confusion as to which one to believe.
* Even though we achieve some mapping across domains under common
“color” administration,
* For CAR NLRIs with LCM, implementation can become complicated to
deal with color present in NLRI and color present in LCM, the effective color
can vary from prefix to prefix and this may end up inefficient data storage and
prefix management.
* It also adds operational complexity for troubleshooting to trace
the routes and color across hops, multiple RRs and different domains. The
operator has to track the effective color, sometimes it will be the color in
the NLRI, and sometimes it may be in LCM, and it has to be tracked on a hop by
hop basis along the multi-domain path – thus making it impractical or very
difficult to track prefix and its effective color.
* One may end up with routes as below. These are two different
prefixes as the color is different. But LCM makes them comparable. So can they
be considered as multipaths ? Can either of the paths be used for route
resolution ? If one has to be preferred over other route, what is the
selection criteria and why. The draft does not provide details:
Route1: Prefix:1.1.1.1, Color 100; attribute local-pref 10
Route2: Prefix:1.1.1.1, Color 200; attribute LCM 100, local-pref 20
* With ADD-PATH, multiple paths for the prefix {E,C} get advertised,
but the identity of the originator of the route will be lost. For
troubleshooting, it may be very useful to know who originated the route,
especially with color mapping across domains.
1. CAR NLRI encoding: In section 2.9 of the 03 version, the non-key fields
can have “Transitive” bit. This is going towards the attribute definition way.
While this may be a good idea to provide key and non-key structure for managing
prefixes, I am not sure if the added complexity would be justified.
* This is going towards a mode where NLRI can become very big with many
objects can exist within NLRI as non-key fields. This may also lead to more
discussions when a new object is introduced as to should it be in
attribute-only or as non-key field only in NLRI or both, leading to
interoperable issues and misinterpretations. IMHO the use case does not mandate
or lead to such a big change in NLRI encoding.
* I understand that moving label from prefix SID to the NLRI may improve
packing, but it is not clear if there is a definite gain. Even if there is
some gain, the number of labeled routes in any network would be relatively
small thus making gain insignificant. We know that operators attach communities
to NLRIs that may bring in uniqueness, so you may be optimizing for a
non-practical use case. I feel this is an academic exercise. The Prefix-SID has
been standardized at IDR (rfc8669) and has been deployed in many networks
already. I have not seen discussions on NLRI packing as an issue raised by any
operator. Also, I’m not convinced if it is worth going through protocol
modifications and implementations across networks, as the so called “packing
issue” will continue to exist until old
Re: [bess] [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)
Mustapha, I think Shraddha is pointing about the paragraph “When providing best-effort connectivity…” where it specifically talks about fallback to best-effort and if so, perform the resolvability check on the service-SID. Going by what you are saying that its general behavior of SRv6 policy, there is no need to over specify that it SHOULD check for resolvability and need for SRH. srihari… On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) from spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> on behalf of mustapha.aissa...@nokia.com<mailto:mustapha.aissa...@nokia.com> said > [External Email. Be cautious of content] Hi Shraddha, An implementation can allow any fallback strategy, including multiple levels of fallback, but the backup path you are describing is simply the general behavior of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is the top SID. So, the service SID will indeed be pushed into a SRH and the End SID is looked up by the ingress PE to forward the packet. It does not matter if the End SID is from base topology of from a flex-algo topology. Regards, Mustapha. From: spring On Behalf Of Shraddha Hegde Sent: Tuesday, July 20, 2021 5:56 AM To: Robert Raszuk Cc: spr...@ietf.org; bess@ietf.org Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07) Good to know the intention is to support fallback for Srv6. The way current text is written, it implies service SID is always in the destination address. And hence service SID should be resolvable. This is not the case when a service SID Corresponding to flex-algo wants to fallback on best effort services. The destination address cannot carry Service SID for fallback cases and hence it need not be resolved. I suggest that the authors add below text in bold to the draft. “When providing best-effort connectivity or flex-algo connectivity to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. “ “In some cases a service prefix intending to use flex-algo paths may want fallback on best effort paths when a flex-algo path isn’t available. The fallback behavior SHOULD be governed by local policies. The destination address SHOULD contain the best-effort locator based END SID of the egress PE and the SRH SHOULD contain the service SID. Service SID resolvability SHOULD NOT be checked on the ingress for this case.” Rgds Shraddha Juniper Business Use Only From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Tuesday, July 20, 2021 12:04 PM To: Shraddha Hegde mailto:shrad...@juniper.net>> Cc: spr...@ietf.org<mailto:spr...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07) [External Email. Be cautious of content] Shraddha, > that authors don’t intend to support any form of tunnelling for SRv6 > because it is not optimal. Is that the right read? Quite the opposite. It is the local operator's choice (not the draft authors) to decide to fall back to best effort or to drop. Thx, R. On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde mailto:shrad...@juniper.net>> wrote: Robert, What do you mean by SR? is it SR-MPLS or SRv6. My question is about draft-ietf-bess-srv6-services and applies only to SRv6. Let me repeat the question. Do the authors intend to support the case of fallback from SRv6 flex-algo to SRv6 best effort transport for SRv6 Services or not? From your vague answer it appears that authors don’t intend to support any form of tunnelling for SRv6 because it is not optimal. Is that the right read? Rgds Shraddha Juniper Business Use Only From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Tuesday, July 20, 2021 11:17 AM To: Shraddha Hegde mailto:shrad...@juniper.net>> Cc: Aissaoui, Mustapha (Nokia - CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; Rabadan, Jorge (Nokia - US/Mountain View) mailto:jorge.raba...@nokia.com>>; Rajesh M mailto:mraj...@juniper.net>>; Rajesh M mailto:40juniper@dmarc.ietf.org>>; Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; gdawra.i...@gmail.com<mailto:gdawra.i...@gmail.com>; Clarence Filsfils (cfilsfil) mailto:cfils...@cisco.com>>; bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; spr...@ietf.org<mailto:spr...@ietf.org>; b...@ans.net<mailto:b...@ans.net>; Srihari Sangli mailto:ssan...@juniper.net>>; bess@ietf.org<mailto:bess@ietf.org> Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07) [External Email. Be
[bess] BGP CAR SAFI NLRI format
Hello, Looking at the archives on this topic, there was a small discussion about the structure of the NLRI as proposed in the BGP CAR draft. The conversation was not conclusive and here’s my thought and a question related to the topic. While the proposed NLRI format enables NLRI types to be encoded and provides extensibility, it also lists the key and non-key fields. If we go down this path, there may be a tendency to add more fields into the NLRI. While ‘Type-specific Key Fields’ may be justifiable (for obvious reasons of identifying the NLRI), the ‘Type-specific Non-Key Fields’ has a potential to grow. Also, this is a departure from base BGP specification of NLRI and attributes where attributes carry the common information and non-key fields. Am wondering if the authors have done more investigation on this. Thanks. srihari… Juniper Business Use Only ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Working group document discussion - any request for time ?
Hi, Folks: I request a slot to present the following. Draft : draft-ssangli-idr-bgp-vpn-srv6-plus-01.txt Speaker : Srihari Sangli Duration : 10 mins srihari… On 09/07/19, 4:50 AM BESS on behalf of Mankamana Mishra (mankamis) from bess-boun...@ietf.org<mailto:bess-boun...@ietf.org> on behalf of manka...@cisco.com<mailto:manka...@cisco.com> said > Hi All, We have dedicated session in coming IETF to discuss working group documents. If any one wants some topic to be discussed, please let me know. We can put it in agenda & allocate time for discussion . Thanks Mankamana ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
