Subject: draft-bryant-mcpherson-pwe3-cw-00.txt WG request

From: Stewart Bryant <[email-masked]>
Date: Mon, 09 Aug 2004 12:54:04 +0100

The authors request that 

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt

be adopted as a WG item with its title changed to

PWE3 MPLS Control Word 

- Stewart

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 9 Aug 2004 15:12:54 +0200

I support this.

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

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, August 09, 2004 1:54 PM
> To: [email-masked]
> Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request
> 
> 
> The authors request that 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 9 Aug 2004 17:55:46 -0400

Stewart,

I agree that we need a WG document that defines how Control Words must be used.  I do have concerns about the proposed solution, though:

1) The document proposes a solution to the hypothetical situation in which a PW Control Word could be mistaken for an IP packet. However, as far as I can tell, all encapsulation drafts define a CW that starts with 0000.

2) The document introduces a Payload Type identifier. Why? In the past, Mustapha Aissaoui and Dave Allan submitted drafts that argued that there was a need for a Payload Type Identifier. However, I don't think we ever accepted the underlying rationale. E.g. Mustapha's point was that a PTI was required for Service Interworking, but recent work in Service Interworking in the MPLS Forum has resulted in solutions that don't require a PTI.

The general PWE architecture does not require a PTI. The PW Type is established as part of PW set up. Therefore, carrying a PW Type in the PTI only complicates matters. If the type established during PW setup is not the same as the type carried in the PTI, what should a PE do?

3) The only application that really needs a new CW is VCCV. Ironically, VCCV is not covered by the draft, as VCCV is not one of the PW Types mentioned in the IANA registry. If VCCV is indeed the only application that requires a new CW, would it not make more sense to use the MPLS Preferred CW with 0001 instead of 0000, rather than introducing the PTI?

Peter  

> Sent: Monday, August 09, 2004 7:54 AM
> To: [email-masked]

---

From: [email-masked]
Date: Tue, 10 Aug 2004 07:15:18 +0100

Peter...

> Stewart,
> 
> I agree that we need a WG document that defines how Control 
> Words must be used.  I do have concerns about the proposed 
> solution, though:
> 
> 1) The document proposes a solution to the hypothetical 
> situation in which a PW Control Word could be mistaken for an 
> IP packet. However, as far as I can tell, all encapsulation 
> drafts define a CW that starts with 0000.
NH=> Yes, I have noticed that.  I have also noted that:
-	adaptation between different client/server modal pairs is not
identical either....so a common CW is not a good thing anyway.
-	the default client/server relationship must be layer
independence....one consequence of which is client transparency.
....these obviously true requirements seem to fall on deaf ears though.
> 
> 2) The document introduces a Payload Type identifier. Why? In 
> the past, Mustapha Aissaoui and Dave Allan submitted drafts 
> that argued that there was a need for a Payload Type 
> Identifier. However, I don't think we ever accepted the 
> underlying rationale. E.g. Mustapha's point was that a PTI 
> was required for Service Interworking, but recent work in 
> Service Interworking in the MPLS Forum has resulted in 
> solutions that don't require a PTI.
> 
> The general PWE architecture does not require a PTI. The PW 
> Type is established as part of PW set up. Therefore, carrying 
> a PW Type in the PTI only complicates matters. If the type 
> established during PW setup is not the same as the type 
> carried in the PTI, what should a PE do?
NH=> I would but agree with you but for one point:
....the need to add OAM (which BTW must be inserted/extracted at the
trail termination points of the LSP, not the PW) was drop-off in MPLS
protocol design, and a PTI seems a good way to 'recover' from this
design error.
> 
> 3) The only application that really needs a new CW is VCCV.
NH=> Not IMO.  VCCV seems an amalgam of several things.  Having a simple
way to differentiate traffic and OAM payloads on the other hand is not
mixed of purpose, and is the correct way to sort this issue.

> Ironically, VCCV is not covered by the draft, as VCCV is not 
> one of the PW Types mentioned in the IANA registry. If VCCV 
> is indeed the only application that requires a new CW, would 
> it not make more sense to use the MPLS Preferred CW with 0001 
> instead of 0000, rather than introducing the PTI?
NH=> The only thing that really matters here (I ignore fixing the other
problems of MPLS for now, but these too need addressing) is to
differentiate traffic (whatever that might be) from OAM as the (MPLS)
payload.  This has nothing to do with PWs (at least regarding the view
(which is not right IMO) of treating XoverMPLS = XoverIP).....the OAM
needs to be at the LSP level and clinet agnostic.  This is so obvious I
find it very puzzling why there is so much reluctance to get it right.

