The MPLS-OPS Archive

["alok" <alok.dube@apara.com>]

:o)

i agree,

what confused me is the reason for that constraint...

why does it restrict to IP...

what i meant by same as L3 vpn is that iy gives the same functionality...
ofcourse no seperate routing table for the customers networks etc...

but if CE-id is the deciding factor...which i use in L2VPN, how does the the
ATM/FR thing matter...?

The draft imples " the FR DLCI for example has to be same across the MPLS
network"..which means if its DLCI -100 to CE-2 from CE-1, it has to be set
so at Ce-1 and CE-2

so now if i have ATM on one end and FR on the other (which he talks about in
generalised MPLS section of the draft)...he says L3 has to be
IP...functionally, i cud achieve the same using L3 VPN (ofcourse not
offloading customer routing as u rightly put)....

the point is: what DLCI is to FR and VPI/VCI is to ATM is what CE-ID is to
MPLS L2VPN (in a way its the end point indentifier...am i right? then why
should it matter if the other end is of a different encap type as all my
decisions are based on CE-ID

this is what i could make out of the draft.. that CE-ID plays the deciding
role...but the reason why confine it to IP is not clear...(there is some
stuff abt TOS )

it does say :
For example, an ATM Layer 2 VPN could have some CEs
   connect via Frame Relay links, if their PE could translate Frame
   Relay to ATM transparent to the rest of the VPN.  This would be
   private to the CE-PE connection.....

this confuses me...


-rgds
Alok

----- Original Message -----
From: Guy Davies <Guy.Davies@telindus.co.uk>
To: 'alok' <alok.dube@apara.com>; <mpls-ops@mplsrc.com>
Sent: Tuesday, September 10, 2002 6:52 PM
Subject: RE: [MPLS-OPS]: Re: L2VPN



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No, this is actually a limitation specified in the l2vpn draft (You
may want to read it.  It answers your question fairly comprehensively
;-).  You can either have the same encapsulation at both ends and any
L3 protocol or dissimilar L2 encapsulations and be constrained to IP.

This is NOT like L3VPN because the provider has no knowledge of your
networks in his routing tables.  L3VPN requires the provider to
maintain copies of your (and every other customer's) routing
information in a VRF.  L2VPN merely creates "circuits" between two or
more CE devices.  Only the CE devices know about the structure of the
customer's network.

Regards,

Guy

> -----Original Message-----
> From: alok [mailto:alok.dube@apara.com]
> Sent: Tuesday, September 10, 2002 2:12 PM
> To: Guy Davies; mpls-ops@mplsrc.com
> Subject: Re: [MPLS-OPS]: Re: L2VPN
>
>
> but then thats as good as an L3VPN??
> why bother abt it at all then??
>
> what i wanna know is can L2VPN be implemented (non ip
> traffic) to achieve
> this result?
> -rgds
> a
> ----- Original Message -----
> From: Guy Davies <Guy.Davies@telindus.co.uk>
> To: 'alok' <alok.dube@apara.com>; <mpls-ops@mplsrc.com>
> Sent: Tuesday, September 10, 2002 6:32 PM
> Subject: RE: [MPLS-OPS]: Re: L2VPN
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yes.  This is certainly possible using JUNOS (from 5.3 I think).
> It is known in JUNOSspeak as translational cross connect (tcc).
> I'm not sure about other vendors.  You can currently interoperate
> any
> combination of ATM (P2P), FR (P2P), PPP and Cisco-HDLC.  There is a
> downside to this functionality.  You can only carry IP traffic over
> such a VPN.
>
> Regards,
>
> Guy
>
> > -----Original Message-----
> > From: alok [mailto:alok.dube@apara.com]
> > Sent: Tuesday, September 10, 2002 1:53 PM
> > To: mpls-ops@mplsrc.com
> > Subject: [MPLS-OPS]: Re: L2VPN
> >
> >
> > ...i ran this query sometime back...
> >
> > has anyone seen an implementation where the 2 remote ends are
> > of different
> > types..? like ATM on one end and FR on the other?
> >
> > ----- Original Message -----
> > From: alok <alok.dube@apara.com>
> > To: <mpls-ops@mplsrc.com>
> > Sent: Thursday, September 05, 2002 9:58 PM
> > Subject: Re: L2VPN
> >
> >
> > ...as an extension, why shud the encap even be the same at all?
> > i cud have FR on one end and ATM on the other...?
> >
> > am i misinterpreting the draft ?
> >
> > -rgds
> > Alok
> > ----- Original Message -----
> > From: alok <alok.dube@apara.com>
> > To: <mpls-ops@mplsrc.com>
> > Sent: Thursday, September 05, 2002 9:53 PM
> > Subject: L2VPN
> >
> >
> > Hi All,
> >
> > was just reading
> > http://www.ietf.org/internet-drafts/draft-kompella-ppvpn-l2vpn-02.
> > tx t
> >
> > does any one have any idea why the fr encap etc should be a
> > cross connect?
> >
> > why cant we simply let DLCIs change across locations...
> >
> > what i mean is this:
> >
> > Site -A connects to PE via some FR provider to go to Site B..
> > who comes into
> > my MPLS network.....
> >
> > he gives site A a DLCI to connect him from A to B.
> >
> > now the FR provider on the other end of the MPLS VPN cant use
> > the same DLCI
> > number....( he has used it etc)
> >
> > why cant i associate this with another DLCI and send it
> > across....
> >
> > essentially if the CE-id is the distinguisher... why can i
> > simply "simulate"
> > a huge FR network??? rather than a huge FR switch?
> >
> > its upto me how to associate the CE-id with the DLCI..... but why
> > not support "encap-fr" instead of "encap-fr-ccc"?
> >
> > same for ATM...
> >
> > any ideas?
> >
> > -rgds
> > Alok
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.0.1
>
> iQA/AwUBPX3tV43dwu/Ss2PCEQLlEwCfbUwY0BRbmgOLX9YiDQbTOfXaalQAoIB+
> 5QXRCY98QSrlOtXHnDaMrwA7
> =QQQW
> -----END PGP SIGNATURE-----
>
>
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.1

iQA/AwUBPX3yGI3dwu/Ss2PCEQI0QgCfaaRC+w9SuPzKahaueT7w/Jq95pIAn3Q7
EuWUoR5tliQdt+RHTdBpR8uA
=T4GW
-----END PGP SIGNATURE-----



-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml