[Idr] Re: FW: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt

["Krishnaswamy Ananthamurthy (kriswamy)" <[e-mail]>]

Hi Donatas,
                Operation section is added to the “01” version. Also added text on how to dynamically send this capability.
Thanks
Krishna


From: Donatas Abraitis <[e-mail]>
Date: Wednesday, October 23, 2024 at 12:33 PM
To: Robert Raszuk <[e-mail]>
Cc: Krishnaswamy Ananthamurthy (kriswamy) <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Idr] Re: FW: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
Also, we might need another Cease NOTIFICATION message that would tell us to retain the routes
(while _updating_ new route types) combined with Graceful-Restart Notification support?

On Wed, Oct 23, 2024 at 2:29 PM Donatas Abraitis <[e-mail]<mailto:[e-mail]>> wrote:
But then... Without dynamically sending (dynamic capability or another type of message?) this capability it's _hard_ to imagine how it would work correctly.

Clearly, as Robert said, the operational section is a MUST here.

On Wed, Oct 23, 2024 at 2:23 PM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
It is not as sweet as it looks :)

List of route types keeps getting extended in multi route-type AFI/SAFIs .. so you really never know what is supported by the peer unless you know how to operate your network well.

I think the proposal is a safety fuse to address not so well operated networks ...

Cheers,
R.

On Wed, Oct 23, 2024 at 12:21 PM Donatas Abraitis <[e-mail]<mailto:[e-mail]>> wrote:
What optional route types would be advertised? I mean if an implementation supports let's say EVPN, LS, etc. does it
include all of them or the _list_ should be configurable?

On Tue, Oct 22, 2024 at 10:12 PM Krishnaswamy Ananthamurthy (kriswamy) <kriswamy=[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,
Appreciate your quick review and feedback, and the following is the response.

#1 – Will update the text
#2 – Will expand the operation section and will consider your suggestion
#3 – Will discuss with co-authors and respond accordingly.

Thanks
Krishna


From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 22, 2024 at 1:59 PM
To: Krishnaswamy Ananthamurthy (kriswamy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] FW: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
All,

Actually I have a 3rd comment which appeared after I hit the send button.

Since you are really doing route type filtering here it seems to me that a much better suited mechanism for this would be an ORF message.

In fact it is also much more flexible - you can freely use it during BGP sessions being already established without need for session reset to enable reception of new service/new NLRI types.

A simple extension would be like Dynamic Route-Types support with most of the existing cfg/cli/show commands  or logging already in place.

Think about it ....

Cheers,
Robert


On Tue, Oct 22, 2024 at 6:08 PM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I have two comments on this draft.

#1

Draft says:

> This document defines an optional capability exchange of route types
> per AFI/SAFI such that BGP speakers negotiate the route types

Unfortunately BGP capabilities do not negotiate anything in BGP. Please search on number of discussions on this point on the list in the past.

So I recommend you change this into:

This document defines an optional capability exchange of route types per AFI/SAFI such that BGP speakers signal the route types

#2

Operational consideration is missing ...

The scenario where this draft could play a role is that operator enables mix of services between two nodes.

Now this mix of services is not symmetrical.

Today session does not come up and it is clear there is configuration mistake which needs to be corrected.

With this draft session will happily come up and only "supported" services by a peer as expressed in supported route types for a given AFI/SAFI peer will be sent.

How is this helping operator to consistently run the services ? If he would not count on exchanging those with the peer it would not be configured in the first place.

Bigger question how would a router signal that only partial of configured services operate within say EVPN AF ?

It seems that it would lead to really weak configuration habits in a style - enable all and see what get's exchanged.

In other words having ability to know what services/route types my peers support for a given AFI/SAFI seems cool. But only informationally.

Using this information for automated service propagation suppression/filtering is IMHO much less cool .. if at all a good thing.

Kind regards,
Robert

PS. And it may be interesting to see a section on how this may help to enable new route types dynamically on the existing running nodes and within existing established BGP sessions with many AFI/SAFIs. Of course assumption is that running operating systems on those nodes does support it already - but new services where not enable at boot time (BGP sessions establishment time).

Where am I going with this PS note ...

As we are really touching a new territory of signalling embedded route types (different NLRI formats) within single AFI/SAFI(s) perhaps this is good time to rethink it and write up Dynamic Route-Types proposal which could be signalled between nodes not really using BGP Capabilities semantics.


On Tue, Oct 22, 2024 at 12:58 AM Krishnaswamy Ananthamurthy (kriswamy) <kriswamy=[e-mail]<mailto:[e-mail]>> wrote:
IDR WG,

We have posted a new draft outlining route type capability to address BGP session reset whenever new route type is added to address families like EVPN.

https://datatracker.ietf.org/doc/html/draft-kriswamy-idr-route-type-capability

Request the WG to review and provide feedback/comments.

Thanks,
Krishna

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 21, 2024 at 5:51 PM
To: Keyur Patel <[e-mail]<mailto:[e-mail]>>, Krishnaswamy Ananthamurthy (kriswamy) <[e-mail]<mailto:[e-mail]>>, Lukas Krattiger (lkrattig) <[e-mail]<mailto:[e-mail]>>, Mankamana Mishra (mankamis) <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-kriswamy-idr-route-type-capability-00.txt
A new version of Internet-Draft
draft-kriswamy-idr-route-type-capability-00.txt has been successfully
submitted by Krishnaswamy Ananthamurthy and posted to the
IETF repository.

Name:     draft-kriswamy-idr-route-type-capability
Revision: 00
Title:    BGP Route Type Capability
Date:     2024-10-21
Group:    Individual Submission
Pages:    5
URL:      https://www.ietf.org/archive/id/draft-kriswamy-idr-route-type-capability-00.txt
Status:   https://datatracker.ietf.org/doc/draft-kriswamy-idr-route-type-capability/
HTMLized: https://datatracker.ietf.org/doc/html/draft-kriswamy-idr-route-type-capability


Abstract:

   BGP supports different route types, which defines the encoding of
   Network Layer Reachability Information (NLRI) for a some of the
   Address Family Identifier (AFI)/Subsequent Address Family Identifier
   (SAFI) like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on.  BGP
   speaker will reset the BGP session if a given route type is not
   supported.  This document defines an Optional Capabilities to
   exchange the route types supported for a given AFI/SAFI such that
   session are not reset.



The IETF Secretariat
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--
Donatas


--
Donatas


--
Donatas