Folks......this is not hard to sort, but for some reason it is being
made so.  I really don't know why folks don't bite the bullet and
propertly sort out MPLS and stop this silly charade that IP==MPLS and
therefore we must have identical treatment (it isn't like that and this
is kidding no one).  This is especially true given MPLS (not PWs!) is
important to most operators wrt to their convergence plans.  Is this WG
ever going to do the right thing I wonder?

Regards, Neil

---

From: Mustapha Aissaoui <[email-masked]>
Date: Tue, 10 Aug 2004 17:30:57 -0400

Stewart,
I support making this draft a WG document.

One issue I raised in the meeting was the use of the PTI for control
versus its use for data plane payload identification. As Peter said,
all the existing PWE3 encapsulations make use of some sort of 32-bit
word (in some cases it is actually the Generic or Preferred CW)
starting with an all zero nibble. Thus, there is no need to indicate
the PW type with a PTI. I think we should encourage future PW
applications to do the same. 

The other application we have is to carry PW OAM messages such as
VCCV-ping and VCCV-BFD. Both of these are actually IP control
messages (UDP to be more specific). However, we should have the
flexibility to carry non-IP control messages. Example of these are
Y.1711 OAM messages and future BFD messages that are control plane
independent. This is where the PTI is useful.

Finally, I proposed the use of the PTI for user protocol payload
identification in draft-aissaoui-extended-pid-01.txt (expired now).
This is useful if one is going to carry multiple user protocols
under the same PW label. As Peter pointed out, it looks like the
type of interworking we are dealing with at this point in time does
not require it. Though, the PTI concept can be extended as required
in the future.

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

---

From: "Florin Balus" <[email-masked]>
Date: Wed, 11 Aug 2004 14:17:16 -0400

Stewart,

We did promote the idea of a PID/PTI - see Dave Allan's
draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of
ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed
solution are valid.

I just wanted to clarify some technicalities to make sure we clearly
identify where we are headed to - i.e. what changes are required in other
PWE3 drafts.

Assuming we have in the same network PEs that support both formats: 
 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA
PPP_DLL)(OAM payload))] 
 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). 
In the same time let's assume other PEs will accept just the PTI - being
part of those implementations that do not support 0000. How are we going to
ensure the 2 sets of PEs will be able to negotiate in the control plane the
right format?
 
Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just
one bit to determine whether or not the CW should be used - see
draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001
implicitly meant up to now VCCV format. How do we differentiate the other 2
possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there are some PW types for
which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode
- see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will
implement the PTI format are we saying the PW frames (after the 2 labels)
will look like this: (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same way, just re-using what
is already defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM payload)? If not I
assume we will need to clarify the PTI code points that are going to be used
for VCCV/OAM payload? 

Thanks for clarifying the above points.
Regards,
Florin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: Monday, August 09, 2004 7:54 AM
To: [email-masked]
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

The authors request that 

PWE3 MPLS Control Word 

- Stewart

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 11 Aug 2004 14:41:28 -0400

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. I don't recall what rationale it gave for the need for a PTI.
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI.
 
Peter 

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Stewart, 

We did promote the idea of a PID/PTI - see Dave Allan's draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall proposed solution are valid.

I just wanted to clarify some technicalities to make sure we clearly identify where we are headed to - i.e. what changes are required in other PWE3 drafts.

Assuming we have in the same network PEs that support both formats: 
 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA PPP_DLL)(OAM payload))] 
 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). 
In the same time let's assume other PEs will accept just the PTI - being part of those implementations that do not support 0000. How are we going to ensure the 2 sets of PEs will be able to negotiate in the control plane the right format?

Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID) just one bit to determine whether or not the CW should be used - see draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001 implicitly meant up to now VCCV format. How do we differentiate the other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there are some PW types for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a PE that will implement the PTI format are we saying the PW frames (after the 2 labels) will look like this: (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same way, just re-using what is already defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM payload)? If not I assume we will need to clarify the PTI code points that are going to be used for VCCV/OAM payload? 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Stewart Bryant 
Sent: Monday, August 09, 2004 7:54 AM 
To: [email-masked] 
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request 

The authors request that 

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt <http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt>  

PWE3 MPLS Control Word 

- Stewart 

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

---

From: [email-masked]
Date: Wed, 11 Aug 2004 22:08:08 +0100

Peter, I always regarded this as a good way to differentiate traffic
from OAM (though the right/ideal solution would have had this designed
into the 'normal' header).  regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Busschbach, Peter B (Peter)
Sent: 11 August 2004 19:41
To: 'Florin Balus'; Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. I don't recall
what rationale it gave for the need for a PTI.
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason
for an additional control word. However, introducing PTI to solve the
issues related to ECMP seems overkill. It would be good if we can
clearly state why we need a PTI.
 
Peter 

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Stewart, 

We did promote the idea of a PID/PTI - see Dave Allan's
draft-allan-mpls-pid-00.txt on the subject. Also I think the explanation
of ECMP issue (disambiguate from IP/MPLS packets etc) and the overall
proposed solution are valid.

I just wanted to clarify some technicalities to make sure we clearly
identify where we are headed to - i.e. what changes are required in
other PWE3 drafts.

Assuming we have in the same network PEs that support both formats: 
 - the CW [(0000 CW stuff)(data) & the current VCCV format (0001 PA
PPP_DLL)(OAM payload))] 
 - and the newly defined PTI (0001 PTI)(data/VCCV payload/?whatever?). 
In the same time let's assume other PEs will accept just the PTI - being
part of those implementations that do not support 0000. How are we going
to ensure the 2 sets of PEs will be able to negotiate in the control
plane the right format?

Currently we do have in each of the 2 L2 FECs (PWID and Generalized ID)
just one bit to determine whether or not the CW should be used - see
draft-ietf-pwe3-control-protocol-07.txt section 5.1 and 5.2.2. 0001
implicitly meant up to now VCCV format. How do we differentiate the
other 2 possibilities (PTI yes/no)?

Also just to make sure I understood correctly: there are some PW types
for which the CW is REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5 SDU
Frame Mode - see draft-ietf-pwe3-atm-encap-05.txt section 4.3.2). For a
PE that will implement the PTI format are we saying the PW frames (after
the 2 labels) will look like this: (0001  PTI)(0000 CW stuff)(data)?

Is VCCV/OAM going to be differentiated in the same way, just re-using
what is already defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM payload)?
If not I assume we will need to clarify the PTI code points that are
going to be used for VCCV/OAM payload? 

-----Original Message----- 

The authors request that 

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.tx
t 

PWE3 MPLS Control Word 

- Stewart

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 11 Aug 2004 17:13:36 -0400

"though the right/ideal solution would have had this designed into the 'normal' header"
 
If you consider the Control Word to be the normal header, we can still do that. At one point, the plan was to use a CW starting with 0000 for  traffic and a CW starting with 0001 for OAM. It is still not clear to me why we moved away from that plan.

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 5:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Peter, I always regarded this as a good way to differentiate traffic from OAM (though the right/ideal solution would have had this designed into the 'normal' header).  regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Busschbach, Peter B (Peter)
Sent: 11 August 2004 19:41
To: 'Florin Balus'; Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,

 
Peter 

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Stewart, 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Stewart Bryant 
Sent: Monday, August 09, 2004 7:54 AM 
To: [email-masked] 
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request 

The authors request that 

PWE3 MPLS Control Word 

- Stewart

---

From: [email-masked]
Date: Wed, 11 Aug 2004 22:28:44 +0100

No, its not the normal header.  The normal header (of MPLS) is the shim
header........the CW is (was?) some (optional) adaptation function above
that....now bizarrely taking on a life of its own as a layer network.
 
regards Neil
-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
Sent: 11 August 2004 22:14
To: Harrison,N,Neil,IKR2 R
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

"though the right/ideal solution would have had this designed into the
'normal' header"
 
If you consider the Control Word to be the normal header, we can still
do that. At one point, the plan was to use a CW starting with 0000 for
traffic and a CW starting with 0001 for OAM. It is still not clear to me
why we moved away from that plan.

-----Original Message-----

Florus,

 
Peter 

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Stewart, 

-----Original Message----- 

The authors request that 

PWE3 MPLS Control Word 

- Stewart

---

From: "Florin Balus" <[email-masked]>
Date: Thu, 12 Aug 2004 12:42:14 -0400

Peter,
See in-line...
 
Stewart,
There might be another motivator for a mandatory CW/consolidation under PTI:
assuming we have a PW type that does not mandate a CW (ATM N to one cell
mode) couldn't we get payloads that are mistaken also for 0001/VCCV packets
- e.g. VPI 64 in an ATM cell could be interpreted by the receiving PE as
0001? (thanks Jeff for bringing this up)
 
Regards,
Florin

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2004 2:41 PM
To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,
 
Draft-allan-mpls-pid-00.txt  is not accessible anymore. I don't recall what
rationale it gave for the need for a PTI.

