Re: Proposed changes to draft kamapabhava-01

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

Stewart,

I've already thrown in the towel on this issue.  Claude is going to update 
the kamapabhava draft to use the Q.922 bit ordering.  Regarding what line 
rates the Martini encapsulation can be done at for arbitrary frame sizes, I 
can't say until we go public at Supercomm.  So ask me again in June ... :-)

Cheers,
Andy

-------

At 4/22/2002 01:04 PM +0100, Stewart Bryant wrote:


>"Andrew G. Malis" wrote:
> >
> > 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.
> >
>
>At what speed?
>
>The issue wrt speed is not so much frame relay emulation per se, it is the 
>customers who want
>to use the technology for VPN (ie PPVPN) multiplexing. In this case we 
>have no effective
>ceiling on performance demand. As I have shown microcode implementatons 
>will find it tough to do
>the bit manipulations at speeds, which can be expected to rise to 10Gb/s 
>in the reasonable
>future. I suppose they could also just lie about the value of the bits!
>
>Since it is the MPLS teams, looking for compatibility with Martini that 
>want the strange bit
>ordering, can we agree that this format will be restricted to MPLS 
>implementations?
>
> > 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.
>
>I agree with this. It seems very unlikely that anyone will ever run 
>directly over IP. It offers
>no particular advantage, and has the disadvantage of lacking an 
>intermediate multiplexing
>layer. It will also consume a protocol number and it seems unlikely that 
>one will be allocated
>given the limited number available.
>
>Stewart
>
> >
> > 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]]
> > > 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
> > >
> > > 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/>