Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

From: "Amir Halperin" <[email-masked]>
Date: Mon, 4 Oct 2010 15:17:27 +0200

Hi all.

Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then
welcomed.

Draft location:

http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00

Thanks in advance,

Amir Halperin
System Engineer
Orckit-Corrigent Systems Ltd
Office:  +972-3-694-5379

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815
mailto:[email-masked] <mailto:[email-masked]>

---

From: "Puneet Agarwal" <[email-masked]>
Date: Tue, 5 Oct 2010 00:12:42 -0700

Hi Amir/Rafi,

As I see it, the problem really devolves into the following:
For every packet that enters the network, you need to carry (with the packet) which interface type (root  vs leaf) the packet entered the network. This property is independent of the PW between any 2 PEs. Doubling the number of PWs just to carry this information is not very scalable as the number of managed objects doubles (along with OAM observation points). It seems a better approach would be to carry an additional label below the PW label (or potentially in the control word) to carry this network ingress interface property (root vs leaf).

A potential hack would be to generalize the entropy label to carry not just the entropy label but also network ingress interface properties and require entropy label for these PWs (with an option to disable the entropy for load distribution). I list this only as an option - but I am not too thrilled about this.

Moreover, if you look Ali's preso at the IETF78 on Routed VPLS, it seem to need not just a single attribute of the network ingress interface but potentially may need to carry the network ingress interface id itself (which btw will have its own naming and scaling challenges - solvable but still a challenge). Architecturally I would hope that the Etree becomes a special case of Ali's work (and we add a label below the PW label to carry these attributes/id) rather than creating point solutions and blowing out the number of PWs.

Thanks.

-Puneet
From: [email-masked] [mailto:[email-masked]] On Behalf Of Amir Halperin
Sent: Monday, October 04, 2010 6:17 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: Rafi Ram
Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

Hi all.

Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then welcomed.

Draft location:

Thanks in advance,

Amir Halperin
System Engineer

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815
mailto:[email-masked]

---

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Tue, 5 Oct 2010 10:47:23 -0400

We should take a fresh look at what VPLS deployed on wired networks
drives as requirements. The way VPLS is actually realized in the network
requires specialized PWs on a per VPN basis, all of our other services
use the underlying LSPs built between PEs. This drives unique
network/ops models for this service. We want to re-use our existing
infrastructure and NM. As VPLS grows I come to the realization that a
better paradigm is to treat L2VPN more like L3VPN and carry MAC state in
the control plane, re-using data plane learning technology is well
suited for LANs and CE<->PE but not for L2VPN over WANs. Specific to
E-Tree I believe at best the solutions based on inferring topology
information based on examination of a data packet is flawed as it blurs
the line between control and data plane functions.. Below find reqs I
have socialized before on this forum..

a)      Spokes on the same PE that are home into the same VRF are not
precluded from communication. There is "special" configuration needed by
vendors to preclude intra-spoke communication. Again the control plane
semantic is not enforced in the data plane forcing band-aid type
solutions. I want the definition of the spoke to preclude the ability to
communicate with other spokes.

b)      Intra-PE PW construction/behavior does not exist.. This means
the semantics needed to preclude leaking between Hub and Spoke sites on
the same PE needs to have some 'special" config. By definition a Hub and
Spoke on the same PE should not be able to communicate, we should not
need to configure what is needed on a per vendor basis. This causes much
pain in our Ops/System models.. Open Kimono.. BGP signaling and using
RTs should be useful here. I am not well versed in LDP signaling but
there should be the same requirement there.. No special configuration
outside the scope of VPLS signaling.

c)       Multiple PWs may be useful to restrict data learning inter-PE.
This is but based upon how different vendors construct the PW topology.
We may find this to be untenable if we have lots of E-Tree and lots of
Hubs.. We then have spaghetti...

All of the concerns above speak to the same issue.. We are trying to
force fit ethernet LAN technology over a WAN by constructing PWs..

Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Puneet Agarwal
Sent: Tuesday, October 05, 2010 3:13 AM
To: Amir Halperin; [email-masked]; [email-masked]; [email-masked]
Cc: Rafi Ram
Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

Hi Amir/Rafi,

For every packet that enters the network, you need to carry (with the
packet) which interface type (root  vs leaf) the packet entered the
network. This property is independent of the PW between any 2 PEs.
Doubling the number of PWs just to carry this information is not very
scalable as the number of managed objects doubles (along with OAM
observation points). It seems a better approach would be to carry an
additional label below the PW label (or potentially in the control word)
to carry this network ingress interface property (root vs leaf). 

A potential hack would be to generalize the entropy label to carry not
just the entropy label but also network ingress interface properties and
require entropy label for these PWs (with an option to disable the
entropy for load distribution). I list this only as an option - but I am
not too thrilled about this.

Moreover, if you look Ali's preso at the IETF78 on Routed VPLS, it seem
to need not just a single attribute of the network ingress interface but
potentially may need to carry the network ingress interface id itself
(which btw will have its own naming and scaling challenges - solvable
but still a challenge). Architecturally I would hope that the Etree
becomes a special case of Ali's work (and we add a label below the PW
label to carry these attributes/id) rather than creating point solutions
and blowing out the number of PWs. 

Thanks.

-Puneet

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Amir Halperin
Sent: Monday, October 04, 2010 6:17 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: Rafi Ram
Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

Hi all.

Draft location:

Thanks in advance,

Amir Halperin
System Engineer

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815

---

From: "Amir Halperin" <[email-masked]>
Date: Wed, 6 Oct 2010 10:59:55 +0200

Hi Jim.

I want to make sure I understand your suggestion.

Are you suggesting that root/leaf information should be per user i.e.
per MAC address, and not per AC?

Amir Halperin

[email-masked] <mailto:[email-masked]> 

________________________________

From: UTTARO, JAMES (ATTLABS) [mailto:[email-masked]] 
Sent: Tuesday, October 05, 2010 4:47 PM
To: Puneet Agarwal; Amir Halperin; [email-masked]; [email-masked];
[email-masked]
Cc: Rafi Ram
Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

Jim Uttaro

Hi Amir/Rafi,

Thanks.

-Puneet

Hi all.

Draft location:

Thanks in advance,

Amir Halperin
System Engineer

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815

---

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Wed, 6 Oct 2010 11:04:47 -0400

Amir,

No.. I was commenting on the fact that notion of whether a packet is
received from a Root/Leaf should not be determined by examination of the
packet.. This blurs the line between control/data plane.. 

Jim Uttaro

From: Amir Halperin [mailto:[email-masked]] 
Sent: Wednesday, October 06, 2010 5:00 AM
To: UTTARO, JAMES (ATTLABS); Puneet Agarwal; [email-masked];
[email-masked]; [email-masked]
Cc: Rafi Ram; [email-masked]
Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

Hi Jim.

Amir Halperin

Jim Uttaro

Hi Amir/Rafi,

Thanks.

-Puneet

Hi all.

Draft location:

Thanks in advance,

Amir Halperin
System Engineer

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815