Subject: PWE3 Arch/CW & RTP Order (Rough Consesus?)

From: Danny McPherson <[email-masked]>
Date: Fri, 02 May 2003 15:55:57 -0600

Given that many folks have been quite vocal regarding this, and that this
discussion has been trolling on for quite a while now, I think we've reached
_rough consensus on how to proceed.  On my count the majority of views
expressed here support this layering model:

MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload

We need to move forward with this (as we'd like to have WG LC on the Arch
again [again] within a week or two), and although there are arguments both
ways, there are no show-stoppers either way.  As such, given my perception
of consensus on the list, we'll move forward with the the model depicted
above, and RTP will immediately precede the CW.

An updated version should be posted soon for another round of WG LC.

-danny

---

From: Shahram Davari <[email-masked]>
Date: Mon, 5 May 2003 14:25:16 -0700

And what is your proposal for PW types that don't have their first nibble
reserved (such as SONET/SDH PW)? 

-Shahram 

>-----Original Message-----
>From: George Swallow [mailto:[email-masked]]
>Sent: Monday, May 05, 2003 3:59 PM
>To: Danny McPherson
>Cc: [email-masked]; [email-masked]
>Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) 
>
>
>Danny -
>
>Just what is this MPLS PID that you're hanging you hat on?
>
>No standard or MPLS wg document exists.  There is no item in the MPLS
>charter.  
>
>I do not see the MPLS group doing a standards track 4 byte payload
>type ID.  All I want MPLS to do is write an informational document
>citing the issues of ECMP and recomending the above use of the first
>nibble of a non-IP payload.
>
>So as far as I'm concerned what folks are calling the "MPLS PID" is
>merely a variant of the PW CW.  And your diagram is:
>
>MPLS->PW label->PW CW->RTP->PW CW->PW Payload
>
>...George
>
>===============================================================
>=========
>George Swallow             Cisco Systems                  
>(978) 936-1398
>                           1414 Massachusetts Avenue
>                           Boxborough, MA 01719
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 6 May 2003 09:59:37 +0200

Hi all,

I believe that George's comment has been very much in place.

The "MPLS PID" story looks to me like following:

1. There was a recognized but, for some reasons, undeclared need
   to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts
   complied with this, and some did not; some others simply
   declared that the CW is optional.

2. At some (rather late) stage, the need has been declared,
   explained (which is always good!) and proposed as part of
   the standard (moving the architecture document int the
   Standards Track). 

3. In order to minimize impact on some pre-standard implementations
   that have either utilized the 1st nibble of the CW or used RTP
   (or both), an optional opaque 32-bit word has between the PW label
   (at the bottom of the label stack) and a the CW/RTP header has been
   proposed as the simplest way out. The only requirement for this
   block of data has been to keep its 1st nibble zeroed. 

4. After that, this patch has been somehow "promoted" to the title
   and associated status of of "MPLS PID". And this promotion has 
   triggered a long discussion of its possible uses far beyond the
   original patchy fuctionality.

5. The proposals mentioned in is discussion are, IMO, paramount 
   to an alternative PWE3 architecture (including allocation
   of a PWE3 protocol number in IP header etc.). They also include 
   amendments to Y.1711 which is presumably out of scope of PWE3 
   (and IETF in general) etc.
   And somehow the fact that existing LSRs carry IP traffic over
   LSPs without any MPLS PID and will hardly be ever retrofitted
   has been happily ignored by some of the participants. 

IMHO the best way out of the confusion would be to demote 
"MPLS PID" to what it really is - a patch solving the ECMP 
problem for the following three cases (and just for these cases):

o	PW encapsulations that do not mandate a CW, so that payload
immediately
	follows the PW label. In other words, make SOME CW mandatory.
o	PW encapsulations that mandate a CW but utilize its 1st nibble. 
	They would prepend an opaque 32-bit word with the zeroed 1st nibble
      by default, reserving an option to drop it if ECMP is not used in
	the core network.
o	PW encapsulations that use RTP. They may follow the same rules as in
	the previous case, or may use weaker rules because the first nibble
	of an RTP header distinguishes it from IPv4/IPv6 headers and this
	is probably sufficient for ECMP.

I think that building theories/architectures on patches is
counter-productive.

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

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Monday, May 05, 2003 11:25 PM
> To: 'George Swallow'; Danny McPherson
> Cc: [email-masked]
> Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) 
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 6 May 2003 11:24:44 +0300

Sasha, 

I think that you have summed up the situation admirably.

The purpose of the first four bits was well known to most of us, 
but for some reason there was an agreement not to put it in writing.
I am glad Stewart came out with it at last.

As you said, the problem is that some of the PW types
allow the CW to be optional, and some have a non-compliant CW.
As you will recall, I brought precisely these issues up
in IETF55, and was angrily attacked.

The invention of a 4 byte MPLS PID in order to 
contain the 4 bits, is in my opinion, a ridiculous
waste of bandwidth. You will no doubt recall the
email discussions with Ron Cohen, who was strongly
advocating this route.

So although we agree on the problem definition,
I can not agree with your conclusions.

My suggestion is much simpler and cleaner:

  1) Mandate a single CW format for all PW types.
     For those types that require a lengthy structure pointer,
     an extended format (8 byte CW) should be used
     (as suggested by Andy in one of his emails).
     Note that my IETF55 suggestion of precisely this
     was opposed on the grounds of being wasteful in BW,
     by precisely those who now promote a 4 byte MPLS PID!
  2) If ECMP is used, then the CW can not be omitted.

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 6 May 2003 13:47:45 +0200

George,

I'm not sure why the current MPLS WG charter changes any of the
arguments that led to the rough consensus on the PW architecture and
layering. 

If the name MPLS-PID is problematic, would naming it PW-MPLS-CNV (for
MPLS Convergence layer in the PW architecture draft) be ok with you?
That is:

MPLS->PW label->PW MPLS CNV->RTP->PW CW->PW payload

Ron

> No standard or MPLS wg document exists.  There is no item in 
> the MPLS charter.  
> 
> I do not see the MPLS group doing a standards track 4 byte 
> payload type ID.  All I want MPLS to do is write an 
> informational document citing the issues of ECMP and 
> recomending the above use of the first nibble of a non-IP payload.
> 
> So as far as I'm concerned what folks are calling the "MPLS 
> PID" is merely a variant of the PW CW.  And your diagram is:
> 

> 
> ...George
> 
> ==============================================================
> ==========

---

From: Shahram Davari <[email-masked]>
Date: Tue, 6 May 2003 06:59:20 -0700

>nibble of a non-IP payload.

Is this your personal opinion or the consensus of MPLS WG?

>MPLS->PW label->PW CW->RTP->PW CW->PW Payload

Why are there 2x PW CW?

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Tue, 6 May 2003 07:02:29 -0700

Why do you think that IETF is in the business of standardizing patches to
proprietary implementations and not in the business of building proper architecture?

-Shahram

---

From: George Swallow <[email-masked]>
Date: Tue, 06 May 2003 11:07:29 -0400

> Is this your personal opinion or the consensus of MPLS WG?

Clearly it is my opinion as there is absolutely no consensus in the
MPLS WG.

> >MPLS->PW label->PW CW->RTP->PW CW->PW Payload

Exactly my point.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: [email-masked]
Date: Tue, 6 May 2003 16:15:54 +0100

Sasha....sounds bang-on to me.  I'd like to see the real problem formally
recognised as such:  

MPLS(sic) PID is a fix for using LDP mp2p in a co pkt-sw forwarding mode,
and the consequential need to run (proprietary) ECMP algorithms to effect a
sort-of TE function.  Further, (though I suspect this problem won't get
recognised) it is not valid IMO to run a load-sharing algorithm across
multiple layered networks.....fine within a *single* layer network.  It is
for sure not an MPLS PID as it does not belong to the MPLS layer at all, but
lives in the twilight world of PWs, as yet another unneccesary function
(which heaven forbid will spawn more bolt-on PW functions like OAM) to fix
architectural errors which emanate in a lower server layer.

Just want to see fair identification of what the real problems are.....so
one day we may even do the right thing and get rid of the real problems ;-)

regards, Neil

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: 06 May 2003 09:00
> To: 'Shahram Davari'; 'George Swallow'; Danny McPherson
> Cc: [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Tue, 6 May 2003 08:23:07 -0700

George,

But I recall that it was you who proposed the 4 byte MPLS PID in this 
archived email:

"So this would be my proposal for doing so:

For any PWE3 control header, define the first nibble of the first word
as a format identifier with the following values:

Value 0 = control word as defined in PWE Arch, data

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0| Flags |FRG|  Length   | Sequence Number               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value 1 = control word as defined in PWE Arch, OAM

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1| Flags |FRG|  Length   | Sequence Number               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note:  The sequence number would either be unused or used to mark the
position in the sequence, that is, carry the same value as the last
data PDU sent.

Value 2 = PPP PID 

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 1 0|  reserved             | PPP DLL Protocol Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As defined by PID                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Values 3 - 15 = Reserved.

New PPP DLL Protcol numbers would then be defined to indentify the
further contents, such as the Sonet encaps. 

...George"

-Shahram

>Sent: Tuesday, May 06, 2003 11:07 AM
>To: Shahram Davari
>Cc: 'George Swallow'; Danny McPherson; [email-masked]; [email-masked]

---

From: [email-masked]
Date: Tue, 6 May 2003 16:15:56 +0100

George...The MPLS PID is not an *MPLS* PID at all....it is a *PW* PID.  If
it was an *MPLS* layer PID it would belong to the MPLS layer
networks.....but it doesn't.  It lives in the 'in-between-layer' world of
PWs.

So I have to agree with your conclusion (MPLS(sic) PID == PW CW), but I have
my own reasons.....based on trying to get people to think a bit more
architecturally about what is going on and why, rather than just creating ad
hoc/expedient fixes to problems that actually reside in other layer networks
(eg see my recent mail to Akiva).

Maybe its too late now (at least for the current crop of PWE3 stuff)?  But
we should be striving for far more architectural rigour in IETF IMO....and
this means recognising/accepting the world is not just cnls/IP, and that
there are valid/important technologies that belong to co cct-sw and co
pkt-sw modes whose required functional behaviour/specifications are quite
different to the cnls mode.  We operators need all all these modes.  So we
should stop trying to make them look like they are all the 'same'.

We can, as an industry/community, do things much better IMO.  I hope/pray
others can also see the logic in this.

regards, Neil

> Sent: 05 May 2003 20:59

---

From: George Swallow <[email-masked]>
Date: Tue, 06 May 2003 11:44:25 -0400

> But I recall that it was you who proposed the 4 byte MPLS PID in this 

I didn't propose an "MPLS PID", I proposed alternate forms for the PW
CW.  It's one thing.  Not two.   

...George

---

From: Shahram Davari <[email-masked]>
Date: Tue, 6 May 2003 09:01:35 -0700

>CW.  It's one thing.  Not two.   

Let's forget about the term "MPLS PID". What I can't understand 
is how the following 2 formats could be the same thing?

 0                   1                   2                   3

Value 2 = PPP PID 

       0                   1                   2                   3

New PPP DLL Protocol numbers would then be defined to identify the
further contents, such as the Sonet encaps. 

Specially when you propose that SONET encap could follow the latter header.
The SONET format has a pointer, bunch of flags, sequence # etc called CEP
header (architecture draft calls it CW). Where should this go? 
If they follow your proposed header, then based on your proposal
 the format for SONET PW would be:

MPLS->PW label->Your proposed header->RTP-> CEP header ->PW Payload

right? If so then we have two things not one.

-Shahram

---

From: George Swallow <[email-masked]>
Date: Tue, 06 May 2003 13:26:05 -0400

> is how the following 2 formats could be the same thing?

When you set up a PW circuit you say what is going down it.  All the
second format gives you is an inband communication channel for that
circuit.  Similar to a DCC channel in SONET/SDH.  

> Specially when you propose that SONET encap could follow the latter header.

I haven't proposed anything with regard to SONET encap.  I've only
commented on the diagram that Danny showed.  As far as I'm concerned,
the first thing after the PW label should be the PW CW.  What you call
things beyond that, or what order they go in is not my present
concern.  Just don't put in a second PW CW.

...George

---

From: Shahram Davari <[email-masked]>
Date: Tue, 6 May 2003 10:46:43 -0700

>I haven't proposed anything with regard to SONET encap.

I meant in  your email that I quoted from a few weeks ago.
In that email you said:

"New PPP DLL Protocol numbers would then be defined to identify the
further contents, such as the Sonet encaps."

My understanding of this sentence is that SONET Encap should follow your
proposed header or whatever you like to call it.

>I've only
>the first thing after the PW label should be the PW CW.

The issue is What do you mean by PW CW? do you mean the 4-byte header
that provides details such as seq#, length, flags, pointer, etc? If so
then please explain to me what are you proposing here:

" 0                   1                   2                   3

Should this replace the SONET CW (i.e., CEP header), precede it or follow it?

-Shahram

---

From: "David Allan" <[email-masked]>
Date: Tue, 6 May 2003 14:20:51 -0400

We do have two separate problems....

1) Is a means of identifying a generic payload. This would appear to
potentially require additional services such as sequencing etc. stuff
already dealt with in the exissting PWE control words. This would include
ordering, and if this was preserved in the presence of proprietary ECMP so
much the better.

