Re: [Idr] WG adoption call for draft-zzhang-idr-rt-derived-community-03 (12/27 to 1/13)

[Susan Hares <[e-mail]>]

Robert:
[WG chair hat off]
Questions below for understanding your proposal.

Robert here’s my understanding of your logical argument
1. RT were defined as type values of
   [High: 0x00, Low: 0x02],
   [high:0x01, Low:0x01]
  [high:0x02,  Low:0x02]

2. some [unspecified] documents
Define high order values
(something besides 0x00, 0x01, or 0x02]

3. draft-zzhang-idr-rt-derivced-community-02
Text (which text is unspecified) extends its algorithm to
RFC4360 type pairs for RTs
   [High: 0x00, Low: 0x02],
   [high:0x01, Low:0x01]
  [high:0x02,  Low:0x02]

And other [unspecified pairs] (see #2).

4.  You feel this is unwise and suggest
3 options.

I need a bit more details on your logic.

Glad to chat on Monday (1/23) via phone.

Cheers, Sue


From: Robert Raszuk <[e-mail]>
Sent: Friday, January 20, 2023 3:58 PM
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] WG adoption call for draft-zzhang-idr-rt-derived-community-03 (12/27 to 1/13)

Dear Sue and WG, I would like to reiterate one major issue with this draft in the current form. Route Targets have been formally defined in RFC4360 as an extended community with high order octet of 0x
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzE3OTg2ZjJiZjcxYzQwODRlNzgwMDg3NDNhZmI0YTQwLzE2NzQyNDgzMTcuNDE=#key=4e592a08905081687abbce58ff466e84>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Dear Sue and WG,

I would like to reiterate one major issue with this draft in the current form.

Route Targets have been formally defined in RFC4360 as an extended community with high order octet of  0x00, 0x01, or 0x02 and low order octet of 0x02.

There are documents which do not formally update RFC4360, but define new high order octet extended community values and also call it  Route Targets. They usually reuse low-order octet value of 0x02.

[Sue]: Please specify the documents.  RFC7153 sets up IANA Registries for Extended Community (IETF and FCFS).
If these are registered, how does

The intention of this draft is to extend the notion of the Route Targets to cover any extended community with low-order octet value of 0x02 claiming this is de-facto unwritten standard.
[Can you indicate what text causes you to believe this draft is going beyond the subtypes defined by RF4360? ]


So with the above we have few options here:

Option 1 - We make an update to RFC4360 redefining RT as any high-order octet value with low-order octet of 0x02 then proceed with this draft.

or alternatively

Option 2 - Redefine this draft as a generic derived community where low-order octet is 0x02 without calling it RT.

or alternatively

Option 3 - Collect all documents which define RT with different high-order octet then 0x00, 0x01, or 0x02 and add them as a list to update RFC4360. And keep doing this each time someone wants to define a new high order octet type and call it RT.
[While my administrative hat things collecting all with specifying RTs is a good idea.
Why is the definitions given in https://datatracker.ietf.org/doc/rfc7153/ (which modifies RFC4360)
And the IANA registries insufficient:

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#transitive
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#non-transitive
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

Glad to chat about this in person as well
Sue



On Fri, Jan 20, 2023 at 9:30 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Greetings:

The IDR WG did a call for draft-zzhang-idr-rt-derived-community-03.txt.
https://mailarchive.ietf.org/arch/msg/idr/uwY3Hdrk2ned2hqMimpB6alhd9U/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxFjb0OwiAURl-lYTZcoFiok3FycXRwpIUK6Z9eqCYa393i4npOvvO9yYID2RXEp3SLO4DRhMFg68PD0eBSR2e8QgYwxisEi7A8L-XRYi8mZ4W_n8J4O1Rm8LY-A9kUpM-5yaV1yNlWVzUXEL1BF_eTfXnaziNwVeuqE02neCuZlk5pxrSSpekaaSQDXikppC65opLnqstVnBuHaY8mvpaerh_Z2J_5o88XdrlBrQ.MEUCIQDD0Gfcmdf5YzAOCAjz1HUu47o0BBXdkqsNOIr2jFy-EgIgPNeUhEKjYUefQ3yQPvrPXryJbjOQKa7D2aMdxMKRZ10>

We have received a lite support and no objections.
The IDR chairs are inclined to adopt this draft as a useful
addition to BGP.

As IDR document shepherd, I have queried the BESS and Grow WG
(from 1/20 to 2/3) to determine if there are any objections to adopting this draft.

The results of these queries to BESS and Grow will be summarized to this
Thread on 2/4.

Cheerily, Sue
([e-mail]<mailto:[e-mail]>)

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxFjUEOgyAURK9iWDd8vv4KdeVVUKESFRrAmNj07pVuup038-bN9riyrmJzzq_UARzHwZ3Jlof4hE27ddMeVpey8zaAmyK7VWwpC2_y1UFxV-0Da0izjib1fjpnPoYNUD5Ua-vBShxJKDJSCaEkNdoOpEkAtpJqUg1KTlisplhjGEzMfdTp3Bd-fRQy_cg_-nwBxbo36g.MEYCIQDWGv9BV_RKo252IYb3_YTnP_UhKkNvwzsR_DC2jUOYZQIhAPtG9CTBF192jZWgQp3ulUwk5epR4CGAqVhl3Jik_K1d>