Subject: RE: BGP/MPLS VPN PE LSR

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 14 May 2001 20:06:40 +0200

Jim,
Thank you once more. Please confirm if the following understanding is
correct
(even if, probably, incomplete):
1. From the provider's point of view, the VPN consists only of CE routers,
   i.e., it knows their addresses but not destinations behind them
  (in you terms, PE-1 learns a (direct) route to ASBR-A but not to any
prefix N behid ASBR-A)
2. CE routers belonging to the same VPN maintain iBGP sessions between them.

   These sessions are used to distribute information about prefixes behind
each CE to its peers 
   with the corresponding CE as a BGP next hop for these prefixes.
3. PEs advertise to their peers and, through them, to their adjacent CEs:
   a) Routes to other CEs :
      * In a PE such a route is a BGP route with the appropriate PE as its
BGP next hop; 
        it isadded to the appropriate VRF instance
      * In the CE this route is not really necessary (a default route would
suffice). But it is a
        regular route with the adjacent PE as its next hop
    b) Incoming labels for 4-hop LSPs:
      * The ingress CE
      * Appropriate VRF instance in the ingress PE
      * Apropriate VRF instance in egress PE
      * Egress CE. 
    c) This advertisement is initiated by the egress PE (and not by the
egress CE);
        as a consequence, the LSP in question operates is if PHP were
negotiated
5. Ingress CE flow:
  a) Look at the dest IP address
  b) Find an egress CE which is a BGP next hop to the prefix which matches
this dest IP address
  c) Push a label which corresponds to (this CE-to-the BGP next hop CE) and
send to PE
6. Ingress PE flow:
  a) Swap the incoming label to one advertized by the egress PE for this
LSP. 
     I expect that at this point all the 4-hop LSPs with the common egress
CE 
     would be merged at this point
  b) Push atop of it a label for the PE-to-PE tunnel. This label is defined
like following:
     * Look at the FEC for the incoming label - it is the egress CE address
     * Find a BGP next hop for this address in the VRF  - it is the egress
PE address
    *  Find a label which suits to the best-matching FEC for this address.
 
The gain provided by this scheme vs. the normal RFC2547 one will be
perceived if 
the CEs in question are really ASBRs, i.e., there are multiple prefixes
behind each of them. In such a case the core learns only ASBR addresses but
not
the actual prefixes behind them.

