Subject: RE: [PWE3] Generic vs Preferred CW

From: [email-masked]
Date: Thu, 5 May 2005 14:20:33 +0100

Yaakov wrote 05 May 2005 13:15
 
> Mustapha,
> 
> If the ONLY intention of the CW draft is to avoid
> IP packet aliasing, then it should not have specified
> a 4 byte CW at all.
NH=> Tend to agree.  But this has really nothing to do with any useful
adaptation function.  This is just an embarassing kludge/fix is it not? 
> 
> It should have defined a 1 nibble preamble
> (OK, perhaps we could allow it to splurge
> and throw away an entire byte)
> and left the rest to the encap documents.
> 
> In particular, some encap might want to use
> only one or 2 bytes of CW overhead.
> If we are interested in minimizing header overhead 
> why use 4 bytes and then worry about compression?
NH=> Very good point.  You may recall me making a similar point many
times in the past, ie the nature of the adaptation function required
between a given client and a given server is a function of the both the
network mode of the client and the server.  A 1 size fits all approach
is just silly, and its no wonder folks will want to deviate from it.

The analogy for application adaptations into IP would be to say that we
don't actually need UDP (with/without RTP for some cases) and TCP, so
let's just define 1 adaptation that will fit everything...why not, its
exactly the same argument?  The answer here of course is easy to see:
Applications can be generally grouped into either messages, files or
streams, and their functional adaptation requirements are clearly
different.....so its pretty obvious a single adaptation will be rather
silly as some functional fields will be turned-off for certain
application types.

In the case of client/server layer network adaptations there are 9
possible combinations between the 3 modes (more if you are crazy enough
to think client compression is agood idea.....but this is a 'must have'
for the TDM stuff I guess, else there is no value-add).  We obviously
don't need 9 adaptations, but we sure need more than 1.  What we should
have here is a minimal set....just like the UDP and TCP case for IP
(with RTP added when dealing with stream applications).

Further, if folks understood and accepted the fact that XoverMPLS !=
XoverIP (at least this truth is FORCED for those dealing with the co-cs
mode in GMPLS) then perhaps we would not be facing the fiasco of
creating a new PW layer network and the unecessary implications of
interworking the data and control planes of XoverMPLS and XoverIP....I
mean just how daft is this really!?  (BTW - We operators would like to
reduce the number of layer networks we have to deal with.....we don't
really want more unnecessary ones being created).

Just as I was about to post this I noted you posted the following
comment (against the thread "RE: [PWE3] RE: [L2tpext] Re: Local CE IP
Address AVP" :

	"Actually, I guess it is time to admit that we did a lousy job
of trying to define an abstract "PW" which could be based on either MPLS
or L2TPv3. No matter what the architecture document says, de facto PWE3
means MPLS-PWs."

.....exactly so....so why is it so very hard to come clean on this truth
I wonder, ie cl-ps != co-ps != co=cs?

I sometimes have to pinch myself to believe folks have blundered their
way as far as they have into this PW mess.  But then I only need to look
at LDP and PHP to be reminded where/why the journey started ;-)
> 
> The CW draft proposes more than that -
> it standardizes the PWE CW
> (already grounded in the architecture RFC).
> Almost all the encap drafts use the same CW anyway,
> with the noncompliant ones slowly adopting it as well
> (first CESoPSN and now CEP).
NH=> I think I could put up some pretty strong arguments for turning-off
most of the stuff that appears in these in many cases.  And I can put up
even stronger arguments to say (i) there should be no client compression
as the default and (ii) the server layer should be generically managed
in the same way irrespective of its client.  To be brutally honest here,
what we are seeing are folks making a living off client compression and
poor MPLS functional specification, eg a lack of good MPLS OAM results
in things like 'adaption layer OAM' being created in the L/R bits to
'add some value'...wrong place, wrong solution.   And just think when
the PW layer network really gets up steam as a multi-hop entity we can
repeat it all again here!

> 
> We should welcome the simplification proposed here,
> even if it means that some old pre-standard
> implementations have to be updated,
> and some new suggestions have to take the
> standard into account.
NH=> I wonder if anyone has ever considered doing things right instead
of building kludges on kludges?  Just an idea.

PS - I just noticed Stewart has posted a mail asking for consensus on
option a.  Well, does it really matter any more?  This stuff is so
broken top to bottom it seems almost churlish to try and inject any
sense now on one 'symptom'.

regards, Neil
>  
> 
> Y(J)S
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Thu, 5 May 2005 15:45:52 -0400

Neil,
I am with you on this one. I do not believe in the one size fits all.
However, I also think striving to achieve commonality across technologies of
the same type is highly desirable. This is why I say that for each new
application, a decision has to be made taking all factors into account.

