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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Robert,

Please see replies inline:

From: Robert Raszuk [mailto:[e-mail]]
Sent: Tuesday, October 18, 2022 6:01 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>; Van De Velde, Gunter \(Nokia - BE/Antwerp\) <[e-mail]>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

Hi Jie,

Thank you for uncovering corner of one potential use case. We need more real use cases.

[Jie] That simple example shows that there can be problem if RT is used for both VRF importing and targeted nodes distribution. If we don’t modify the semantics or the processing rule of RT, a new community type would be a reasonable choice.

In the draft I do not see anywhere statement that node target extended community must be automatically more important then route target extended community.

Since such text is missing I presume it will be subject to operator's local policy configuration.

And if so there is nothing - neither on sender nor on the receiver - to prevent one from using RT value X (RT1 in yr example) as an absolute drop/accept filtering criteria.


[Jie] Good point. I remember we discussed this in the beginning of this adoption call, my consideration is NT should be processed first, then the RT. We could add some text in next revision if the WG agrees with this.

- - -

As far as your IANA allocation I do recommend calling things much more clearly. Currently you asked and IANA allocated sub-type name "Node Target Extended Community" - it is good for the draft, but in the registry it should be "BGP Router ID" or "BGP Identifier" which makes it very clear what is being encoded.

[Jie] I understand your point. The main purpose of the IANA section is to request for a new sub-type code point. Once the WG reached consensus on the format and content of this extended community, the IANA section will be updated accordingly.

Best regards,
Jie

Many thx,
R.

On Tue, Oct 18, 2022 at 5:53 AM Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Please note that the use case is to distribute the information to a VRF on specific set of nodes, which are a subset of nodes which are provisioned with that VPN.

A route with both RT-A and RT1 will be imported into the VRFs of all PE nodes of that VPN. Clearly this is not the expected result.

I agree that for non-VPN cases using RT-A only would be OK, while it is not a generic solution to cover the VPN related cases.

Best regards,
Jie

From: Robert Raszuk [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, October 18, 2022 12:04 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>; Van De Velde, Gunter \(Nokia - BE/Antwerp\) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

Hi Jie,

To your example clearly if you insert both RT2 and RT1 either will cause the import to PE global table. In addition RT2 will also result in import to a VRF.

However if you are to distribute information which is not targetted to a VRF you do not need to insert this extended community (here RT2) to an UPDATE message. Then RT1 alone will result in exactly what you need. I honestly do not see a problem here.

Filtering on a fixed Router_IDs is not flexible enough IMHO even considering targetted information distribution.

Kind regards,
R.

On Mon, Oct 17, 2022 at 5:45 PM Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

As described in the introduction section of this draft, RT and the RTC mechanism applies to the filtering of routes to all nodes with specific VRFs. One cannot use RTs for both node filtering and VRF filtering, because the matching rule for RTs is “match-any”.

Here is a simple example: Assume you want to use RT-A to specify the target node (say node A), and RT-2 is used to specify the target VRF, then BGP routes carrying both RT-A and RT-2 will be imported by all PE nodes (not just node A) which has RT2 as the import RT of their VRFs, clearly this does not meet the requirement on targeted node distribution.

That’s why this document proposes a new extended community type:  to distinguish its semantics and operation logic with the current RT. Whether we need to use wide community or large community depends on how much information needs to be carried.

Best regards,
Jie

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, October 16, 2022 6:00 AM
To: Jeff Tantsura <[e-mail]<mailto:[e-mail]>>
Cc: Gert Doering <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>; Van De Velde, Gunter \(Nokia - BE/Antwerp\) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

Jeff,

> Imagine a 1000s devices in 9-11-13 stages multi-planar leaf-spine block
> with eBGP (next-hop rewrite) between them

So because you bended BGP to be used in such topologies you now want to load it with features specific to accommodate such topologies ? And where is the rest of the world in this picture ? Where is the Internet in this picture ?

> (requires some planning of how router-ids are allocated)

Why are Router_IDs now an optimal filtering parameter ?

If you have such topology running BGP as IGP just allocate RT and use RT based filtering (perhaps even with RTC) instead of reinventing the wheel. If you are already using RT and for any reason prefer not to touch it, allocate a std, extended, large or wide community and use it for filtering.

Cheers,
Robert



On Sat, Oct 15, 2022 at 11:47 PM Jeff Tantsura <[e-mail]<mailto:[e-mail]>> wrote:
Hey Gert (long time ;-)),

We are much beyond the time when an AS was bunch of ASBRs with RR and iBGP in between only.
/* fictional
Imagine a 1000s devices in 9-11-13 stages multi-planar leaf-spine block with eBGP (next-hop rewrite) between them, policies are horizontally consistent (based on a position of a device in the block). When everything is up and running, stage interconnection is highly consistent (equidistant end-points)and works just great with consistent distribution of reachability (p2mp).
Single or even double failures are easily mitigated by wide ECMP (with fast rehash, easily below 100ms).
When an optical span fails however, it is a very different story, so you need to update either all relevant receivers (could be just a subset of routes, could be some additional meta-data(metrics/BW/etc) or sender(s) (or a controller that injects said subset m). In many cases, being able to target a specific set of BGP speakers is the only solution (temp mitigation).

As you rightfully said - all of this can be done with 0 changes to the protocol (through management plane), however has a number of its own issues (trade-offs).

I agree that 1:1 mapping doesn’t really scale, we could think a a more efficient distribution through wildcarding (requires some planning of how router-ids are allocated). Would be somewhat similar to “passive BGP” in some implementations - accept all peers that come from 10/8.

I have a mixed feeling about this, BGP person in me is saying (throw this over the board to management), operating this stuff at scale one is seeing some opportunities  ;-)
Hence my support.

Cheers,
Jeff

> On Oct 14, 2022, at 09:10, Gert Doering <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi,
>
>> On Thu, Oct 13, 2022 at 08:30:45AM -0700, Jeff Tantsura wrote:
>> Looking at my toolset (sometimes i need to move GWs of capacity from one region to another) - this would be a very useful addition.
>
> If you need a mechanism to actually control routing propagation, this
> can all be built today with route-policies and communities, without
> protocol changes.  Exactly the way an AS needs.
>
> If you want this to propagate something else, I am yet to be convinced
> BGP is what we should burden with it.
>
> Gert Doering
>        -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: [phone]         USt-IdNr.: DE813185279

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr