Subject: [PWE3] PW type identification

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 21 Apr 2008 10:57:13 +0300

Hi all, 
 
A few years ago there we had a discussion on the identification of the
PW type
in the data packets. You may recall that my original control word had a
"format ID",
which I removed in order to conform with Luca's CW.  We made a conscious
decision
NOT to identify the PW payload type (in order to speed processing and in
order not to have
to flag errors) knowing that we were somewhat breaking the standard
model of the IP suite.
 
Recently I have seen many people using standard sniffing tools, such as
Ethereal,
to disect packet streams that include PWE packets. I wrote some scripts
to support
PW packets and then discovered that the newest version of Wireshark
actually has some PWE support. In particular, it recognizes the VCCV CW,
and can parse the stack for Ethernet PWs with no CW.
 
However, of course, such scripts can not be fully general. I was quite
confused
with the output of the Wireshark scripts, until I noticed that it was
misinterpreting
ATM PWs as Ethernet ones. 
 
I ended up writing some more complex routines, but even they have to
make assumptions.
 
I would really like to be able to have a sniffer work properly. Stewart
proposed
having a VCCV message that associates the PW type with the PW label.
I guess we really need to know whether there is a CW too. 
So perhaps we could periodically send the setup data in a VCCV message.
 
Any thoughts ?
 
Y(J)S

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 21 Apr 2008 21:58:56 +0300

Yaakov and all,
I believe that this would happen if when you send LPS-Ping requests in VCCV. The body of the LSP-Ping message would include the PW FEC which, in its turn, includes the PW type. IP Header checksum and the UDP packet checksum would provide some measure of protection against mis-interpreting Ethernet PW packets without the CW.

The main problem with this approach is, of course, that if you do not run LSP-PIng in VCCV, you will not see anything...

Did I miss something?

Regards,
             Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Monday, April 21, 2008 10:57 AM
To: [email-masked]
Subject: [PWE3] PW type identification

Hi all,

A few years ago there we had a discussion on the identification of the PW type
in the data packets. You may recall that my original control word had a "format ID",
which I removed in order to conform with Luca's CW.  We made a conscious decision
NOT to identify the PW payload type (in order to speed processing and in order not to have
to flag errors) knowing that we were somewhat breaking the standard model of the IP suite.

Recently I have seen many people using standard sniffing tools, such as Ethereal,
to disect packet streams that include PWE packets. I wrote some scripts to support
PW packets and then discovered that the newest version of Wireshark
actually has some PWE support. In particular, it recognizes the VCCV CW,
and can parse the stack for Ethernet PWs with no CW.

However, of course, such scripts can not be fully general. I was quite confused
with the output of the Wireshark scripts, until I noticed that it was misinterpreting
ATM PWs as Ethernet ones.

I ended up writing some more complex routines, but even they have to make assumptions.

I would really like to be able to have a sniffer work properly. Stewart proposed
having a VCCV message that associates the PW type with the PW label.
I guess we really need to know whether there is a CW too.
So perhaps we could periodically send the setup data in a VCCV message.

Any thoughts ?

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 21 Apr 2008 22:34:32 +0300

Sasha
 
Well, that is one way of doing it, and not too far from what I was
proposing.
 
However, if we send the entire FEC message then the script would have to
interpret TLVs,
which is a bit awkward.
 
And since I use BFD and do not implement LSP-ping, I would prefer not
using that format.
 
So I was proposing a new VCCV type, which would be optionally sent at
some interval,
and would only indicate whether the CW is used, and the PW type.
To that we could add the full PW FEC structure if someone needs more
info
(e.g. for the TDM case to know the number of timeslots, etc.).
 
Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 21, 2008 9:59 PM
To: Yaakov Stein
Cc: [email-masked]
Subject: RE: PW type identification

Yaakov and all,
I believe that this would happen if when you send LPS-Ping requests in
VCCV. The body of the LSP-Ping message would include the PW FEC which,
in its turn, includes the PW type. IP Header checksum and the UDP packet
checksum would provide some measure of protection against
mis-interpreting Ethernet PW packets without the CW.
 
The main problem with this approach is, of course, that if you do not
run LSP-PIng in VCCV, you will not see anything...
 
Did I miss something?
 
Regards,
             Sasha

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Yaakov Stein
	Sent: Monday, April 21, 2008 10:57 AM
	To: [email-masked]
	Subject: [PWE3] PW type identification

	Hi all, 
	 
	A few years ago there we had a discussion on the identification
