Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

[tom petch <[e-mail]>]

From: Dongjie (Jimmy) <[e-mail]>
Sent: 30 September 2022 06:12

Hi Tom,

Thanks for your comments on the terminology and the IANA section. Please see some replies inline:

> -----Original Message-----
> From: Idr [mailto:[e-mail]] On Behalf Of tom petch
> Sent: Thursday, September 29, 2022 4:23 PM
>
> From: Idr <[e-mail]> on behalf of Susan Hares
> <[e-mail]>
> Sent: 27 September 2022 18:30
>
> This begins a 2 week WG adoption and IPR call for
> draft-dong-idr-node-target-ext-comm-05.txt.
> https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/
>
> <tp>
> The protocol depends in part on whether or not a router is an ASBR.  I am
> used to seeing that term used in the context of OSPF and not of BGP.  I did
> find a usage in RFC7705 but note that that RFC felt it necessary to explain what
> an ASBR was.  Is the term ASBR well-understood in the context of BGP (as
> opposed to OSPF)?

As other folks kindly mentioned on the list, ASBR is a well-known term in BGP. While to make it clear, the authors have chosen to expand it at first use.

I also noticed your concerns below:

"The text in the I-D says
'If this node is a Route Reflector, ...'
'If this node is an Autonomous System Border Router (ASBR),  '
That is it, no other options, it is either or for a BGP speaker.
Is this adequate for an implementation, that is my doubt. "

This is a good point.

The current text in section 3 firstly describes the behavior which applies to all BGP nodes, then it gives the additional behavior when the node is an RR or an ASBR. Thus the intent here is not "either or" .

If this is not quite clear, we could rephrase it in next revision.

<tp2>
Yes please, this is my concern about the use of ASBR, not about expanding it or no.  The way that the I-D is formatted, with indents for Route Reflector  and ASBR, creates a doubt in my mind and a further item in that list for other cases, would clarify that.

>
> I find the IANA Considerations imprecise.  It asks for a new sub-type in a
> registry whose name is not present in IANA; there is one that is close (but no
> cigar).
>
> Likewise, it talks of 'registry of the "BGP Extended Communities"  registry'.
> This is wrong on two counts.  A registry is part of a registry group, not part of
> a registry (prior to recent discussions on the Last Call list I would have just said
> 'group').  Second, there are no BGP registry groups and that identifier does
> not appear anywhere on the IANA website AFAICT.

Thanks for pointing out this. I agree it could be more precise.

We will update this section to refer to the "Transitive IPv4-Address-Specific Extended Community Sub-Types" registry and the "Non-Transitive IPv4-Address-Specific Extended Community Sub-Types" respectively, without mentioning other registries.

<tp2>
but I would also mention the Registry Group for completeness which I think is 
Border Gateway Protocol (BGP) Parameters
As I said before, BGP is one of those rare protocols where the names of the groups are ok but there are still three of them!

Tom Petch

Hope this helps.

Best regards,
Jie

>
> Tom Petch
>
> The authors should respond to this email with an IPR statement.
>
> The WG should consider in their discussion:
> 1) Will this new  transitive extended community help in operational
> networks?
>
> 2) What conflicts does this new Extended Community have with other
> functions in general BGP route distribution or VPNs (EVPN, IPVPN)?
>
> 3) do you have any concern about the text in the draft?
>
> Cheerily, Sue
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr