RE: Proposed changes to draft kamapabhava-01

[[e-mail]]

Andrew....I don't agree with what you say below about backwards
compatibility with Martini being 'very important'.  I would agree with you
if this represented some agreed stds document but IMO Martini is just a
draft ID with no official stds status.  If vendors want to build to such a
'stds intercept' then they do so at risk and they must accept they may need
to change.  I also don't like this 'we've built to it therefore its the de
facto std by an existence proof' argument........because for 1 thing what is
to stop a few vendors (and maybe SPs) having some private agreement to do
this and then using this 'proof by existence' to force it on everyone else? 
 
regards, Neil

-----Original Message-----
From: Andrew G. Malis [mailto:[e-mail]]
Sent: 19 April 2002 15:36
To: Claude Kawa
Cc: [e-mail]
Subject: RE: [PWE3] Proposed changes to draft kamapabhava-01


Claude,

Thanks for the updates.  It's clear from recent list activity that Martini
backwards compatibility is very important, and so I suggest keeping BFDC.
It's really not that tough to do, folks - there are already several
wire-speed Martini implementations, so there's certainly proof by example.

Regarding IP tunnels - I agree to focus on L2TPv3 and MPLS for now, and add
IP if someone cares enough about it to write the text.

Cheers,
Andy

--------

At 4/19/2002 09:52 AM -0400, Claude Kawa wrote:



I still see arguments for frame relay bit ordering. In draft kama...-01 they
were changed back to the martini order: BFDC at the request of some people
on the PWE3 email discussion. In version 00 they were in Q.922 "order":
FBDC.

Let us agree please on an order BFCD or FBDC? Any strong preference for one
or the other. This is an important issue to close.

Another issue raised is whether we support IP tunnel or MPLS and L2TPv3
only. PWE3 charter lists the 3 types of tunnels. May be we need guidance
from above (chair or AD). Otherwise I propose for the first version of a WG
draft to focus of MPLS and L2TPv3 (unless L2TPv3 is addressed elsewhere).

Thanks 

Claude Kawa 

-----Original Message----- 
From: Lloyd Wood [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, April 19, 2002 8:20 AM 
To: Kawa, Claude [CAR:CS49:EXCH] 
Cc: [e-mail] 
Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01 

On Thu, 18 Apr 2002, Claude Kawa wrote: 

> I would like to propose changes to draft kamapabhava-01 taking into
account 
> the comments received the last few days in order to progress this work. I 
> will be able to produce a new draft in 2-3 weeks (next week I am out of
the 
> office). 
> 
> Proposed changes to draft-kamapabhava-01: 

that is, draft-kamapabhava-fr-pwe3-01.txt 

> -Fragmentation is an important issue, if we cannot resolve it now I
propose 
> the following changes to the FRoPW header: We encode bits I and L used to 
> identified the fragments as 0 0 (0 0 means a complete frame) and work on
the 
> solution without preventing the draft to progress. 
> 
> -The P bit used to identified the payload as user data or network
management 
> data, I propose that we keep this bit with the following description: 
> 
> P - Payload Type  (bit 3): 
>    If set to zero then the payload field contains user's data else its 
>    contents is not specified in this document. 
> 
>    With this proposal, network and vendor may use P=1 in a proprietary way

> to carry whatever they want to carry with the caveat that standardization
of 
> the use of P=1 in the future may obsolete its proprietary use. 
> 
> With these two changes the header will look like: 
> 
>  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 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> | Res |P|B|F|D|C|0|0|  Length   | Sequence Number               | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

I see draft-kamapabhava-fr-pwe3-00.txt had PFBDC. 
The above in 01 has changed that to PBFDC, which matches the Martini 
layout in draft-martini-frame-encap-mpls-00.txt 
- note the reordering of B and F. 

> We have now the header in draft-martini (when P = 0). 

so the ordering of the bits will incur extra processing, since they're 
FBD in a _real_ frame relay datagram, and reordering kawa to match 
martini is a retrograde step - as discussed in detail in 
draft-bryant-pwe3-fr-compare-00.txt 
See also the slides at the bottom of: 
http://www.ietf.org/proceedings/01dec/234.htm
<http://www.ietf.org/proceedings/01dec/234.htm>  

I personally think that if you can choose to reorder the kama bits at 
this stage, you can at least choose to reorder them efficiently. 

(I do find it strange that those concerned with the efficiency of the 
 number of bits on the wire -- "it's a 1.4% overhead!" "No, it isn't!" 
 -- aren't also concerned with the processing efficiency of how those 
 bits get there. FR congestion notification is unlikely to be made to 
 work well, and the complexity of bit manipulation isn't helping.) 

> -Next comments are from LLoyd Wood email that came today (Thursday) 
> 
> 1-We will address the use of IP tunnel. We have a placeholder for that but

> MPLS seemed to have a higher priority. 

so this format is mpls-specific? (Where efficiency matters?) 

> 2-About the security section we will use what is
draft-bryant-pwe3-fr-encap. 
> It looks good. 
> 
> 3-We will try to adopt other useful material from draft bryant
complementing 
> draft kamapabhava-01. 

good to hear. 

cheers, 

L. 

<[e-mail]>PGP< http://www.ee.surrey.ac.uk/Personal/L.Wood/
<http://www.ee.surrey.ac.uk/Personal/L.Wood/> >