of the PW type
	in the data packets. You may recall that my original control
word had a "format ID",
	which I removed in order to conform with Luca's CW.  We made a
conscious decision
	NOT to identify the PW payload type (in order to speed
processing and in order not to have
	to flag errors) knowing that we were somewhat breaking the
standard model of the IP suite.
	 
	Recently I have seen many people using standard sniffing tools,
such as Ethereal,
	to disect packet streams that include PWE packets. I wrote some
scripts to support
	PW packets and then discovered that the newest version of
Wireshark
	actually has some PWE support. In particular, it recognizes the
VCCV CW,
	and can parse the stack for Ethernet PWs with no CW.
	 
	However, of course, such scripts can not be fully general. I was
quite confused
	with the output of the Wireshark scripts, until I noticed that
it was misinterpreting
	ATM PWs as Ethernet ones. 
	 
	I ended up writing some more complex routines, but even they
have to make assumptions.
	 
	I would really like to be able to have a sniffer work properly.
Stewart proposed
	having a VCCV message that associates the PW type with the PW
label.
	I guess we really need to know whether there is a CW too. 
	So perhaps we could periodically send the setup data in a VCCV
message.
	 
	Any thoughts ?
	 
	Y(J)S

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 21 Apr 2008 15:41:28 -0400

I was going to suggest snooping the LDP setup for the PW, but that also uses TLVs, and you may not have been snooping at the time that the PW was set up.  That also wouldn't be useful on staticly configured PWs.

But it does seem silly to create something new when VCCV-ping already exists, and why would this be more likely to be implemented than VCCV-ping?

Cheers,
Andy

At 4/21/2008 10:34 PM +0300, Yaakov Stein wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>        boundary="----_=_NextPart_001_01C8A3E6.C37A9B19"
>
>Sasha
> 
>Well, that is one way of doing it, and not too far from what I was proposing.
> 
>However, if we send the entire FEC message then the script would have to interpret TLVs,
>which is a bit awkward.
> 
>And since I use BFD and do not implement LSP-ping, I would prefer not using that format.
> 
>So I was proposing a new VCCV type, which would be optionally sent at some interval,
>To that we could add the full PW FEC structure if someone needs more info
>----------
>----------

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 21 Apr 2008 15:45:41 -0400

Well, maybe I should have said "redundant" rather than "silly" ..... :-)

Cheers,
Andy

At 4/21/2008 03:41 PM -0400, Andrew G. Malis wrote:
>>From: Alexander Vainshtein [ mailto:[email-masked]] 
>>From: [email-masked] [ mailto:[email-masked]] On Behalf Of Yaakov Stein

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 21 Apr 2008 21:07:05 +0100

What I had in mind was simply an ACH type on which you announced a bunch 
of information about the PW an its parameters.

The binding to the PW would be automatic.

Stewart

Yaakov Stein wrote:
> ------------------------------------------------------------------------
> *From:* Alexander Vainshtein [mailto:[email-masked]]
> *Sent:* Monday, April 21, 2008 9:59 PM
> *To:* Yaakov Stein
> *Cc:* [email-masked]
> *Subject:* RE: PW type identification
>
> Yaakov and all,
> in its turn, includes the PW type. IP Header checksum and the UDP 
> packet checksum would provide some measure of protection against 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Yaakov Stein
>     *Sent:* Monday, April 21, 2008 10:57 AM
>     *To:* [email-masked]
>     *Subject:* [PWE3] PW type identification
>
>     Hi all,
>      
> ------------------------------------------------------------------------
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 22 Apr 2008 13:42:03 +0300

Yaakov,
IMHO Occam's razor, a.k.a. lex parsimoniae (entia non sunt multiplicanda praeter necessitatem) fully applies to the ACH/VCCV types. Unless I am mistaken, this is effectively what Andy says, too.
And since the TLV format is extremely popular, I think that modern sniffers can do it anyway for a lot of protocols...

My 2c,
             Sasha

________________________________
From: Yaakov Stein [[email-masked]]
Sent: Monday, April 21, 2008 10:34 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: PW type identification

Sasha

Y(J)S

Yaakov and all,

Did I miss something?

Regards,
             Sasha

Hi all,

Any thoughts ?

Y(J)S

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 22 Apr 2008 06:49:51 -0400

Sasha,

Yes, that's what I was saying, just not in Latin!

Cheers,
Andy

