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

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 14 Jul 2004 09:04:01 +0300

> 	I personally agree with making the CW mandatory. 

So do I.

> The reasons you give are precisely why it makes sense; 

I think something was lost here.
I understood Neil to be arguing AGAINST using a CW.

> 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.

I think these two issues are really one.
The providers who will object are those who have already deployed
hardware that doesn't support the CW.

But that is the risk early adopters take upon themselves.

I believe that implementations could ease a migration from
pre-standard to standard CW formats by supporting both
options in the near term. But after that we should settle
on the correct solution.

 Y(J)S

---

From: [email-masked]
Date: Wed, 14 Jul 2004 17:16:04 +0100

Thanks Yaakov...well spotted, and you are essentially correct (I think Tom may have perhaps misinterpreted what I said)....please see below.

Yaakov noted 14 July 2004 07:04
> I understood Neil to be arguing AGAINST using a CW.
NH=> I was making a couple of points:
-	one wants a consistent method of fault management of trails irrespective of the client(s) they are carrying.....this applies to all technologies (I think that should be obvious/agreeable)
-	however, if we have varying CI (Characteristic Information) constructs.....as seems possible with the CW and PID options, and some CW fields are also variable (some of which are client dependent).....then this looks like it will complicate defect detection/handling if there are misconnectivity defects between different structured LSPs.

So I was arguing for at least the PID to always be present......mainly to provide a consistent method of traffic vs OAM payload differentiation *irrespective* of the client (and also address the ECMP issue in the process).  I also said we can make the CW 'always present' too, but then tried to explain that inter-layer client/server adaptation is not the same for all the 3 networking modes (there are 9 combinations here).  So, for example, if I take Pings' propsal for 'PWs_over_co-cs' say, we don't need any of the CW fields at all....however, we do need:
-	a muxing adaptation function (and here the key point of the proposal is to standardise on the shim header and LDP for config for this particular function) and
-	when the server is co-cs we also need an alignment adaptation, ie client/server rate decoupling (eg idle fill) and delination.

For other clinet/server mode combinations the adaptation required is different.

So, in summary, the key point I am trying to get across here is that:
-	the CI (which includes the OAM) that goes between trail termination points of some server layer network should be consistent/generic across *all* client cases.
-	the inter-layer adaptation is *not* be consistent/generic across all pairs of client/server cases.....it depends on the mode of both the client and the server.

So my point about making the PID mandatory is all about the 1st item above wrt ensuring consistent/generic trail CI.
> But that is the risk early adopters take upon themselves.
NH=> Correct.  I don't like the idea of forcing stds to comply with what someone has 'gone early' with.  This is a very dangerous precedent IMO and it does worry me that the IETF continues to work on this basis, ie rough consensus and running code (before RFC status).  Don't get me wrong, I think the philosophy has some merit....its just that I worry that things that have been done badly might stop us doing things right.
> options in the near term. But after that we should settle
NH=> I agree Yaakov.....but to be 'correct' there are several things that need consisderation here....I can't list everything I'd perhaps like to, but in the context of this thread topic:
-	the 3 modes are not the same......a 1 size fits all approach is therefore not a good idea for many aspects of networking....and one must respect the connectivity constraints of the mode and try and ensure that the particular technology is functionally complete, eg don't miss out the right sort of OAM up front (its quite different in all 3 modes), use an OOB control/management plane for the co modes to make more secure, ensure consistent access point addressing of trails however they are instantiated, etc.  I'd say we have not got all this right in the base MPLS technology yet.
-	client/server and peer-partition i/w are not the same.  The key rule for client/server is layer independence.  However, as I tried to show above, the client/server inter-layer adaptation is not the same between all modal cases.  Further, the precendent set by FRF.8 for FR/ATM 'service i/w' cannot be generalised to any pair of technologies....esp if they belong to different modes.  There will be significant function and feature mismatch.  So the key rule here is to terminate all the server layer CI at the i/w point......though I note this requires careful consideration of the 'thing' that is now the common client of the peer server layers (defect mapping is one consisderation here).  IMO we are some way from having got either of these i/w cases 'correct' as yet.

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 15 Jul 2004 12:59:35 +0300

> Thanks Yaakov...well spotted, and you are essentially correct 
> (I think Tom may have perhaps misinterpreted what I 
> said)....please see below.

> -	one wants a consistent method of fault management of 
> trails irrespective of the client(s) they are 
> carrying.....this applies to all technologies (I think that 
> should be obvious/agreeable)

As I mentioned in the previous email, I am not sure this is
required or even a good idea.