Hopefully I did not extend your patience beyond reasonable limits.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: jim guichard [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 5:16 PM
> To: Sasha Vainshtein
> Cc: Sasha Vainshtein; Metz, Eduard; 'Shahram Davari'; 
> [email-masked]'; Alik Shimelmits; Elena Vinkler
> Subject: RE: BGP/MPLS VPN PE LSR
> 
> 
> Sasha,
> 
> comments in-line ...
> 
> At 17:39 14/05/2001 +0200, Sasha Vainshtein wrote:
> >Jim,
> >Thank you for a prompt response. However, it leaves several 
> point unclear.
> >1. Neither RFC 2547 nor rfc2547bis does not specify which 
> routing protocols
> >run between
> >    CE and PE if any at all. In the basic model, CE does not 
> require any
> >    specific route at all - a default route via its PE is 
> sufficient. In its
> >turn,
> >    PE may learn routes to destinations behind its adjacent 
> CE via static
> >configuration.
> >    So what happens if  there is no routing protocol between 
> CE and its
> >adjacent PE?
> 
> you may use OSPF, RIPv2 or static between PE-CE. LDP provides label 
> distribution across the link.
> 
> >2. AFAIK in the 2547 model:
> >    a) PE somehow learns routes to destinations behind its 
> adjacent CEs and
> >installs
> >        them in the VRF instance associated with the given VPN
> 
> in the case of CsC, the PE learns BGP next-hop addresses that 
> are behind 
> the adjacent CE router. Other routes may be exchanged 
> directly between 
> sites WITHOUT being advertised toward the PE. This is 
> achieved through iBGP 
> sessions between sites.
> 
> >    b) iBGP distributes addresses of PEs as BGP next hops for the
> >        VPN destinations behind their adjacent CEs together 
> with _internal_
> >labels which
> >        are associated with the VRF instances within these PEs
> 
> yes and no. If the site is not running MPLS then BGP next-hops are 
> exchanged with the PE but without labels. If the site is 
> running MPLS then 
> the BGP next-hop is advertised to the PE as normal and a 
> label binding for 
> the prefix is agreed between PE and CE routers - standard LDP 
> behaviour. 
> Once the PE has these routes within the VRF, MP-BGP 
> distributes the prefix 
> information as per 2547 model.
> 
> >    c) IGP (OSPF or ISIS)  within the MPLS backbone provides for IP
> >connectivity between PEs
> >    d) LDP provides for MPLS connectivity between PEs
> >    e) PEs use labels associated with LSPs to their peers as 
> _external_
> >labels in the
> >        two-level label stack.
> >    This means that  internal labels refer to VRF 
> instance-to-VRF instance
> >LSPs while
> >    external labels refer to PE-to-PE LSPs.
> 
> PEs will use a two level label stack (simple case) where the 
> inner label is 
> the VPN label (BGP next-hop address) as allocated by the 
> ingress PE router 
> and the outer label is the IGP label as allocated by LDP. This is the 
> normal 2547 model, nothing new with CsC.
> 
> >3. Now comes the key question: to which LSP should belong a 
> label in a
> >    packet sent by the CE to its adjacent PE?
> 
> The flow is as follows :
> 
> Site A has prefix N which is reachable via ASBR_A. Site A 
> advertises prefix 
> N to Site B via iBGP with a next-hop of ASBR_A. Site A 
> advertises prefix 
> ASBR_A to PE-1 within the MPLS VPN backbone. PE-1 imports 
> ASBR_A prefix 
> into VRF A. PE-1 redistributes prefix ASBR_A into MP-BGP. 
> PE-1 advertises 
> RD:ASBR_A to PE-2 which imports the route into VRF A. PE-2 advertises 
> ASBR_A to CE-2 in Site B and distributes label X via LDP. 
> CE-2 advertises 
> ASBR_A into Site B using its IGP.
> 
> When a packet comes into Site B destined for network N, the 
> next-hop for 
> network N on the incoming ASBR points to ASBR_A. As ASBR_A 
> was learnt from 
> within the IGP the traffic takes the IGP path toward the 
> next-hop. When the 
> packet hits CE-2, label imposition occurs as a label for 
> ASBR_A was learnt 
> from PE-2. CE-2 sends the packet with label X to PE-2 which 
> swaps the label 
> for a two-level label stack. This label stack is the VPN 
> label for prefix N 
> as assigned by PE-1 and the IGP label to reach PE-1. When 
> PE-1 receives the 
> packet it will have a one level label stack. The packet is 
> then switched 
> toward CE-1 as a normal IP packet destined for prefix N.
> 
> >    I see the following use cases:
> >    a) They belong to CE-to-CE LSPs which are tunneled in the
> >        VRF instance-to-VRF instance ones,
> >        i.e. they are never visible in the MPLS VPN backbone 
> including PEs.
> >       This is the scenario I had in mind. It also may be 
> related to the
> >flavor which you have
> >       called hierarchical VPN. The probelm is that PE has 
> to recognize these
> >labels in order to
> >       process them in any way. I do not see how this is possible.
> >    b) They belong to CE-to-CE tunnels which are just 
> extensions of the
> >        VRF instance-to-VRF instance ones. This will only
> >       work if there is just one customer site per PE per VPN.
> >   c) They belong to (upstream CE)-to-(VRF instance in the 
> downstream PE)
> >LSPs.
> >       IMHO this corresponds to the process you have 
> described in your answer
> >and
> >       also to the "VPN site running MPLS" flavor. The 
> problem with this
> >scenario is
> >       that the provider's network topology becomes 
> partially visible to the
> >CE routers
> >       ( they have to know which PE acts as the BGP next hop 
> for the specific
> >destination
> >      in their VPN). AFAIK this is considered as undesirable 
> in the common
> >VPN framework.
> >
> 
> all that is needed within a site is to learn the route via BGP and 
> understand how to route to that BGP destination. This is 
> driven by the BGP 
> next-hop. As the next-hop is learnt from an exit point CE, we 
> route toward 
> the CE (assuming no MPLS within the site) and then perform 
> label imposition 
> on the CE - there is no knowledge of the providers network topology 
> required. Hope this helps. Jim
> 
> 
> >With best regards,
> >                                    Sasha Vainshtein
> >email:     [email-masked]
> >tel:       +972-3-7659993 (office)
> >            +972-8-9254948 (res.)
> >            +972-58-674833 (cell.)
> >
> >
> >
> > > -----Original Message-----
> > > From: jim guichard [mailto:[email-masked]]
> > > Sent: Monday, May 14, 2001 10:35 AM
> > > To: Sasha Vainshtein
> > > Cc: Metz, Eduard; 'Shahram Davari'; [email-masked]'; Alik
> > > Shimelmits; Elena Vinkler
> > > Subject: RE: BGP/MPLS VPN PE LSR
> > >
> > >
> > > Sasha,
> > >
> > > At 11:03 14/05/2001 +0200, Sasha Vainshtein wrote:
> > > >Regarding the Carriers Carrier model:
> > > >My assumption is that in this model the label on the packet
> > > >sent by the upstream CE router to its appropriate  PE has
> > > been assigned
> > > >(to some FEC)
> > >
> > > your assumption is not correct. The label that the CE will use is
> > > distributed by its upstream PE router. The external routes of
> > > the site are
> > > distributed to other sites using iBGP. The BGP next-hops for
> > > these prefixes
> > > are exchanged with the MPLS VPN backbone using standard
> > > routing protocols
> > > but also LDP label distribution. The BGP next-hops are placed
> > > into the PE
> > > routers VRF and then advertised across the backbone as VPNv4
> > > prefixes. Once
> > > imported into the receiving PE routers VRF, they are 
> advertised using
> > > standard routing protocols to the CE but also with LDP label
> > > distribution.
> > > All of this provides an end-to-end LSP between ASBRs in
> > > different sites,
> > > and provides the ability to off load large amounts of prefix
> > > information
> > > from the MPLS VPN backbone .. Jim
> > >
> > > >  by the peer downstream CE router at the
> > > >other side of the CE<-->CE tunnel and then distributed to
> > > >the upstream CE (e.g., via a direct LDP session between the
> > > two CE routers)
> > > >  without any involvement of the PE routers (save from that that
> > > >they provide an IP VPN connectivity between CEs
> > > >so that the latter can run LDP sessions between them).
> > > >This means that PE cannot do anything with such a label per se!
> > > >One way to overcome siuch a situation would be for the two
> > > CEs to run either
> > > >
> > > >MPLS-in-IP or MPLS-in-GRE between them as described in
> > > ><draft-worster-mpls-in-ip-04.txt>.
> > > >
> > > >With best regards,
> > > >                                    Sasha Vainshtein
> > > >email:     [email-masked]
> > > >tel:       +972-3-7659993 (office)
> > > >            +972-8-9254948 (res.)
> > > >            +972-58-674833 (cell.)
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: jim guichard [mailto:[email-masked]]
> > > > > Sent: Thursday, May 10, 2001 11:41 AM
> > > > > To: Metz, Eduard
> > > > > Cc: 'Shahram Davari'; [email-masked]'
> > > > > Subject: RE: BGP/MPLS VPN PE LSR
> > > > >
> > > > >
> > > > > The case where a PE will receive a labelled packet is
> > > > > referred to as the
> > > > > Carriers Carrier architecture and it has several flavours. In
> > > > > the case
> > > > > where the VPN site is running MPLS, then you will see a two
> > > > > level label
> > > > > stack across the carrier backbone. A three level label stack
> > > > > will be seen
> > > > > when the VPN site is running MPLS VPN and this is 
> referred to as a
> > > > > hierarchical VPN. Jim
> > > > >
> > > > > At 10:43 10/05/2001 +0200, Metz, Eduard wrote:
> > > > >
> > > > > >I assume you are referring to the 'carriers-carrier' model.
> > > > > This section in
> > > > > >the draft is pretty vague. However, are you sure 2 labels
> > > > > will be added?
> > > > > >Could the PE not also use the customer label as the inner
> > > > > label (and thus
> > > > > >swap it)?
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Shahram Davari 
[mailto:[email-masked]]
> > > > > > Sent: 09 May 2001 21:16
> > > > > > To: [email-masked]'
> > > > > > Subject: BGP/MPLS VPN PE LSR
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS
> > > > > > packet rather than an IP packet to a PE router, the PE router
> > > > > > should still push 2 labels. My question is, should the PE
> > > > > > router swap the customer's label too or leave it unchanged?
> > > > > >
> > > > > > Yours,
> > > > > > -Shahram
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > Jim Guichard CCIE #2069
> > > > Technical Leader EMEA
> > > >
> > > > +44 208 756 8806
> > > > Mobile: +44 7802 809763
> > > >
> >
> >
> >
> > Jim Guichard CCIE #2069
> > Technical Leader EMEA
> >
> > +44 208 756 8806
> > Mobile: +44 7802 809763
> >