At 4/22/2008 01:42 PM +0300, Alexander Vainshtein wrote:
>Content-Language: en-US
>        boundary="_000_A3C5DF08D38B6049839A6F553B331C766B14257270ILPTMAIL02eci_"
>
>Yaakov,

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 23 Apr 2008 17:34:00 +0300

Andy and Sasha
 
1) I agree that the LDP itself may SOMETIMES be intercepted, if you are
really lucky and see it.
 
   However, some PWs are static, and thus still have a PW type, but
there was no LDP.
   Second, the LDP may not go through the device being monitored.
   Third, the LDP is so infrequent that the chance of seeing it in a
capture file is effectively zero.
 
2) I did not say that I would rule out the use of TLVs.
   However, I would like to see one of you write an Ethereal script that
parses them.
   Basically the scripting language makes it is very easy to field out
parameters at given bit offsets and lengths,
   but I don't know of any easy way to follow the logic of a TLV, let
alone nested TLVs.
 
Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2008 1:42 PM
To: Yaakov Stein
Cc: [email-masked]
Subject: RE: PW type identification

Yaakov,
IMHO Occam's razor, a.k.a. lex parsimoniae (entia non sunt multiplicanda
praeter necessitatem) fully applies to the ACH/VCCV types. Unless I am
mistaken, this is effectively what Andy says, too. 
And since the TLV format is extremely popular, I think that modern
sniffers can do it anyway for a lot of protocols...
 
My 2c,
             Sasha

Sasha

 

Y(J)S

Yaakov and all,

Did I miss something?
 
Regards,
             Sasha

	Hi all, 

	 

	 
	Any thoughts ?
	 
	Y(J)S

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 24 Apr 2008 11:39:03 -0400

Hi Yaakov,

> and can parse the stack for Ethernet PWs with no CW.

The current (incomplete and heuristic) logic in wireshark is based on 
the first nibble after the MPLS Label Stack, treating the payload as 
IPv4 (if "4"), IPv6 (if "6"), PW-ACH (if "1") and Ethernet without FCS 
the rest of the cases. Aamer Akhter added most of this logic and I 
submitted the PW-ACH support.

> So perhaps we could periodically send the setup data in a VCCV message.

Like Sasha and mentioned this can be inferred from LSP-Ping, or like 
Stewart proposed it could be inferred from a new PW-ACH value; but I 
think that the major challenge for network protocol analyzers is to 
identify the PW "conversations" based on the complete (and potentially 
variable in LSEs) Label Stack, and identify the other direction of the 
same conversation, to then apply the type to the payload. And that would 
be on one direction, unless sourcing LSP-Ping from both endpoints. 
Another alternative (which I submitted to ethereal at the time for 
L2TPv3 PWs) is adding a Preference dialog option for decoding the PW 
Payload as different protocols, and option for CW (for L2TPv3, I also 
included presence/size of the Cookie and L2SS). This is hacky in the 
sense that it would apply the decoding rule to all the PWs in the 
capture (and different PWs can carry different protocols), but is 
pragmatic (I typically am interested in a single payload in a given 
capture at the time).

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 25 Apr 2008 17:35:19 +0300

Carlos and all,
Please see inline below.

My 2c,
            Sasha

> -----Original Message-----
> Behalf Of Carlos Pignataro
> Sent: Thursday, April 24, 2008 6:39 PM
> To: Yaakov Stein
> Cc: [email-masked]
> Subject: Re: [PWE3] PW type identification
>
> Hi Yaakov,
>
[Sasha] IMHO the heuristics can be improved when PW-ACH carries IPv4, e.g., by checking
the IPv4 header checksum.
>
> >
> > However, of course, such scripts can not be fully general.
> I was quite confused with the output of the Wireshark scripts, until I noticed
> that it was misinterpreting ATM PWs as Ethernet ones.
[Sasha] Could it be because '0' in the first nibble is not interpreted as the beginning
of the PW CW?
> same conversation, to then apply the type to the payload. And
> that would be on one direction, unless sourcing LSP-Ping from both endpoints.

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 27 Apr 2008 09:18:43 +0300

Carlos

Thanks for your response.

> The current (incomplete and heuristic) logic in wireshark is based on
the first nibble after the MPLS Label Stack, 
> treating the payload as IPv4 (if "4"), IPv6 (if "6"), PW-ACH (if "1")
and Ethernet without FCS the rest of the cases. 
> Aamer Akhter added most of this logic and I submitted the PW-ACH
support.

