RE: Proposed changes to draft kamapabhava-01

["Andrew G. Malis" <[e-mail]>]

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