Regards,
Mustapha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 05, 2005 9:21 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [PWE3] Generic vs Preferred CW

> Mustapha,
>
> If the ONLY intention of the CW draft is to avoid IP packet aliasing,
> then it should not have specified a 4 byte CW at all.
>
> It should have defined a 1 nibble preamble (OK, perhaps we could allow
> it to splurge and throw away an entire byte) and left the rest to the
> encap documents.
>
> In particular, some encap might want to use only one or 2 bytes of CW
> overhead.
> If we are interested in minimizing header overhead why use 4 bytes and
> then worry about compression?
NH=> Very good point.  You may recall me making a similar point many times
in the past, ie the nature of the adaptation function required between a
given client and a given server is a function of the both the network mode
of the client and the server.  A 1 size fits all approach is just silly, and
its no wonder folks will want to deviate from it.

The analogy for application adaptations into IP would be to say that we
don't actually need UDP (with/without RTP for some cases) and TCP, so let's
just define 1 adaptation that will fit everything...why not, its exactly the
same argument?  The answer here of course is easy to see:
Applications can be generally grouped into either messages, files or
streams, and their functional adaptation requirements are clearly
different.....so its pretty obvious a single adaptation will be rather silly
as some functional fields will be turned-off for certain application types.

In the case of client/server layer network adaptations there are 9 possible
combinations between the 3 modes (more if you are crazy enough to think
client compression is agood idea.....but this is a 'must have'
for the TDM stuff I guess, else there is no value-add).  We obviously don't
need 9 adaptations, but we sure need more than 1.  What we should have here
is a minimal set....just like the UDP and TCP case for IP (with RTP added
when dealing with stream applications).

Further, if folks understood and accepted the fact that XoverMPLS != XoverIP
(at least this truth is FORCED for those dealing with the co-cs mode in
GMPLS) then perhaps we would not be facing the fiasco of creating a new PW
layer network and the unecessary implications of interworking the data and
control planes of XoverMPLS and XoverIP....I mean just how daft is this
really!?  (BTW - We operators would like to reduce the number of layer
networks we have to deal with.....we don't really want more unnecessary ones
being created).

Just as I was about to post this I noted you posted the following comment
(against the thread "RE: [PWE3] RE: [L2tpext] Re: Local CE IP Address AVP" :

	"Actually, I guess it is time to admit that we did a lousy job of
trying to define an abstract "PW" which could be based on either MPLS or
L2TPv3. No matter what the architecture document says, de facto PWE3 means
MPLS-PWs."

.....exactly so....so why is it so very hard to come clean on this truth I
wonder, ie cl-ps != co-ps != co=cs?

I sometimes have to pinch myself to believe folks have blundered their way
as far as they have into this PW mess.  But then I only need to look at LDP
and PHP to be reminded where/why the journey started ;-)
>
> The CW draft proposes more than that - it standardizes the PWE CW
> Almost all the encap drafts use the same CW anyway, with the
> noncompliant ones slowly adopting it as well (first CESoPSN and now
> CEP).
NH=> I think I could put up some pretty strong arguments for turning-off
most of the stuff that appears in these in many cases.  And I can put up
even stronger arguments to say (i) there should be no client compression as
the default and (ii) the server layer should be generically managed in the
same way irrespective of its client.  To be brutally honest here, what we
are seeing are folks making a living off client compression and poor MPLS
functional specification, eg a lack of good MPLS OAM results in things like
'adaption layer OAM' being created in the L/R bits to
'add some value'...wrong place, wrong solution.   And just think when
the PW layer network really gets up steam as a multi-hop entity we can
repeat it all again here!

>
> We should welcome the simplification proposed here, even if it means
> that some old pre-standard implementations have to be updated, and
> some new suggestions have to take the standard into account.
NH=> I wonder if anyone has ever considered doing things right instead of
building kludges on kludges?  Just an idea.

PS - I just noticed Stewart has posted a mail asking for consensus on option
a.  Well, does it really matter any more?  This stuff is so broken top to
bottom it seems almost churlish to try and inject any sense now on one
'symptom'.

regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 06 May 2005 07:31:52 +0100

I have another area that I need to test consensus on - the CW length text.

We have three options:

a) Say that the semantics of the length field is PW type specific
and is defined in the encap definition.

b) Define two modes - skip zero and use zero - and say that the
PW type uses the most appropriate.

c) The OPTIONAL / MANDATORY text that was last proposed.

I think that the consensus of the WG is to reject (c).

(b) documents what have used in the existing encap drafts.

I detect a mild consensus for (a).

Is that correct?

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 06 May 2005 12:24:31 -0400

Stewart,

You mean sequence number, not length, and I support the consensus for (a).

Cheers,
Andy

-------