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

[Kaliraj Vairavakkalai <[e-mail]>]

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

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

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 <[e-mail]>
Date: Friday, February 16, 2024 at 9:49 AM
To: Igor Malyushkin <[e-mail]>
Cc: Kaliraj Vairavakkalai <[e-mail]>, Natrajan Venkataraman <[e-mail]>, idr@ietf. org <[e-mail]>
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 <[e-mail]<mailto:[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]<mailto:[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://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 <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[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/<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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!AZEUHyTPYNlG9OKb52muKBAGkNew-0Po8FKLaviWSEg-Oqp4Bqg_H6hwb1DZEuJaszphNMHxl9CJwiz8$>