Subject: Comments on draft-ietf-bmwg-fr-00.txt

From: David Newman <[email-masked]>
Date: Wed, 24 Feb 1999 22:47:51 -0500

Fellow BMWGers,

I'd like to offer a few comments on draft-ietf-bmwg-fr-00.txt, the frame
relay terminology draft.

Section 1. 
There is a statement that the document will contain background and
definitions, but I don't see the background discussion. 

Given the huge amount of interest in mapping various classes of IP
traffic over frame relay networks, it would be helpful to include some
context for this document.

Section 2. 
This is a nit, but the first paragraph advises that RFCs 1242 and 1944
"should be consulted." Then the authors raise RFC 2285, but do not
recommend whether it too should be consulted--which is strange
considering that it is the only layer-2 document of the bunch. Surely
this was an oversight. For brevity's sake it might be best to include a
single statement that all three RFCs should be consulted.

Section 2.II
It is implied but not stated explicitly that performance metrics are the
second of two classes of terms to be defined.

Section 2.II.1 (?)
I'm having a hard time following the numbering scheme. It might be best
to  label the definitions as section 3.X, as is done in RFC 1242.

Section 1.2.1 BECN
Three comments here. First, it might be helpful to include an ASCII
representation of a frame relay header showing the location of the BECN,
FECN, and DE bits.

Second, the definition states that BECN "is" set. My experience with
frame relay equipment is that not all devices will set the BECN, FECN,
or DE bits during periods of congestion, even though they're supposed
to. It might be advisable to use MUST or SHOULD in place of "is" here.

Third, if any of the terms given are defined in specific Frame Relay
Forum documents, this should be explicitly stated (e.g., FRF.8).

All three comments pertain to most definitions in the draft.

Section 1.2.2 CIR
This definition probably belongs in the performance metrics section.

Section 1.2.5 Frame
This definition might distinguish between between a frame relay header
and  a payload of user data, or if no payload is mandatory make that
clear.

1.2.6 Frame relay
Might make clear that frame relay is a link-layer interface.

1.X
I would also include definitions for a couple of terms with specific
meanings in a frame relay context:

Congestion
Port speed

2.2 Definitions of performance metrics
Besides the CIR definition given above, I would also include definitions
for other terms:

Burst excess (B(e), sometimes called excess information rate or EIR)
Discardable traffic above B(e)
Network interworking (FRF.5)
Service interworking (FRF.8)
Availability (FRF.13)

Regards,
David Newman

---

From: Jeffrey Dunn <[email-masked]>
Date: Thu, 25 Feb 1999 11:03:24 -0500

David,

Thank you for your comments on the FR draft.  I agree with most of your
comments.  Our intent in splitting the documents was to stimulate
seperate discussions of ATM and FR and, hopefully, find someone to
either take over the FR draft or work with us on it.  If you would like
to assume either of these roles, we would be most appreciative.  Our
responses to your comments are included below.

Regards,

Jeff and Cynthia

> context for this document.

See above statement of intent.

> single statement that all three RFCs should be consulted.

Agreed.

> second of two classes of terms to be defined.

Not exactly.  We are refering to QoS and traffic contract metrics.  The
discussions attached to these definitions associate them with TCP and IP
performance.  It is not the intent of this document to provide FR
performance metrics.

> to  label the definitions as section 3.X, as is done in RFC 1242.

This is the kind of editorial issue with which we would like some help.

> representation of a frame relay header showing the location of the BECN,

Agreed.  See above.

> to. It might be advisable to use MUST or SHOULD in place of "is" here.

In principle, I agree that it would be nice if network equipment acted
in this fashion; however, this is a terminology document.  This sort of
requirement is appropriate for the methodology document.

> Forum documents, this should be explicitly stated (e.g., FRF.8).

Agreed.

> This definition probably belongs in the performance metrics section.

I disagree.  CIR is not a metric, it is traffic contract parameter. 
There will be an associated metric, e.g., frames per second, which will
depend on the CIR.

> and  a payload of user data, or if no payload is mandatory make that

I am not sure what you are getting at.  An IP datagram with a zero
length payload is still a valid datagram.  I see no reason to specify
payload lengths in a terminology document.  This is handled in
methodology documents.

> Might make clear that frame relay is a link-layer interface.

OK.  Unfortunately, I could not find a neato diagram like the B-ISDN
model in any of the FRF literature.  If you have one, please forward it
to me with the reference.

> meanings in a frame relay context:

Agreed.

> Service interworking (FRF.8)

Agreed.

Would you provide definitions for the terms which you requested be
included in the document.  Thanks.