Subject: RE: [Fwd: I-D ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] - OAM considerations

From: [email-masked]
Date: Tue, 13 Jul 2004 11:48:43 +0100

Hi Stewart,

I note Yaakov has already posted remarks on this draft regarding ambiguity in the use/ordering of the CW and/or PID (which I agree with).  However, I see a further problem.  If I am reading the draft correctly it seems there are potentially many options:
-	CW only;
-	PID only;
-	PID and CW (must appear in this order);
-	...and when the CW is used the various fields therein are optional or vary, eg Seq Nos are optional, flags vary on client;
-	the above only applies to PW LSPs, IP LSPs have none of this, ie this is essentially the case of 'no CW and no PID';
-	....and the above can be with/without OAM.

So the further problem I see is when we have misconnectivity defects between LSPs that are not identically specified wrt above (which of course is currently a given anyway for the case of mixed PW LSPs and IP LSPs even if all the PW LSPs are identically coded).

Perhaps a good generic solution would have been to make the PID mandatory on all LSPs (any client case, including IP).  This appears to give:
-	give a consistent solution (for the ECMP hack) in all cases
-	and allows correct identification of payload as OAM or traffic

The CW is always going to be a problem IMO......both from the fact that it is optional per se, and that even when present some of the fields therein are optional or variable dependent on the client.  I don't see any easy way out of this now.....though I suspect you know my view on why this all such a problem now, ie MPLS is not IP, and for forms of MPLS that do not violate the connectivity constraints of the co-ps mode one does not need the CW IMO, nor does one need it if the server layer technology belongs to the co-cs mode, ie Ping's recent proposals for such.  Furthermore, I also believe that client layer transparency should always be the default behaviour, ie any minute savings from client BW squeezing is not a major issue, complexity however is.

Could the best compromise be to make PID+CW the mandatory case?.....where the PID still identifies the payload as traffic or OAM, but we now know that there is always a CW interposed here (and for folks who think it of little value they can just effectively set it to 'null').  The other alternative is to code the PID for every possible CW case.....though this would only seem important if varying CW structures could exist in the same MPLS network.

regards, Neil

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 13 Jul 2004 14:35:52 +0200

Neil and all,
Please see a brief comment inline.
(I have taken the liberty to snip the parts of your response that are not
related
to this specific comment.)
Hopefully it would be helpful.
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: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 13, 2004 12:49 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [PWE3] [Fwd: I-D 
> ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] - OAM considerations
> 
> 
> Hi Stewart,
> 
... nipped ..
>for forms of MPLS that do not violate the connectivity constraints 
> of the co-ps mode one does not need the CW IMO, nor does 
> one need it if the server layer technology belongs to the co-cs mode, ie 
> Ping's recent proposals for such.  
>
[Sasha] Here is one example where server being co-ps does NOT eliminate
the need for sequence numbers. It is (unsurprisingly) the case of
TDM clients, where the need to detect (and compensate for)
LOST packets requires sequence numbers. I think that you 
recognize ATM as a compliant co-ps server layer (even if cells
are not exactly packets), but AAL1 and ATM-CES use sequence
numbers (even if limited to 3 bits only).
(I assume that your definition of co-ps includes zero packet loss:-)
>
>Furthermore, I also 
> believe that client layer transparency should always be the 
> default behaviour, ie any minute savings from client BW 
> squeezing is not a major issue, complexity however is.
> 
> Could the best compromise be to make PID+CW the mandatory 
> case?.....where the PID still identifies the payload as 
> traffic or OAM, but we now know that there is always a CW 
> interposed here (and for folks who think it of little value 
> they can just effectively set it to 'null').  The other 
> alternative is to code the PID for every possible CW 
> case.....though this would only seem important if varying CW 
> structures could exist in the same MPLS network.
> 
> regards, Neil
>  
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Tue, 13 Jul 2004 15:00:35 +0100

Thanks Sasha,  Please see below.  regards, Neil

> (I assume that your definition of co-ps includes zero packet loss:-)

NH=> This does not address the problem I raised.....but since you brought this up.....

The key question here is this:  Given the traffic from all applications will be either message, file or stream in nature then just how many technologies and QoS/traffic classes does one need to support this?  Answer is a heck of lot less than some folks think.  However, every time a new technology arrives its advocates try and solve everything in that technology/mode.  This gives us many problems....stovepipes and the downstream i/w issues created are examples of these.  We don't need loads of technologies per mode......but we do need the 3 modes as they do different jobs.

I can postulate a rather simple target network arch where the cl-ps and co-ps modes work in harness, we have sensible client/server relationships of each of these (service-level) modes to the lower (transport/aggregate) co-cs mode, and where one simply does not need lots of QoS/traffic classes in each (service-level) mode to address the full public/private service vista most optimally.  {Aside - real networks run lightly loaded (many reasons), and the real challenge is to do with creating consistently meaningful services over all load points, where service_price and BW_used are independent parameters.  Having lots of QoS/traffic classes is a BW squeezing optimisation that is not worth it....we should use BW wisely to remove complexity.  But the trick is seeing how to use the different modes in harness to do this.}  However, I'll leave that one here as I think this vision could be considered counter-culture......though it is important to be aware of this to understand *why* we keep causing a mess with the '1 technology/mode can do it all' view.

ATM was a classic example of falling for this 1-mode-can-do-it-all flawed thinking.  ATM has several AALs for different clients, 5 of them at one stage......this is far too many QoS/traffic classes IMO, and harks back to (i) the notion that BW is scarce resource that must be conserved at all costs and (ii) some folks think they can get something for nothing.  AAL5 does not have Seq Nos as it was designed for message and file traffic.....AAL1 does have Seq Nos however as it was designed for stream traffic.  So the issue you raise has nothing to do with ATM per say as the common networking co-ps layer technology (ie cell level), the issue is all to do with the adaptation function, and specifically here AAL1.

So, given you need Seq No.s for the TDM client case and you quote the AAL1 example, then why don't you just use AAL1 and be done with it?.......there is no need to make the network always carry this function for every other client case.  Indeed, I understand most folks don't even use the Seq Nos.

{Further aside - IP has 2 major application adaptation functions UDP and TCP for the message and file traffic respectively....UDP does not natively carry sequence numbers, but one can add RTP to UDP for the real time stream case if one thinks that is a good solution.

I also think we have to distinguish 'application->1st layer network adaptation' (ie the message/file/stream issues) from 'client/server adaptation' between different layer networks.  One size does not fit all here in the latter case.  2 key adaptation functions are muxing and alignment.  However, the precise nature of the adaptation function required is dependent on the client and server modes concerned.  For example, if we adapt a co-ps or cl-ps client into a co-cs server we have an alignment function that must cater for rate-decoupling (ie idle-fill) and client traffic unit delination....GFP say could do this job, and indeed will do for (say) ethernet over SDH. These adaptation function alignment requirements don't exist for other client/server mode pairs......and instead we might have a padding requirement or (less nice) a fragmentation requirement (ie client traffic unit > server traffic unit payload).  A special muxing function is never needed with a cl-ps client to any mode as the server......the cl-ps mode inherently does muxing (never merging) because each/every traffic unit carries a network-wide DA/SA semantic.  Not true for the co-ps and co-cs modes when we have >1 client into a single server as link-connection IDs are not network-wide unique, and need to be controlled/configured when a parent trail entity is brought into being.}

regards, Neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 13 Jul 2004 16:26:11 -0400

On Jul 13, 2004, at 6:48 AM, [email-masked] wrote:

> Hi Stewart,
>
> I note Yaakov has already posted remarks on this draft regarding 
> ambiguity in the use/ordering of the CW and/or PID (which I agree 
> with).  However, I see a further problem.  If I am reading the draft 
> correctly it seems there are potentially many options:
> -	CW only;
> -	PID only;
> -	...and when the CW is used the various fields therein are optional 
> or vary, eg Seq Nos are optional, flags vary on client;
> -	the above only applies to PW LSPs, IP LSPs have none of this, ie 
> this is essentially the case of 'no CW and no PID';
> So the further problem I see is when we have misconnectivity defects 
> between LSPs that are not identically specified wrt above (which of 
> course is currently a given anyway for the case of mixed PW LSPs and 
> IP LSPs even if all the PW LSPs are identically coded).
>
> Perhaps a good generic solution would have been to make the PID 
> mandatory on all LSPs (any client case, including IP).  This appears 
> to give:

	I personally agree with making the CW mandatory. The
reasons you give are precisely why it makes sense; however,
I think that there is some subset of providers that
will object.  There is also the issue of deployed
hardware that cannot recognize the CW.

	--Tom

>
> The CW is always going to be a problem IMO......both from the fact 
> that it is optional per se, and that even when present some of the 
> fields therein are optional or variable dependent on the client.  I 
> don't see any easy way out of this now.....though I suspect you know 
> my view on why this all such a problem now, ie MPLS is not IP, and for 
> forms of MPLS that do not violate the connectivity constraints of the 
> co-ps mode one does not need the CW IMO, nor does one need it if the 
> server layer technology belongs to the co-cs mode, ie Ping's recent 
> proposals for such.  Furthermore, I also believe that client layer 
> transparency should always be the default behaviour, ie any minute 
> savings from client BW squeezing is not a major issue, complexity 
> however is.
>
> case?.....where the PID still identifies the payload as traffic or 
> OAM, but we now know that there is always a CW interposed here (and 
> for folks who think it of little value they can just effectively set 
> it to 'null').  The other alternative is to code the PID for every 
> possible CW case.....though this would only seem important if varying 
> CW structures could exist in the same MPLS network.
>
> regards, Neil
>
>