RE: [PWE3] Proposed change to 5..4.1 of PWE3 architecture

["Yaakov Stein" <yaakov_s at rad.com>]

Sasha,

As conventional, my remarks are in-lined. 

<snip>
> Let's start from a simple point: if PW label over an IP PSN 
> is an MPLS label, what protocol number must be set in the IP 
> header of the corresponding packets?
> 
> I see two options:
> 
> 1) It is MPLS-in-IP protocol number (still to be assigned by IANA).
>    If this is the case, then MPLS-in-IP encapsulation mechanism
>    as described in draft-ietf-mpls-in-ip-or-gre-07 fully applies.
>    Of course in this case the demultiplexor is an MPLS label, and,
>    IMO, this is the only way to use an MPLS label as a demultiplexer
>    for PWs over an IP PSN.
> 
> 2) It is some new, not yet specified protocol (let's call it
>    PW-in-IP). If this is the case, you may use any 32-bit 
>    demultiplexer (a.k.a PW label) you wish but, IMHO, you 
>    MUST NOT call this demultiplexer an MPLS label.
>    (Of course, it would be also nice to specify such a protocol
>    and to provide justification for adding it to the 
>    set of already existing tunneling mechanisms.:-)

This is the same debate we had regarding Ethertypes
in another forum ...

It seems obvious to me that when using UDP/IP the IP protocol type 
is set to obviously 11H, signifying UDP. Then the UDP destination
port MUST be set to an application identifier assigned
by IANA to the PW type being used. As you know,
IANA has assigned 085EH to TDMoIP for this purpose.
We should request port numbers for the various PW types.

If you choose NOT to use UDP, rather L2TP,
then the protocol is set to 73H. 
Similarly, if use use MPLS-in-IP, then you use 
whatever IANA decides.

The question arises - where is the PW label 
for the UDP case? Well, this is the function of the UDP
port, but that has already been taken, so the only sensible
thing to do is to use the UDP source port.

This actually makes a lot of sense, since it 
1) allows standard use of the UDP destination port
   (solving the problem you raised)
2) doesn't require an additional field (there is already a 
   16 bit field sitting there...)
3) according to our standard use the PW label is a 
   downstream (source) identifier.


> In particular, does the use of this format for the PW label 
> mean that one MUST support label stacking?
> > (I don't see how you can rule that out in an MPLS network.)
> >
> Of course, I may be totally wrong, but, IMHO, you are asking 
> the following question:
> 
> 	Is it possible to terminate MPLS-in-IP PWs in PEs that
> 	do not support MPLS?

Why such a complex way of reading an easy question.
You stated (and have defended this view in the past)
that by using an MPLS-like label, we are effectively creating
an MPLS network. In that case, the network has to act like an MPLS
network.
 
> The answer depends on what you are going to do with such a device:
> - you clearly cannot use it in MPLS networks
> - you can, IMO, easily use it in IP networks for termination of
MPLS-in-IP PWs.

... or could you terminate the IP layer and launch the MPLS packets
into an MPLS network ?

> > 
> > Does it rule out non-LDP control protocols for PW setup?
> >
> IMO, no. You can always use manual PW setup. 

Yes, of course. But I was asking whether alternative
control PROTOCOLS are ruled out. 

Although UDP/IP has been with us in PWE from the beginning,
we have tacitly assumed MPLS in almost everything we have done.
In particular, the control protocol is LDP based.

Of course, there is nothing wrong with using targetted LDP
in a pure IP network for this purpose. But perhaps we may want
to do something else (I intend writing a draft before the next
meeting on this subject).

Y(J)S


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3