FB: Dave addressed the need for an MPLS PID one year ago from an overall
MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles or
ECMP in LDP network,  OAM extensibility, Multiprotocol over MPLS...
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for
an additional control word. However, introducing PTI to solve the issues
related to ECMP seems overkill. It would be good if we can clearly state why
we need a PTI.
FB I agree with you that the justification in section 4 for PTI versus CW +
VCCV could be improved. On the other hand we need the extensibility provided
by a PTI/PID:  VCCV is just an instantiation of a PTI if you think about it,
just the formats need to be aligned. 
Whether or not is a good idea to move the PW user data to 0001 format is to
be debated. We need to make sure though the 2 formats could coexist in a
network in the mean time.
 
Peter 

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Stewart, 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Stewart Bryant 
Sent: Monday, August 09, 2004 7:54 AM 
To: [email-masked] 
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request 

The authors request that 

http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt
<http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt>

PWE3 MPLS Control Word 

- Stewart 

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

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 12 Aug 2004 13:29:56 -0400

Florin,
I think the intent is that if you want to use the VCCV CW (0001
nibble) on OAM packets, then you are required to use the regular CW
(000 nibble) on the user packets. Otherwise, you will have to use
the alert label option for OAM packets but this may not work with
ECMP.

Mustapha.
------------
> Florin Balus wrote:
> 
> Peter,
> See in-line...
> 
> Stewart,
> There might be another motivator for a mandatory CW/consolidation
> under PTI: assuming we have a PW type that does not mandate a
> CW (ATM N to one cell mode) couldn't we get payloads that are
> mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell
> could be interpreted by the receiving PE as 0001? (thanks Jeff for
> bringing this up)
> 
> Regards,
> Florin
> 
>      Subject: RE: [PWE3]
>      draft-bryant-mcpherson-pwe3-cw-00.txt WG request
> 
>      Florus,
> 
>      Draft-allan-mpls-pid-00.txt  is not accessible anymore.
>      I don't recall what rationale it gave for the need for a
>      PTI.
>      FB: Dave addressed the need for an MPLS PID one year ago
>      from an overall MPLS perspective: e.g. issues arisen
>      from loadsharing on TE link bundles or ECMP in LDP
>      network,  OAM extensibility, Multiprotocol over MPLS...
> 
>      Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as
>      the sole reason for an additional control word. However,
>      introducing PTI to solve the issues related to ECMP
>      seems overkill. It would be good if we can clearly state
>      why we need a PTI.
>      FB I agree with you that the justification in section 4
>      for PTI versus CW + VCCV could be improved. On the other
>      hand we need the extensibility provided by a PTI/PID:
>      VCCV is just an instantiation of a PTI if you think
>      about it, just the formats need to be aligned.
>      Whether or not is a good idea to move the PW user data
>      to 0001 format is to be debated. We need to make sure
>      though the 2 formats could coexist in a network in the
>      mean time.
> 
>      Peter
> 
>           Subject: RE: [PWE3]
>           draft-bryant-mcpherson-pwe3-cw-00.txt WG
>           request
> 
>           Stewart,
> 
>           We did promote the idea of a PID/PTI - see
>           Dave Allan's draft-allan-mpls-pid-00.txt on
>           the subject. Also I think the explanation of
>           ECMP issue (disambiguate from IP/MPLS packets
>           etc) and the overall proposed solution are
>           valid.
> 
>           I just wanted to clarify some technicalities
>           to make sure we clearly identify where we are
>           headed to - i.e. what changes are required in
>           other PWE3 drafts.
> 
>            - the CW [(0000 CW stuff)(data) & the current
>           VCCV format (0001 PA PPP_DLL)(OAM payload))]
>           In the same time let's assume other PEs will
>           accept just the PTI - being part of those
>           implementations that do not support 0000. How
>           are we going to ensure the 2 sets of PEs will
>           be able to negotiate in the control plane the
>           right format?
> 
>           Currently we do have in each of the 2 L2 FECs
>           (PWID and Generalized ID) just one bit to
>           determine whether or not the CW should be used
>           - see draft-ietf-pwe3-control-protocol-07.txt
>           section 5.1 and 5.2.2. 0001 implicitly meant
>           up to now VCCV format. How do we differentiate
>           the other 2 possibilities (PTI yes/no)?
> 
>           Also just to make sure I understood correctly:
>           there are some PW types for which the CW is
>           REQUIRED (e.g. ATM N to 1 Cell Mode and AAL5
>           SDU Frame Mode - see
>           draft-ietf-pwe3-atm-encap-05.txt section
>           4.3.2). For a PE that will implement the PTI
>           format are we saying the PW frames (after the
>           2 labels) will look like this: (0001
>           PTI)(0000 CW stuff)(data)?
> 
>           Is VCCV/OAM going to be differentiated in the
>           same way, just re-using what is already
>           defined: i.e. (0001  PTI)(0001 PA PPP_DLL)(OAM
>           payload)? If not I assume we will need to
>           clarify the PTI code points that are going to
>           be used for VCCV/OAM payload?
> 
>           From: [email-masked]
>           [mailto:[email-masked]] On Behalf Of
>           Stewart Bryant
>           Subject: [PWE3]
>           draft-bryant-mcpherson-pwe3-cw-00.txt WG
>           request
> 
>           The authors request that
> 
>    ------------------------------------------------------------

