Re: Proposed changes to draft kamapabhava-01

[Stewart Bryant <[e-mail]>]

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