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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Please see zzh> below.



Juniper Business Use Only
From: Idr <[e-mail]> On Behalf Of Robert Raszuk
Sent: Saturday, January 21, 2023 6:12 AM
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)

[External Email. Be cautious of content]

Hello Sue,

Actually my point is very simple.

Subject draft defines derived community for Route Target.

But Route Target is not formally defined in any RFC nor draft except the original RFC4360. It has no dedicated registry. So in general it is a very loose term or rather just a name. Anyone can call his extended community a Route Target and there seems to be no specific policy other then the primary definition of RFC4360 which can be used to block it.

Zzh> While there have been one-off values beside the 0x02 sub-type, the semantics of Route Target is clear.

With that I am just suggesting that free form name should not be used as a base of any normative document. Moreover if any implementer wants to add this functionality to his code base it must push the complexity to the user to explicitly define source of the mapping.

Zzh> There is already RFC 4684 based on Route Target though 😊 In fact, RT Constrain implementations can and should be enhanced to handle newer types for Route Targets (e.g., EVPN ES-Import Route Target) even though we don’t need to update RFC4684.

So this is just a name thing. The draft in it's technical content seems cool and useful.

Zzh> I do agree that the draft can/need be more stringent with the sub-type 0x02 wording. However, I don’t think it is a problem to use RT-derived-community as the name.

> [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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7153/__;!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qfpUNUuY$> (which modifies RFC4360)

Very glad you mentioned RFC7153 as for some reason it does not redefine Route Targets. Just extends it with few new values.

In fact it also defines Route Target which no longer follows the rule that low-order octet must be 0x02 .. Namely it defines a "UUID-based Route Target" which low order octet is now 0x11 (sub-type value 0x0011) as it was just next available .. Subject draft however only defines one single RT-derived-EC in this registry Transitive IPv6-Address-Specific Extended Community Types 0x0015 there (btw draft has a bug as it says 0x15 - which is incorrect in respect to this very registry sub-types).

Zzh> There is no issue with 0x15, as it is indeed only for those RTs with separate type/sub-type:

   IANA has assign a new sub-type "RT-derived-EC" with value 0x15 in the
   following registries:

   *  Transitive Two-Octet AS-Specific Extended Community Sub-Types

   *  Transitive Four-Octet AS-Specific Extended Community Sub-Types

   *  Transitive IPv4-Address-Specific Extended Community Sub-Types

   *  Non-Transitive Opaque Extended Community Sub-Types

   *  EVPN Extended Community Sub-Types

   IANA has also assigned a new type "RT-derived-EC" with value 0x0015
   in the following registry:

   *  Transitive IPv6-Address-Specific Extended Community Types

Zzh> As the subject draft was written, we did not notice the UUID RT. We can certainly request an additional value, say 0x0016 to indicate it is derived from UUID RT.
Zzh> In fact, UUID RT should not have been allocated from that registry, because it is not “IPv6 Address” specific. A new “Opaque 20-Octet” Extended Community should have been defined along with “IPv6 Address Specific” Extended Community, but that’s water under the bridge now.

So even at this point it is not clear which Route Target should be mapped to it 0x0002 or 0x0011. Note selected the current set:

      0x0002             Route Target
      0x0003             Route Origin
      0x0004             OSPFv3 Route Attributes (deprecated)
      0x0005              IPv6-Address-Specific IFIT Tail Community
      0x000b             VRF Route Import
      0x000c             Flow-spec Redirect to IPv6
      0x0010             Cisco VPN-Distinguisher
      0x0011             UUID-based Route Target

The subject draft says:

If and when additional Extended Community types are defined with a Route Target sub-type

Question: Where is Route Target sub-type defined and what is its value ?

Zzh> What if it’s rewarded as following:

  If and when additional Extended Community types and/or sub-types are defined for Route Target purposes,
  the "RT-derived-EC" sub-type and/or type may also be registered for those.

Zzh> Thanks.
Zzh> Jeffrey

Thank You,
R.

On Sat, Jan 21, 2023 at 2:56 AM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Sent: Friday, January 20, 2023 3:58 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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  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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc7153/__;!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qfpUNUuY$> (which modifies RFC4360)
And the IANA registries insufficient:

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml__;!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qThvFrBC$>
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#transitive<https://urldefense.com/v3/__https:/www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml*transitive__;Iw!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qU0fxTYq$>
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#non-transitive<https://urldefense.com/v3/__https:/www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml*non-transitive__;Iw!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qRKJpEnV$>
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml__;!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qThvFrBC$>

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://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/uwY3Hdrk2ned2hqMimpB6alhd9U/__;!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qUrGCPE0$>

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://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!CHCcK6tyymajGv3uuhUIrAPL7r49im6ebnEtP2RtcfDNGKBhHlAwdqE9qD5wAsfRK_jgHIS3qeyOCSD0$>