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

[Robert Raszuk <[e-mail]>]

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]> 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]> 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] <[e-mail]>
>> *Date: *Monday, October 21, 2024 at 5:51 PM
>> *To: *Keyur Patel <[e-mail]>, Krishnaswamy Ananthamurthy
>> (kriswamy) <[e-mail]>, Lukas Krattiger (lkrattig) <
>> [e-mail]>, Mankamana Mishra (mankamis) <[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]
>> To unsubscribe send an email to [e-mail]
>>
>