2) A means of instrumenting PWs such that packets fate shares with  PW
forwarding. Tom has proposed VCCV which needs an available bit in the CW and
control handshaking to agree on what the bit means. The PPP DLL approach
(Georges proposal) or my proposal permits the instrumenting protocol to self
identify and therefore IMHO is preferable. 

But I am skeptical that simply having a protocol identifier means a PW can
carry anything. Its not designed with the requisite attributes for service
bearing. If we want "carry anything" with ordering fragmentation etc. we
have more to do.

my 2 cents
Dave

> Sent: Tuesday, May 06, 2003 4:00 AM

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 6 May 2003 22:04:20 +0200

Exactly! This is why I believe MPLS-PID is a reasonable name for this
layer.
 
> Can we mandate that the only payloads EVER to run over MPLS 
> will be IP and PWE3?
> 
> If yes, then the PID is a component of PW.
> 
> If no, then the PID is a component of MPLS.
> 
> Stewart
> 
> 
>

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 6 May 2003 22:04:20 +0200

George,

> I haven't proposed anything with regard to SONET encap.  I've 
> only commented on the diagram that Danny showed.  As far as 
> I'm concerned, the first thing after the PW label should be 
> the PW CW.  

Why? Why not RTP, or foo? All you said up till now is that you don't
want to define 4 bytes MPLS PID in the MPLS WG. What are your technical
arguments?

> What you call things beyond that, or what order 
> they go in is not my present concern.  Just don't put in a 
> second PW CW.

First you change the name of the first 4 bytes from MPLS-PID to PW CW,
and then argue that it doesn't make sense to have two. Interesting.

Ron 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Swallow
> Sent: Tuesday, May 06, 2003 7:26 PM
> To: Shahram Davari
> When you set up a PW circuit you say what is going down it.  
> All the second format gives you is an inband communication 
> channel for that circuit.  Similar to a DCC channel in SONET/SDH.  
> 
> I haven't proposed anything with regard to SONET encap.  I've 
> only commented on the diagram that Danny showed.  As far as 
> I'm concerned, the first thing after the PW label should be 
> the PW CW.  What you call things beyond that, or what order 
> they go in is not my present concern.  Just don't put in a 
> second PW CW.
> 
> ...George
> 
> > The SONET format has a pointer, bunch of flags, sequence # 
> etc called 
> > CEP header (architecture draft calls it CW). Where should 
> this go? If 
> > they follow your proposed header, then based on your proposal  the 
> > format for SONET PW would be:
> >

---

From: George Swallow <[email-masked]>
Date: Tue, 06 May 2003 15:51:06 -0400

Shahram -

> further contents, such as the Sonet encaps."

I recant.  Bad idea.  If you stick a PID in there, then you're PW
circuit is really some generalized LSP.  So I would (now) stick with
using LDP to signal the payload as SONET.  If also signal that you
have a PW CW you can then use the PID format as well, but only as a
DCC.

...George

---

From: [email-masked]
Date: Tue, 6 May 2003 21:14:25 +0100

Stewart,
> [email-masked] wrote:
> Can we mandate that the only payloads EVER to run over MPLS will be IP
> and PWE3?
NH=> PWE3 is not a real layer network that I recognise, whereas IP (and
MPLS) are. 
> If yes, then the PID is a component of PW.
NH=> But PWs are artifical/unnecessary....that is the whole point of my
observations.
> If no, then the PID is a component of MPLS.
NH=> Could be.  But then why are they artifically attached to the PW layer?
The only answer I have is (i) to try and make IP/X appear the same as X/MPLS
(which is not arch sensible) and (ii) to cater for the (wrong) usage of ECMP
across MPLS due to LDP (which again is not sensible....deprecate LDP mp2p is
however sensible).  MPLS originally assumed consistent client mappings to an
LSP over its lifetime, so there was no need for a PID in the data-plane.

regards, Neil

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 07 May 2003 18:41:55 -0400

Dave and all,
I agree with your assessment. Given that we want to progress the
PWE3 work, I propose to address the issues raised in 2 phases:

Phase 1: 
the current scope of the PWE3 working group is to provide for a PW
between two endpoints of the same type (e.g., FR-MPLS-FR). In this
environment, the native service OAM and link management achieves all
what is needed and we do not need to define a specific PW OAM. At
the PSN level, OAM can be achieved using either IP tools such as
LSP-Ping, or Y.1711 tools. Any OAM specific issues with the PSN are
clearly outside the scope of the PWE3.
The only requirement is to address the IP aliasing issue. The most
straighforward way to resolve it is to make sure that all CWs have
the nibble following immediately the bottom label set to a value
different of 4, 6, or 8 (zero seems to be the accepted value). This
means that the SONET encapsulation would have to go with Option 3 in
Andy's three proposals.

Phase 2: 
the work of the PWE3 may expand to support endpoints of different
types (e.g., FR-MPLS-Ethernet). In this scenario, if the native
service is terminated locally at each PE, then clearly there is a
need for the following:
a. the ability to define a PW specific OAM and link management
functions and inteoperate it with the native service OAM and link
management.
b. the ability to self-identify the protocol carried in a single PW.
A PW can carry both user packets and OAM packets and we want them to
share the same path in the presence of ECMP. A PW can also carry
both a end-user bridged and a routed PDU (multiprotocol PW). This is
where the MPLS/PW PID is useful but it should be addressed in a much
wider scope than the current PWE3 issues.

Let me know what you think.
Mustapha.
------------
> David Allan wrote:
> 1) Is a means of identifying a generic payload. This would appear
> to potentially require additional services such as sequencing etc.
> stuff already dealt with in the exissting PWE control words. This
> would include ordering, and if this was preserved in the presence
> of proprietary ECMP so much the better.
> 
> 2) A means of instrumenting PWs such that packets fate shares
> with  PW forwarding. Tom has proposed VCCV which needs an
> available bit in the CW and control handshaking to agree on what
> the bit means. The PPP DLL approach (Georges proposal) or my
> proposal permits the instrumenting protocol to self identify and
> therefore IMHO is preferable.
> 
> But I am skeptical that simply having a protocol identifier means
> a PW can carry anything. Its not designed with the requisite
> attributes for service bearing. If we want "carry anything" with
> ordering fragmentation etc. we have more to do.
> 
> my 2 cents
> Dave
>

---

From: [email-masked]
Date: Thu, 8 May 2003 11:13:24 +0100

Mustapha,

Please see in-line.  regards, Neil

Mustapha Aissaoui wrote 07 May 2003 23:42
> what is needed and we do not need to define a specific PW OAM.
NH=> Absolutely correct.....when I want to interwork ATM/MPLS say there is
not need whatsover for PW OAM, but further there is no need for PWs at all!

> At

> types (e.g., FR-MPLS-Ethernet).
NH=> I suggest some caution here.  It is perfectly valid (and required) to
have service-interworking between technologies that belong to the *same*
network mode.  It is not so valid to have service-interworking between
technologies that don't belong to the same mode......here only client/server
relationships make sense, and even then only certain ones between the 3
modes.  One can of course ignore this, and no doubt this is going to
happen.......but I advise caution.

> In this scenario, if the native
NH=> Why?  The scenario described (ie service-interworking) requires that
the trails of each technology terminate at the IWF....if one drew out the
G.805 diagrams this would be clear.  This means their native OAM functions
(if any) also terminate at the IWF.  One therefore requires some
higher/common 'networking entity' to be carried end-end across the
concatenated server technologies.  However, I don't see any difference
between ATM/MPLS service interworking and ATM/MPLS/FR service interworking
and ATM/MPLS/ethernet service interworking (other than the validity of
having mode mismatch, and the functional specification differences of each
of the technologies in question).

> A PW can carry both user packets 
NH=> of which layer network?

> and OAM packets
NH=> of which layer network?

> and we want them to
> both a end-user bridged and a routed PDU (multiprotocol PW).
NH=> Whoa!  You have just changed the service-interworking case into a
(partial) client/server case....in the former the etherent component is
simply a server layer access partition (terminates at the IWF) but now you
are describing the case where the ethernet pkts have to be carried across
all intervening networks....so, for example, it could be that ethernet is
client to both MPLS and ATM partitions say, but the MPLS and ATM partitions
are using service interworking.  As I noted previously, if you draw out the
G.805 relationships this would be much clearer.

> This is
NH=> Please note this observation:  A PID field is only required to identify
the *clients* of a given layer network when these can change over the life
of the (server) layer trail.  In G.805 terms this is describing a
multiplexing function that is related to the adaptation of the client signal
into the payload of the server signal.  Each layer network however, should
have its own native OAM that is *independent* of any higher client layer.
That is, the PID field and the layer network's native OAM are *not* in any
way related (and the PID function sits above the OAM
functionally).....putting this is very plain terms, the *client* PID field
should not be used to identify OAM pkts.

Finally, if MPLS is properly specified there is no need for any of this
artifical PW stuff....we simply need to interwork MPLS and the other
technologies natively.  The PW stuff only 'lives' because:
-	of LDP and the issues/hacks of ECMP.....load-splitting only makes
arch sense in a *single* layer network.
-	MPLS is 'allowed' to re-order pkts
-	someone thinks squeezing a bit of BW (wrt certain client layers) is
useful
-	the erroneous belief that X/IP is somehow the same as X/MPLS

An unneccessary networking layer (the PW) has thus been created, that is now
starting to take on a life of its own as an 'in-between' layer network, when
there is no need for it....esp when we have to manage the MPLS network
anyway (so do it once, and do it right).  Thanks, just something else to
manage ;-)  On a serious note however, I hope/pray there are some suppliers
out there that can understand what I am saying here and will provide
solutions without these unnecessary problems.  I don't think its that hard
(technically at least).

---

From: [email-masked]
Date: Thu, 8 May 2003 11:13:10 +0100

Rahul,  please see below, regards, Neil
> [clipped]
> In this environment there is still a need for a PW OAM. 
> Please see section
> 3 of:
> 
> draft-nadeau-pwe3-vccv-00.txt

NH=> There is not a 'need' for PWs at all.  The only 'need' arises due to
reasons I pointed out in my response to Mustapha.  Given we still have to
manage the MPLS layer networks why not do it once and do it right?  However,
given it *is* possible to do things differently/simpler, then I think
operators who want to have such solutions should be able to achieve them.
And of course, those who want PWs as being defined can have them too.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 8 May 2003 06:57:57 -0700

>	1) Use of VCCV allows you to get as close to the
>		disposition point as possible; LSP 
>		or ICMP ping doesn't necessarily do 
>		this in all cases.

If you can test the PSN tunnel and if you can test the
carried service using segment OAM then you can achieve the
same result (i.e.,get as close to the disposition point as possible)
For example in ATM/MPLS case, if you test the
LSP tunnel between PEs using any method you like (LSP-ping,
your hated Y.1711, etc.) then you are sure the PEs have connectivity.
Now if you run an ATM segment OAM between PEs, you can test that the
ATM connection is correctly mapped to the proper PW or not.
So we won't need PW OAM. If your answer is that some technologies such
as Ethernet don't have segment OAM, then the answer is go and fix them,
which is what MEF and ITU are doing at this time.

>
>	2) VCCV is a generic CV mechanism for IETF defined
>		PWs regardless of the underlying PSN technology
>		that allows CV traffic to flow on EXACTLY the
>		same path as the data plane.

It is not generic, it requires a CW and a reserved word in it.
for example SONET/SDH PW doesn't have it.

>	Also, pitching Y.1711 as a possible alternative is
>irresponsible. It is badly broken for LDP-based networks
>and has been shown to be quite difficult to implement
>besides, so lets not go there. Of course, its proponents 
>are working feverishly to patch it up within the ITU
>so that they can ask service providers to replace all
>of their hardware (again) to support the ultimate OAM
>swiss army knife. I assert that it is certainly 
>not ready and should not be considered as an acceptable
>approach.

I can equally prove that LSP-ping is badly broken. LSP-ping
is in effect a quick patch to the problem (like a band aid), 
not a proper OAM. But Let's not go there. 

>
>	Again, read the OAM requirements referenced above. 
>OAM traffic MUST be carried on the same data path regardless 
>of whether ECMP is active or not.  Are you suggesting that
>we should ignore that 25 SPs have told us?

No we should not ignore them. But you are confusing the solution
with the requirement. I am sure the 25 SPs didn't mandate VCCV !
All they need is a way to manage their PWs and as I said above there are
better architectural alternatives to VCCV.

>	--Tom
-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 10:04:53 -0400

> Behalf Of [email-masked]
> Sent: Thursday, May 08, 2003 6:13 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> NH=> There is not a 'need' for PWs at all.  The only 'need' 
> arises due to reasons I pointed out in my response to 
> Mustapha. 

	Your lack of need aside, the fact still remains
that there are lots of deployments of PWs. Therefore,
they do indeed need PW-level OAM.

	--Tom

 Given we still have to manage the MPLS layer 
> networks why not do it once and do it right?  However, given 
> it *is* possible to do things differently/simpler, then I 
> think operators who want to have such solutions should be 
> able to achieve them. And of course, those who want PWs as 
> being defined can have them too.

---

From: "David Allan" <[email-masked]>
Date: Thu, 8 May 2003 10:17:39 -0400

Tom:

<snipped>
> 
> > OAM can
> > be achieved using either IP tools such as LSP-Ping, or Y.1711 
> > tools. Any OAM specific issues with the PSN are clearly 
> > outside the scope of the PWE3. 
> 
>  	Use of just LSP-ping for PWs is not going to cut 
> the mustard for two reasons, which I will explain
> below. I believe that LSP ping/ICMP ping/native OAM
> and VCCV need to be used in conjunction to satisfy
> the requirements specified in the OAM requirements.

I thought VCCV as described "was" LSP PING or ICMP just carried in a form
hidden from existing proprietary ECMP implementations. Why do you draw such
an artifical distinction?

> 		This is important because tools designed to 
> 		test/debug/verify PWs can be written more
> 		generally.  This is also important because
> 		there are cases where using regular ICMP-ping
> 		will not follow the same data plane path over
> 		the IP tunnel.
> 
> irresponsible. It is badly broken for LDP-based networks and 
> has been shown to be quite difficult to implement besides, so 
> lets not go there. 
> Of course, its proponents 
> swiss army knife. 

I find your characterization rather hysterical....you may want to check the
defintion of "irresponsible".

> I assert that it is certainly 
> not ready and should not be considered as an acceptable approach.
> 
> > The only requirement is to
> > address the IP aliasing issue. The most straighforward way to 
> > resolve it is to make sure that all CWs have the nibble 
> > following immediately the bottom label set to a value 
> > different of 4, 6, or 8 (zero seems to be the accepted 
> > value). This means that the SONET encapsulation would have to 
> > go with Option 3 in Andy's three proposals.
> > 
> > Phase 2:
> > the work of the PWE3 may expand to support endpoints of 
> > different types (e.g., FR-MPLS-Ethernet). In this scenario, 
> > if the native service is terminated locally at each PE, then 
> > clearly there is a need for the following: a. the ability to 
> > define a PW specific OAM and link management functions and 
> > inteoperate it with the native service OAM and link 
> > management. b. the ability to self-identify the protocol 
> > carried in a single PW. 
> 
> > A PW can carry both user packets and
> > OAM packets and we want them to share the same path in the 
> > presence of ECMP. 
> 

Looks to me that he stated accurately in the sentence above what those 25
SPs told you. Just described it in two phases. So what are you objecting to?
Is there a real technical point in this diatrabe?

cheers
Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 10:35:52 -0400

> Sent: Thursday, May 08, 2003 9:58 AM
> To: [email-masked]'; 'Mustapha Aissaoui'; 'David Allan'
> Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; 
> [email-masked]
> same result (i.e.,get as close to the disposition point as 
> possible) For example in ATM/MPLS case, if you test the LSP 
> tunnel between PEs using any method you like (LSP-ping, your 
> hated Y.1711, etc.) then you are sure the PEs have 
> connectivity. 

	Nope. If you have actually implemented this, you
would understand my point. The code that intercepts the
MPLS LSP ping code is different from that that does the
disposition. It is close, but not as close as possible. 
Also, you are not considering what we should do if IP 
is the PSN. BTW, the same arguments apply.

> Now if you run an ATM segment OAM between PEs, 
> you can test that the ATM connection is correctly mapped to 
> the proper PW or not. 

	And what do you do if you find that it is not
correctly mapped? What does ATM segment OAM tell you
that helps you trouble-shoot the situation?

> So we won't need PW OAM. If your answer 
> is that some technologies such as Ethernet don't have segment 
> OAM, then the answer is go and fix them, 

	I think that even with segement OAM you still need
PW OAM (VCCV). To further complicate things, consider what
is needed for VPLS.

> which is what MEF and ITU are doing at this time.

	I wouldn't call what the ITU is doing anything
useable.  I would call what the IEEE is doing for 
801.11ab the right way, however.

> It is not generic, it requires a CW and a reserved word in 
> it. for example SONET/SDH PW doesn't have it.
> 
> irresponsible. It 
> >is badly broken for LDP-based networks and has been shown to 
> be quite 
> >difficult to implement besides, so lets not go there. Of course, its 
> >proponents are working feverishly to patch it up within the ITU

	Well, we all have our opinions. I guess
the market will tell us ultimately what will be
used.
 
> No we should not ignore them. But you are confusing the 
> solution with the requirement. I am sure the 25 SPs didn't 
> mandate VCCV ! All they need is a way to manage their PWs and 
> as I said above there are better architectural alternatives to VCCV.

	You are right that most SPs don't care about the
solution, just that it solves the problem, at least
at a high level. However, there are many ways to
skin a cat, and from the feedback I have been getting
use of VCCV and LSP ping are the way my customers 
want to skin this cat (i.e.: they don't want to use
y.1711's so-called 'architecturally correct' solution).

	--Tom

---

From: Shahram Davari <[email-masked]>
Date: Thu, 8 May 2003 08:04:15 -0700

>disposition.

I did not argue against this point at all. In fact the segment OAM
that I proposed is a recognition of this fact. 

>It is close, but not as close as possible.

Correct, PSN tunnel test gives you PSN connectivity, not PW
connectivity. That is why I proposed segment OAM as well.
 
>is the PSN.

Same thing, use IP-ping (like LSP-ping) for the IP connectivity
test and then use segment OAM for the carried service.

>BTW, the same arguments apply.
>

If the PSN tunnel test is OK then segment OAM
tells you that the ATM VC is not mapped correctly
to the proper PW. Then in the diagnostics phase you
have to check the actual ATM VC mapping to the PW in
both PE ends, and find why the mapping is not correct.

>PW OAM (VCCV). To further complicate things, consider what

No you don't need VCCV. In fact segment OAM gives you a
much closer test to the desposition point than VCCV. The reason is
simple. The layering is : PSN-PW-ATM. I proposed testing PSN
and ATM, but you proposed testing PW. Which one goes higher in
the protocol stack? Off course segment OAM goes higher than
PW OAM, because ATM is higher in the stack that PW.

>801.11ab the right way, however.

What? 801.11ab !!!!!!!!! is this a new IEEE group?
As far as I know IEEE is only doing link level OAM (802.3ah).

>y.1711's so-called 'architecturally correct' solution).

The PSN OAM method that you use is irrelevant to this discussion.
So please don't bring that as a justification for VCCV.

As you said your customers should not care how the PW management
is solved, they just want a solution. It is the duty of IETF to
find the best solution. If they want VCCV please tell them to 
explain why they think it is superior to other proposals (may be
you have't given them any more options). So far I have seen only
one provider (BT) that has spoken on the list and in fact not
in favor of VCCV.

-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 11:07:01 -0400

-----Original Message-----
From: David Allan [mailto:[email-masked]] 
Sent: Thursday, May 08, 2003 10:18 AM
To: [email-masked]'; 'Mustapha Aissaoui'
Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; 'Danny
McPherson'; [email-masked]
Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?)

Tom: 

<snipped> 

It is not artificial. VCCV can be used as a generic "OAM container" between
two PW end-points regardless of the underlying PSN that carries this
information over the same data plane path as normal traffic.

  It is irresponsible to tout a mechanism that doesn't work while claiming
that it a) works, b) solves the worlds MPLS OAM problems, and c) does so in
a cost-effective and timely manner.  Y.1711 did none of those things
originally while claiming it did. It was and still is being positioned as
the "architecturally correct" visionary solution. At that time its
proponents suggested that it was okay to replace all of a network's line
cards to support this solution. Well, guess what, if we all had drunk the
Y.1711 Koolaid then, SPs would have to be spending OPEX and CAPEX replacing
line cards a second time because shortly after it was ratified at the ITU,
folks like myself showed it not to work for LDP-based networks. Yea, sure
the number of SPs I just mentioned includes a mere %95, but heck, we should
all obey architectural correctness because the Y.1711 folks said so the
first time, so we should believe them this time too.  So please stop passing
the FUD about Y.1711 being something that it is not because that is indeed
hysterical.

    --Tom

cheers 
Dave

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 08 May 2003 11:19:46 -0400

Rahul,

Rahul Aggarwal wrote:
> In this environment there is still a need for a PW OAM. Please see section
> 3 of:
> 

There is nothing in Section 3 which justifies the need for a PW OAM
in the case of endpoints of the same type. You may want to double
check it.

> Regards,
> rahul

---

From: David Zelig <[email-masked]>
Date: Thu, 8 May 2003 18:25:32 +0200

> PW OAM, because ATM is higher in the stack that PW.

Shahram,
two major points are not solved with the suggestion to use segment OAM of
the native signal:
1) What happened if the customer is using the segmented OAM over a span that
include the PW?
2) A unified approach, applicable to all carried signal types, has
operational benefits for the operators who wish to use PW for carrying of
more than one signal type.

David

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 11:29:02 -0400

> Sent: Thursday, May 08, 2003 11:04 AM
> >MPLS LSP ping code is different from that that does the disposition.
> 
> I did not argue against this point at all. In fact the 
> segment OAM that I proposed is a recognition of this fact. 
> 
> Same thing, use IP-ping (like LSP-ping) for the IP 
> connectivity test and then use segment OAM for the carried service.

	If segment-OAM means VCCV then I agree. If it 
doesn't that I don't agree. There are load-share cares
where if you ping the L2TPv3 control channel you might
not take the same data plane path as the data.	The
forthcoming version of VCCV will include an option
to send information for L2TPv3. 

> both PE ends, and find why the mapping is not correct.

	What do you do in the VPLS case?  The
segment OAM in that case goes completely end-to-end.
How do you know which segment is broken in that case?
 
> much closer test to the desposition point than VCCV. The 
> reason is simple. The layering is : PSN-PW-ATM. I proposed 
> testing PSN and ATM, but you proposed testing PW. Which one 
> goes higher in the protocol stack? Off course segment OAM 
> goes higher than PW OAM, because ATM is higher in the stack that PW.
	
	I propose using native OAM to go from end-to-end,
if that fails, use VCCV for the PW and perhaps LSP ping/trace
for the PSN.
 
> As far as I know IEEE is only doing link level OAM (802.3ah).

	802.1ad.  Stiky fingers.
 
> The PSN OAM method that you use is irrelevant to this 
> discussion. So please don't bring that as a justification for VCCV.

	It is indeed germain to this discussion for the
reasons I have given.
 
> As you said your customers should not care how the PW 
> management is solved, they just want a solution. It is the 
> duty of IETF to find the best solution. If they want VCCV 
> please tell them to 
> explain why they think it is superior to other proposals (may 
> be you have't given them any more options). So far I have 
> seen only one provider (BT) that has spoken on the list and 
> in fact not in favor of VCCV.

	Indeed more providers' operational departments need 
to speak on this issue.

	--Tom

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 08 May 2003 11:56:49 -0400

Tom,

"Thomas D. Nadeau" wrote:
> > Behalf Of Mustapha Aissaoui
> > Sent: Wednesday, May 07, 2003 6:42 PM
> > To: David Allan
> > Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow';
> > Danny McPherson; [email-masked]
> > I agree with your assessment. Given that we want to progress
> > the PWE3 work, I propose to address the issues raised in 2 phases:
> >
> > Phase 1:
> > the current scope of the PWE3 working group is to provide for
> > a PW between two endpoints of the same type (e.g.,
> > FR-MPLS-FR). In this environment, the native service OAM and
> > link management achieves all what is needed and we do not
> > need to define a specific PW OAM. At the PSN level,
> 
>         I suggest that you read the MPLS OAM
> requirements in draft-ietf-mpls-oam-requirements-00.txt,
> as well as the justifications for VCCV in
> draft-nadeau-pwe3-vccv-00.txt and then tell the
> 25 or so service providers that were polled for
> these requirements about how it is so
> clear that there is no need to have such a mechanism.

I am really not saying anything different from what service
providers are saying. I am just stating that in the case of
endpoints of the same type we can troubleshoot the PSN using PSN
specific OAM (out of scope of PWE3) and the PW using the native
service OAM. Of course, one needs to correlate a defect indication
from the PSN level to the native service level, but this is a local
PE matter.

>                 will not follow the same data plane path over

Again, you are saying the same thing as I said. The only difference
is that you believe that the PW level OAM requires a new mechanism
while I am challenging you that it not required in the case of
endpoints of the same type.

> not ready and should not be considered as an acceptable

I am not pitching anything here. I think you are overreacting :-)
 
> we should ignore that 25 SPs have told us?

Tom, please read carefully before you reply. You just wrote exactly
what I wrote. The good news is that we are in agreement here at
least.

> 
>         --Tom
> 
> > A PW can also carry both a end-user bridged
> > and a routed PDU (multiprotocol PW). This is where the
> > MPLS/PW PID is useful but it should be addressed in a much
> > > already dealt with in the exissting PWE control words. This would
> > > include ordering, and if this was preserved in the presence of
> > > proprietary ECMP so much the better.
> > >
> > > forwarding. Tom has proposed VCCV which needs an available
> > bit in the
> > > CW and control handshaking to agree on what the bit means.
> > The PPP DLL
> > > approach (Georges proposal) or my proposal permits the
> > instrumenting
> > > protocol to self identify and therefore IMHO is preferable.
> > >
> > > But I am skeptical that simply having a protocol identifier
> > means a PW
> > > can carry anything. Its not designed with the requisite
> > attributes for
> > > service bearing. If we want "carry anything" with ordering
> > > fragmentation etc. we have more to do.
> > >
> > > my 2 cents
> > > Dave
> > >
> > "MPLS PID"
> > > > to what it really is - a patch solving the ECMP problem for the
> > > > following three cases (and just for these
> > > cases):
> > > >
> > > >       They would prepend an opaque 32-bit word with the
> > zeroed 1st
> > > > nibble
> > > >       by default, reserving an option to drop it if ECMP
> > is not used
> > > > in
> > > >       the core network.
> > > >       the previous case, or may use weaker rules because
> > the first
> > > > nibble
> > > >       of an RTP header distinguishes it from IPv4/IPv6
> > headers and
> > > > this

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 08 May 2003 12:13:30 -0400

David,

> 1) What happened if the customer is using the segmented OAM over a span that

Since a PW always terminates on a L2 endpoint, your native segment
OAM flow will terminate on that same endpoint. Thus a segment that
spans a PW works the same way as any native service segement.

> more than one signal type.

I am being realistic about what can be done to progress the work in
PWE3. The current scope of this working group is to work on
endpoints of the same type. Therefore, one wants to reuse as much as
possible the existing mechanisms. In phase 2, I agree that such a
mechanism is required.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 8 May 2003 09:17:03 -0700

>doesn't that I don't agree. 

Segment OAM is not VCCV. In fact it is superior to
VCCV because it goes much further to the disposition point than VCCV.

>There are load-share cares

I am not expert on L2TPV3, but if the management packets
don't follow the data-plane, then that is L2TPs problem not
PWE3.

>How do you know which segment is broken in that case?

I assume you mean tandem VPLS. There are 2 cases:

1) If you only switch based on PW label (as Eric Rosen has
suggested in another email thread) then to test each VPLS
network you can use your normal MPLS OAM (LSP-ping or anything
else).

2) If you actually terminate the PW label and start another PW
then the segment OAMs will also be terminated and another one generated.
So you can test all VPLS networks using their own separate segment OAM.

>if that fails, use VCCV for the PW and perhaps LSP ping/trace

Since the end-to-end OAM belongs to customer, 
unfortunately the problem in that case is that it would be the
customer who first discovers the problems and calls you to 
correct it. The delay in correcting the problem would be in the order
of hours.

>	It is indeed germain to this discussion for the

I am sorry but if it is I don't get it. We are talking about
PW testing, what has it got to do with how PSN is tested?

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Thu, 8 May 2003 09:24:59 -0700

David,

>1) What happened if the customer is using the segmented OAM 

You have a point, but I am not sure why customer wants to run
segment OAM, rather than end-to-end OAM.

>more than one signal type.

Are you saying that operators prefer introducing a new protocol management layer
with a new management protocol, rather than using the native OAM that is
available for carried services? I think service providers need to speak on that.

-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 12:27:57 -0400

> From: Mustapha Aissaoui [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 11:57 AM
> To: [email-masked]
> Cc: [email-masked]
> > > Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; Danny 
> > > McPherson; [email-masked]
> > > the PSN level,
> > draft-nadeau-pwe3-vccv-00.txt and then tell the 25 or so service 
> > providers that were polled for these requirements about how it is so
> endpoints of the same type we can troubleshoot the PSN using 
> PSN specific OAM (out of scope of PWE3) and the PW using the 
> native service OAM. Of course, one needs to correlate a 
> defect indication from the PSN level to the native service 
> level, but this is a local PE matter.

	I might have misinterpreted what you said earlier. It
appears that we agree on the point that endpoint-OAM should
be used to trouble-shoot/CV the service. What it looks like
we don't agree on is whether VCCV is considered the PSN-specific
OAM piece. Let me suggest that you look at it this way, 
consder VCCV to be part of the PSN-specific OAM.
 
> > > OAM can
> > > be achieved using either IP tools such as LSP-Ping, or 
> Y.1711 tools. 
> > > Any OAM specific issues with the PSN are clearly outside 
> the scope 
> > > of the PWE3.
> > 
> Again, you are saying the same thing as I said. The only 
> difference is that you believe that the PW level OAM requires 
> a new mechanism while I am challenging you that it not 
> required in the case of endpoints of the same type.

	I am suggesting that the use of VCCV obviates the need
to consider either case because it works for both, as well as
VPLS.
 
> and has been 
> > shown to be quite difficult to implement besides, so lets not go 
> > there. Of course, its proponents are working feverishly to 
> patch it up 
> > within the ITU so that they can ask service providers to replace all

	Maybe. I have been known to in the past. *)

	--Tom

> > > resolve it is to make sure that all CWs have the nibble following 
> > > immediately the bottom label set to a value different of 
> 4, 6, or 8 
> > > (zero seems to be the accepted value). This means that the SONET 
> > > encapsulation would have to go with Option 3 in Andy's three 
> > > proposals.
> > >
> > > Phase 2:
> > > need for the following: a. the ability to define a PW 
> specific OAM 
> > > and link management functions and inteoperate it with the native 
> > > service OAM and link management. b. the ability to 
> self-identify the 
> > > protocol carried in a single PW.
> > 
> > > OAM packets and we want them to share the same path in 
> the presence 
> > > of ECMP.
> > 
> OAM traffic 
> > MUST be carried on the same data path regardless of whether ECMP is 
> > active or not.  Are you suggesting that we should ignore 
> that 25 SPs 
> > have told us?
> 
> Tom, please read carefully before you reply. You just wrote 
> exactly what I wrote. The good news is that we are in 
> agreement here at least.
> 
> > 
> >         --Tom
> > 
> MPLS/PW PID 
> > > is useful but it should be addressed in a much wider 
> scope than the 
> > > current PWE3 issues.
> > >
> > > > >    (or both), an optional opaque 32-bit word has 
> between the PW
> > > > label

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 12:32:58 -0400

> Sent: Thursday, May 08, 2003 12:14 PM
> To: David Zelig
> Cc: [email-masked]
> much closer 
> > > test to the desposition point than VCCV. The reason is 
> simple. The 
> > > layering is : PSN-PW-ATM. I proposed testing PSN and ATM, but you 
> > > proposed testing PW. Which one goes higher in the protocol stack? 
> > > Off course segment OAM goes higher than PW OAM, because ATM is 
> > > higher in the stack that PW.
> > >
> > >
> > 
> > Shahram,
> > two major points are not solved with the suggestion to use 
> segment OAM 
> > of the native signal:
> > 1) What happened if the customer is using the segmented OAM over a 
> > span that include the PW?
> 
> Since a PW always terminates on a L2 endpoint, your native 
> segment OAM flow will terminate on that same endpoint. Thus a 
> segment that spans a PW works the same way as any native 
> service segement.
> 
> > operational benefits for the operators who wish to use PW 
> for carrying 
> > of more than one signal type.
> 
> I am being realistic about what can be done to progress the 
> work in PWE3. The current scope of this working group is to 
> work on endpoints of the same type. Therefore, one wants to 
> reuse as much as possible the existing mechanisms. In phase 
> 2, I agree that such a mechanism is required. 

	Assuming that we are in agreement for the any-to-any
case, why not define a generic mechanism that works for
both any-to-any and like-to-like?  If you don't, then the
operator/operational software has to figure out which combination
is in use, and then choose which mechanism to test rather
than just mechanically trying the native service OAM, and then 
running VCCV?

	--Tom

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 08 May 2003 12:43:22 -0400

Shahram and David,

Shahram Davari wrote:
> >segment OAM of

We need to spearate customer testing from service provider testing.
Assume that we have a simple 3-hop network scenario (CE-PE-PE-CE).
Assume also we have a ATM-MPLS-ATM PW running over this network. 

The customer can test his/her connectivity using an end-to-end OAM
flow. The service provider will pass these cells unaffected provided
that:
a. There was an agreement allowing the customer to inject OAM cells.
b. The aggregate traffic on that connection des not violate the
traffic contract when policing user traffic in the PE. 

The service provider can run a segment OAM flow between the ATM
endpoints of the PW. These points are under his managment. Both the
customer OAM testing and the service provider OAM testing can
operate concurrently.

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 8 May 2003 10:36:10 -0700 (PDT)

Mustapha,

> in the case of endpoints of the same type. You may want to double

Its a matter of interpretation. VCCV provides a mechanism to validate the
PW forwarding path on the egress PE i.e. the MPLS Label FIB->PW mapping.
Even if endpoints are of the same type there may be a need to validate the
egress PW forwarding path. 

Regards,
rahul

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 8 May 2003 14:02:22 -0400

Mustapha,

I don't think I agree with your rationale. In case of service interworking, e.g. Frame Relay to Ethernet, there is one point in the network where the two protocols meet. Let's call that point A. Further assume that CE1 is the Frame Relay endpoint and CE2 is the Ethernet endpoint. On the link between CE1 and A, Frame Relay OAM applies. On the link between A and CE2 ethernet OAM applies.
Now assume that A coincides with a PE, say PE2. In that case, one segment of the link between CE1 and A is carried over a PW. I would argue that from a PW perspective this is an encapsulation of Frame Relay, nothing more, nothing less. Therefore:

a)Frame Relay OAM can be used to validate the sanity of the PW segment

b)There is no need to self-identify the protocol. As is the case for all PWs, the protocol carried over it is identified during PW set up.

By the way, I agree with your observations on phase 1.

Peter
> > > zeroed 1st nibble
> > > headers and this

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 08 May 2003 14:17:51 -0400

Neil,
see some comments inline.

Regards,
Mustapha.
-----------
> not need whatsover for PW OAM, but further there is no need for PWs at all!

You raise an important question which I believe deserves much
attention. Is a PW layer a regular MPLS layer or not. The currently
defined mechanism for encpasulation and signaling are vague about
that. The only thing I can think does not encourage removing this
ambiguity is the fact that a PW does not exist in its own. It is
always inside a tunnel of some sort and is a single hop as far as
the tunneling network is concerned.   
 
> of the technologies in question).

Apart from the important question of whether a PW layer is a MPLS
layer, the rest is not different from FR-ATM service interworking
(FRF.8.1). In the latter case, you can carry a bridged or routed PDU
across these 2 L2 networks. In fact you can carry a mix of protocols
over the same VC.
 
> NH=> of which layer network?

I am talking about protocols used by the end-user equipment. The CPE
may be routing IP, IPX, or any network layer protocol over a ATM VC.
It could also bridge Ethernet, FDDI, or any other bridged media
protocol over a ATM VC. 
 
> NH=> of which layer network?

I am referring to segment OAM messages originating and terminating
in the PW endpoints (or inner LSP endpoints).  
 
> G.805 relationships this would be much clearer.

I do not understand your point here. If I want to carry a higher
layer protocol PDU over a Ethernet-(PE1)-MPLS-(PE2)-ATM network, I
can do it in three different ways:
a. Extend Ethernet over MPLS (network interworking) to the PE2 and
then perform Ethernet-ATM service interworking there.
b. Extend ATM over MPLS (network interworking) to PE1 and then
perform Ethernet-ATM service interowrking there.
c. Terminate ATM and Ethernet locally at each PE and perform 2
service interworking functions, one at PE1 (Ethernet-MPLS), the
other at PE2 (ATM-MPLS).

It is clear to me that in (a) and (b), OAM messages of either the
Ethernet layer or the ATM layer need to be carried in the inner LSP.
It is not the case in (c), since both ATM and Ethernet are
terminated. Are we saying the same thing?
 
> should not be used to identify OAM pkts.

I agree with you on this point. The PID is in principle an
identifier of the higher layer protocol, not of the OAM messages of
the layer below it.

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 08 May 2003 14:31:52 -0400

Peter,
thanks for the comments. See more below.

Mustapha.
----------
"Busschbach, Peter B (Peter)" wrote:
> I don't think I agree with your rationale. In case of service >interworking, e.g. Frame Relay to Ethernet, there is one point in the >network where the two protocols meet. Let's call that point A. Further >assume that CE1 is the Frame Relay endpoint and CE2 is the Ethernet >endpoint. On the link between CE1 and A, Frame Relay OAM applies. On the >link between A and CE2 ethernet OAM applies.
> Now assume that A coincides with a PE, say PE2. In that case, one >segment of the link between CE1 and A is carried over a PW. I would >argue that from a PW perspective this is an encapsulation of Frame >Relay, nothing more, nothing less. Therefore:
> 

I guess your observation is correct if one extends FR to the remote
PE. In my response to Neil, I mentioned three ways of performing
Ethernet-(PE1)-MPLS-(PE2)-FR:
a. Extend Ethernet over MPLS (network interworking) to PE2 and
then perform Ethernet-FR service interworking there.
b. Extend FR over MPLS (network interworking) to PE1 and then
perform Ethernet-ATM service interowrking there.
c. Terminate Ethernet and FR locally at each PE and perform 2
service interworking functions, one at PE1 (Ethernet-MPLS), the
other at PE2 (FR-MPLS). 

Your observation applies to (a) and (b). In (c), a new mechanism for
OAM is required since both FR and Ethernet are terminated locally.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 14:32:17 -0400

One point below.

> Sent: Thursday, May 08, 2003 2:18 PM
> To: [email-masked]
> Cc: [email-masked]
> > NH=> Absolutely correct.....when I want to interwork ATM/MPLS say 
> > there is not need whatsover for PW OAM, but further there 
> is no need 
> > for PWs at all!
> 
> attention. Is a PW layer a regular MPLS layer or not. The 
> currently defined mechanism for encpasulation and signaling 
> are vague about that. The only thing I can think does not 
> encourage removing this ambiguity is the fact that a PW does 
> not exist in its own. It is always inside a tunnel of some 
> sort and is a single hop as far as
> > > clearly outside the scope of the PWE3. The only requirement is to 
> > NH=> I suggest some caution here.  It is perfectly valid (and 
> > required) to have service-interworking between technologies that 
> > belong to the *same* network mode.  It is not so valid to have 
> > service-interworking between technologies that don't belong to the 
> > same mode......here only client/server relationships make 
> sense, and 
> > even then only certain ones between the 3 modes.  One can of course 
> > ignore this, and no doubt this is going to happen.......but 
> I advise 
> > caution.
> > 
> > > service OAM and link management.
> > NH=> Why?  The scenario described (ie service-interworking) 
> requires 
> > that the trails of each technology terminate at the 
> IWF....if one drew 
> > out the G.805 diagrams this would be clear.  This means 
> their native 
> > OAM functions (if any) also terminate at the IWF.  One therefore 
> > requires some higher/common 'networking entity' to be 
> carried end-end 
> > across the concatenated server technologies.  However, I 
> don't see any 
> > difference between ATM/MPLS service interworking and ATM/MPLS/FR 
> > service interworking and ATM/MPLS/ethernet service 
> interworking (other 
> > than the validity of having mode mismatch, and the functional 
> > specification differences of each of the technologies in question).
> 
> Apart from the important question of whether a PW layer is a 
> MPLS layer, the rest is not different from FR-ATM service 
> interworking (FRF.8.1). In the latter case, you can carry a 
> bridged or routed PDU across these 2 L2 networks. In fact you 
> can carry a mix of protocols over the same VC.
>  
> I am talking about protocols used by the end-user equipment. 
> The CPE may be routing IP, IPX, or any network layer protocol 
> over a ATM VC. It could also bridge Ethernet, FDDI, or any 
> other bridged media protocol over a ATM VC. 
>  
> > > and OAM packets
> I am referring to segment OAM messages originating and 
> terminating in the PW endpoints (or inner LSP endpoints).  
>  
> > > and we want them to
> > (partial) client/server case....in the former the etherent 
> component 
> > is simply a server layer access partition (terminates at 
> the IWF) but 
> > now you are describing the case where the ethernet pkts have to be 
> > carried across all intervening networks....so, for example, 
> it could 
> > be that ethernet is client to both MPLS and ATM partitions say, but 
> > the MPLS and ATM partitions are using service interworking.  As I 
> > noted previously, if you draw out the G.805 relationships 
> this would 
> > be much clearer.
> 
> I do not understand your point here. If I want to carry a 
> higher layer protocol PDU over a 
> Ethernet-(PE1)-MPLS-(PE2)-ATM network, I can do it in three 
> different ways: a. Extend Ethernet over MPLS (network 
> interworking) to the PE2 and then perform Ethernet-ATM 
> service interworking there. b. Extend ATM over MPLS (network 
> interworking) to PE1 and then perform Ethernet-ATM service 
> interowrking there. c. Terminate ATM and Ethernet locally at 
> each PE and perform 2 service interworking functions, one at 
> PE1 (Ethernet-MPLS), the other at PE2 (ATM-MPLS).
> 
> It is clear to me that in (a) and (b), OAM messages of either 
> the Ethernet layer or the ATM layer need to be carried in the 
> inner LSP. It is not the case in (c), since both ATM and 
> Ethernet are terminated. Are we saying the same thing?
>  
> > > This is
> > NH=> Please note this observation:  A PID field is only required to 
> > identify the *clients* of a given layer network when these 
> can change 
> > over the life of the (server) layer trail.  In G.805 terms this is 
> > describing a multiplexing function that is related to the 
> adaptation 
> > of the client signal into the payload of the server signal.  Each 
> > layer network however, should have its own native OAM that is 
> > *independent* of any higher client layer. That is, the PID 
> field and 
> > the layer network's native OAM are *not* in any way related 
> (and the 
> > PID function sits above the OAM functionally).....putting 
> this is very 
> > plain terms, the *client* PID field should not be used to 
> identify OAM 
> > pkts.
> 
> identifier of the higher layer protocol, not of the OAM 
> messages of the layer below it.

	The PID gives an indication of what type of PW 
VC is being carried, which includes the higher layer
protocol; thus, it is reasonable to indicate PW
OAM with this.

	--Tom

> > Finally, if MPLS is properly specified there is no need for any of 
> > this artifical PW stuff....we simply need to interwork MPLS and the 
> > other technologies natively.  The PW stuff only 'lives' because:
> > An unneccessary networking layer (the PW) has thus been 
> created, that 
> > is now starting to take on a life of its own as an 
> 'in-between' layer 
> > network, when there is no need for it....esp when we have to manage 
> > the MPLS network anyway (so do it once, and do it right).  Thanks, 
> > just something else to manage ;-)  On a serious note however, I 
> > hope/pray there are some suppliers out there that can 
> understand what 
> > I am saying here and will provide solutions without these 
> unnecessary 
> > problems.  I don't think its that hard (technically at least).
> > >
> > > > 2) A means of instrumenting PWs such that packets fate 
> shares with  
> > > > PW forwarding. Tom has proposed VCCV which needs an 
> available bit 
> > > > in the CW and control handshaking to agree on what the 
> bit means. 
> > > > The PPP DLL approach (Georges proposal) or my proposal 
> permits the 
> > > > instrumenting protocol to self identify and therefore IMHO is 
> > > > preferable.
> > > >
> > > > > IMHO the best way out of the confusion would be to 
> demote "MPLS 
> > > > > PID" to what it really is - a patch solving the ECMP 
> problem for 
> > > > > the following three cases (and just for these
> > > > cases):
> > > > >
> > > > >       They would prepend an opaque 32-bit word with 
> the zeroed 
> > > > > 1st nibble
> > > > >       by default, reserving an option to drop it if 
> ECMP is not 
> > > > > used in
> > > > >       the core network.
> > > > >       of an RTP header distinguishes it from 
> IPv4/IPv6 headers 
> > > > > and this

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 8 May 2003 14:49:34 -0400

> Sent: Thursday, May 08, 2003 2:32 PM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]
> value). This
> > I don't think I agree with your rationale. In case of 
> service >interworking, e.g. Frame Relay to Ethernet, there is 
> one point in the >network where the two protocols meet. Let's 
> call that point A. Further >assume that CE1 is the Frame 
> Relay endpoint and CE2 is the Ethernet >endpoint. On the link 
> between CE1 and A, Frame Relay OAM applies. On the >link 
> between A and CE2 ethernet OAM applies.
> > Now assume that A coincides with a PE, say PE2. In that 
> case, one >segment of the link between CE1 and A is carried 
> over a PW. I would >argue that from a PW perspective this is 
> an encapsulation of Frame >Relay, nothing more, nothing less. 
> Therefore:
> > 
> > b)There is no need to self-identify the protocol. As is the 
> case for all PWs, the protocol carried over it is identified 
> during PW set up.
> 

Mustapha,

You are right and I have to apologize because I didn't read your first email carefully enough.

Case c) as you identify is a perfectly valid way to interconnect Ethernet and Frame Relay endpoints over an MPLS core network. However, this would require Service Interworking between Ethernet and MPLS on the one hand and Frame Relay and MPLS on the other.

Service Interworking is quite different from Network Interworking as specified in PWE3. I don't think it requires a "new" mechanism for OAM. I think it requires interworking of Frame Relay OWM with MPLS OAM and of Ethernet OAM with MPLS OAM. I also don't think it requires an MPLS PID.

In any case, I think we should not try to get commonality between MPLS Network Interworking (i.e. PWE3) and MPLS Service Interworking, without analyzing carefully what exactly we are trying to do.

I am with Neil on this one: G.805 and a clear understanding of what is the client layer and what is the service layer will avoid a lot of problems.

Peter

---

From: [email-masked]
Date: Thu, 8 May 2003 21:11:34 +0100

Tom,

<snipped>
> y.1711's so-called 'architecturally correct' solution).
NH=> Once you have bought into a given direction it ain't easy to
change....if its bad choice then kludge on kludge results.  The poor cat
they bought has no choice now but to be skinned in 1 way.  What I very
seriously object to however, is the misinformation you pedal that Y.1711 is
'complex/wrong' and your stuff is 'simple/right'.   I can't speak for other
carriers, but there is a major movement here (which has even surprised me
and colleagues who have been closer to it for some time) as those who have
to now get involved in considerations of deploying this stuff suddenly
realise its (how shall I put this politely) 'not very nice'.  You may be
surprised how they feel about this (and I am not talking about the poor
design team who have already bought the cat....ever heard of the hostage
syndrome?).  

Neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 16:18:50 -0400

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 4:12 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> NH=> Once you have bought into a given direction it ain't 
> easy to change....if its bad choice then kludge on kludge 
> results.  The poor cat they bought has no choice now but to 
> be skinned in 1 way.  What I very seriously object to 
> however, is the misinformation you pedal that Y.1711 is
> 'complex/wrong' and your stuff is 'simple/right'.   

	Frankly that message is coming from both sides, so
