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

Hi,

> So do you agree that with distinct CLUSTER_ID on the

> RRs/ABRs, there is an issue?

I do. But I call it misconfiguration.

Of course you can/will say that in most if not all BGP implementations
configuring CLUSTER_ID is optional and by default BGP RTR_ID is taken which
makes it different by default RR by RR - but oh well - there is few things
in BGP one is expected to just know before getting to the keyboard.

Setting next-hop-self on RRs in IBGP is yet another topic for discussion,
but I don't think we need to really spend time on it now.

> Configuring same CLUSTER_ID, if feasible, is another way to deal with it,
agree.

Glad we agree on that one.

Thx,
R.

On Fri, Feb 16, 2024 at 10:01 PM Kaliraj Vairavakkalai <kaliraj@juniper.net>
wrote:

> OK, now onto the technical discussion,
>
>
>
> > On the technical side just configured same CLUSTER_ID on both RRs/ABRs
> and there is no issue.
>
>
>
> So do you agree that with distinct CLUSTER_ID on the RRs/ABRs, there is an
> issue?
>
>
>
> Configuring same CLUSTER_ID, if feasible, is another way to deal with it,
> agree.
>
>
>
> Thanks
>
> Kaliraj
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Friday, February 16, 2024 at 12:27 PM
> *To: *Kaliraj Vairavakkalai <kaliraj@juniper.net>
> *Cc: *Igor Malyushkin <gmalyushkin@gmail.com>, Natrajan Venkataraman <
> natv@juniper.net>, idr@ietf. org <idr@ietf.org>, Susan Hares <
> shares@ndzh.com>, Keyur Patel <keyur@arrcus.com>, Jeff Haas <
> jhaas@juniper.net>, idr-chairs@ietf.org <idr-chairs@ietf.org>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Kaliraj & Sue,
>
>
>
> > The text in this draft has been reviewed by WG, as part of draft-ct.
>
>
>
> I do not agree with this explanation/justification. If someone is not
> interested at all in CT draft lot's of smuggled features and extensions may
> not get sufficient attention.
>
>
>
> So I am very glad chairs recommended to remove it from the CT draft into a
> separate document. As such I am afraid it would have a hard time to even
> become an IDR WG document so I am not sure if the fact that some orthogonal
> text was pulled out of WG document makes is automatically a WG document.
>
>
>
> On the technical side just configured same CLUSTER_ID on both RRs/ABRs and
> there is no issue.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
> On Fri, Feb 16, 2024 at 8:28 PM Kaliraj Vairavakkalai <kaliraj@juniper.net>
> wrote:
>
> Hi Robert, Igor,
>
>
>
> To provide some context –
>
>
>
> The text in this draft has been reviewed by WG, as part of draft-ct.
>
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-23.html#name-avoiding-loops-between-rout
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-23.html*name-avoiding-loops-between-rout__;Iw!!NEt6yMaO-gk!HK1hMYBmWLPwtF2YCSAargxA_wbJrNC8lBcRa2wgLKBTusa6Yay2o3Ttz1O02ODTI36LdYU1PN5-1jQ3$>
>
>
>
> During the WG Directorate and Chair reviews of draft-ct, it was suggested
> to pull out this section to a new draft, as the described problem is not
> specific to CT.
>
>
>
> This document history is described in:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00#appendix-A.1
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00*appendix-A.1__;Iw!!NEt6yMaO-gk!HK1hMYBmWLPwtF2YCSAargxA_wbJrNC8lBcRa2wgLKBTusa6Yay2o3Ttz1O02ODTI36LdYU1PF2tKmx3$>
>
>
>
> I will cleanup the Author and Contributor list, to not inherit from
> draft-CT.
>
>
>
> About whether the problem being described is real or not, we can have
> further discussions, and clarify draft text as required. We hit these
> issues in our testing with LU and CT, and I think it is very likely to hit
> it in the field. That’s why it is important to document it.
>
>
>
> Just wanted to first clear the confusion on the origin/history of this
> draft. So that we can focus on technical discussion.
>
>
>
> IDR-chairs may want to add something.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Friday, February 16, 2024 at 9:49 AM
> *To: *Igor Malyushkin <gmalyushkin@gmail.com>
> *Cc: *Kaliraj Vairavakkalai <kaliraj@juniper.net>, Natrajan Venkataraman <
> natv@juniper.net>, idr@ietf. org <idr@ietf.org>
> *Subject: *Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
>
> *[External Email. Be cautious of content]*
>
>
>
> 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 <gmalyushkin@gmail.com>
> 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 <robert@raszuk.net>:
>
> 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00*appendix-C-2__;Iw!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl8ErvDlz$>
>
> 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 <robert@raszuk.net> 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: <internet-drafts@ietf.org>
> Date: Fri, Feb 16, 2024 at 2:23 PM
> Subject: I-D Action: draft-ietf-idr-bgp-fwd-rr-00.txt
> To: <i-d-announce@ietf.org>
> Cc: <idr@ietf.org>
>
>
>
> 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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl6sQStEm$>
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-00__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl5yt5xQa$>
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl_q06C-f$>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl9CJwiz8$>
>
>