---

From: "Florin Balus" <[email-masked]>
Date: Thu, 12 Aug 2004 13:42:16 -0400

Right. I was just saying that could be added to
draft-bryant-mcpherson-pwe3-cw-00.txt as another motivator.

-----Original Message-----
From: Mustapha Aissaoui [mailto:[email-masked]] 
Sent: Thursday, August 12, 2004 1:30 PM
To: Balus, Florin [CAR:6955:EXCH]
Cc: Busschbach, Peter B (Peter); Stewart Bryant; [email-masked]; Sugimoto,
Jeffrey [CAR:6955:EXCH]
Subject: Re: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florin,
I think the intent is that if you want to use the VCCV CW (0001
nibble) on OAM packets, then you are required to use the regular CW (000
nibble) on the user packets. Otherwise, you will have to use the alert label
option for OAM packets but this may not work with ECMP.

Mustapha.
------------
> under PTI: assuming we have a PW type that does not mandate a CW (ATM 
> N to one cell mode) couldn't we get payloads that are mistaken also 
> for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be 
> interpreted by the receiving PE as 0001? (thanks Jeff for bringing 
> this up)
> 
> Regards,
> Florin
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 13 Aug 2004 15:16:11 -0400

Florin,
 
You write: "On the other hand we need the extensibility provided by a PTI/PID:  VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned".
 
I agree that VCCV is one instantiation of a protocol that could be carried over a PW. However, the point I raised in an earlier email is whether there are other instantiations. Because, if VCCV is the *only* instantation, you don't need a PID, but just a way to differentate VCCV traffic from the PW payload traffic.
 
That said, this email thread has made a few things clear:
 
1) As Mustapha observed, even if you don't need to identify the PW payload traffic, you might still need to differentiate between different types of OAM traffic
 
2) As you observed, if you run VCCV traffic over a Pseudo Wire, then a Control Word , be it CW or PTI, must necessarily preceed all payload and OAM traffic.
 
3)  draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical considerations result in a PW Control Word that could be mistaken for an IP packet, the Control Word SHOULD be preceded by a PWE3 PTI." However, as we all seem to agree on, a CW will never be mistaken for an IP packet.
 
Therefore, rather than proposing a PTI that preceded a CW, I think the following solution would be sufficient and more elegant:
 
If the PW does not carry VCCV traffic, a CW is only mandatory if specified in the relevant encapsulation draft
 
If the PW carries VCCV traffic, then:
 
a) all payload traffic MUST be preceded by a Control Word that starts with 0000
 
b) all VCCV traffic MUSTbe preceded by an "OAM Protocol Identifier" (OPI), which has the following format:
 
    [0001 | resv | protocol id],
 
where protocol id identifies one of the following protocols: LSP Ping, ICMP, BFD, Y.1711, other(?).
 
Peter

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Thursday, August 12, 2004 12:42 PM
To: Busschbach, Peter B (Peter); Stewart Bryant
Cc: [email-masked]; Jeffrey Sugimoto
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Peter,
See in-line...
 
Stewart,
There might be another motivator for a mandatory CW/consolidation under PTI: assuming we have a PW type that does not mandate a CW (ATM N to one cell mode) couldn't we get payloads that are mistaken also for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could be interpreted by the receiving PE as 0001? (thanks Jeff for bringing this up)
 
Regards,
Florin

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2004 2:41 PM
To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,

FB: Dave addressed the need for an MPLS PID one year ago from an overall MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles or ECMP in LDP network,  OAM extensibility, Multiprotocol over MPLS...
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason for an additional control word. However, introducing PTI to solve the issues related to ECMP seems overkill. It would be good if we can clearly state why we need a PTI.
FB I agree with you that the justification in section 4 for PTI versus CW + VCCV could be improved. On the other hand we need the extensibility provided by a PTI/PID:  VCCV is just an instantiation of a PTI if you think about it, just the formats need to be aligned. 
Whether or not is a good idea to move the PW user data to 0001 format is to be debated. We need to make sure though the 2 formats could coexist in a network in the mean time.
 