lets put that argument aside for the moment. What 
would be misinformation would be the assertion you and others
made a few years ago that operations should throw away all of 
their existing line cards to implement Y.1711 at the time in the
name of architectural OAM purity. Y.1711 clearly didn't
and doesn't work for LDP-based networks -- you have admitted
to that as have the other Y.1711 authors -- yet at the time
it was peddled as the ultimate OAM solution. If operators had
listened to you at the time and replaced all of their line
cards, they would be SOL right now, wouldn't they? Oh,
but of course, they would just overhaul them again to
support the kludges...ehm, addendums to Y.1711 so that they
could be architecturally pure again...maybe.  So why should
anyone believe you this time?

	--Tom

---

From: "David Allan" <[email-masked]>
Date: Thu, 8 May 2003 16:25:47 -0400

Tom: 

  It is irresponsible to tout a mechanism that doesn't work while claiming
that it a) works, b) solves the worlds MPLS OAM problems, and c) does so in
a cost-effective and timely manner.   

At the risk of wasting everyone;s time, I would  be curious to have you
substantiate some of these outlandish claims. 

 Y.1711 did none of those things originally while claiming it did. It was
and still is being positioned as the "architecturally correct" visionary
solution.  

I like the term "originally", ECMP broke a lot of stuff. I also believe
there have always been strong applicablity statements associated with 1711.

 At that time its proponents suggested that it was okay to replace all of a
network's line cards to support this solution.  

Of course all of your implementations are merely IOS upgrades.

 Well, guess what, if we all had drunk the Y.1711 Koolaid then, SPs would
have to be spending OPEX and CAPEX replacing line cards a second time
because shortly after it was ratified at the ITU, folks like myself showed
it not to work for LDP-based networks.  

WHy is it that you characterize a solution designed for ease of
implementation is such an onerous burden. This is vendor specific
implementation issues.... noone has mandated continual replacement of line
cards.

 Yea, sure the number of SPs I just mentioned includes a mere %95, but heck,
we should all obey architectural correctness because the Y.1711 folks said
so the first time, so we should believe them this time too.  So please stop
passing the FUD about Y.1711 being something that it is not because that is
indeed hysterical.

If you have real technical issues, drafts are posted with real technical
detail, lets discuss.

Dave 

cheers 
Dave

---

From: [email-masked]
Date: Thu, 8 May 2003 21:11:36 +0100

Tom, in-line and snipped. Neil

> irresponsible.
NH=> Why does this worry you so?  But maybe plagiarising is not
irresponsible....the early stuff you did as 'requirements', when you
eventually figured out OAM was important (which took quite a while I must
say) was largely a cut-paste on what I wrote over a year previous in Y.1710
and you even choose to use similar 'CV' nomenclature.

> It is badly broken for LDP-based networks
NH=> The only broken thing here is all the kludges that LDP has
spawned....this is the cat you sold us which we now have to skin in a fixed
direction with pretty blunt tools.  Your PW OAM stuff is p2p and between 2
fixed locations just like Y.1711, and has nothing to so with LDP....its just
operating in some new 'in-between' layer that we have to manage (besides the
client and MPLS).

> are working feverishly to patch it up within the ITU
NH=> The only truly 'feverish' work in ITU I am aware of came from Cisco
trying to object to 4 ITU Recommendations at the last minute.  You stand in
a class of 1 wrt this behaviour and I believe it is a record...it has not
gone unoticed.  You failed to derail the Recs in all cases (though I'll
grant you delayed the stuff)...and BTW Cisco finally agreed to Y.1711 (and
the other 3 Recs).

---

From: [email-masked]
Date: Thu, 8 May 2003 21:11:37 +0100

Tom,
 
> they do indeed need PW-level OAM.

NH=> You seem to have missed the point Tom.  This is nothing to do with *my*
need, I am merely pointing out the flaws in the architecture/thinking that
has led to this unnecessary state.....and the bad stuff is still
proliferating, eg your PW OAM stuff. Not sure where other trad operators are
at with this stuff, but I would be amazed if their CTO equivalents were not
thinking along the same lines as we are.  

regards, Neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 8 May 2003 16:39:47 -0400

T> I don't want to beat a dead horse. Just read back on the threads
regarding Y.1711 on the MPLS list. Also check the many comments/discussion
on Y.1711 at the ITU.  I think that the people that are interested and are
still listening know what I am referring to anyway.

T> I guess that is your opinion, and you are entitled to it. The fact is
that many of my and other vendor's customers use it, so we have two options:
a) throw away all of our gear and redesign everything, b) work with what we
have to solve the problems at hand.  

T>    Well, yes we do have implementations that people actually use. And
yes, our first implementations of LSP ping and VCCV are in fact merely IOS
upgrades. Follow-ons are also planned as IOS upgrades with possible hardware
accelleration. The point is that out of the gate, we don't need hardware to
implement this stuff for it to be useful.

WHy is it that you characterize a solution designed for ease of
implementation is such an onerous burden.  

T> There is nothing wrong with ease of implementation. The issue at hand is
that Y.1711 requires hardware accelleration to work at all on any reasonable
scale, especially if it were used as its authors originally intended -- on
all LSPs at 1 second intervals!

 This is   vendor specific implementation issues....  

    T> Yes, I realize that at the ITU implementation issues are not
considered, but this is the IETF which is concerned with them.

 noone has mandated continual replacement of line cards. 

T>    I guess it depends on how you characterize "ease of implementation".

   Sure the number of SPs I just mentioned includes a mere %95, but heck, we
should all obey architectural correctness because the Y.1711 folks said so
the first time, so we should believe them this time too.  So please stop
passing the FUD about Y.1711 being something that it is not because that is
indeed hysterical.

T> Yes, still wading through all of them. *)

    --Tom

---

From: [email-masked]
Date: Thu, 8 May 2003 21:59:16 +0100

Thanks Mustapha....excellent responses, you have clearly a good grip on this
stuff.

My remarks/answers are below....snipped as necessary.  regards, Neil

> attention.
NH=> Yes indeed.  Think about the large ATM networks trad operators have.
They need a next generation core.  ATM/MPLS interworking is pretty high on
the agenda here.  And it has nothing to do with PWs, let alone PW OAM stuff.

> Is a PW layer a regular MPLS layer or not.
NH=> No it can't be.  It sits above the MPLS layer in its own 'in-between'
layer world.  Also note this: 
Tom makes a big thing that Y.1711 is broken for LDP....its p2p, but so is PW
OAM.  But, because LDP mp2p uses merging based on a co pkt-sw forwarding
mode you *always* must have p2p LSPs above this to effect the demerging (ie
the p2p 'martini' LSPs for want of a better term).  So why not run Y.1711 on
these! Pretty obvious solution I think.  So even with the LDP mp2p stuff in
the X/MPLS case there is always the possiblility to use the simple Y.1711
stuff on the higher p2p LSPs.  And if these show a problem one can then
roll-out the heavy-weight 'Leatherman' LSP-Ping toolbox (bit bigger than a
swiss army knife!) at leisure to look at the mp2p layers *iff* any lower L1
layers don't show any problems.  So I see next to no justification at all
for the PW OAM stuff in the X/MPLS case.  As I also remarked, we are going
to have to manage the client/server layers anyway....so let's do it at least
as well as possible.

> layer,
NH=> It is not.

> the rest is not different from FR-ATM service interworking
NH=> Agreed.  Let's keep the layers to a min and do things right....at some
point we simply have to say 'we have had enough kludges thanks'.
> component is
NH=> Yes we are....its clear you understand....that make me feel far more
comfortable.
> identifier of the higher layer protocol, not of the OAM messages of
NH=> Thanks.  Let's make sure we avoid this kludge then.  Let's keep trying
to move things to a sound arch basis.

---

From: Chris Liljenstolpe <[email-masked]>
Date: Thu, 08 May 2003 17:24:02 -0400

There is an issue here that needs to be addressed, however.

If the PWE implimentation is

A---C---A where A is a PWE3 aware ATM switch, and C is an MPLS core, then 
native signaling (i.e. PNNI) will work (C looks just like a circuit). 
However, if the case is

A---B---C----D where B is an ATM core, and D is an MPLS MSE (running 
PWE3), then we have a problem in signaling and recovering from faults at 
the BC boundary.  This is a problem that will hinder MSE deployment at 
carriers with deployed classical networks that need to interoperate them 
with new model systems.

        Chris

- --It is whispered that on 2003-05-08 21:59 +0100, [email-masked] 
mumbled this regarding RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough 
Consesus?)

> Thanks Mustapha....excellent responses, you have clearly a good grip on
> this stuff.
>
> They need a next generation core.  ATM/MPLS interworking is pretty high
> on the agenda here.  And it has nothing to do with PWs, let alone PW OAM
> stuff.
>
> NH=> No it can't be.  It sits above the MPLS layer in its own
> 'in-between' layer world.  Also note this:
> Tom makes a big thing that Y.1711 is broken for LDP....its p2p, but so
> is PW OAM.  But, because LDP mp2p uses merging based on a co pkt-sw
> forwarding mode you *always* must have p2p LSPs above this to effect the
> demerging (ie the p2p 'martini' LSPs for want of a better term).  So why
> not run Y.1711 on these! Pretty obvious solution I think.  So even with
> the LDP mp2p stuff in the X/MPLS case there is always the possiblility
> to use the simple Y.1711 stuff on the higher p2p LSPs.  And if these
> show a problem one can then roll-out the heavy-weight 'Leatherman'
> LSP-Ping toolbox (bit bigger than a swiss army knife!) at leisure to
> look at the mp2p layers *iff* any lower L1 layers don't show any
> problems.  So I see next to no justification at all for the PW OAM stuff
> in the X/MPLS case.  As I also remarked, we are going to have to manage
> the client/server layers anyway....so let's do it at least as well as
> possible.
>
>
> NH=> Agreed.  Let's keep the layers to a min and do things right....at
> some point we simply have to say 'we have had enough kludges thanks'.
>>
>>
>> > > and we want them to
> NH=> Thanks.  Let's make sure we avoid this kludge then.  Let's keep
> trying to move things to a sound arch basis.
>

- --
Chris Liljenstolpe
GPG keys: http://www.io.com/~cds/cdl-keys.asc

---

From: "David Allan" <[email-masked]>
Date: Thu, 8 May 2003 17:33:16 -0400

D> Well the short history seems to be absurd idea, not needed, needed but
proposed is wrong, etc.etc......I'd assume we're in a different OAM epoch
than you are referring to ;-)

<snipped>

D> I love the way that continuing to sell the "same old" is positioned as
noble.....and anything but your preferred solution is "throwing away
everything and starting over"

D> And you believe this to be a unique attribute of your solutions...

D> Folks I talk to suggest adapting the I.610 ucode is not a big deal, you
may want to talk to folks down the hall. 

D> I'd characterize it a bit differently....I'm hardly a spokesperson but
IMHO the ITU is less concerned with the standardizing of and being bound by
existing implementations, this has it's good and bad points. If we believe
that existing implementations trump any advancement of MPLS, then it is time
to invent somthing new, which has more or less the exact same effect as the
ITU approach as far as provider investment to replace equipment is
concerned....

looking forward to your feedback ;-)

Dave

---

From: [email-masked]
Date: Thu, 8 May 2003 22:34:52 +0100

Mustapha/Peter, small remark below.  regards, Neil
<snipped>

> OAM is required since both FR and Ethernet are terminated locally.
NH=> I don't think so.  In case c. we have 3 peer trails:  FR, MPLS and
ethernet.  Each trail should run its own independent OAM.  Now whether
mixing network modes in a service interworking case is sensible (recall
there are the 3 network modes of cnls, co pkt-sw and co cct-sw) is
debatable....it depends on what applcations are running across these 3
partitions.  However, the key point is that in service interworking the OAM
of the 3 network trails are strictly independent since they are peers and
have no client/server relationships.

regards, Neil

---

From: [email-masked]
Date: Thu, 8 May 2003 22:34:54 +0100

Tom,
<snipped> 
 
> > messages of the layer below it.
NH=> Not quite right Mustapha.  You are right it should never indicate the
OAM of a layer *below* the one in question, but I was also trying to point
out it should also never indicate the *same* layer OAM, ie the PID field in
a given layer network indicates the *clinet* carried....the OAM of the layer
in question occurs functionally *below* this in the adpatation process, and
is an intrinsic property of the layer per se *irrespective* of the client it
carries.  Re-read what I wrote above carefully and think about a G.805
functional model of what is going on here.  If there are any G.805 experts
reading this then please chip-in and confirm my comments.
> protocol; thus, it is reasonable to indicate PW
NH=> You could do this kludge (not as bad as some) but it's not right for
the reasons I gave above.

regards, Neil

---

From: [email-masked]
Date: Thu, 8 May 2003 21:59:18 +0100

