Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Func tion in draft-stein-pwe3-pwce2e-00.txt

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 12 Nov 2003 04:03:34 +0200

Yaakov and all,
Please see some comments/answers inline.
I have snipped the irrelevant parts of the original text to increase
readability.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, November 12, 2003 3:28 AM
To: Sasha Vainshtein
Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG
(E-mail); David Sinicrope (E-mail)
Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching
Function in draft-stein-pwe3-pwce2e-00.txt

Sasha,

See a few comments below,

[[Sasha]] ...snipped ...

 This decision CANNOT be based on the PW labels in these packets,
because these labels are independently allocated by CE-2 and CE-3
respectively, so that nothing prevents them from being equal
(accidentally or else).
And inspection of the encapsulated data will not help either.

[[Sasha]] ... snipped ... 
[Y(J)S]  You are assuming that these inner labels are
independently downstream allocated by CE2 and CE3,
which doesn't have to be the case.

[Y(J)S] An easy fix is for PW labels to have "structure",
for example (what we do) is to use input-port + output port + serial-number.

[Y(J)S] All that is needed is for the PW labels to be unique in CE1.
[[Sasha]] I do not see this as ever becoming a standard approach.  PW labels
must be understood by the devices that terminate the pWs (in your case -
CE-2 and CE-3).These devices can have their own preferences regarding global
label space etc., and your "structured" labels can easily contradict these
preferences. Not every device is ready to receive and process any value
between 16 and 1M as a valid incoming labels (in fact, most don't). In
addition, you require the labels to be correctly interpreted in two points -
by the CE that terminates them and by the PE that adds transport labels
based on the PW ones. IMO, this is a fundamental contadiction with the MPLS
architecture and hence not acceptable. But let's, at least, present the
complete solution ("structured" non-local labels and all) and discuss it!
The draft did not ever mention "structured" labels (unless I missed
something), and I did not consider an option that clearly contradicts the
basics of the MPLS architecture.

How can this be fixed?

I see three ways to do so.

1. Limit this case to one PW per CE. IMO, this is
   a very problematic limitation (one could say, that
   it is ultimately non-scalable!) and does not
   justify any action wrt the existing documents.

[Y(J)S] Agreed that this is very limited, although a common situation.
[[Sasha]] The problem, as I see it, is that, with your solution, this is a
dead-end situation. The moment your customer requests termination of one
more PW in the same CE, you cannot provide a solution even if the customer
is ready to pay for a more powerful CE!

2. Allow the CE to push both the PW and transport labels
   on top of the payload and PWE3 control info.
   This would make it equivalent to the "normal" PW,and no
   technical changes in the architecture doc are required.
   The transport label can be obtained in many different ways,
   including usage of the MPLS UNI (as suggested by David
   Sinicrope).

[Y(J)S] I don't want to make an MPLS stack here.
[[Sasha]] Franly I do not see it as a problem, but, if it is, let's solve it
in the specific devices that encounter it - this is definitely not a common
problem! 
[[Sasha]] ... snipped ...

 IMO, any technical changes in the architecture document should be
considered
only if we reach a conclusion that advantages of the PW stitching option
outweigh its disadvantages.
  
Hope these notes would be helpful.

[Y(J)S] Very.

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 12 Nov 2003 17:39:14 +0200

Yaakov,
Please see some answers/comments inline.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, November 12, 2003 4:27 AM
To: Sasha Vainshtein
Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG

[Y(J)S] But these are NOT MPLS labels, they are PW labels.
Why should PW labels be required to conform to the full MPLS
constraints?
[[Sasha]] One reason could be that demultiplexing in your data plane is the
common MPLS one. BTW, this is why the PW labels are required to be marked as
"bottom of the stack" while the transport labels are (implicitly) required
not to be marked so. Another reason can be that you can use a well-known
Ethertype (for Ethernet) or PPP protocol type (for PPP) when you carry the
packet with asingle label over the CE-PE attachment circuit.  

[Y(J)S] What do we really need the PW label for? To diifferentiate
between multiple PWs going together in a tunnel between the same two
devices.
For example, several E1s going between two points.
[[Sasha]] IMO you contradict yourself here, because, in fact, your draft
requires that the "PW label" is understood both by the receiving CE and by
the PE adjacent to he transmitting CE. 
A very common solution is to use some coding of the port numbers
of these E1s.
[[Sasha]] I am not sure there is anything common about that, at least not
with MPLS-based PWs.

<snip>

[Y(J)S] Once again, the inner label is not a true MPLS label,
and I don't see the need to force it to be one.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 12 Nov 2003 19:54:33 +0200

Yaakov and all,
I did not address the following statement/question in my previous email:
<quote>

<end quote>
I'll try to do so now.
 
Let's assume for the moment that the inner label is not part of the label
stack (IMO,it cannot be if it is not a true MPLS label!). As a consequence,
the transport label must be marked as the bottom-of-the-stack,and the PE
that is adjacent to the egress CE must know (somehow) how to forward the
packet after it pops the last label.
This brings us to the situation described in Section 2.2 of RFC 3032
"Determining the network layer protocol". Instead of quoting the RFC I will
only say that the egress PE MUST know that the packets carried over the
terminated tunnel are CE-2-CE PW labels. In other words,you cannot reuse the
PE-PE tunnel used by your CE-to-CE PWs to carry anything but PWs. What's
more, in the case when more than one CE is attached to the same egress PE,
you will need multiple tunels between the same pair of PEs (because PEs
cannot rely on the non-MPLS "PW labels" for forwarding decisions.
In short, as far asI can see, your proposal willonly work under the
following restrictions:

1.	No more than one CE is attached to each PE
2.	No more than one PW is terminated at each CE.

I do not think that these limitations are realistic, especially as I do not
see any technical problems with doing same things in the standard way.

-----Original Message-----
From: Sasha Vainshtein 
Sent: Wednesday, November 12, 2003 5:39 PM
To: 'Yaakov Stein'
Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG

Yaakov,

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, November 12, 2003 4:27 AM
To: Sasha Vainshtein
Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG

<snip>

Y(J)S