RE: Proposed changes to draft kamapabhava-01

["Kavi, Prabhu" <[e-mail]>]

Stewart and Andy,

I am glad that we are going with the Q.922 bit ordering.
Not because of a performance issue, but simply because it
is more logical.

The performance problem is less of an issue.  With the
advances in NPs, I know there exist C-coded versions 
of Martini encaps that runs in hardware and can support 
OC-192c rates for 40-byte packets.

Prabhu


> -----Original Message-----
> From: Andrew G. Malis [mailto:[e-mail]]
> Sent: Monday, April 22, 2002 12:35 PM
> To: [e-mail]
> Cc: Andrew G. Malis; [e-mail]
> Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01
> 
> 
> 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/>
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
>