Re: [Idr] Reply to question on "BGP MPLS-namespaces" from IDR-111 notes

[Gyan Mishra <[e-mail]>]

Hi Kaliraj

I reviewed the draft & presentation you gave during IETF 111 and went over
it a few times and I believe this email summarizes the goals and concepts
of the draft.

So the goal of this draft to provide scalability for inter-as option C or
Seamless MPLS next-hop-unchanged end to end LSP, where the PE loopbacks are
flooded between multiple AS’s domain wide to take advantage of end to end
LSP to avoid service stitching complexity as well as other benefits.

So in this draft we are leveraging the RFC 5331 section 8 context label to
be used to provide a MPLS extension for new private MPLS FIB label that
uses a discovery context label that takes the BGP-LU or CT RIB intra-as
underlay labeled prefixes maps to a context label in the global table which
now maps at inter-as at BN to new MPLS AFI for defined the context label to
Private MPLS FIB mapping either SAFI 1 global table or SAFI 128 VPN FIB.
The next hop for the private MPLS FIB can be IPv4 for 6to4 softwire -RFC
55565 IPv4-Only core or IPv6 for 4to6 softwire RFC 5565 IPv6-Only core.

This allows for an end to end LSP for seamless MPLS solutions without
having to flood BGP-LU or CT labeled prefixes domain wide.  Mentioned on
draft that  next hop self at BN  does not change the private MPLS FIB entry
inter-as so it acts like next-hop unchanged for end to end LSP, since MPLS
private FIB ‘RFC 5331 context label’ concept is utilized.

This draft provides for the scalability of Seamless  MPLS which eliminates
service stitching simplification, without the down side of domain wide PE
loopbacks BGP labeled prefix flooding.

Few questions below to help my understanding.

I don’t understand why the context label is required SAFI 128 but not for
SAFI 1. The private MPLS RIB would consist of in both cases context labels
with IPv4 or IPv6 next hop.  For the mapping of the BGP-LU & CT on BN to
private MPLS label FIB,  I would think you would always require the RFC
5331 context  label for the aggregator label.

This draft creates a new Private MPLS RIB for the topmost transport labels
end to end inter-as LSP, so I believe this draft should be Standards Track.

As inter-as options b/ab/c are valid can coexist with Segment Routing SR-TE
binding sid steering policy on BN,  this draft would still be applicable
for Seamless  SR-MPLS to avoid domain wide loopback flooding.

This draft would not be applicable to SRv6 for seamless end to end services
to avoid service stitching.  I wonder if maybe a similar type concept can
be developed for SRv6.  SRv6 utilizes LPM routing & summarization and that
would allow operators to avoid domain wide flooding so problem already
solved.

Today the BGP AFI/SAFI we only have two AFIs IPv4 and IPv6.

https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

Seamless MPLS

https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls

The seamless MPLS draft has normative references to some of the drafts you
are referencing as well.


  [I-D.minto-2547-egress-node-fast-protection
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls#ref-I-D.minto-2547-egress-node-fast-protection>],
   [I-D.bashandy-bgp-edge-node-frr
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls#ref-I-D.bashandy-bgp-edge-node-frr>],
   [I-D.bashandy-idr-bgp-repair-label
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls#ref-I-D.bashandy-idr-bgp-repair-label>],
[I-D.bashandy-mpls-ldp-bgp-frr
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls#ref-I-D.bashandy-mpls-ldp-bgp-frr>],
   [I-D.bashandy-bgp-frr-mirror-table
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls#ref-I-D.bashandy-bgp-frr-mirror-table>],
   [I-D.bashandy-bgp-frr-vector-label
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls#ref-I-D.bashandy-bgp-frr-vector-label>],
   [I-D.bashandy-isis-bgp-edge-node-frr
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls#ref-I-D.bashandy-isis-bgp-edge-node-frr>].



Kind Regards

Gyan
On Wed, Jul 28, 2021 at 3:14 AM Kaliraj Vairavakkalai <kaliraj=
[e-mail]> wrote:

> Hi Swadesh, Replying to question from IDR-111 notes (
> https://codimd.ietf.org/notes-ietf-111-idr# ) >4. BGP MPLS-namespaces:
> Improve Scaling and Convergence in Seamless-MPLS networks [Kaliraj
> Vairavakkalai] (10 mins)
>
> >
> https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels/
> >Swadesh: How many routes will be seen by the PE if the domain has 100 PEs
> and 1000 vrfs?
>
> Service-route scale at remote-PE:
>
>
>
> Remote PE will see same number of service-routes as before. No difference.
> RTC may be used to optimally pull only interesting service routes. Nothing
> new there.
>
>
>
> Transport-route scale at remote-PE or remote-BNs:
>
>
>
> Remote PE will see reduced number of transport-routes. 1 route per-BN for
> a CPNH1 representing the region. Instead of 100 PE transport-routes.
>
>                 ECMP also order of num-BNs, not order of num-PEs.
>
>
>
> MPLS Scale at option-BC local-region BNs:
>
>
>
> In above scenario, because there are 100K VRFs in all, and assuming each
> VRF is doing “per-table label allocation”,
>
>
>
> The BN1 will see 100K mpls-routes installed in “<cpnh1>.mpls” table,
> received via MPLS-Namespace BGP-family from the external-allocator(RR).
>
>
>
> The BN takes this load. But frees up all other nodes in the network (BNs,
> remote-PEs) from consuming resources per Service-Endpoint/PE-lo0.
>
>
>
> Assuming the capacity of a BN is 100K mpls routes, and more than 100K VRFs
> (e.g. PE101 – PE200) get deployed in a region, a new set of BNs can be
> deployed for “CPNH2”, which serve the next 100K VRFs. Simple scale-out
> design.
>
>
>
> So basically, the “forwarding-resources scale usage” remains confined to
> the edge of the network, in each region. It uses as much resources as
> required, very close to the service origination point.
>
>
>
> And because that forwarding scale is also function of
> num-Service-endpoints and not service-routes, PIC or PDC convergence
> happens quickly in a service-family agnostic manner.
>
>
>
> Thanks
>
> Kaliraj
>
> Juniper Business Use Only
> _______________________________________________
> 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*