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

[Donatas Abraitis <[e-mail]>]

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]>
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]> 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]> 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]> 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]>
>>>> *Date: *Tuesday, October 22, 2024 at 1:59 PM
>>>> *To: *Krishnaswamy Ananthamurthy (kriswamy) <[e-mail]>
>>>> *Cc: *[e-mail] <[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]>
>>>> 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]
>>>>
>>>> _______________________________________________
>>>> Idr mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>>>
>>> --
>>> Donatas
>>>
>>
>
> --
> Donatas
>


-- 
Donatas