Shahram Davari wrote 08 May 2003 17:25
<snipped>
> available for carried services? I think service providers 
NH=> David...your company is coming to see us soon....we will give you
chapter/verse on our arch requirements then.  But if you have been
understanding what I have been saying on the lists you will be fore-armed.

regards, Neil

---

From: [email-masked]
Date: Thu, 8 May 2003 22:34:53 +0100

Hi Peter....please see below.

regards, Neil
<snipped>

> Case c) as you identify is a perfectly valid way to 
> interconnect Ethernet and Frame Relay endpoints over an MPLS 
> core network. However, this would require Service 
> Interworking between Ethernet and MPLS on the one hand and 
> Frame Relay and MPLS on the other.
> 
> Service Interworking is quite different from Network 
> Interworking as specified in PWE3. I don't think it requires 
> a "new" mechanism for OAM. I think it requires interworking 
> of Frame Relay OWM with MPLS OAM and of Ethernet OAM with 
> MPLS OAM. I also don't think it requires an MPLS PID.
> 
> In any case, I think we should not try to get commonality 
> between MPLS Network Interworking (i.e. PWE3) and MPLS 
> Service Interworking, without analyzing carefully what 
> exactly we are trying to do.
> 
> I am with Neil on this one: G.805 and a clear understanding 
> of what is the client layer and what is the service layer 
> will avoid a lot of problems.
> 
> Peter

NH=> Just saw this after I posted my response to Mustapha...I think we are
all in sync on this now.  regards, Neil

---

From: [email-masked]
Date: Fri, 9 May 2003 00:08:52 +0100

I think this is getting a little non technical now, so hopefully last
posting in this vein....please see in-line Tom.  regards, Neil
<snipped>

> name of architectural OAM purity.
NH=> Never said that AFAI recall.  But there is nothing wrong with trying to
do things right 1st time, and from bitter experience if you break the arch
rules for some near-term expediency then you usually get paid back in spades
in the long-run.

> Y.1711 clearly didn't
> it was peddled as the ultimate OAM solution.
NH=> Never said that either...and I have never held that view, at least the
way it seems you are trying to portray it.  Y.1711 was written (I know
because I did the original drafting) based on lessons learnt from previous
co pkt-sw technologies.  It is based on a concept which is now central to
our internally agreed net arch strategy (which we have called 'functional
convergence') that says we have/need 3 network modes (cnls, co pkt-sw and co
cct-sw) and we want to see functional convergence of technologies *within*
each mode but not across them.  This is quite logical/sensible in our view.
So I wrote Y.1711 with a view to it being a generic solution for *any* co
pkt-sw technology, not just MPLS....because we don't want to see functions
repeated in a variety of ways across a common mode (but this is more than
data-plane OAM).  The intention is to seek out/use best-of-breed functional
components and try to avoid stovepies and/or gateways in
data/control-planes.  Again, this would seem logical/sensible. 

Now, in any technology that uses link-connection identifiers for forwarding
the only architectural constructions that make sense (ie don't cause lots of
problems) are p2p and p2mp.  Further, if you create a mp2p construction you
have to run a p2p instance over this to demerge....its all about losing
sight of the source in the mp2p lower layer. 
 
I have *always* insisted therefore that mp2m is not a sensible topological
structure for a co pkt-sw forwarding mode....so the right answer is not to
keep fixing this but just accept it, live with it and ultimately find ways
to move away from it.  If any-any connectivity is required then use a cnls
mode like IP....and I have also been consistent on that view too.  Use the
right mode in the right way for the job required.
<snipped>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 9 May 2003 09:56:57 -0400

Chris,

I am not sure I fully understand your A-B-C-D model. Are you describing a situation where a protocol X is carried over ATM in A and B and carried over MPLS in C and D?

If so, then I believe that this is another example of service interworking and PWE3 does not apply. (Or, PWE3 could apply, but then the MPLS core would carry X-over-ATM instead of just X)

I was told that the IETF is not interested in standardizing service interworking. Is that correct?

Service interworking is an important element in the evolution towards a common MPLS core. AFAIK, both the MPLS Forum and the Metro Ethernet Forum started working on it.

Peter

> From: Chris Liljenstolpe [mailto:[email-masked]]
> Sent: Thursday, May 08, 2003 5:24 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (Darwin)
> 
> iD8DBQE+usr0HhGWzf9XZ/YRAsODAJ9X8aVv401aKbAfsZcsrdQR5ZXOYgCfbS3a
> y4FiSS7/maf5zIcC6Mgieu8=
> =r7DP
> -----END PGP SIGNATURE-----
>

---

From: "Himanshu Shah" <[email-masked]>
Date: Fri, 9 May 2003 10:36:59 -0400

Yep, we tried unsuccessfully for service interworking 
in PPVPN. Metro E and MPLS forum is now working on this.

However, I am hopeful that with PPVPN evolving
with new groups and 'mgmt', we can make a case
for importance of this subject again.

/himanshu
Wavesmith Networks

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: Friday, May 09, 2003 9:57 AM
> To: 'Chris Liljenstolpe'; [email-masked];
> [email-masked]
> Cc: [email-masked]
> I am not sure I fully understand your A-B-C-D model. Are you 
> describing a situation where a protocol X is carried over ATM 
> in A and B and carried over MPLS in C and D?
> 
> If so, then I believe that this is another example of service 
> interworking and PWE3 does not apply. (Or, PWE3 could apply, 
> but then the MPLS core would carry X-over-ATM instead of just X)
> 
> Service interworking is an important element in the evolution 
> towards a common MPLS core. AFAIK, both the MPLS Forum and 
> the Metro Ethernet Forum started working on it.
> 
> Peter
>

---

From: Mustapha Aissaoui <[email-masked]>
Date: Fri, 09 May 2003 10:39:02 -0400

Neil,

> reading this then please chip-in and confirm my comments.

I think my wording of it was incorrect. Indeed, the concept of PID indicates the
higher layer protocol carried in this layer's PDU. This layer's OAM should be
identifiable at this layer independently of any higher layer protocol running
over it.

---

From: Mustapha Aissaoui <[email-masked]>
Date: Fri, 09 May 2003 10:56:18 -0400

Chris,

> carriers with deployed classical networks that need to interoperate them

I believe we have two options here:
1. If D can terminate ATM over MPLS, one can model the full ABCD path as a VCC.
You can extend a PNNI SPVC towards D and you have got now a protected path. The
ATM Forum is finalizing the extended PNNI specification in order to achieve
that. Note here that only the MSE, not the core LSRs,  need to participate in
PNNI signaling and routing.

2. If D cannot terminate ATM over MPLS, or if one wants to use target LDP
signaling between C and D, then you have got to coordinate the operation and
failure recovery of the PNNI domain and the p2p LDP domain. This could be done
either through a management system, or through a signaling interworking
function.

All I can say is that option 1 is the most straightforward way to do it
currently, given the availability of the standards. Option 2 is an attractive
longer term solution. If there is enough interest, this could be done as a
joint work with the ATM Forum.

---

From: George Swallow <[email-masked]>
Date: Fri, 09 May 2003 11:23:12 -0400

> identifiable at this layer independently of any higher layer protocol running

Here's the model I have in mind.  It's exactly analogous to 

   SONET/SDH -> DCC -> NLPID

You have in the first Nibble an indication (0000 or 0001) of whether
this packet belongs to the data flow or the DCC.  If its part of the
DCC then you have a PID which indicates the protocol carried in the
DCC.

Then you get your IP packet (or whatever you indicate).  But it's a
channel associated with the PW and *nothing more*.  The DCC is bound
to the control entities at the ends of a PW.  It's there for those
control entites at each end of a PW to communicate.  

...George

---

From: Shahram Davari <[email-masked]>
Date: Fri, 9 May 2003 09:23:01 -0700

This is not like DCC at all. A DCC is part of every frame which carries
DCC traffic alongside user traffic inside the same frame. While your 
proposal cannot carry both user traffic and DCC traffic in a single
packet. In fact your proposed DCC has no rate associated with it
and can actually occupy the whole available user BW.

I would categorize it more as in-band OAM indicator. But to be an in-band OAM
indicator, this Nibble (or word) MUST be present after all bottom labels
including those that carry IP user traffic. Why? because or two reasons:

1) Consistency and compatibility. For example consider the case of spliced PWs that
Eric has raised. What happens if a SP uses this nibble/word and another one doesn't?
2) It is needed for IP payload (such as L3VPN) to test proper actual FEC to NHLFE mapping, which can't be done with LSP-ping, because LSP-ping does not get as close to the disposition point as the in-band OAM.

-Shahram

---

From: George Swallow <[email-masked]>
Date: Fri, 09 May 2003 12:46:16 -0400

> and can actually occupy the whole available user BW.

That just because of how you have to do the framing for SONET.

> including those that carry IP user traffic. Why? because or two reasons:

Don't really care what it gets called.  In fact I call it "in-band OAM
indicator".  I'm only saying that it is analogous to DCC

> 1) Consistency and compatibility. For example consider the case of
> spliced PWs that Eric has raised. What happens if a SP uses this
> nibble/word and another one doesn't?

Since you signal the use of this with each PW you don't have a
problem.  Just don't splice unlike things together.  Not that I think
splicing is a good idea.  Different SPs are going to want to be able
to certify whether their piece is working or not.  So I would
terminate the OAM at the edge.

> 2) It is needed for IP payload (such as L3VPN) to test proper actual
> FEC to NHLFE mapping, which can't be done with LSP-ping, because
> LSP-ping does not get as close to the disposition point as the in-band
> OAM.

LSP Ping goes further.  So what's the issue?

...George

---

From: [email-masked]
Date: Fri, 9 May 2003 19:03:58 +0100

