Subject: RE: Arch sections 5.4.3 and 5.4.4

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 10:57:30 +0300

Andy, 

Yes, I know that RTP has been that way all along,
and as you have probably noticed, I have been going along with it. 

In all the anavi drafts I have also put the RTP 
between the PSN layers and the control word.
I guess I should claim temporary insanity,
but the real reason is that I never saw RTP to be needed,
and thus never really thought too much about it.

However, I was awakened by the thought of having
this anomaly sanctioned in a document called
the PWE ARCHITECTURE draft.

>From a purely architectural point of view the order is clearly wrong.

Let me explain, using the OSI layering model
(in G.805 layer network terms it is even worse, 
but I think that the OSI terminology is more 
familiar to most of readers of this list).

* Each layer performs a service for the layer directly above it.

* Working inwards on a packet we reach higher layers.
After we have finished processing the layer's header
(i.e. that layer's service has been performed),
we strip the header and proceed to process the next higher layer.

* A layer should carry its protocol identifier, protocol version number,
and whatever other information is needed to process the control
information of that layer. 

Now starting from the bottom, we have MPLS or IP
which are identifiable and carry in their headers
all the information they need for their functionality
(addresses, service classes, TTLs, etc).

Next we look at the IP type or MPLS PID
and discover that we have a PW
(yes, I know that we haven't yet defined a IP-type
for PW, and MPLS PIDs are not yet defined,
but I am talking about what we want to have).

At this point the IP or MPLS header has been stripped
since the PSN layer has performed its service,
and we should process the PW information
(as admirably described in the architecture doc)
based on the contents of the PWE CW.
This service having been performed,
the PW-type should now tell us what
encap we have, and the CW should be stripped.

In particular, the CW may indicate that RTP is being used,
and after the CW is stripped this could be processed.
Of course, the RTP-type would refer to whatever
payload is above it.

Now, we COULD perform a short-cut,
whereby we decide that there is no such thing as 
a purely generic PW, rather there are atm-PWs,
ethernet-PWs, fr-PWs, sonet-PWs, and TDM-PWs.
In that case we need to define 5 MPLS-PIDs or IP-types;
but we would still put the CW next 
(although we could now allow different CW formats).

If instead, we decide to have the IP-type or MPLS PID
refer to RTP, and have the RTP-type equal PW,
then we have completely divorced those PWs using RTP
from the mainstream of PWE. In particular,
those PWs for which RTP is optional
now have two completely separate instantiations.

BOTTOM LINE

By placing the RTP info first, we are implying
that it is a lower layer which services the PW,
rather than being a higher layer option.
Since RTP comes first, it will perform its sequencing,
timing and whatever functions, before we even know
we are talking about a PW. 
The PW has lost control over this functionality.

By placing the RTP after the PSN layers,
the processing of those PWs which use it 
becomes divorced from that of all other PW types.
We thus need to start talking about two types
of entities, PWs, and RTP-PWs,
with completely different network processing.
The previous point shows that sequencing and
timing are performed at different layers, 
we now see that all super-PSN layer processing is different.

Do we really want to add this complexity for
RTP which is only used by two drafts,
and even there optional?

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 1 May 2003 11:14:11 +0200

Yaakov and all,
As promised, I have read this mail also.
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, May 01, 2003 9:58 AM
> To: Andrew G. Malis; Sasha Vainshtein
> Cc: [email-masked]; Ron Cohen; Tim Frost (E-mail); [email-masked]
> Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4
> 
> 
> Andy, 
> 
... snipped...
> From a purely architectural point of view the order is clearly wrong.
... snipped ...
> information of that layer. 
AFAIK, MPLS does not have version numbers and protocol identifiers
in its data plane. Nor does it carry any global addresses.
> but I am talking about what we want to have).
No, we most definitely do NOT want it.
MPLS PID is a NOT processed by the PEs terminating
the PW, and we do NOT define a new Protocol Type for
PWs in IP. And, in any case, the MPLS PID is below the VC label
which uniquely defines the egress PW IWF instance, so  all
your fine theory is broken completely at this point.
> At this point the IP or MPLS header has been stripped
Once more: an MPLS label stack includes both the PSN
and the PW demultiplexing function (the latter is implemented
via the VC label). 
> encap we have, and the CW should be stripped.
You may have missed the fact that all the PE encapsulations 
do not carry any service type indicators in their data plane. And
the architecture documnet is well-alighed with this fact.
Draft-anavi is the only exception to that rule, but then it 
violates other PWE3 architectural principles as well.
... snipped ...
> a purely generic PW,
Indeed, there is no such thing - definitely not in
the architecture draft. And I think it is the correct approach.
Instead, the architecture drfat refers to generic functions and
generic payload types.
IMO, your "explanation" demonstrates that your private 
"PWE3 architecture" does not have much in common with 
the WG-adopted one.  
... snipped to the end ...

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 13:24:35 +0300

