[L2tpext] [Fwd: draft-ietf-l2tpext-pwe3-fr-05.txt]

Forwarding to l2tpext for comments there. Thanks for the review, Mark.

- Mark

-------- Original Message --------
Subject: draft-ietf-l2tpext-pwe3-fr-05.txt
Date: Thu, 26 May 2005 00:50:05 +0100
From: Mark Lewis <mark@mjlnet.com>
Reply-To: mark@mjlnet.com
To: mark@townsley.net
CC: iesg@ietf.org

Hi Mark,

Here's a review of draft-ietf-l2tpext-pwe3-fr. Apologies if
some of my comments are off-the-mark as I unfortunately had
to review it in haste.

It seems like another very good draft to me. Just one or two
relatively minor comments:

1.

Is it worth mentioning in the introduction that, ‘LCCEs
supporting Frame Relay DLCI pseudowires perform Frame Relay
PVC switching and MAY (must?) participate in LMI with
connected CE devices.’

Also, might it be worth mentioning in the introduction
that, ‘Frame Relay traffic may also be transported between
LCCEs using an HDLC pseudowire [draft-ietf-l2tpext-pwe3-
hdlc]. When Frame Relay traffic is transported over an HDLC
pseudowire, however, LCCEs do not perform Frame Relay PVC
switching, and do not participate in LMI.’ ??

2.

In section 3, might it be worth stating that, ‘LCCEs MAY
[must?] participate in FR Local Management Interface [LMI].
An LCCE MAY transmit an SLI message indicating a change in
the status of the local PVC as the result of the reception of
an LMI message. Similarly, an LCCE receiving an SLI
indicating a change in status of a FR PVC (on a remote LCCE)
MAY send a corresponding LMI message to its connected CE
device indicating this status change.’

The above wording may well be a little rough, but in general
might it be worth explicitly mentioning *possible*
interaction between LMI and SLI on LCCEs?

3.

In section 3.5, is it worth explicitly stating the purpose of
the FR header length AVP somewhere (or is in the draft
elsewhere, and I just missed it?!)? Obviously, this AVP is
used to advertise the FR header length between LCCEs, but is
it worth explicitly stating somewhere why this is
necessary/desirable??

4.

In section 4.1 support for 2 and 4 byte FR headers are
discussed. Off the top of my head, isn’t there is also a 3
byte header format(Q.922)? Might it be an idea to state why
the 3 byte header format is not supported (or why it is
irrelevant in this context?).

Also, (and I am admittedly being pedantic here!) the
words ‘FR header’ obviously (I think!) refer to the FR
Address field. Would it be a good idea to change ‘FR header’
to ‘FR header (Address Field)’ at least the first time it
appears (again, this may well be too pedantic/utterly
unnecessary!).

Anyway, hope that helps,

Mark

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext