Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

[Gyan Mishra <[e-mail]>]

On Wed, Aug 12, 2020 at 11:44 PM Aijun Wang <[e-mail]>
wrote:

> Hi, Gyan:
>
>
>
> *From:* Gyan Mishra [mailto:[e-mail]]
> *Sent:* Wednesday, August 12, 2020 10:56 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; Keyur Patel <
> [e-mail]>; Robert Raszuk <[e-mail]>; UTTARO, JAMES <
> [e-mail]>; idr <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Hi Aijun
>
>
>
> See in-line responses.
>
>
>
> Service Providers networks are built to be robust enough to carry customer
> prefixes and account for flood of routes.
>
>
>
> The layers of protection are basic standard protection mechanisms for any
> SP core public or private.
>
>
>
> 1.  Infrastructure security ACLs on PE-CE links.
>
>
>
> 2.  RTC on PE-RR to only advertise interesting RTs defined on PEs based on
> import policy.
>
>
>
> 3.  Per VRF maximum prefix setting based on edge node resources.
>
> *[WAJ] You mean to configure VRF maximum prefix on the PE-RR BGP session?
> What you will do when the limit is exceeded? *
>
> *a)     **Breaking down the BGP session with RR?  Will influence other
> VRFs on this PE.*
>
                         No.  This is on the VRF global configuration for
per VRF maximum prefix for the VRF RIB

> *b)    **Warning Only? The received PE will be busying to dealing the
> afterward overloading routes, exacerbate the situation then?*
>

                   I think you are confusing peer maximum prefix with
global VRF level maximum prefix.

                    The warning option is there for peer maximum prefix
command which is why I think you maybe confused.