Jim Guichard CCIE #2069
Technical Leader EMEA

+44 208 756 8806
Mobile: +44 7802 809763

---

From: jim guichard <[email-masked]>
Date: Mon, 14 May 2001 19:05:38 +0100

>   (in you terms, PE-1 learns a (direct) route to ASBR-A but not to any

 From the providers point of view it only knows of routes that are 
advertised from the CE router - there may be other addresses (such as 
internal servers) which must also be reachable from other sites so these 
may also be advertised to the provider. In general, the only routes which 
will be off-loaded will be external routes to the site e.g. Internet or 
customer routes.

>2. CE routers belonging to the same VPN maintain iBGP sessions between them.

yes.

>    with the corresponding CE as a BGP next hop for these prefixes.

they are used to distribute any external routes such as Internet or 
customer routes.

>         it isadded to the appropriate VRF instance

yes

>         regular route with the adjacent PE as its next hop

the CE cannot use default as the default cannot point to all other sites. 
It could use default for a central site.

>       * Apropriate VRF instance in egress PE

just VPN label is advertised from the originating PE to other PEs which 
import the routes into their attached VRFs. They then allocate their own 
IGP label for the route and advertise this label to any attached CE routers 
with whom they have an LDP adjacency.

>         as a consequence, the LSP in question operates is if PHP were

I would say ingress ASBR ..

>   a) Look at the dest IP address

yes

>   b) Find an egress CE which is a BGP next hop to the prefix which matches

route toward the next-hop of the BGP route - this is normal routing 
behaviour. If MPLS is run within the site then label imposition will occur 
at this point. If not, then the first label will be imposed by the exit 
point CE router.

>the actual prefixes behind them.

absolutely and this is the main purpose of this architecture ..

>Hopefully I did not extend your patience beyond reasonable limits.

not at all .. Jim

Jim Guichard CCIE #2069
Technical Leader EMEA

+44 208 756 8806
Mobile: +44 7802 809763