Peter 

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Stewart, 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Stewart Bryant 
Sent: Monday, August 09, 2004 7:54 AM 
To: [email-masked] 
Subject: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request 

The authors request that 

PWE3 MPLS Control Word 

- Stewart

---

From: [email-masked]
Date: Mon, 16 Aug 2004 11:05:19 +0100

Peter,
 
The point made by Mustapha is conceptually right but should be stated
like this:  "In a layer network the traffic and OAM must be able to be
differentiated."
 
So this ought to be a design consideration for the layer network
technology right from the outset.  But please also note that the nature
of the data-plane behaviour (including the defects it can experience) is
different in each of the 3 networking modes.   
 
The OAM required for IP is therefore not the same as the OAM required
for MPLS....and neither is the same as the OAM required for SDH (as an
example of a co-cs technology).
 
I do wish this could be understood/accepted as its simply a fact.
 
Now if folks want to create OAM for PWs then please be under no illusion
that PWs will need to be considered as a layer network in their own
right.....indeed, the notion of 'PW switching' is a clear confirmation
of this direction.  Note that the OAM required for the server IP or MPLS
networks is something else.  So one is now creating a client/server
relationship between 3 layer networks that looks like either:
-    X/PW/IP, or
-    X/PW/MPLS, or
-    if folks embraced Ping's ideas for 'PWs over anything' X/PW/SDH
(other)'
 
This is where the WG is now heading.  I don't think we need to go here
as I do not believe it is required, and certainly not from our
perspective.  There is no need for PW switching IMO for a large operator
like BT seeking convergence on MPLS, nor do I beleive this is warranted
for the Internet either.  We do however, want the right sort of OAM for
MPLS and all we need for XoverMPLS is a simple client/server adaptation
relationship.  IMO folks are creating complexities where they are simply
not required and I am completely unclear *who* this stuff is being
written for.
 
regards, Neil

-----Original Message-----
Sent: 13 August 2004 20:16

Florin,
 
You write: "On the other hand we need the extensibility provided by a
PTI/PID:  VCCV is just an instantiation of a PTI if you think about it,
just the formats need to be aligned".
 
I agree that VCCV is one instantiation of a protocol that could be
carried over a PW. However, the point I raised in an earlier email is
whether there are other instantiations. Because, if VCCV is the *only*
instantation, you don't need a PID, but just a way to differentate VCCV
traffic from the PW payload traffic.

1) As Mustapha observed, even if you don't need to identify the PW
payload traffic, you might still need to differentiate between different
types of OAM traffic
 
2) As you observed, if you run VCCV traffic over a Pseudo Wire, then a
Control Word , be it CW or PTI, must necessarily preceed all payload and
OAM traffic.
 
3)  draft-bryant-mcpherson-pwe3-cw-00.txt states: "If technical
considerations result in a PW Control Word that could be mistaken for an
IP packet, the Control Word SHOULD be preceded by a PWE3 PTI." However,
as we all seem to agree on, a CW will never be mistaken for an IP
packet.
 
Therefore, rather than proposing a PTI that preceded a CW, I think the
following solution would be sufficient and more elegant:
 
If the PW does not carry VCCV traffic, a CW is only mandatory if
specified in the relevant encapsulation draft

a) all payload traffic MUST be preceded by a Control Word that starts
with 0000
 
b) all VCCV traffic MUSTbe preceded by an "OAM Protocol Identifier"
(OPI), which has the following format:

where protocol id identifies one of the following protocols: LSP Ping,
ICMP, BFD, Y.1711, other(?).
 
Peter

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Thursday, August 12, 2004 12:42 PM
To: Busschbach, Peter B (Peter); Stewart Bryant
Cc: [email-masked]; Jeffrey Sugimoto
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Peter,
See in-line...
 
Stewart,
There might be another motivator for a mandatory CW/consolidation under
PTI: assuming we have a PW type that does not mandate a CW (ATM N to one
cell mode) couldn't we get payloads that are mistaken also for 0001/VCCV
packets - e.g. VPI 64 in an ATM cell could be interpreted by the
receiving PE as 0001? (thanks Jeff for bringing this up)
 
Regards,
Florin

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2004 2:41 PM
To: Balus, Florin [CAR:6955:EXCH]; Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Florus,