> in its data plane. Nor does it carry any global addresses.

The addresses are only global in connectionless networks,
they are local in CO networks.

The use of protocol identifiers and version numbers
are part of the OSI layer model (see X.200).
I am aware that MPLS is not YET using an identifier.

> your fine theory is broken completely at this point.

The present term is PW label (or interworking label in ITU-speak).
This label is used to enable the use of multiple PWs
in a tunnel, and so is in the correct place.

> and the PW demultiplexing function (the latter is implemented

The outer/tunnel/transport labels are stripped when the
PSN service is completed, leaving the inner/PW/interworking label.

> the architecture documnet is well-alighed with this fact.

I have complained about this omission in the past.

> violates other PWE3 architectural principles as well.

1) I am not aware of any PWE document where ii is
stated that the use of an indicator is an architecture violation.
2) What other "violations" ?

> "PWE3 architecture" does not have much in common with 

The IETF is not always a stickler for pure architectural principles,
and our WG is no exception.

However, I have never heard it stated that good architectural
design is not allowed in the IETF.

Our WG has already designed another new layer
(in addition to the already added "layer 2.5" of the MPLS)
and we have to realize that this layer needs to properly
placed and interfaced with the other layers.

My "private architecture" is simply an attempt
to add some coherence to the new layers
we are adding.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 1 May 2003 14:27:35 +0200

Yaakov and all,
Please see some responses inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, May 01, 2003 12:25 PM
> To: Sasha Vainshtein
AFAIK, nobody is going to retrofit the Internet and to use it for IP
traffic. 
AND nobody is going to use it with PWs that utilize the generic PWE3 CW.
AND there is no protocol version in the MPLS stack either.
I suggest to take further discussioin of the differences between the
OSI layering model and IP or MPLS off this list (if you are interested).
> in a tunnel, and so is in the correct place.
I do not know what exactly the "interworking label" means, and 
hence I do not want to discuss whether this term is appropriate.
However, the archutecture draft defines that the PW (a.k.a. VC)
label is the MPLS-specific PW demultiplexer, i.e. the data plane
method of of IDENTIFYING the PW by the terminating PE. 
And if you take a look at the current proposals for distributing
this label (in ietf-pwe3-control-protocol-02.txt) you will find out that
it is bound to a FEC that includes the type of the emulated service.
(BTW, the same holds for L2TPv3) and is allocated from the
global device label pool.
... snipped ...
> I have complained about this omission in the past.
Correct. However, IMO, your complaint has been either ignored or rejected
by the WG.
... snipped ...
> and our WG is no exception.
Please take a look at RFC 1925,  especially at item 2 (1).
 IMO, this is a great architectural principle consistently pursued 
by the IETF, and this WG is no exception.  
I also recommend for your attention item 2 (10) as highlly relevant
for this discussion.

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 May 2003 17:11:48 +0300

> AFAIK, nobody is going to retrofit the Internet and to use it for IP traffic. 

I'm not quite sure I understand this statement.

> AND nobody is going to use it with PWs that utilize the 

Why not?  As a matter of fact a lot of people are just waiting
to try this stuff our on IP networks.  And it they aren't
why is the IETF working on this?

> OSI layering model and IP or MPLS off this list (if you are interested).

Sorry if I have offended anyone by talking about architectural design.

> I do not know what exactly the "interworking label" means,

See, e.g. ITU-T recommendation Y.1411

> and hence I do not want to discuss whether this term is appropriate.

VC label was the old (ATM-speak) label.
Luca has promised to erradicate it from all the drafts
over which he has control; I suggest the rest of us do as well.

> this label (in ietf-pwe3-control-protocol-02.txt) you will 
> find out that it is bound to a FEC that includes the type of the emulated service.

Precisely my point.
The fact that this is the ONLY place where the encap type is
mentioned is problematic (see my previous email about the problems
with making a "PWE chip").

Of course the encap type needs to be mentioned during set-up,
making it available to the forwardin layer,
since the LSP may need to be tailored for the service requirements.
However, it should also be available to the PW layer, 
both for architectural and practical reasons.
However, as you will recall, I was willing to compromise
on this in the past, for example, allowing the set-up to dictate
the major type (atm, fr, tdm, etc) and the FORMID
determine the minor type (1:1vs N:1, AAL1 vs AAL2, etc).

> global device label pool.

Good point. Where do you suggest putting the RTP for the L2TP case?

> Correct. However, IMO, your complaint has been either ignored 

sigh.

> or rejected by the WG.

I haven't heard rejection,
so I guess the former is the case.
But then again, my whole CW crusade was ignored for a year, 
but then came to life. So I haven't lost hope.

> I also recommend for your attention item 2 (10) as highlly relevant