OK, that is what I had concluded from using it.
Note - Ethernet is also without CW.

The way I found out about this new version is when technicians contacted
me
when they updated their filters, and could no longer understand what was
happening.
Wireshark now states definitively that the contents of the PW is
Ethernet,
and goes on to tell you spurious MAC addresses, etc.
This is disconcerting to the technicians, and it took me a long time to
convince
them that it is simply wrong. They are not use to Ethereal "guessing"
and are sure that if it declares that something is an Ethernet PW,
then it must be.

I assume that the choices were made for a VPLS-type application,
while in my case we are looking at a cellular backhaul network
with Ethernet, ATM (AAL2 and AAL5), and TDM PWs.

> Like Sasha and mentioned this can be inferred from LSP-Ping, 

Unfortunately, we use VCCV-BFD

> or like  Stewart proposed it could be inferred from a new PW-ACH
value; 

The purpose of my email was to gauge the interest level of people in
standardizing something along these lines.

> but I think that the major challenge for network protocol analyzers is
to 

> be on one direction, unless sourcing LSP-Ping from both endpoints. 

I agree that this is a real challenge. Why do you need this ?

> pragmatic (I typically am interested in a single payload in a given 

That tactic is OK for me personally on a few select capture files sent
back to me.
However, I don't see technicians in the field having the time or
competence 
to do this kind of manual work all the time,
nor could it be mechanised to automatically catch unusual phenomena.

I find it troubling that I have always managed in the past to figure out
a way to deduce
the format from several packets, even for such non-self-describing
protocols
as ATM AAL (where AAL1, AAL2, AAL5 all have various checks that can be
identified). Only for PWE does the possibility of automatically infering
the packet format break down. This leaves us with no sanity checks,
makes it harder to track down strange phenomena that break various
mechanisms in the network, and precludes strong bandwidth optimization
techniques.

Y(J)S

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 28 Apr 2008 11:26:26 +0100

Yaakov, Carlos

Thinking about the things that are coming down the line from the 
transport space I can see a lot a benefit in occasionally sending a 
bunch or end point data down the OAM channel, complete with the 
corresponding binding and even data from the other end. Of course there 
may well be a bunch of security issues, and this is one case where there 
is a conflict that is not easily resolved between security by obscurity 
and providing public debug info.

I see a couple of questions:

1) Do we think this information is useful?

2) If we provide the necessary information can the debug tools do the 
decode the packets, or do they still require manual intervention?

3) Is it worth adding this as a option to the PW?

In the transport case the PW paths will be congruent, so we can get both 
directions. This will also be possible in certain key parts of an LDP 
network, the fact that we cannot do it everywhere is just a 
characteristic of general IP networking.

So is there interest in this? If so I think we need to ask Yaakov and 
Carlos to put together a draft outlining the various approaches.

Stewart

---

From: <[email-masked]>
Date: Mon, 28 Apr 2008 12:04:38 +0100

Thanks Stewart,

I have a couple of observations on this.....please see in-line:

Stewart Bryant wrote 28 April 2008 11:26....
 
> 1) Do we think this information is useful?
NH=> I'm not sure.  A key issue with networks (any mode/technology) is
to have consistent characteristic information (CI) in the DP traffic
units and OAM.  We don't have this in MPLS (fundamentally because MPLS
treats (i) IP, (ii) MPLS (ie nested LSPs) and (iii) all-else
differently).  So the traffic units and OAM don't have consistent
CI...which is OK until misconnectivity defects arise.  And of course PWs
are now fairly well recognised as creating a new layer network above
MPLS per se, ie this has its own DP and set of functional components,
including OAM.  However, although this is all now water under the
bridge, it does beg the question (at least in my mind) of whether it is
worth now worrying about this just for the PW case when we are ignoring
the underlying MPLS case?
> decode the packets, or do they still require manual intervention?
NH=> If the traffic units and OAM have consistent CI then one can at
least be sure of correctly parsing/understanding their content even when
delivered to the wrong location.  But what happens if a 'PW created LSP'
gets misconnected/mismerged with a 'LDP LSP' (or 'RSVP-TE created LSP'
or 'BGP4 created LSP')?
> 3) Is it worth adding this as a option to the PW?
NH=> Has this factored-in any further PW load-spreading possibilities,
ie the fat-PW stuff?
> directions.
NH=> Not sure I'm properly understanding what you mean here.  Did you
mean bidirectionally congruent?  We can have p2p and p2mp connections in
a co-ps or co-cs mode layer network....mp2p constructs are not
connections of course (and this is all rather important for many issues,
but esp deterministic resource management and simple OAM).   A p2p
connection is clearly bidirectionally congruent but a p2mp connection is
not.

