Rob,
Lots of thanks for a very important response!
So, the RFC defines proto-route-type (with lots of details) and bp:route-type (
mentioned just once without any description, examples etc.)…
Instead it says that the prefix bp: means a definition that is imported from
the BGP Policy
Model<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-17> draft
(expired).
I have looked up this draft and this is what it says about route-type:
leaf route-type {
type enumeration {
enum internal {
description
"route type is internal.";
}
enum external {
description
"route type is external.";
}
}
description
"Condition to check the route type in the route update.";
}
But RFC 9607 has the following identities under the proto-route-type:
identity bgp-internal {
base proto-route-type;
description
"Identity for routes learned from internal BGP (IBGP).
It is only applicable to BGP routes.";
reference
"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
}
identity bgp-external {
base proto-route-type;
description
"Identity for routes learned from external BGP (EBGP).
It is only applicable to BGP routes.";
reference
"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
}
Is this a duplication? An error? Or something else?
And how can I express a condition that refers to EVPN, MCAST-VPN or BGP-LS (RFC
7752<https://datatracker.ietf.org/doc/html/rfc7752>) routes of a specific NLRI
Type in a BGP policy?
Regards,
Sasha
From: Robert Raszuk <[email protected]>
Sent: Thursday, June 6, 2024 7:09 PM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [EXTERNAL] Re: Routing policies for AFI/SAFI with "typed" NLRI in
RFC 9067
Hey,
This is when YANG model RFC fun begins :)
So for BGP we have two different route-types (ibgp vs ebgp) and route-type
within NLRIs.
Any YANG expert can correct me if my reading of this is wrong but the way I
understand this is that the former is of type "identityref" and the latter is
of type "enumeration".
For identityref it is actually well explained in the RFC, but I failed to find
any explanation for route-type of "enumeration" type. Logically enumeration
would mean 1..2..3 ..4...5 etc ... so exactly what would be required to
recognize EVPN route-types.
Best,
Robert
PS. A bit outside of your question I do not feel that comfortable with typed
NLRIs considering no capability negotiation. Perhaps it would be useful to
enhance BGP capabilities with NLRI types at some point. The obvious issue is
that we would need dynamic capabilities for that to be practical and
operationally deployable.
On Thu, Jun 6, 2024 at 5:42 PM Alexander Vainshtein
<[email protected]<mailto:[email protected]>> wrote:
Robert,
Lots of thanks for a prompt response.
The examples that I see in the RFC refer to protocol-specific route types (like
IS-IS Level 1 or Level 2).
I am not sure the RFC covers “typed NLRI”. Do I miss something?
Regards,
Sasha
From: Robert Raszuk <[email protected]<mailto:[email protected]>>
Sent: Thursday, June 6, 2024 6:23 PM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [EXTERNAL] Re: Routing policies for AFI/SAFI with "typed" NLRI in RFC
9067
Hi Sasha,
But the RFC9067 supports route type match under policy definitions so I am not
sure what the question is :)
| +--rw match-route-type
| +--rw route-type* identityref
| +--rw bp:bgp-conditions
| +--rw bp:med-eq? uint32
| +--rw bp:origin-eq? bt:bgp-origin-attr-type
| +--rw bp:next-hop-in* inet:ip-address-no-zone
| +--rw bp:afi-safi-in* identityref
| +--rw bp:local-pref-eq? uint32
| +--rw bp:route-type? enumeration
On Thu, Jun 6, 2024 at 4:51 PM Alexander Vainshtein
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I have looked up RFC 9067<https://datatracker.ietf.org/doc/html/rfc9067> in
order to understand whether it supports ability to define NRLI-type-specific
conditions in policies that are applied to AFI/SAFI that use “typed” NLRI, and
I did not find anything relevant.
I wonder if the need for such conditions have ever been considered. If not, can
somebody please explain why?
One example that comes to my mind is a policy that would apply specific
actions to IP Prefix (EVPN Type 5, RFC
9136<https://datatracker.ietf.org/doc/html/rfc9136>) routes with a specific
destination while ignoring EVPN routes of other types.
For comparison, Section 5.4 of RFC
7606<https://datatracker.ietf.org/doc/html/rfc7606#section-5.4> defines
dedicated rules for handling the situations in which a BGP speaker supports
only some, but not all NLRI in a given “typed” AFI/SAFI.
Your timely feedback would be highly appreciated.
Regards, and lots of thanks in advance,
Sasha
Disclaimer
This e-mail together with any attachments may contain information of Ribbon
Communications Inc. and its Affiliates that is confidential and/or proprietary
for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
_______________________________________________
rtgwg mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
rtgwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