> 4.  PE-CE edge peer maximum prefix
>
>
>
> 5. Inter AS Opt B RT level protection for rewrite or limit interesting RTs
> to be accepted.
>
>
>
> The main point is the SP router infrastructure is built to account for
> edge flood of prefixes intra or inter-as
>
> within any given edge or SP.  The protection mechanisms above have address
> all the issues of prefix flooding and has been the basic a used for years.
>
>
>
> Maybe first documenting actual use cases with a problem statement draft
> that depicts the providers that had the problems you are describing and the
> impact and why the solutions above did not resolve the issue.
>
>
>
> I think that is a first step as most all the responses on the ML are
> stating that the above has historically solved the issues described.
>
> *[WAJ] We will add more contents in the updated draft to reflect the
> response on the ML.*
>
>
>
> I am the lead architect and SME for Verizon a tier 1 carrier which carries
> tremendous weight as a stakeholder worldwide and we have used these basic
> standard best practices for years since the inception of MPLS IP VPNs 20+
> years ago.  We have not run into any of the problems you are mentioning.
>
> *[WAJ] Actually, we write this draft mainly for EVPN over VxLAN/SRv6
> inter-AS scenario, where the Option-B/C will be preferred, instead of
> Option-A as in MPLS-VPN.  But the VPN route trashing possibilities exists
> also within one AS.*
>
> That does make a difference and maybe you should state in the draft also I
> think maybe exclude MPLS vpn.
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Wed, Aug 12, 2020 at 2:57 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Gyan:
>
>
>
> *From:* Gyan Mishra [mailto:[e-mail]]
> *Sent:* Wednesday, August 12, 2020 2:02 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; Keyur Patel <
> [e-mail]>; Robert Raszuk <[e-mail]>; UTTARO, JAMES <
> [e-mail]>; idr <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
>
>
> Hi Aijun
>
>
>
> Standard practice for service providers is to have Infrastructure ACLs I
> call “Leaving the Kingdom” as when a packet enters or leaves the trusted
> SP domain it is a requirement per security posture for providers to secure
> the edge.  As far as config errors, centralized NMS controller for
> Restconf/Yang southbound policy push is the standard practice and that
> makes for ZTP and day to to day operations configuration changes error free.
>
> *[WAJ] This is just the **“perimeter protection”, is useful but not
> enough.*
>
>           Gyan> I don’t understand why that does not work for you.
>
>
>
> As far as inter domain for opt B & C your control point is still your
> PE-CE protecting your edges from a control plane perspective and data plane
> perspective via infrastructure ACLs.  The NNI inter as link with option B
> is already a built in control point by design as you have to turn on
> retain-route-target all and then tie to a policy for interesting RTs to
> import as well as if their is an RT mismatch you have to manually via the
> same protection policy perform a RT-Rewrite.
>
> *[WAJ] we are concerning the **“trashing routes” from interested VRFs,
> not from the uninterested VRFs.*
>
>
>
>           Gyan> I understand and even with the RTs imported you can still
> define the per VRF maximum prefix in the RT translation case or existing
> RTs on the ASBR as well as the PEs in the domain importing the routes.
>
> For Option C the SAFI 128 VPN control plane Is RR-RR so no RT filtering by
> default but not to worry as RTC takes care of the RR-PE advertisements.
>
>
>
> I know your concern is with trashing of routes, however if you think about
> it “who originates the trashing routes” ?
>
>
>
> So in this particular case it would be the provider outside of your
> administrative control.
>
>
>
> If it’s the inter-as is within a single administrative domain that is one
> thing but if it’s outside of the operators administrative domain and if
> this issue exists with certain RTs they have trashing routes or RD.  I do
> see your point with opt b and c.
>
>
>
> In those cases where you had an RT or RD that had trashing routes you
> could switch those to option-a back to back VRF and apply the maximum
> prefix filter.
>
>
>
> So I think we have narrowed the scope of the trashing routes to inter-as
> opt b or c going between administrative domains.  At that layer you cannot
> does the maxim prefix knob as it’s a VPN peer carrying all RTs.  So all
> you can do is filter on RTs.
>
> *[WAJ] If the **“trashing routes” from the interested VRF, filter on RTs
> will erase all prefixes from this VRF?*
>
>  Gyan> Understood, however you also have the per VRF maximum prefix that
> you can set on the RTs imported from the other providers.
>
> I do still stand by the per VRF maximum prefix knob as the first global
> control point that would be set on all PEs including the NNI inter-as
> boundary PEs and that would be your first line of defense against trashing
> routes.
>
>
>
> An example of how that would work is if you set the per VRF maximum to
> 100,000 prefixes.  Let’s say you get 1M+ prefixes on a 1000 different
> VRFs and that happened all simultaneously a coincidental flood with all the
> stars and moons in alignment.
>
>
>
>  In that case for each VRF you would drop 900,000 routers per VPN.
>
> *[WAJ] But protect other VPNs in this PE from crashing.*
>
>  Gyan> I don’t understand the crashing.  Is that crashing of the router.
> What would happen is the routes above the maximum would be clipped and
> dropped.
>
> The RD-ORF or RT-ORF is still working at the RD RT VPN layer and does not
> have the prefix level granularity as the PE-CE maximum prefix.
>
> *[WAJ] RD-ORF has the effect of PE-CE maximum prefix.*
>
>  Understood.  I think you need a study of service providers to depict why
> the list of mentioned protection mechanisms won’t work for you.
>
> On every inter-as b c NNI if their was an RT that is thrashing you could
> adjust the RT filter / RT translation policy to not permit the RT doing the
> thrashing.
>
>
>
> As far as the RD-ORF the RD is used to make the prefix unique 64 bit
> quantity so you can have overlapping prefixes within different VRFs unique
> by the RD.  As far as filtering their is no need to ever filter using RD.
> That is never done in practice that I know of.  So I would remove that from
> the draft.  The RD is usually set to auto which makes it unique within a
> domain and of using a RR is required to be set to auto so that all the RDs
> originated by each PE has a different RD so that they all get reflected by
> the RR.  Without that sub optimal routing can occur as all paths are not
> reflected.  In that the case of RD auto making the RD unique per VRF so
> then their is no benefit from RD ORF.  That being said if RR is not used
> then the RD does not have to be unique pet VRF on a PE and so all VRFs
> could have the same RD.
>
> *[WAJ]  On one PE, different VRF will use different RD, or the address
> spaces from different VRF has the possibilities to collide.  If you can
> assure the address space unique within different VRFs, what the reason to
> use different VRFs then?*
>
>  Gyan> I mis stated the RD scenario.  Sorry. The RD can be the same on all
> PEs within a VPN or different per PE within the same VPN on the VRF
> definition.  When RR is utilized the RD must be set to Auto which is the
> standard practice so the the VPN routes from different PEs within the same
> VPN can be reflected within the VRF which can only be possible if the RD is
> different.  L3 VPN does not have the option of “add path” as does SAFI 1
> so you must do RD auto for the RR route reflection to work on a per path
> basis. So the RD as stated has to  be different per VRF as that is what
> makes the prefix unique and each prefix can have many RTs tagged to the
> prefix if it is imported into many different VRFs.  Your draft addresses
> the RR scenario to use the RD-ORF prefix filtering feature.  So now the RD
> in the RR scenario now references the source  per PE VPN routes advertised
> to the RR and does not represent all PEs as the RD must be unique by RD
> auto set to type 1 RD IP:Y.  So your policy would be matching the Type 1
> RD.
>
> More dangerous in this case would allow you to ORF RD filter all VPNs
> coming from a particular PE.
>
> *[WAJ] If these VPNs on this PE, uses same RD(you assure the address space
> are non-overlapped),  what the harm that we filtered based on RD ? These
> VPNs act just like one VPN.*
>
>
>
>           Gyan> See above comment
>
>
>
>   That does seem quite dangerous and as it is a very unique case as RRs
> are almost alway used my recommendation is to nix the ORF-RD.
>
> *[WAJ] RR is always used, RD is often unique for each VRF on one PE. Then
> the scenarios that you described will not happen, what**’s the dangerous
> then?*
>
> Gyan> See comments above addresses this.
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Tue, Aug 11, 2020 at 9:42 PM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Gyan:
>
> Theoretically, you are right.
>
> But, don’t’ you worry that if only one of the edge points being
> comprised/error-configured/attacked, then all of PEs within your domain are
> under risk?
>
> Furthermore, if you control different domains, and use Option-B/C to
> provide the inter-AS VPN services, such risk/”trashing routes” can easily
> spread among these domains?
>
> Don’t’ you think such network is too fragile?
>
>
>
> RD-ORF is the mechanism that aims to strengthen the risk resistance
> capabilities.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Gyan Mishra [mailto:[e-mail]]
> *Sent:* Wednesday, August 12, 2020 3:54 AM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; Keyur Patel <
> [e-mail]>; Robert Raszuk <[e-mail]>; UTTARO, JAMES <
> [e-mail]>; idr <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Aijun
>
>
>
> If you use maximum prefix on every PE-CE peering at the edge how would the
> PE-RR peering send “trashing routes”.  The “trashing routes” would not be
> present in the VPN RIB on the PE to send to the RR.
>
>
>
> To me that’s “Problem Solved”.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Mon, Aug 10, 2020 at 5:20 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Robert:
>
>
>
> RD-ORF is mainly for restricting PE from sending trashing routes. When the
> source PE receives such notification info, it should find which CE is the
> real source of the routes. This is not the scope of this draft, but if
> necessary, we can add some deployment consideration for this part later.
>
> “Prefix Limit” mechanism can only protect the edge between PE-CE, can’t
> be deployed within PE that peered via RR.  We should not rely solely on the
> edge protection.
>
>
>
> You can also refer our discussion at
> https://mailarchive.ietf.org/arch/msg/idr/d79fKMXa3HZcq6Zti5H7qnxJ1_o/
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk [mailto:[e-mail]]
> *Sent:* Monday, August 10, 2020 5:06 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* Gyan Mishra <[e-mail]>; UTTARO, JAMES <[e-mail]>;
> Keyur Patel <[e-mail]>; John E Drake <jdrake=
> [e-mail]>; [e-mail]; idr <[e-mail]>
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Aijun,
>
>
>
> > Using the RD-ORF can restrict the influence within one limited
> scope(within one VRF, one PE, one domain or different domains)
>
>
>
> Please kindly observed that this is still not enough of granularity.
>
>
>
> As you know src VRF can have many CEs and perhaps just one of them say out
> of 10 is injecting trashing routes. Then IMO penalizing reachability to all
> 10 CEs instead of 1 is a very bad thing to do to your customer's VPN.
>
>
>
> RD is per VRF and not per CE and does not provide sufficient
> granularity to address the protection problem you are pointing out.
>
>
>
> Also apologies if I missed it but I do not think you have sufficiently
> explained what is wrong with using the prefix limit on incoming sessions to
> your PE. You said this is one way. If it solves the problem why to invent
> different way ? If it does not solve the problem please explain why.
>
>
>
> Thx,
> R.
>
>
>
> On Mon, Aug 10, 2020 at 3:58 AM Aijun Wang <[e-mail]>
> wrote:
>
> Hi, Gyan, Jim, John and Robert:
>
>
>
> Thanks for your detail analysis.
>
> Actually, we know the value of RTC mechanism, but it is not enough for
> controlling the route limit within one VRF.
>
> The propagation of routes that influence the router performance can come
> from different VRFs and can also come from the same VRF.
>
> RTC aims to solve the former problem, RD-ORF aims to solve the latter.
>
>
>
> If we depend on the local discard, as Robert proposed, the route
> inconsistence can also occur. It is the sacrifice we should accept.
>
> Using the RD-ORF can restrict the influence within one limited
> scope(within one VRF, one PE, one domain or different domains), in
> controlled manner.
>
> RD-ORF is based on the ORF mechanism, which is transferred via P2P
> message. Every node on the path can have its policy to determine whether or
> not sending this filter information to the upstream BGP peer, based on its
> performance criteria.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Gyan
> Mishra
> *Sent:* Saturday, August 8, 2020 6:39 AM
> *To:* UTTARO, JAMES <[e-mail]>
> *Cc:* Keyur Patel <[e-mail]>; John E Drake <jdrake=
> [e-mail]>; [e-mail]; Robert Raszuk <
> [e-mail]>; idr <[e-mail]>
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Agreed and good points.
>
>
>
> As you said the processing is not impacting the forwarding aspect.  Agreed.
>
>
>
> As RTC is SAFI 132 flood control mechanism RR to PE optimization if you
> have a ton of SAFI stacked as you’ve mentioned the optimization applies
> to all the SAFI stacked onto the PE to RR peering.
>
>
>
> RTC is an optimization in that respect and not a requirement as default RT
> filtering rule application eliminates all accept what is explicitly
> imported.
>
>
>
> I gave the IP VPN example but as you stated the RTC optimization can be
> used for a variety of SAFI but is not a requirement.
>
>
>
> L3 VPN is a good example although it it does not really come into play as
> much for intra domain as in general all PEs have the same VPNs defined,
> however inter-as is a different story and there as that is not the case the
> flooding can really be cut down as stated to interesting RTs only.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Fri, Aug 7, 2020 at 6:21 PM UTTARO, JAMES <[e-mail]> wrote:
>
> *The rationale for RTC is not to prevent paths being sent from an RR to a
> PE in a L3VPN. Granted that this could be a secondary benefit when routes
> are flooded from an RR towards a PE. Flooding of routes occurs in two
> cases:*
>
>
>
> a.  *PE is rebooting. In this case the PE is not operational so in
> reality it does not matter how many paths are being sent. I have seen
> millions of paths  being sent to a vintage router @1999 and it rips through
> these paths keeping the ones it needs for the VPNs instantiated on it and
> discarding the rest.  Again the PE is not up so it really does not matter.*
>
> b.  *A VRF is added to an existing PE that is operational. In this case
> the RR floods the paths towards the PE, the RE processes and keeps paths of
> interest. This processing in no way affects the forwarding aspect of the
> router. I have seen millions of paths flooded towards for this case and
> there is no effect on forwarding.*
>
>
>
> *RTC’s assumption is that the RR topology services a set of VPNs that are
> localized. As an example, if VPN A is localized to California and VPN B to
> New York an RR topology that has two clusters East and West can deploy RTC
> to ensure the East cluster never has to “see” the VPN B routes and the West
> cluster never has to “see” the VPN A routes. *
>
>
>
> *Generally speaking VPNs are not localized in this fashion and RTC has
> limited value and the downside of path hiding. Assume one wants to dual
> purpose the RR as a stitcher and wants to “stitch” as subset of VPN A paths
> to VPN B and vice versa.. Path hiding would prevent this.*
>
>
>
> *Where RTC makes a lot of sense to me is where the VPN is local..
> Specifically Kompella VPWS spec is by definition local where each VPN has
> two members in a point to point topology and is also generally localized to
> a given region/metro/LATA.  Here RTC can reduce the number of paths on RRs
> in a substantial manner. In the above ex all California VPWS paths are
> local and there is no need to populate said paths on the East coast RRs.
> This also makes sense for Kompella/VPLS, EVPN/VPLS, EVPN/VPWS, and
> EVPN/FXC..*
>
>
>
> *Thanks,*
>
> *              Jim Uttaro*
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Gyan Mishra
> *Sent:* Friday, August 07, 2020 5:32 PM
> *To:* John E Drake <jdrake=[e-mail]>
> *Cc:* Keyur Patel <[e-mail]>; [e-mail]; Robert
> Raszuk <[e-mail]>; idr <[e-mail]>
> *Subject:* Re: [Idr] [Responses for the comments during the IETF108] New
> Version Notification for draft-wang-idr-rd-orf-01.txt
>
>
>
> Hi Authors
>
>
>
> I agree with Roberts’s analysis as well.
>
>
>
> As pointed out by Robert this feature appears to be a dangerous addition
> to the BGP specification.  The concept or idea of wanting to drop routes
> for select devices based on criteria that is not holistic.
>
>
>
> BGP is a holistic routing protocol and by that I mean consistent and
> ubiquitous propagation of NLRI’s throughout the domain.  The concept of
> resource constrained nodes and creating a BGP knob for resource constrained
> nodes is out of the scope of the BGP protocol.  The goal and primary
> purpose of BGP is to provide “reachability” a by that I mean every router
> in the domain has a consistent view of the topology soft state and
> identical RIB..  This is not different then the goal of an IGP to provide
> next hop reachability and a consistent view of the domain meaning IGP
> database synchronization.  Vendors provide plenty of knobs to filer that
> consistent view of the domain but those are very one off exception use
> cases where that happens in both the IGP and EGP world.  In the IGP world
> for example take OSPF or ISIS you can as a corner case filter the IGP RIB
> that is on a router with an inbound prefix filter.  This is an exception to
> the rule but it must be done carefully as since the LSDB is “synchronized”
> every router interface on every device in the domain bust now require that
> same filter implemented as the database is “synchronized” for the goal of
> both IGP and EGP to provide a consistent identical view of the domain.
> Similarly with EGP such as BGP iBGP intra domain filtering is not
> recommended and is not built by design to so as the goal BGO is to provide
> the same reachability.  You can match and manipulate BGP attributes but not
> filter as it will break the goal and primary purpose of BGP in the intra
> domain construct of a consistent identical view throughout the domain.
>
>
>
> There is already control mechanisms built into BGP to prevent routing
> loops and re-advertisements such as BGP originator-id and cluster-id and
> cluster list path created for route-reflector-client originated routes to
> prevent loops as well as RR side sidenon client to non client
> re-advertisement controls.
>
>
>
>
>
> From an IP VPN framework perspective you have to understand that a PE has
> RT filtering enabled by default which is the control mechanism.  Their is
> absolutely no need for any additional resource constrained node knob to
> drop NLRI in what seems to be a random inconsistent fashion.  What PE “RT
> filtering” means and this is a very basic concept but and applied
> directly to what you are proposing and is the grounds to stop development
> of the draft.  So when an RR advertises prefixes to a PE and let’s say
> their are a million RTs and let’s say the PE is configured to import RT=1
> and so only one RT.  So now what happens is the RR advertises 1M RTs and
> the PE per “RT filtering” drops 999,999 RTs as the PE only has RT=1
> defined.
>
>
>
> This issue caused unnecessary flood of RTs that soaks up operators
> bandwidth that is not necessary that are going to be dropped anyway.
>
>
>
> RTC to the rescue!!
>
>
>
>
>
> RTC provides a elegant function to control advertisements from RR to PE
> and is very robust and sensible in that it not dropping routes randomly or
> because a few nodes have a resource constraint.  RTC has a well defined
> purpose which is to cut down on a flood or RTs to a PE as described.
>
>
>
> So the PE-RR peering had a RTC BGP MP reach AFI/SAFI defined on each peer
> SAFI 132 enabled on each PE-RR peering  capability is established
> send/receive state.  So now what happens is the PE does an ORF to the RR
> stating that I only have RT=1 defined for import which is sent in a RTC
> membership report to the RR.  The RR with RTC capability enabled now honors
> what the PE has stated and only sends RT=1 and not 1M RTs.
>
>
>
> Hooray for RTC saves the day = Job well done
>
>
>
> This issue can be exacerbated with NNI inter-as when using option-b where
> all VPN routes are propagated.  In this case we have default “RT filtering
> ” to the rescue to slow down the RT propagation to be done in a
> controlled fashion.  So by default on the RR node does not have RT
> filtering enabled by default and only PEs have that feature enabled by
> default. With Option-B the inter-as link is PE-PE peering connecting the
> two SP domains together.  So looking deeper into option-b you can set “
> retain-route-target” which now changes the default behavior and is
> required for the VPN routes to be propagated.  In some cases between
> providers the RT does not match so a RT-rewrite is required so in that case
> the rewrite policy become the RTC like filtering mechanism.  In case where
> RT is the same between providers we tie the “retain-route-target all” to
> a RT filter “RTC like” to only accept RTs pertinent to the domain.
>
>
>
> With inter-as option C we run BGP LU for labels unicast end loopback FEC
> all leaked between domains via eBGP and IBGP LU for data plane forwarding
> and the control plane function vpn peer that was on the PE-PE in option-b
> is RR-RR eBGP vpnv4 vpnv6 SAFI 128.  Since the RR sits in the control plane
> not the data plane “RT filtering” is not enabled by Default.  So for the
> proper end to e f LSP data plane forwarding we have to set BGP “
> next-hop-unchanged” so that the next hop attribute is now the ingress and
> egress PEs between domains for the end to end LSP.  So now in this case all
> the SAFI 128 RTs are propagated between domains.  You can apply explicit RT
> filtering in this scenario but generally that is not done as opt-c used
> mostly within same administrative domain or special agreement scenario
> between SPs that work closely together or in M&A activity type scenarios..
> So now we still have RTC SAFI 132 eatabled PE-RR within each domain so even
> if you got a quadrillion RTs on the RR-RR peering and did not want to
> filter there we have RTC back to the rescue and if you only have 1M RTs
> defined for import on the PE within each domain,  now in a graceful
> controlled fashion only 1M RTs are not advertised RR to PE within each
> domain.
>
>
>
> This same concept as IP VPN is an “overlay” it applies to SR both SR-MPLS
> and SRv6 as well.
>
>
>
> From an BGP architecture and designer perspective when building a “SP core”
> in that standard framework where you have separation of control plane and
> data plane where the RRs are dedicated control plane function and don’t
> sit in the data plane where the PEs RRC clients sit at the edge sit in the
> data plane for ingress to egress LSP to FEC to be built.
>
>
>
> So in a nutshell, a combination of default RT filtering on PEs, and
> controlled RT advertisements via ORF RT membership via RTC we have complete
> control of SAFI 128 advertisements for resource constrained nodes as it
> stands today and there is absolutely no need for this draft to be
> considered with IDR.
>
>
>
> I did not mention the per VRF maximum prefix knobs to control how big each
> VPN gets at a micro level so we have that control mechanism as well.  In
> general most providers have this set as a rule of thumb per VRF maximum
> which is sized accordingly to the lowest resource constrained node within
> an operators network and is publish as the SLA customer agreement contract
> as part of the VPN service offering.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Fri, Aug 7, 2020 at 8:35 AM John E Drake <jdrake=
> [e-mail]> wrote:
>
> Hi,
>
>
>
> I agree with Robert’s analysis.  There is no need to define an external
> mechanism to deal with an internal node issue.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Idr <idr-bounces@i <[e-mail]>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD