Subject: RE: FR Service Type

From: Nishit Vasavada <[email-masked]>
Date: Wed, 21 Mar 2001 15:57:39 -0800

Andy,

I appreciate your feedback.  We will work on your suggestions.

Thanks,
Nishit

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 2:42 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: FR Service Type 
> 
> 
> Danny,
> 
> For the benefit of the people on the list that weren't at the meeting 
> today, it was draft-vasavada-l2tpext-fr-svctype-00.txt I was 
> commenting 
> on.  Here are some specific comments:
> 
> 1. Most importantly, given the wide and mature implementation of FR 
> switches and deployment of FR networks, there are a number of 
> specific 
> requirements that service providers must meet in order to 
> carry frame relay 
> traffic for paying customers - if you don't meet those 
> requirements, end 
> users will go elsewhere.  By far, the easiest way to get the 
> requirements 
> for transporting FR traffic over another technology is by 
> reading FRF.5 
> (http://www.frforum.com/5000/Approved/FRF.5/FRF5.PDF).  While 
> this document 
> is specific to FR over ATM, it's easy to see, such in 
> sections 1-3, what 
> the general requirements are, and in sections 4.2 through 
> 4.4, what is 
> required regarding error reporting, congestion indications, 
> and such in the 
> data path, and in section 5, what is required for traffic 
> management and 
> PVC status signaling.  FRF.5 can easily be used a blueprint for any 
> specification to carry FR over a different technology, such 
> as this one.
> 
> 2. I very much agree with Mark's concern, as he stated in the 
> meeting, that 
> FR frame contents need to be protected.  There are any number 
> of ways of 
> doing so, such as requiring the UDP checksum (even though it 
> is weaker than 
> the FR FCS), carrying the FR FCS end-to-end, adding a new 
> FCS, etc.  But 
> you need something.
> 
> 3. FR frames are often much larger than typical IP network 
> MTUs - almost 
> all FR switches support frames up to 4K octets, and some 
> support up to 
> 8K.  You're going to need fragmentation of some sort.  Rather 
> than using IP 
> fragmentation, I would rather suggest that you use FRF.12 
> (http://www.frforum.com/5000/Approved/FRF.12/frf12.pdf) at the tunnel 
> endpoints.  FRF.12 is very easy to implement, in that it is 
> largely based 
> on RFC 1990, which is itself very widely implemented.
> 
> 4. Rather than referencing ANSI T1.618 (reference 4), which 
> is obsolete, 
> you should instead be referencing ITU-T Q.922 for FR core 
> aspects and Q.933 
> for PVC status signaling.
> 
> 5. FR users have expectations that CIR really does mean 
> committed bandwidth 
> over the window measurement interval.  That needs to be 
> acknowledged in the 
> draft, and there needs to be a mechanism to commit the 
> bandwidth, unless 
> you specifically only intend to be able to carry CIR=0 (e.g. 
> best effort) 
> VCs, in which case this should be made explicit.
> 
> 6. I highly agree with the text in section 7.3.  I suggest 
> borrowing text 
> from FRF.5.
> 
> That's about it for now.  I'll send more comments as they occur to me.
> 
> Cheers,
> Andy
> 
> -------------------
> 
> At 3/21/2001 01:09 PM -0700, Danny McPherson wrote:
> 
> >Andy,
> >You mentioned "several apparent shortcomings" in the
> >L2TP Service Type draft in the WG session today.  We
> >definitely appreciate your input and ask that you
> >provide the mailing list specific pointers to the
> >problems you see with it.
> >
> >Aslo, if you could provide the list of pointers you
> >mentioned we should be referencing that'd be of
> >great benefit as well.
> >
> >Thanks!
> >
> >-danny
>