Subject: FW: ce range in l2 mpls vpns

From: "Metz, E.T." <[email-masked]>
Date: Thu, 23 Nov 2000 12:47:45 +0100

This is indeed a bit confusing. 

As far as I understand (Kireeti: correct me if I'm wrong here) the
parameters are actually *configured* on the PE. However, the CE should know
about this. In particular the CE configuration should reflect the same logic
that is applied by the PE in mapping CE-to-CE circuits to eachother. This is
the algorithm described in Section 4.3.1. When CE and PE configuration are
not aligned on this point, the CE may expect to connect to one site on a
particular circuit, while the PE actually connects it to another one.

I think the text should say that the parameters are configured on the PE,
and that the CE should know about this / reflect this in it's configuration.
Currently, it is described in the exact opposite way. Also it makes less
sense to configure it on the CE since there is no interaction between PE and
CE to exchange this information.

cheers,
	Eduard

Metz, E.T. writes:

 > it is the pe that is configured with the parameters you mention, not
 > the ce.

that is not what the i-d says:

4.2.1. CE Configuration

   Each CE that belongs to a VPN is given a "CE ID".  CE IDs must be
   unique in the context of a VPN.  We assume that the CE ID for CE-k is
   k.  Each CE is also configured with a maximum number of CEs that it
   can connect to; this is the CE's "range".

   Each CE is configured to communicate with its corresponding PE with
   the set of DLCIs given above; for example, CE0 is configured with
   DLCIs 100 through 109.  OSPF is configured to run over each DLCI. 

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 23 Nov 2000 15:01:18 +0200 (EET)

Metz, E.T. writes:

 > When CE and PE configuration are

in fr or atm world, the ce learns via lmi or ilmi about new or deleted
labels.  then it sends an inarp message along the vc and learns who is
behind that vc and starts to exchange ospf messages with it.  the vc
topology doesn't need to be full mesh and still all the vpn members can
share a common ip subnet.

as long as the ce-pe protocol remains fr or atm and mpls is used only in
the provider network, there should be no changes whatsoever to the above
described ce operation.

but if the ce-pe protocol is native mpls, then the standard fr or atm
inarp procedure stops working, because (a) mpls vcs are unidirectional
and (b) can be merged.  one possibility might be that the destination ce
that receives an inarp request for an unkown source, sends the reply
back to all vcs that are still unknown to it.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 23 Nov 2000 15:48:15 +0200 (EET)

Jim Guichard writes:

 > it seems to me that as the SP part of the picture is MPLS (as opposed to
 > ATM) then the DTE to DCE part of the VC (PE to CE) is essentially unchanged
 > and therefore such mechanisms as lmi and inverse-arp should continue to
 > function as-is. 

 > >the provider network, there should be no changes whatsoever to the above

this case just needs to be covered in the i-d as well as the trickier
case when ce-pe protocol is mpls.

-- juha

---

From: Jim Guichard <[email-masked]>
Date: Thu, 23 Nov 2000 13:37:44 +0000

Juha,

it seems to me that as the SP part of the picture is MPLS (as opposed to
ATM) then the DTE to DCE part of the VC (PE to CE) is essentially unchanged
and therefore such mechanisms as lmi and inverse-arp should continue to
function as-is. As soon as the PE 
activates a new dlci, this should be reflected within the lmi and therefore
the router (CPE) will signal using inverse-arp for the protocol address at
the other end of the VC. If this is not the case then some kind of static
frame-relay map would be needed on the CPE ..Jim

>back to all vcs that are still unknown to it.

Jim Guichard CCIE #2069
Technical Advisory Consultant EMEA
Global Solutions Engineering 

+44 208 756 8806
Mobile: +44 7802 809763