Subject: RE: L2vpn Digest, Vol 96, Issue 56

From: "Sam Cao" <[email-masked]>
Date: Thu, 10 May 2012 13:08:36 +0800

Yuanlong,

Please check the mail list :). Giles gave his comments on this, too, and
finally we can ignore this and don't go on discussion.

We need to forward to key items, then we can move forward, ..

Thanks,

Sam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, May 10, 2012 3:00 AM
To: [email-masked]
Subject: L2vpn Digest, Vol 96, Issue 56

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/l2vpn

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send L2vpn mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/l2vpn
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of L2vpn digest..."

Today's Topics:

   1. RE: Discussion on E-Tree and H-VPLS (Jiangyuanlong)
   2. (no subject)
   3. PBB E-VPN and TRILL (Giles Heron)
   4. RE: L2vpn Digest, Vol 96, Issue 15 (Sam Cao)
   5. RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN
      traffic	over IP PSN using MPLS-in-UDP encapsulation// fwd: New
      Version	Notification for draft-xu-mpls-in-udp-00.txt
      (AshwoodsmithPeter)

----------------------------------------------------------------------

Message: 1
Date: Wed, 9 May 2012 12:30:43 +0000
From: Jiangyuanlong <[email-masked]>
To: Jiangyuanlong <[email-masked]>, Sam Cao
	<[email-masked]>,	"[email-masked]"
	<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Discussion on E-Tree and H-VPLS
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

Seems too big to be received, snipped and send again. Sorry for the
inconvenience.

-----Original Message-----
From: Jiangyuanlong 
Sent: Wednesday, May 09, 2012 7:59 PM
To: 'Sam Cao'; [email-masked]'
Cc: [email-masked]
Subject: RE: Discussion on E-Tree and H-VPLS

Hi Sam,

Your statements are misleading at best IMHO, but let us go over the original
question from YOU to see what problem is behind.

You believe it make no sense that:
>>For VPWS access, we should configure Root/Leaf for Spoke PW;
>>for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW.

Not so correct, speaking more exactly, the dual-VLAN will:
In the 1st case, each root/leaf AC (attached to a PE-r) has a corresponding
Spoke PW connecting to the PE-rs, so we configure the Root/Leaf attribute
for the Spoke PW on the PE-rs;
In the 2nd case, all root/leaf AC (attached to a MTU-s) share a single Spoke
PW connecting to the PE-rs, so we configure the Root/Leaf attribute for the
AC on the MTU-s.

We exchanged several emails on this topic and reached no agreement on what
you said, just simply take a snip from the email (thank Giles):
"
On 24/04/2012 10:25, "Sam Cao" <[email-masked]> wrote:

> Giles,
> > Configure Root/Leaf on MTU-s and have the MTU-s add the root/Leaf 
> VLAN. It is correct and reasonable for Fig. 3. We can not configure it 
> on PE1-rs anymore.

Right.
 
> In Fig. 4, shall we configure on PE-r? It seems not reasonable since 
> on PE-r, it is VPWS. So in Fig. 4, we will have to configure on 
> PE1-rs. PE1-rs has different behavior in the 2 cases. This does not make
sense for me :).

For PE-r each spoke is root or leaf.  It can't be both.  And yes, it's VPWS
not VPLS.  So it makes more sense to configure on the PE-rs.  Quite possibly
the VPWS would be untagged in that instance...
"

Therefore, the fact is, two of us thought it make sense, and the third
regarded it as non sense^&^

Let us go over your conclusion again:
>> Multi-PW has no problem on this: Configure Root or Leaf on PE1-rs in the
2
>> cases since it uses different PATH, not inferring context in frame.
It seems you prefer to configuring root/leaf attribute for Spoke PW on PE-rs
in both cases.

------------------------------

Message: 2
Message-ID: <[email-masked]>

nfiguration of root/leaf attribute for the ACs is further needed on the PE-=
r,
and I believe in the 2nd use case, configuration of root/leaf attribute for=
 the ACs is also needed on the MTU-s (otherwise, how can the 2PW use differ=
ent PATH?), so that 2 PWs can be set up to carry the E-Tree traffic.

Now we can compare the Dual-VLAN with 2PW approach to see what is different=
:
In the 1st case, both configure the Root/Leaf attribute for the Spoke PW on=
 the PE-rs; and 2PW will further configure the Root/Leaf attribute for the =
AC on the PE-r.
In the 2nd case, both configure the Root/Leaf attribute for the AC on the M=
TU-s, and 2PW will further configure the Root/Leaf attribute for the Spoke =
PW on the PE-rs.
In both cases, configuration for Dual-VLAN is simpler, so, does a more comp=
lex configuration really make more sense to you?

Regards,
Yuanlong

----------------------------------------------------------------------
Date: Wed, 9 May 2012 09:40:12 +0800
From: "Sam Cao" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: RE: Discussion on E-Tree and H-VPLS
Message-ID: <D8A170B760DE4CACA680B7C6737926BF@R01842>
Content-Type: text/plain;	charset=3D"gb2312"

Hi Lizhong?

Thank you very much for your comments. I updated the result on this
question.

[Lizhong] agree with the above analysis. And we did not say it is a
technical problem, but it is an operational problem again.
[Sam] I agree. Dual-VLAN does not make sense. I also discussed this with
Giles and Yuanlong in another mail, and we reached agreement on this: MTU
should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN
ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but w=
e
can figure this out in draft. It seems ok.

[Lizhong] not fully understand. Do you mean,  when VPWS accessing for
H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW)
for each AC access?
[Sam] Yes.

Thanks,

Sam
----snipped------

------------------------------

Message: 3
Date: Wed, 09 May 2012 13:34:16 +0100
From: Giles Heron <[email-masked]>
To: <[email-masked]>
Cc: "Ali Sajassi \(sajassi\)" <[email-masked]>,	Stewart Bryant
	<[email-masked]>
Subject: PBB E-VPN and TRILL
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="US-ASCII"

Ali presented the PBB-EVPN draft at IETF83 in Paris:

http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01

This has since been updated:

http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02

During our discussions Ali mentioned that the authors would like the TRILL
section of the draft to be separated out into a separate draft.  In response
Stewart questioned whether interconnecting TRILL islands is in-scope for
L2VPN.

Stewart, Nabil and I have just been discussing these issues.  Whilst TRILL
interconnect is not explicitly in-charter for L2VPN it would appear to be
implicitly in-charter - our decision to standardise solutions for PBB VPLS
and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by
the charter).

On this basis we would like to ask the WG the following three questions:

1) is the WG happy for us to pursue interconnection of TRILL islands over
L2VPN?

2) is the WG happy for the authors to split the TRILL section of the PBB
E-VPN draft into a separate draft?

3) is the WG happy for the TRILL draft to be a WG doc?

Please respond by May 22nd if you are unhappy with any of these 3 actions
(I'll take no response to mean the WG is in agreement with us proceeding...)

Giles

------------------------------

Message: 4
Date: Wed, 9 May 2012 22:36:15 +0800
From: "Sam Cao" <[email-masked]>
To: "'Rogers, Josh'" <[email-masked]>,	"'Lucy yong'"
	<[email-masked]>, <[email-masked]>
Cc: 'Jiangyuanlong' <[email-masked]>
Subject: RE: L2vpn Digest, Vol 96, Issue 15
Message-ID: <9B621211971C4C3AA39BBF435FC4718F@v2comsam>
Content-Type: text/plain;	charset="us-ascii"

Lucy, Josh,

Thank you very much for your insight comments. Sorry for late reply for busy
day job :).

I picked your comments below and see my comments inline.

>[[LY]] I interpret this as people want to spend time to finalize dual
>VLAN solution. Multi-PW has some operation impact. How do operator to
>maintain this service and be able to trouble shooting. How do you expect
>traceroute work when using two PWs for one VPN? How do you expect PE
>report when there is an error on one of two PWs? Do you have one FEC or
>two FEC for a E-Tree in control plane?
[JR] I don't see this any more of a problem than troubleshooting one.  If
LDP is used, a simple mols traceroute shows the path that ALL PW's to that
PE take, regardless of which service (this VPLS or another VPLS instance).
 If RSVP is used, there should be a route-object that shows me the path,
and allows me to troubleshoot.  Additionally, if I wanted to have traffic
engineering that impacted root-sourced and leaf-sourced traffic
differently, I can do that with multi-PW, where I could not (save for
ingress/egress) with the 2VLAN approach.  PE should report signaling on
second PW same as it does for the 100th PW between PE's.  Again, I don't
see the problem you are alluding to.
[Sam] Lucy, I agree with your comments, and both approaches need time to
finalize. I answered to your questions one by one, and wish this is clear.
First, there is no problem on traceroute or trouble-shooting or LSP ping.
Josh has given some insight comments, and yes, we have 2 PWs, but we just
repeat the OAM work twice, and there is no difference. If there is an error
on one of 2 PWs, ok, OAM just report the error on the corresponding PW. For
example, if Leaf PW has an error, OAM detects Leaf PW error. Finally, in
control plane we don't introduce new FEC. Only one FEC for an E-Tree
instance, FEC 128 or FEC 129.

>[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree
>your statement here.
[Sam] Lucy, first of all, PW label is NOT used as VSI indicator. In RFC
4762, "In a VPLS, we use a VCID to identify an emulated LAN segment (from
RFC 4762)", and VPLS identifier is not carried in frame; in RFC 4761, Route
Target is used as VPLS identifier. PW label (ILM) can be taken as PW
identifier. What I mean is, one frame from Root AC on PE 1 to PE 2, for
example, Dual-VLAN will add 2 identifiers in the frame, Root-VLAN ID to
identifier the frame from Root; PW label means which PW will carry the
frame. But for Multi-PW, we only need one PW label, and it is enough.

>[[LY]] Don't understand the first part. When egress pop-out PW label, it
>find corresponding VSI first, then perform MAC lookup associated to all
>ACs. We can't assume there is one AC.
[Sam] Same description as above. Dual-VLAN uses one PW to carry frames from
Root-AC or Leaf-AC, but Multi-PW uses one to carry frames from Root and one
carry frames from Leaf. MAC lookup is basic bridge function and both should
use this. We can ignore this first. Multi-PW popped the PW label out, then
do MAC lookup; But dual-VLAN popped the PW label out, it should check VLAN
identifier, and then do MAC lookup. If we implement it in NP, obviously it
will cost more time and decrease forwarding performance.