> -	however, if we have varying CI (Characteristic 
> Information) constructs.....as seems possible with the CW and 
> PID options, and some CW fields are also variable (some of 
> which are client dependent).....then this looks like it will 
> complicate defect detection/handling if there are 
> misconnectivity defects between different structured LSPs.

OK, now I see your problem.
If transport LSPs get swapped, we depend on the PW label for 
detecting misconnections (stray packets) and you would like 
another field to help differentiation in case they happen to overlap.
Of course, this assumes that the particular network really has many 
different PW types in it, else the probability of having the same PW
type
is high. I think cookies or source IDs are much stronger for this
purpose,
and you could get these by using L2TP or RTP.

> So I was arguing for at least the PID to always be 
> present......mainly to provide a consistent method of traffic 
> vs OAM payload differentiation *irrespective* of the client 
> (and also address the ECMP issue in the process).  I also 
> said we can make the CW 'always present' too, but then tried 
> to explain that inter-layer client/server adaptation is not 
> the same for all the 3 networking modes (there are 9 
> combinations here).  So, for example, if I take Pings' 
> propsal for 'PWs_over_co-cs' say, we don't need any of the CW 
> fields at all

we still need flags and perhaps FRG 

<kill to end>

Y(J)S

---

From: [email-masked]
Date: Thu, 15 Jul 2004 16:33:00 +0100

Another go Yaakov then I give up......

> required or even a good idea.
NH=> Blimey!  Are you seriously telling me that my ops folks should manage our transport network trails differently as a function of the clients they carry....and when such networks are nested and we don't even own the higher layer networks this is still true?  This is crazy.  We must have consistent fault management of server layers trails.  Your views sound like someone addressing an enterprise market, not a major operator market.
> OK, now I see your problem.
NH=> It only becomes a problem (for us) when the stuff I am stating gets ignored.

> another field to help differentiation in case they happen to overlap.
NH=> Not exactly.  We must have the basic trail CI (which includes OAM) completely client agnostic.......this seems so very obvious (from an ops perspective) that I can't understand the difficulty in getting this.  Now different clients may require different adaptations to the (common lower) server parts......these are client specific adaptations (but we for sure don't needs loads of these....this is the QoS illusion of efficiency).

Example:  UDP and TCP are different client adaptations to the common IP network.  But IP has common parts that apply irrespective of the client, eg its ICMP fault-management.  Now try out ATM.  I.610 OAM is common to all clients, but different clients use AAL1 or AAL2 or AAL5 adaptations.  SDH is the same.
  
> and you could get these by using L2TP or RTP.
NH=> The best solution is to use the access point address of the layer network in question (which is why its importnat these are consistent irrespective of how the trail was instantiated....noting these belong to the data-plane and not the control-plane).
> we still need flags and perhaps FRG 
NH=> The problem with PWs they are different things to different folks.....they look like a camel, but that is probably being rather disrepectful to camels ;-)

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 15 Jul 2004 18:55:16 +0300

> NH=> Blimey!  

Sorry, but that term doesn't appear in my (admittedly US English)
dictionary.
Could you please explain?

<snip>

> Example:  UDP and TCP are different client adaptations to the 
> common IP network.  But IP has common parts that apply 
> irrespective of the client, eg its ICMP fault-management.  
> Now try out ATM.  I.610 OAM is common to all clients, but 
> different clients use AAL1 or AAL2 or AAL5 adaptations.  SDH 
> is the same.

Once again, I think we are talking at right angles.
Your argument is completely cogent for the MPLS-layer MPLS
(e.g. Y.1711), but we have been discussing VCCV and other
PW-layer OAM mechanisms.

I completely agree that the MPLS-layer OAM should not care
about the PW type (assuming that the PW is over MPLS).

> NH=> The problem with PWs they are different things to 
> different folks.....they look like a camel, but that is 
> probably being rather disrepectful to camels ;-)

The advantage of PWs is that they solve a lot
of problems for a lot of different folks.
... and they look more like a zebra 
(which is a horse developed by a standards organization).

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 15 Jul 2004 19:39:02 +0200

Yaakov, Neil and all,
Please see a breif and not very essential comment.
I've snipped the part of the text that is not related.

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: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, July 15, 2004 5:55 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] [Fwd: I-D 
> ACTION:draft-bryant-mcpherson-pwe3-cw-00.txt] -OAM considerations
> 
> 
>  
> > NH=> Blimey!  
> 
...snipped ...
> (which is a horse developed by a standards organization).
[Sasha] Last time I've hader this, the camel - and not zebra! -
has been defined as a horse developed by an SDO.
In this respect I think Neil got it right.
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Thu, 15 Jul 2004 17:31:03 +0100

> Could you please explain?

surprise/astonishment/disbelief.  regards, Neil