> This will also be possible in certain key parts of an LDP 
NH=> Agreed, but IP is different as it is a cl-ps mode layer network and
does not have connections per se, ie connections once created should
have known resource demands and must not be subject to any ad hoc
movement under subsequent routing changes that do not affect the current
connection routing, eg add nodes/links.
> Carlos to put together a draft outlining the various approaches.
NH=> If this is pursued could I ask that the above observations are
taken into account please (at least as far as is now possible anyway)?
Thanks.

regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 28 Apr 2008 12:40:24 +0100

> the underlying MPLS case?
I am not sure how closely you have been following the MPLS-TP work, but 
anything we can carry under an ACH for PW, we can carry over an ACH via 
the LFU (label 13 mechanism for MPLS).

> gets misconnected/mismerged with a 'LDP LSP' (or 'RSVP-TE created LSP'
My question was about the tools suite and how it worked.

However given a mismerge you should be able to figure out that something 
was wrong even if you cannot decode the packets.
> NH=> Has this factored-in any further PW load-spreading possibilities,
No - how we do comprehensive OAM for fat-pw is definately WIP. However 
many PWs, including high bandwidth PWs will be conventional skinny PWs.

> connection is clearly bidirectionally congruent but a p2mp connection is
I was thinking bidirectionally congruent unicast.

Note that a p2p may not be congruent. If you set it up statically it may 
be - it's up to the operator. If you set it up via RSVP it will be. If 
you set it up via LDP where it inherits the path from the IGP, you have 
no reason to expect congruence, although frequently you get it.

> taken into account please (at least as far as is now possible anyway)?

Yes

Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 28 Apr 2008 20:06:45 +0300

Neil, 

units
> and OAM.  We don't have this in MPLS (fundamentally because MPLS
differently).  

The inconsistency between the three MPLS clients is less important here
(although perhaps inelegant - but elegance is a matter of taste).
The problem is the lack of a way to differentiate between different
clients of your type (iii).

ATM was perhaps more consistent, but still suffered from the lack of a
client PID.
However, I can kludge around that as ATM has idiosyncratic HEC fields
that help me identify the types.
MPLS lacks any identification mechanisms.

> So the traffic units and OAM don't have consistent CI...which is OK
until misconnectivity defects arise.  
> And of course PWs are now fairly well recognised as creating a new
layer network above MPLS per se, 

I assume that you have seen Y.1418 - Pseudowire Layer Networks

> ie this has its own DP and set of functional components, including
OAM.  
> However, although this is all now water under the bridge, it does beg
the question (at least in my mind) 
> of whether it is worth now worrying about this just for the PW case
when we are ignoring the underlying MPLS case?

Once again, I have a practical problem of identifying the client format.
For (i) MPLS, there is no problem - MPLS is MPLS.
For (ii) IP there are two possibilities, but the first nibble serves as
a PID.
For (iii) there are multiple possibilities (5 modes of ATM, 3 modes of
TDM, 2 modes of Ethernet, ...)
and some modes can either use or not use the control word. This needs
addressing.

> NH=> If the traffic units and OAM have consistent CI then one can at
least be sure of correctly parsing/understanding their content 
> even when delivered to the wrong location. 

Unfortunately, this is not the case. If an Ethernet PW is misconnected
to a SAToP PW
then you get rubbish, and don't know why.

>  But what happens if a 'PW created LSP' gets misconnected/mismerged
with a 'LDP LSP' 
> (or 'RSVP-TE created LSP' or 'BGP4 created LSP')?

I am trying to parse that. I think you are asking what happens if a PW
gets misconnected
to a MPLS tunnel carrying IP. If we use the CW, this should be
immediately identifiable.

Next, you are asking what happens if an MPLS tunnel set up using LDP is
misconnected
to one set up using BGP or RSVP.  Why is this any different from
misconnecting MPLS tunnels
set up using the same label distribution protocol ?

ie the fat-PW stuff?

Indeed, that will make everything even worse.

Y(J)S

---

From: <[email-masked]>
Date: Mon, 28 Apr 2008 18:55:46 +0100