FB: Dave addressed the need for an MPLS PID one year ago from an overall
MPLS perspective: e.g. issues arisen from loadsharing on TE link bundles
or ECMP in LDP network,  OAM extensibility, Multiprotocol over MPLS...
 
Draft-bryant-mcpherson-pwe3-cw-00.txt mentions ECMP as the sole reason
for an additional control word. However, introducing PTI to solve the
issues related to ECMP seems overkill. It would be good if we can
clearly state why we need a PTI.
FB I agree with you that the justification in section 4 for PTI versus
CW + VCCV could be improved. On the other hand we need the extensibility
provided by a PTI/PID:  VCCV is just an instantiation of a PTI if you
think about it, just the formats need to be aligned. 
Whether or not is a good idea to move the PW user data to 0001 format is
to be debated. We need to make sure though the 2 formats could coexist
in a network in the mean time.
 
Peter 

-----Original Message-----
From: Florin Balus [mailto:[email-masked]]
Sent: Wednesday, August 11, 2004 2:17 PM
To: Stewart Bryant
Cc: [email-masked]
Subject: RE: [PWE3] draft-bryant-mcpherson-pwe3-cw-00.txt WG request

Stewart, 

-----Original Message----- 

The authors request that 

PWE3 MPLS Control Word 

- Stewart

---

From: [email-masked]
Date: Wed, 18 Aug 2004 19:39:35 +0100

Tom....
> > Peter,
> > I agree with your proposal. One clarification though: strictly 
> > speaking the PTI on OAM packets is only required when ECMP or other 
> > load balancing schemes could split the OAM and data packets over 
> > different paths. Otherwise, the router alert label should be 
> > sufficient and this will not require the use of the control word on 
> > data packets if not required by the encapsulation. Thus, we 
> have the 
> > following two options:
> >
> > 1. If PTI is used on OAM packets, CW is mandatory on data packets.
> 
> 	I am not sure if you need to explicitly make it 
> mandatory, but it probably will not hurt. This has been the 
> implicit assumption all along that those of us working on 
> VCCV have told people. There is no free lunch -- if you want 
> OAM, turn on the CW on that PW.
> 
> 	--Tom
NH=> OAM should always be designed into the data-plane *traffic*
structures of layer networks from day-1.....just like OAM is designed
into the various internal session/control/management protocols
themselves (whatever their function) to check they are working OK per se
(might not call it 'OAM' here but that is what it is, eg timers,
exception handling, etc).  The OAM required in the data-plane is a
function of the mode.....and it is not the same for all modes.  The
'lunch' starts getting expensive however when it is not properly
factored-in from day-1.

