Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt

[Robert Raszuk <[e-mail]>]

Hey Igor,

Well I think there is no problem to be solved here to start with.

It looks to me like someone completely unfamiliar with IETF process or even
BGP Route Reflection took a CT draft and deleted most text except Appendix
A, Co-Authors, Contributors and part of References :)

I am actually surprised that IETF Submit script allowed to post it with
such document name. Looks like it is broken.

Cheers,
R.


On Fri, Feb 16, 2024 at 6:37 PM Igor Malyushkin <[e-mail]>
wrote:

> Hello all,
>
> Agreed with Robert. I thought too I missed the adoption call and was
> surprised to see the doc already adopted.
>
> About CT parts, to me they look like a some form of advertising, not sure
> they are necessary to express the problem statement at all. Not to mention
> that it looks like AIGP solves the problem in general.
>
> пт, 16 февр. 2024 г. в 19:27, Robert Raszuk <[e-mail]>:
>
>> All,
>>
>> > draft-ietf-idr-bgp-fwd-rr-00.txt
>>
>> Also please kindly indicate why this text is posted as an IDR WG document
>> as the format of the name suggests ...
>>
>> I do not recall any single discussion on this proposal on the IDR WG
>> list.
>>
>> Are the authors, so many co-authors and a large list of contributors not
>> aware about the draft naming convention not to mention BGP Route Reflection
>> principles of operation ?
>>
>> The Ack section also seems copied from CT draft ... not too mention it
>> says this:
>>
>> The decision to not reuse SAFI 128 and create a new address-family to
>> carry these transport-routes was based on suggestion made by Richard
>> Roberts and Krzysztof Szarkowicz.¶
>> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00#appendix-C-2>
>> I think it would be simply best if you delete this doc from datatracker
>> at this point.
>>
>> Cheers,
>> Robert
>>
>>
>>
>> On Fri, Feb 16, 2024 at 5:24 PM Robert Raszuk <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> I have two comments on your draft:
>>>
>>> #1 - RFC4456 does not assume RRs not to be in the data plane. Quite
>>> contrary when this RFC was originally written all RRs were in the
>>> forwarding path as most networks did not use any form of encapsulation. Yes
>>> I do recall running network which did not run MPLS nor SR :) In fact the
>>> mentioned above encapsulations moved the RRs out of data path as
>>> encapsulated packets did not need IP lookup.
>>>
>>> #2 - What you are saying in respect to CLUSTER_LIST is incorrect. The
>>> entire point of CLUSTER_LIST is not to allow paths with local CLUSTER_ID to
>>> enter Route Reflector in the first place. Quote from RFC4456:
>>>
>>>
>>> *If the local CLUSTER_ID is found in the CLUSTER_LIST, the advertisement
>>> received SHOULD be ignored**.*
>>>
>>> Best path has nothing to do with it. The augmentation to BGP best path
>>> selection only aims for consistent selection not to prevent the loops.
>>>
>>> Conclusion: What you are describing is a route reflector
>>> misconfiguration not a protocol bug.
>>>
>>> ** "ignored - really means dropped here.
>>>
>>> Cheers,
>>> Robert
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: <[e-mail]>
>>> Date: Fri, Feb 16, 2024 at 2:23 PM
>>> Subject: I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>>> To: <[e-mail]>
>>> Cc: <[e-mail]>
>>>
>>>
>>> Internet-Draft draft-ietf-idr-bgp-fwd-rr-00.txt is now available. It is
>>> a work
>>> item of the Inter-Domain Routing (IDR) WG of the IETF.
>>>
>>>    Title:   BGP Route Reflector in Forwarding Path
>>>    Authors: Kaliraj Vairavakkalai
>>>             Natrajan Venkataraman
>>>    Name:    draft-ietf-idr-bgp-fwd-rr-00.txt
>>>    Pages:   8
>>>    Dates:   2024-02-16
>>>
>>> Abstract:
>>>
>>>    The procedures in BGP Route Reflection (RR) spec [RFC4456] primarily
>>>    deal with scenarios where the RR is not in forwarding path, and is
>>>    reflecting BGP routes with next hop unchanged.
>>>
>>>    These procedures can sometimes result in traffic forwarding loops in
>>>    deployments where the RR is in forwarding path, and is reflecting BGP
>>>    routes with next hop set to self.
>>>
>>>    This document specifies approaches to minimize possiblity of such
>>>    traffic forwarding loops.  One of those approaches updates path
>>>    selection procedures specified in Section 9 of BGP RR.  [RFC4456]
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/
>>>
>>> There is also an HTMLized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00
>>>
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>
>>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>