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

[Gyan Mishra <[e-mail]>]

I support WG adoption of this draft.

The WG should consider in their discussion:

1) Will this new  transitive extended community help

in operational networks?

 Yes.  This mechanism provides an additional layer of control allowing the
RT be imported by a subset cluster of nodes and not all nodes that import
the RT.  In general all routers that are importing the RT explicitly want
the route to be installed in the VRF.  RTC RT membership provides a means
of control however does not provide this layer of subset of nodes
granularity corner case where you don’t want all nodes that are explicitly
importing the RT to all install the route into the VRF.  I don’t see any
conflict of this new target extended community with RTC.

2) What conflicts does this new Extended Community have

with other functions in general BGP route distribution or

VPNs (EVPN, IPVPN)?

 I don’t see any conflicts or issues

3) do you have any concern about the text in the draft?
The txt looks good and explained the well the target extended community
well.  As I think this use case is a subset of the normal  process of
importing the route as long as the RT matches, I think the draft should
explain further what brings up this corner case and more details into this
problem statement.

The draft should also discuss operational considerations when using this
feature in conjunction with RTC where during the RT membership query the
default ORF is sent from RR to PE and the PE installs the adj-rib-out to
advertise all of its RTs, and then PE sends ORF to RR all of its RTs and
the RR subsequently installs adj-rib-out for all of the RTs.  Any caveats
related to RTC procedure if used in conjunction with this new target
extended community.  When the RR is acting on the target extended community
how does that come into play if you have unique RD per PE to avoid hot
potato Routing so the RR reflects all paths and is not doing the best path
selection so as the RR is selecting all and advertising all routes based on
unique RD, and not running best path calculation how would it act on the
target field to check for match.  In general for L3 VPN to avoid hot potato
Routing you have to use unique RD so all paths get advertised or only the
best path chosen by the RR is advertised leading to sub optimal routing.
That being said in reality the RR cannot do the target check since it’s not
running the best path algorithm.

On inter-as option B by default the PE does not in general have explicit
import for all the RTs it receives  so will drop all the RTs by default per
RT filtering rules if an explicit import does not exist for directly
attached VRF, and thus requires retain-rt-all policy to accept all RTs
along with a RT translation filter if necessary.  So if the ASBR receives
RTs but are missing the router-id match in the target extended community,
however is has the retain-rt-all, it will still import the RT even if its
does not have the match on the target extended community router-id.  That
would break the target extended community intended process which would be
to not install the route.  How would you deal with that situation.

Inter-as option AB would have same issue as option B.

With inter-as option C RR-RR eBGP VPN peeing next hop unchanged the RR by
default is not required to have implicit import and installs all routes and
reflects all paths as long as unique RD or if not unique RD runs best path
and reflects the best path.

I think in the draft we should mention all the inter-as options caveats.

With BGP MPLS EVPN RFC 7432 and NVO overlay RFC 8365 it’s common to have
 evpn rt-auto-rewrite as well as for multicast  MVPN / TRM ( Tenant Routed
Multicast) also common to have auto rewrite.

Any caveats related to RT auto rewrite and this new target extended
community.

Kind Regards

Gyan

On Tue, Sep 27, 2022 at 1:31 PM Susan Hares <[e-mail]> wrote:

> 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/
>
>
>
> 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
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*