regards, Neil
> 
> 
> > 2. Otherwise, use router alert label on OAM packets and 
> data packets 
> > will just follow the encapsulaiton requirements, i.e., CW 
> may or may 
> > not be required.
> >
> > Also, I would like to have 
> draft-bryant-mcpherson-pwe3-cw-00.txt add a 
> > statement to encourage future PW encapsulations to continue 
> using the 
> > all zero nibble immediately following the bottom of the label stack 
> > for data packets.
> >
> > Mustapha.
> > ---------
> >> "Busschbach, Peter B (Peter)" wrote:
> >>
> >> Florin,
> >>
> >> PTI/PID:  VCCV is just an instantiation of a PTI if you 
> think about 
> >> it, just the formats need to be aligned".
> >>
> >> whether there are other instantiations. Because, if VCCV is the
> >> *only* instantation, you don't need a PID, but just a way to 
> >> differentate VCCV traffic from the PW payload traffic.
> >>
> >> payload traffic, you might still need to differentiate between 
> >> different types of OAM traffic
> >>
> >> 2) As you observed, if you run VCCV traffic over a Pseudo 
> Wire, then 
> >> a Control Word , be it CW or PTI, must necessarily preceed all 
> >> payload and OAM traffic.
> >>
> >> considerations result in a PW Control Word that could be 
> mistaken for 
> >> an IP packet, the Control Word SHOULD be preceded by a PWE3 PTI." 
> >> However, as we all seem to agree on, a CW will never be 
> mistaken for 
> >> an IP packet.
> >>
> >> Therefore, rather than proposing a PTI that preceded a CW, I think 
> >> the following solution would be sufficient and more elegant:
> >>
> >>      There might be another motivator for a mandatory
> >>      CW/consolidation under PTI: assuming we have a PW type
> >>      that does not mandate a CW (ATM N to one cell
> >>      mode) couldn't we get payloads that are mistaken also
> >>      for 0001/VCCV packets - e.g. VPI 64 in an ATM cell could
> >>      be interpreted by the receiving PE as 0001? (thanks Jeff
> >>      for bringing this up)
> >>
> >>      Regards,
> >>      Florin
> >>
> >>           Draft-allan-mpls-pid-00.txt  is not accessible
> >>           anymore. I don't recall what rationale it gave
> >>           for the need for a PTI.
> >>           FB: Dave addressed the need for an MPLS PID
> >>           one year ago from an overall MPLS perspective:
> >>           e.g. issues arisen from loadsharing on TE link
> >>           bundles or ECMP in LDP network,  OAM
> >>           extensibility, Multiprotocol over MPLS...
> >>
> >>           Draft-bryant-mcpherson-pwe3-cw-00.txt mentions
> >>           ECMP as the sole reason for an additional
> >>           control word. However, introducing PTI to
> >>           solve the issues related to ECMP seems
> >>           overkill. It would be good if we can clearly
> >>           state why we need a PTI.
> >>           FB I agree with you that the justification in
> >>           section 4 for PTI versus CW + VCCV could be
> >>           improved. On the other hand we need the
> >>           extensibility provided by a PTI/PID:  VCCV is
> >>           just an instantiation of a PTI if you think
> >>           Whether or not is a good idea to move the PW
> >>           user data to 0001 format is to be debated. We
> >>           need to make sure though the 2 formats could
> >>           coexist in a network in the mean time.
> >>
> >>           Peter
> >>
> >>                draft-allan-mpls-pid-00.txt on the
> >>                subject. Also I think the
> >>                explanation of ECMP issue
> >>                (disambiguate from IP/MPLS packets
> >>                etc) and the overall proposed
> >>                solution are valid.
> >>
> >>                I just wanted to clarify some
> >>                technicalities to make sure we
> >>                clearly identify where we are headed
> >>                to - i.e. what changes are required
> >>                in other PWE3 drafts.
> >>
> >>                part of those implementations that
> >>                do not support 0000. How are we
> >>                going to ensure the 2 sets of PEs
> >>                will be able to negotiate in the
> >>                control plane the right format?
> >>
> >>                Frame Mode - see
> >>                draft-ietf-pwe3-atm-encap-05.txt
> >>                section 4.3.2). For a PE that will
> >>                implement the PTI format are we
> >>                saying the PW frames (after the 2
> >>                labels) will look like this: (0001
> >>                Is VCCV/OAM going to be
> >>                differentiated in the same way, just
> >>                re-using what is already defined:
> >>                i.e. (0001  PTI)(0001 PA
> >>                PPP_DLL)(OAM payload)? If not I
> >>                assume we will need to clarify the
> >>                PTI code points that are going to be
> >>                used for VCCV/OAM payload?
> >>
> >>                [mailto:[email-masked]] On
> >>                Behalf Of Stewart Bryant

---

From: "Florin Balus" <[email-masked]>
Date: Fri, 20 Aug 2004 12:03:32 -0400

Mustapha, Peter,
I would add to the points you made below that in an ECMP environment
(implementations where for any IP payload, the IP addresses are used for
loadsharing decision) the CW becomes mandatory even if no VCCV is  used. 
Otherwise you might always have some payloads (e.g. IP, ATM, Ethernet PW)
that could be interpreted as IP (certain ATM VPI or dest MAC - same as for
VCCV). 
Regards,
Florin

> Sent: Wednesday, August 18, 2004 10:52 AM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]
> I agree with your proposal. One clarification though: 
> strictly speaking the PTI on OAM packets is only required 
> when ECMP or other load balancing schemes could split the OAM 
> and data packets over different paths. Otherwise, the router 
> alert label should be sufficient and this will not require 
> the use of the control word on data packets if not required 
> by the encapsulation. Thus, we have the following two options:
> 
> 2. Otherwise, use router alert label on OAM packets and data 
> packets will just follow the encapsulaiton requirements, 
> i.e., CW may or may not be required.
> 
> draft-bryant-mcpherson-pwe3-cw-00.txt add a statement to 
> encourage future PW encapsulations to continue using the all 
> zero nibble immediately following the bottom of the label 
> stack for data packets.
> 
> Mustapha.
> ---------
> > PTI/PID:  VCCV is just an instantiation of a PTI if you think about 
> Wire, then a 
> > Control Word , be it CW or PTI, must necessarily preceed 
> all payload 
> > and OAM traffic.
> > 
> http://www.ietf.org/internet-drafts/draft-> bryant-mcpherson-pwe3-cw-00.
> > txt
> >