I re-read this RFC precisely one month ago (on April fools day),
and think that the more relevant principle is 2(6)

    It is easier to move a problem around (for example, by moving
    the problem to a different part of the overall network architecture) 
    than it is to solve it.

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Thu, 1 May 2003 07:23:28 -0700

I tend to agree with Yaakov. Since the multiplexing layer (aka PW label) carries the context information for the PW payload (i.e, CW+ TDM payload) such as type of PW traffic T1, SONET, etc, it seems that in Ron's suggested layering (RTP preceding CW), a client layer (ie. multiplexing layer) is controlling 2 layers below it (ie, the TDM PW). While usually a client layer should control only its immediate server layer, which in this case would be RTP. While, if the RTP is placed after the CW, then the PW label would correctly control its payload which is the TDM PW.

So what are the implications: 

By placing RTP before the CW, in effect we are decoupling the PW from the service that it carries. In other words now all services (like SONET, T1, E1, T3, E3, etc) that use RTP could be effectively transported across the same PW. Because RTP would be doing the job of the service multiplexing not PW label. This is clearly not in line with Arch draft that says:

"  From the perspective of a Customer Edge Equipment (CE), the PW is
   characterized as an unshared link or circuit of the chosen service"

The above discussion was architectural issues. There is also implementation complexity
associated with placing RTP before CW. By doing so, a PE would need to parse and process each PW
packet differently. In other words for some PW packets the MPLS engine needs to forward the
packet to PW engine and for some other PW types the MPLS engine needs to forward the packet
to RTP engine and then from RTP engine to PW engine:

         RTP               > RTP
         ^ v              /   |
         | |             /    v
MPLS --> PW      or  MPLS --> CW

This has 2 problems:

1) The parser now needs to be dynamic in order to find the CW.
1) In the latter case a kind of internal switching (to RTP or CW) needs
to be required which would require context lookup.

So my vote is to have RTP after the CW and have a consistent PW format and architecture
for all PW types.

-Shahram

>Sent: Thursday, May 01, 2003 3:58 AM
>To: Andrew G. Malis; Alexander Vainshtein
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Akiva Sadovski <[email-masked]>
Date: Thu, 1 May 2003 17:42:31 +0200

Yaakov and Sasha,
  short question inline...

thanks,
   Akiva

> From: Sasha Vainshtein 
> Sent: Thursday, May 01, 2003 2:28 PM
> To: 'Yaakov Stein'
> find out that

     Does  a PHP system "see" (and process) VC label ?

> or rejected

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 1 May 2003 19:32:27 +0200

Yaakov and all,
A few comments inlune.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, May 01, 2003 4:12 PM
> To: Sasha Vainshtein
In this particular case it means that nobody will change thousands of
deployed LSRs
that carry IP traffic without any MPLS PID even if this is required by
X.200.  
> why is the IETF working on this?
FYI, people are already running PWs over IP and MPLS networks,
including MPLS networks that implement ECMP. And they do it
without using MPLS PID. 
... skipped ...
> with making a "PWE chip").
Somehow no vendor that has implemented multiple PW types 
has noticed these problems. These icnlude Cisco, Juniper, Laurel, Vivace
etc.
So I think this discussion becomes too theoretic for my taste.
> since the LSP may need to be tailored for the service requirements.
Please read draft-ietf-pwe3-contol-protocol-02.txt. 
> determine the minor type (1:1vs N:1, AAL1 vs AAL2, etc).
A PW connects to PW end services of the same type.
AFAIK, there is no major and minor types in the PWE3 architecture.
Presumably because no one needs them. 
> Good point. Where do you suggest putting the RTP for the L2TP case?
Immediately after the L2TP (v3) header.
... snipped ...
>     the problem to a different part of the overall network 
I suggest we hold a side discussion on comparative importance and
relevance of principles from RFC 1925 off the list.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 01 May 2003 18:57:01 +0100

>      Does  a PHP system "see" (and process) VC label ?

Yes, it may see it as the top (only) label.

Stewart

---

From: [email-masked]
Date: Fri, 2 May 2003 15:06:32 +0100

Sasha Vainshtein wrote 01 May 2003 18:32
<snipped>
> including MPLS networks that implement ECMP. And they do it
NH=> Can you be precise as to which MPLS network type you mean here please?
There are several disjoint types of MPLS network, characterised by the fact
they don't have consistent (or even conciously recognised) addressed
data-plane access points.  Being more obvious however, you don't really need
ECMP with p2p RSVP-TE LSPs.  However, a key observation here is that
load-spreading only makes sense *within* a single layer network.....not
across them.  Think client/server IP to Optics and also in different
commercial ownership cases (ie where the client and server layers belong to
different organisations) if this helps understand this as a general arch
principle, ie load-spreading should be restricted to a single layer network.

regards, Neil