Thanks Yaakov,  I have a few further remarks....

Yaakov Stein wrote 28 April 2008 18:07

> to have consistent characteristic information (CI) in the DP 
> traffic units
> The inconsistency between the three MPLS clients is less 
> important here (although perhaps inelegant - but elegance is 
> a matter of taste). The problem is the lack of a way to 
> differentiate between different clients of your type (iii).
NH=> Always remember...PWs are an artifical product of the above....if
we deprecate this behaviour (which also means deprecating LDP/PHP/ECMP)
and take the CP/MP OOB (eg GMPLS) then the need for PWs completely goes
away.  Bit late now of course, but it is an interesting observation
nevertheless IMO.  Technology historians might find it useful anyway ;-)

> 
> ATM was perhaps more consistent, but still suffered from the 
> lack of a client PID.
NH=> True, but proper connections only strictly require a PID if muxing
multiple clients into the same server connection.  A PID field is
essential in a cl-ps network traffic unit of course because we don't
have connections.

> However, I can kludge around that as 
> ATM has idiosyncratic HEC fields that help me identify the 
> types. MPLS lacks any identification mechanisms.
NH=> Well, it sort of goes like this AFAI understand it:

The 1st PID decision comes from the S bit:
-> If S=0 then client is MPLS, ie another MPLS header follows (done)
-> If S=1 then client is not MPLS but something else......
 
If S=1 then the 2nd PID decision comes from the first 4 bits of the
payload:
-> If 0100 the client is IPv4 (done)
-> If 0110 the client is IPv6 (done)
-> If 0000 the client is PW traffic of unknown type......so....
-> If 0001 and 'channel type' (last 16 bits of 1st 32 bits of payload)
is XXXX the client is PW OAM (XXXX indicates type of OAM) (partially
done)
-> If 0001 and 'channel type' (last 16 bits of 1st 32 bits of payload)
is YYYY the client is a PW of specific type (ie ATM, FR, Ethernet, etc)
as defined by YYYY but in traffic units where the 1st nibble is 0000.

Elegance, which you remarked on above, is not a word that springs to
mind when I look at this.

> I assume that you have seen Y.1418 - Pseudowire Layer Networks
NH=> I've not looked at the detail, but I have been long aware of that
this would be a potential risk (ie creating yet another layer network)
of not having consistent client treatment in MPLS.

> Once again, I have a practical problem of identifying the 
> client format. For (i) MPLS, there is no problem - MPLS is 
> MPLS. For (ii) IP there are two possibilities, but the first 
> nibble serves as a PID. For (iii) there are multiple 
> possibilities (5 modes of ATM, 3 modes of TDM, 2 modes of 
> Ethernet, ...) and some modes can either use or not use the 
> control word. This needs addressing. 
> 
> 
> Unfortunately, this is not the case. If an Ethernet PW is 
> misconnected to a SAToP PW then you get rubbish, and don't know why.
NH=> Oh yes I agree....this was indeed my point....you are just saying
that it's even worse.  However, even if the traffic units are
inconsistent wrt functional field semantics *providing* the connections
all have consistent OAM (ie same CV flow) then one can detect/diagnose
the problem.....but we don't have this either.
> I am trying to parse that.
NH=> All I am saying is that a label issued by CP signalling protocol X
may be misinterpreted (ie still processed in some way, albeit
incorrectly) if it is misdelivered to a CP signalling protocol Y sink.
That is:  some labels have a forwarding semantic (DA proxy), some labels
have a demerging semantic (SA proxy), some have a functional 'action'
semantic, etc. 

> I think you are asking what 
> happens if a PW gets misconnected to a MPLS tunnel carrying 
> IP. If we use the CW, this should be immediately identifiable.
NH=> But the CW is optional.  Also see the above remark about
inconsistent label semantics on 'regular' LSPs.

> 
> Next, you are asking what happens if an MPLS tunnel set up 
> using LDP is misconnected to one set up using BGP or RSVP.  
> Why is this any different from misconnecting MPLS tunnels set 
> up using the same label distribution protocol ?
NH=> I agree...we have both (i) same CP protocol misconnectivity (ie the
normal case in any co mode layer network) and (ii) misconnectivity
between different CP protocols (novel to MPLS).

> Indeed, that will make everything even worse.
NH=> I know....but it's probably a good idea to at least recognise this
will further impact things and try and take it into account if possible.

regards, Neil