The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-May> msg00228



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

BGP/MPLS VPN PE LSR

  • From: jim guichard <jguichar@cisco.com>
  • Date: Mon, 14 May 2001 16:16:10 +0100
  • Cc: Sasha Vainshtein <Sasha@AXERRA.com>, "Metz, Eduard" <Eduard.Metz@KPNQwest.com>, "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>, "'mpls@uu.net'" <mpls@UU.NET>, Alik Shimelmits <alik@AXERRA.com>, Elena Vinkler <elena@AXERRA.com>

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:     sasha@axerra.com
>tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
>
>
>
> > -----Original Message-----
> > From: jim guichard [mailto:jguichar@cisco.com]
> > Sent: Monday, May 14, 2001 10:35 AM
> > To: Sasha Vainshtein
> > Cc: Metz, Eduard; 'Shahram Davari'; 'mpls@uu.net'; 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:     sasha@axerra.com
> > >tel:       +972-3-7659993 (office)
> > >            +972-8-9254948 (res.)
> > >            +972-58-674833 (cell.)
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: jim guichard [mailto:jguichar@cisco.com]
> > > > Sent: Thursday, May 10, 2001 11:41 AM
> > > > To: Metz, Eduard
> > > > Cc: 'Shahram Davari'; 'mpls@uu.net'
> > > > 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:Shahram_Davari@pmc-sierra.com]
> > > > > > Sent: 09 May 2001 21:16
> > > > > > To: 'mpls@uu.net'
> > > > > > 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