>[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for
>E-Tree.
[Sam] If we use tagged mode, yes, I agree with your idea. But if we use raw
mode, generally Multi-PW can supports more, but IMO Dual-VLAN can not. This
is my point.

>[[LY]] This should not be the reason to judge on the solution.
[JR] I tend to agree.
[Sam] I don't make myself understood. If I don't know the VLAN ID allocation
solution, I will have no correct comments on it. Yes, I agree this is not
the reason to judge on the solution.

>[[LY]] VPN label is used for identify the VPN. It already has the
>purpose. Overloading with other meaning has high potential causing a
>problem. Hope you can investigate it more. Since you are very in favor of
>multi-pw solution, it is not proper for you to come out the conclusion
>which is better, because it is very biased. You are welcome to help on
>completing either solution.
[JR] this is humorous to me, because at one time, VLAN-ID was used to
identify a single broadcast domain, and then later asymmetrical VID's were
used to limit communication between endpoints of a broadcast domain
(effectively creating two one-way broadcast domains, very similar to what
we're accomplishing with ETREE).   This should not be the reason to judge
on the solution.
[Sam] Same as above. PW label identify the PW. For example, we can use label
2000 to identify Root PW, label 2001 to identify Leaf PW. This does not
identify E-Tree, although the 2 PWs belong to one E-Tree instance.

Wish this is clear. Again thank you for your time,

Regards,
 
Yuqun (Sam) Cao
E-mail: [email-masked] 

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Comments inline (and s/conquer/concur/)

On 5/7/12 2:58 PM, "Lucy yong" <[email-masked]> wrote:

>Sam,
>
>I concur with Yuanlong's reply on this. Please see inline.
>
>Lucy
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Sam Cao
>Sent: Friday, May 04, 2012 9:09 PM
>To: [email-masked]
>Cc: Jiangyuanlong
>Subject: RE: L2vpn Digest, Vol 96, Issue 15
>
>Lucy/Yuanlong,
>
>I agree that we can not say which approach is better simply, but I really
>agree with Josh's comments. Multi-PW is easy to implement E-Tree.
>[[LY]] I don't get impression Josh state this.
>
>First of all, we discussed 2 approaches for a long time and many rounds,
>and
>for me, there are no pending issues on Multi-PW till now or co-authors of
>multi-PW have given reasonable reply to L2VPN members' questions, but
>there
>are still pending issues for Dual-VLAN. Please trace the mailing list.
>[[LY]] I interpret this as people want to spend time to finalize dual
>VLAN solution. Multi-PW has some operation impact. How do operator to
>maintain this service and be able to trouble shooting. How do you expect
>traceroute work when using two PWs for one VPN? How do you expect PE
>report when there is an error on one of two PWs? Do you have one FEC or
>two FEC for a E-Tree in control plane?
[JR] I don't see this any more of a problem than troubleshooting one.  If
LDP is used, a simple mols traceroute shows the path that ALL PW's to that
PE take, regardless of which service (this VPLS or another VPLS instance).
 If RSVP is used, there should be a route-object that shows me the path,
and allows me to troubleshoot.  Additionally, if I wanted to have traffic
engineering that impacted root-sourced and leaf-sourced traffic
differently, I can do that with multi-PW, where I could not (save for
ingress/egress) with the 2VLAN approach.  PE should report signaling on
second PW same as it does for the 100th PW between PE's.  Again, I don't
see the problem you are alluding to.
>
>Second, Sasha has his concern in NP, or forwarding performance. Compared
>to
>current VPLS, Multi-PW has a little effect on forwarding performance since
>it reuse PW label as AC indicator; Dual-VLAN will have higher side effect
>on
>forwarding performance because it SHOULD use additional indicator. Is
>there
>one prototype for Dual-VLAN? BTW, there is no reply on chip limit.
>[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree
>your statement here.
>
>Third, the difference between Multi-PW and dual-VLAN is, transport ingress
>traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms
>ingress
>traffic into right "path", and egress just pop-out PW label and forward
>the
>frame to ACs. Dual-VLAN has more work on ingress PE or egress PE.
>[[LY]] Don't understand the first part. When egress pop-out PW label, it
>find corresponding VSI first, then perform MAC lookup associated to all
>ACs. We can't assume there is one AC.
>
>Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit.
>Only
>4094 VLAN ID are available, so only 2K E-Tree instances can be supported
>on
>one PE for Dual-VLAN approach. There is no such limit for Multi-PW
>approach,
>[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for
>E-Tree.
>
>Finally, in this thread we don't make agreement on VLAN ID allocation. We
>also have questions on VLAN ID negotiation among PEs (signaling protocol).
>Yuanlong wishes to update, but there is no update till now.
>[[LY]] This should not be the reason to judge on the solution.
[JR] I tend to agree.
>
>For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :),
>and
>it has label, it also wish to use label to identify AC types. I think that
>both solutions need much time to be perfect. Mutli-PW has less extension
>work to do. But now we are focusing on technical details and can not move
>forward :).
>[[LY]] VPN label is used for identify the VPN. It already has the
>purpose. Overloading with other meaning has high potential causing a
>problem. Hope you can investigate it more. Since you are very in favor of
>multi-pw solution, it is not proper for you to come out the conclusion
>which is better, because it is very biased. You are welcome to help on
>completing either solution.
[JR] this is humorous to me, because at one time, VLAN-ID was used to
identify a single broadcast domain, and then later asymmetrical VID's were
used to limit communication between endpoints of a broadcast domain
(effectively creating two one-way broadcast domains, very similar to what
we're accomplishing with ETREE).   This should not be the reason to judge
on the solution.

>Regards,
>Lucy
>Lucy
>Thanks,
>Sam

------------------------------

Message: 5
Date: Wed, 9 May 2012 15:01:39 +0000
From: AshwoodsmithPeter <[email-masked]>
To: Ivan Pepelnjak <[email-masked]>, "[email-masked]"
	<[email-masked]>, Keshava A K <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
	<[email-masked]>,	"[email-masked]" <[email-masked]>
Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN
	traffic	over IP PSN using MPLS-in-UDP encapsulation// fwd:
New	Version
	Notification for draft-xu-mpls-in-udp-00.txt
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

> True, but many existing DC switches that do IP-based load balancing have
> no problems load-balancing on UDP 5-tuple. I am positive there's equipment
> out there that can do load balancing on GRE keys (or some other part of 
> GRE header), I just haven't encountered it yet (or realized it does that),
> so please fix my ignorance.
..
> Ivan

Hey Ivan,

Looking at the specs of one of the most popular chips there are generic CAM
rules that allow you to override some of the 'default' hash behaviors. So I
suspect you could program a number of CAM rules that match the NVGRE
Ethertype and the inner src/dst IP low bits to give you the hash index ..
but of course you'd burn CAM quite quicky but that's probably better than
trying to use more src/dst Ips to get the entropy.

Realistically we can have LAG groups with many 10/40G links that need to be
spread over. Especially between a monster core router and a monster core
switch. So using a couple of extra IP addresses per hypervisor is not going
to be adequate. I.e. does not provide enough entropy for such a wide LAG. So
in that case and the vanilla ECMP case you'd probably be able to trade CAM
space v.s. entropy but that's not a cheap solution.

Peter

------------------------------

_______________________________________________
L2vpn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 96, Issue 56
*************************************