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

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.

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.

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

> [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)

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).

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 ?

Thank You,
R.

On Sat, Jan 21, 2023 at 2:56 AM Susan Hares <shares@ndzh.com> 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 <robert@raszuk.net>
> *Sent:* Friday, January 20, 2023 3:58 PM
> *To:* Susan Hares <shares@ndzh.com>
> *Cc:* idr@ietf.org
> *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/
> (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 <shares@ndzh.com> 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/
>
>
>
> 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
>
> (shares@ndzh.com)
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>