I've passed this across to our SDH and functional modelling guys to formally
comment if they disagree with my remarks....but I don't see the
relevance/connection.  The DCC is a logically disjoint data-plane network
(from that carrying traffic) that carries management/control protocols for
SDH nodes....it has nothing to do with the traffic carrying data-plane(s) in
SDH [there are more than 1, per VC type of layer network].  The notion of a
PID here therefore means nothing to me in the context of my orginal
observations wrt to where a PID field sits (and it's role) within the
data-plane structure of a traffic carrying layer network wrt G.805.
Further, in a co cct-sw network like SDH there is never a PID in the
traffic's data-plane AFAIK....so the only valid context is in relation to a
co pkt-sw mode.

I therefore consider that my orginal observations, which elicited these
remarks, remain valid as stated.

regards, Neil

> Sent: 09 May 2003 17:46
> Cc: 'George Swallow'; Mustapha Aissaoui; Harrison,N,Neil,IKL2 R;
> [email-masked]; [email-masked]; [email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 9 May 2003 14:13:17 -0400

I still don't see why this matters. Call
the field what you wish or whatever layer you
want to cram it into, but from the OAM 
perspective, the PID is only a means by 
which end points can identify in-line OAM 
messages.

	--Tom

> Sent: Friday, May 09, 2003 2:04 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> I've passed this across to our SDH and functional modelling 
> guys to formally comment if they disagree with my 
> remarks....but I don't see the relevance/connection.  The DCC 
> is a logically disjoint data-plane network (from that 
> carrying traffic) that carries management/control protocols 
> for SDH nodes....it has nothing to do with the traffic 
> carrying data-plane(s) in SDH [there are more than 1, per VC 
> type of layer network].  The notion of a PID here therefore 
> means nothing to me in the context of my orginal observations 
> wrt to where a PID field sits (and it's role) within the 
> data-plane structure of a traffic carrying layer network wrt 
> G.805. Further, in a co cct-sw network like SDH there is 
> never a PID in the traffic's data-plane AFAIK....so the only 
> valid context is in relation to a co pkt-sw mode.
> 
> I therefore consider that my orginal observations, which 
> elicited these remarks, remain valid as stated.
> 
> regards, Neil
> 
> > > packet. In fact your proposed DCC has no rate associated 
> with it and 
> > > can actually occupy the whole available user BW.
> >

---

From: Shahram Davari <[email-masked]>
Date: Fri, 9 May 2003 12:26:28 -0700

If the protocol stack is:

PSN layer - Muxing layer - CW - Payload

Which layer will this OAM test?

-Shahram

>From: Thomas D. Nadeau [mailto:[email-masked]]
>Sent: Friday, May 09, 2003 2:13 PM
>To: [email-masked]; [email-masked]; Shahram Davari
>Cc: [email-masked]; [email-masked]

---

From: George Swallow <[email-masked]>
Date: Fri, 09 May 2003 16:56:50 -0400

Shahram -

> Which layer will this OAM test?

You're the one that wants the extra layer.

For L3VPNs the stack is:

PSN -> VPN Label -> User Packet or LSP Ping.

It tests at the user VPN level which is just what you want.

...George

---

From: David Zelig <[email-masked]>
Date: Sun, 11 May 2003 11:00:16 +0200

Mustapha,
Maybe I was not clear enough in what a customer is: from my point of view it
is the ATM entity that is connected through the PW. I am aware that for the
simple case you mention you can use a segment ATM OAM, but the PW is
applicable also for carrier of carriers scenarios, and even internally to an
organization, there is a need for a clear demarcation point. We should be
careful to define the PW transparent enough, where in transparency I mean
also minimum knowledge is required from the PW provider point of view on the
carried signal and the protocols that are used on top of it.

David

> Sent: Thursday, May 08, 2003 6:43 PM
> To: Shahram Davari
> Cc: 'David Zelig'; [email-masked]

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 12 May 2003 01:10:24 -0700

Shahram, Neil:

By going through this email thread regarding OAM for PW, I realized that 
there are several areas of contentions that need further 
exploration/clarification. So lets go over them in a bit more details and 
see where we stand.

We all advocate proper layering for PW OAM but we all have different views 
of what the proper layering should be. One view which I am hearing is that 
there should be a single OAM mechanism for the whole MPLS (both LSP tunnel 
and PW) and some people think that PW is an artificial layer that shouldn't 
have its own OAM. Another view is that PW OAM can be handled by the service 
layer (e.g., either segment ATM or segment Ethernet or segment Foo) and 
thus there is no need for the PW to have its own OAM. Lets look at them a 
bit more closely.

First, I think each layer and sub-layer of transport need their own OAM 
mechanism since they operate independently and the each have different 
termination points (e.g., I.610 - OAM principles for B-ISDN). So if I have 
IP over ATM over SONET, there needs to be a OAM for each of these layers 
and one layer's OAM should not be used to replace another.

Second if there are sub-layers within a transport layer, then these 
sub-layers also need their own OAM because again they can have different 
termination/disposition points. One example that we are all familiar with 
is ATM where VC and VP have their own end-to-end and segment OAM and one 
sub-layer OAM doesn't replace the other. So one can consider an MPLS PW 
analogous to an ATM VC and an MPLS LSP tunnel analogous to an ATM VP and 
thus similar to ATM each have their own OAM mechanism because each of these 
transport sub-layers have different termination/disposition points.

Third, using a service layer OAM to replace/compensate for a transport 
sub-layer OAM is not the right approach for several reasons:
A) In ATM network, when you transport FR between two end points over an 
ATM, you don't use FR OAM in the ATM network to detect/isolate fault but 
instead you relay on  ATM OAM and as the matter of fact FR PVC status 
relies on the ATM PVC (FRF.5).
B) Service layer OAM doesn't give you the right info. For example in a VPLS 
service, Ethernet OAM ping can span several PWs. Also again for proper 
layering, Ethernet OAM should be independent from MPLS layer OAM.
C) There are cases that the service layer doesn't have an OAM mechanism 
associated with it - e.g., in case of a transport of routed packets over a 
PW without L2 layer (refer to draft-sajassi-l2vpn-interworking for 
different interworking scenarios).

There are other reasons of why it is better for PW to have their own OAM 
mechanism such as the use of common mechanism for interworking between 
disparate interfaces but there is no need to get into the details right now 
since the above reasons should be sufficient.

So at the end, I think we need to have a mechanism for PW OAM and VCCV as 
Tom has described it provides such mechanism.

-Ali

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 May 2003 02:19:02 -0700

I was asking about PW or L2VPN.

-Shahram

>Sent: Friday, May 09, 2003 4:57 PM
>To: Shahram Davari
>Cc: [email-masked]'; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 May 2003 03:11:15 -0700

Ali,

I think you are confusing 2 different points:

1) Each layer's OAM only tests that layer's connectivity. 
2) In X over Y layer, in which X is the customer traffic
and Y is the service provider tunnel, customer should have
its X OAM, and service provider should have its Y OAM. But
the service provider cannot test whether his X/Y mapping
is done correctly or not without doing segment X OAM. This
is required for if provider wants to detect a mapping fault
before customer complaints.

Now regarding PW, we can test both PSN label and PW label
using MPLS OAM. Customer can also test its connection (let's
say ATM VC) using ATM OAM. But the only way that provider
can check the correct mapping between customer ATM VC to
PW label, is by running segment ATM OAM between PEs. VCCV
does not help you for doing so.

Now please tell me what VCCV can do that the OAMs I described above
can't do better. 

-Shahram

>From: Ali Sajassi [mailto:[email-masked]]
>Sent: Monday, May 12, 2003 4:10 AM
>To: Shahram Davari; [email-masked]'; 'Mustapha Aissaoui'; 'David
>Allan'

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 12 May 2003 09:21:46 -0700

>1) Each layer's OAM only tests that layer's connectivity.

Good, at least we agree that much :-)

>before customer complaints.

Lets make sure we are talking about the same segment and that is the 
segment between two PEs. There is a one-to-one relationship between PW and 
attachment circuit in VPWS and PW status can be mapped into AC segment OAM. 
When, you transport FR over ATM (FRF.5) this is how it is done and ATM PVC 
status is used (I am not aware of any special FR OAM segment running 
between the two PEs). Now how is it different for MPLS PW ? Maybe you want 
to tell me what is done in FRF.5 that cannot be done for FR over MPLS.

>does not help you for doing so.

How do you check the mapping between FR VC and ATM VC when you have FRF.5 ?
How do you check the mapping between an ATM physical port and a PW when the 
service is port based ?

>Now please tell me what VCCV can do that the OAMs I described above

As I said before VCCV for MPLS PW is analogous to ATM VC OAM and LSP OAM is 
analogous to ATM VP OAM. Now tell me, do you think we only need LSP tunnel 
OAM and not PW OAM.

-Ali

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 May 2003 09:41:31 -0700

Ali,

>Good, at least we agree that much :-)

Good.

>attachment circuit in VPWS and PW status can be mapped into AC 

Correct. 

>to tell me what is done in FRF.5 that cannot be done for FR over MPLS.

FR does not have proper OAM. So we shouldn't base MPLS on deficiencies of
FR.

>How do you check the mapping between FR VC and ATM VC when you 

You can't. FR has poor OAM. 

>How do you check the mapping between an ATM physical port and 

You can use ILM instead.

>analogous to ATM VP OAM. Now tell me, do you think we only 

I didn't say we only need LSP tunnel OAM. I said we can have both
LSP tunnel OAM and PW label OAM using LSP-ping or anything else.
LSP-ping for the PW label is analogous to ATM VP OAM. And if you needed
deeper test you could use ATM segment OAM to test
even the mapping of VCs to PW.
No you tell me what problems you can detect with VCCV that you can't
detect with LSP-ping over the PW label?

-Shahram

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 12 May 2003 10:29:32 -0700

>FR does not have proper OAM. So we shouldn't base MPLS on deficiencies of

Oh, let me see. If I need to transport FR, Ethernet, PPP, or HDLC over 
MPLS, based on your suggestion of using ATM segment OAM , then I am out of 
luck since none of these L2 services have segment OAM. I hope you're not 
suggesting to put them over ATM and then over MPLS :-)

My point in here is that if operators and providers see a problem here, 
then it should be addressed for the whole space and not just for couple of 
special cases. Besides, operators have been offering FR over ATM for years 
and years and if there are any issues with the mapping, they can shed some 
light here.

>You can't. FR has poor OAM.

It is not just FR. As I mentioned before, how about Ethernet, HDLC, and PPP 
and even port-based mode of ATM ?

> >How do you check the mapping between an ATM physical port and

Nice try :-) you cannot use ILMI to do it properly !

>LSP tunnel OAM and PW label OAM using LSP-ping or anything else.

VCCV is not rocket science. It is an extension to LSP ping and it can be 
merged with it. So I guess we agree that we need to test both LSP tunnel 
and PWs and a mechanism need to exist to provide such test, right ?

>even the mapping of VCs to PW.

No, that's the right way for several reasons:
1) In case of ATM network, you don't say that we only need ATM VP OAM and 
to do a deeper test, we need use "X" segment to do it.
2) What about non-ATM scenarios ?
3) What about port-based ATM scenario ?

I am not going to say that you're confused here :-) but there are two 
separate topics here: a) sub-layer OAM for MPLS PW and b) AC to PW mapping 
verification.

>detect with LSP-ping over the PW label?

As I said VCCV is an extension to LSP-ping. So maybe we agree that we need 
an OAM mechanism for both LSP tunnel and PW. Now if you don't like the name 
VCCV, maybe we call it "LSP ping plus" :-)

-Ali

---

From: [email-masked]
Date: Tue, 13 May 2003 12:07:36 +0100

Ali,  please see in-line....note my mail access is limited so I may not be
able to quickly respond further.  regards, Neil

Ali Sajassi wrote 12 May 2003 09:10
 
> have its own OAM.
NH=> Spot on....ask yourself this question....is a PW a networked (ie
switched entity)? If the answer is no (and this is indeed the case) then it
lives between proper layer networks X and Y in a client/server
relationship...in G.805 sense it is part of some client->server adaptation
process as some form of encaps function.  Adapation requires to have minimal
functionality.....the less to manage and specify (and go wrong) the better.
Note however, that when we are considering *service* interworking then the X
and Y trails terminate at the IWF and a PW entity has no need to exist at
all.....in fact it better not.  So if I am considering something like
ATM/MPLS service interworking then I don't want to see any PW notion at
all...it makes no sense.  And of course, such service interworking ought to
be a key consideraion for most major operators for the reasons of functional
convergence across like-mode technologies (eg the resulting capex/opex
savings) as I have noted in previous mails......which is why FR/ATM service
interworking was previously also an important requirement.

> by the service 
NH=> Correct.....but note this is specifically *network* interworking case,
where we have simple client/server layer relationships.  There are no PWs
here please note.
> sub-layer OAM doesn't replace the other.
NH=>In ATM the VP layer network and the VC layer network are truly disjoint
wrt access points, ie can't connect a VP access point to a VC access point.

) So one can consider 
> an MPLS PW 
NH=> You might *like* to make this analogy, but its not correct.  The LSP is
a proper layer networked entity, but the PW is *not* a networked
entity.....its an artifical 'in-between' layer construct and the reasons it
exists are as I have pointed to out in previous mails.
> different interworking scenarios).
NH=> If one constructs the G.805 diagrams than all the above become clear
wrt to what is/is-not required.
> Tom has described it provides such mechanism.
NH=> Try modelling FR/MPLS/ATM *service* interworking, you will very quickly
discover the PW does not exist.

---

From: Mustapha Aissaoui <[email-masked]>
Date: Tue, 13 May 2003 15:03:51 -0400

David,
you are right, according to I.610, OAM segments on a given VCC should not
overlap. Furthermore, I.610 states that once a segment is configured on a VCC,
all segment OAM cells received from outside of this segment should be discarded
at the source/sink of the configured segment.

Thus, if the carrier offering the PW service activates a segment OAM between the
PW endpoints, the segment OAM flow received from his customer will be discarded
until he deactivates it. In any case, these issues are agreed upon on a
bilateral agreement basis, and normally OAM cells are not just passed through a
inter-carrier network interface.

Regards,
Mustapha.
---------------

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 18 May 2003 09:22:05 +0300

> Oh, let me see. If I need to transport FR, Ethernet, PPP, or 
> HDLC over MPLS, based on your suggestion of using ATM segment OAM , 
> then I am out of luck since none of these L2 services have segment OAM. I hope 
> you're not suggesting to put them over ATM and then over MPLS :-)
> 
> My point in here is that if operators and providers see a 
> problem here, then it should be addressed for the whole space and not just 
> for couple of special cases. Besides, operators have been offering FR over 
> ATM for years and years and if there are any issues with the mapping, they 
> can shed some light here.

While addressing OAM issues "for the whole space" is a valid concern, 
it is unfortunately not relevant for the PWE WG.

PWs are by definition native service tunnelings,
and hence service interworking is considered out-of-scope in PWE3.

So any feature not provided by the native service SHOULD NOT 
be provided by the PW emulation of that service, and any borrowing
of techniques from one service to use on another should be outlawed.

The proper PW method of providing a service's functionality is
to use an IWF before each edge (which would be considered an NSP
in PWE terms) to convert to the service with the desired functionality.

If and when we start directly addressing service interworking issues,
this question may be addressed in a more general way.

Y(J)S