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

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 26 May 2005 08:27:04 -0400

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 <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 26 May 2005 10:51:48 -0400

Mark L.,

Please find my comments inline.

> PVC switching and MAY (must?) participate in LMI with

Please see my comments to this on item #2.

> switching, and do not participate in LMI.’ ??

I agree, a small sentence in Section 1. referencing a "port mode FR"
using HDLC PW would definitely help. I think however that the PVC
granularity and LMI considerations of such case should be covered (as
you already suggested) in the HDLC draft directly and not in the FR one.

> device indicating this status change.’

I personally think that the ACTIVE/INACTIVE states and associated PVC
transitions cover the more generic case, and should be generally used.
However, a small mention reference of FR_LMI <-> FR_PW high level
interaction could help; OTOH, trying to add too many details could end
up causing more confusing when coupled with DCE/DTE or NNI LMIs. So
maybe a single paragraph in Section 3. would work. I also unsure if
LCCEs participating in LMI is a MUST or more likely a MAY.

> it worth explicitly stating somewhere why this is

I think the purpose of the AVP is explicitly stated with:

   The "Frame-Relay Header Length AVP", Attribute type AVP-TBD-1,
   indicates the number of bytes in the Frame Relay header. The two peer
   LCCEs MUST agree on the length of the Frame Relay header.

and the usage description rounds the concept:

   If
   the other LCCE supports a different Frame Relay header length, the
   associated L2TP session MUST be torn down via CDN message with result
   code RC-TBD-3 (see Section 3.2).
   If the Frame-Relay Header Length AVP is not signaled, it MUST be
   assumed that the peer uses a 2-byte Frame Relay header.

It seems to me that the above 2 paragraphs make it clear enough on why
the need and how the usage, and I don't personally think any further
clarifications are needed.

> irrelevant in this context?).

Yes, there is also a 3 byte header format in Q.922. I don't think it's
unsupported or irrelevant (perhaps it is uncommon though). But as long
as the LCCEs agree on the FR Header length it is fine (2, 3 or 4 bytes),
the complete header is transported.
I agree including also the 3-octet header format should be a good
addition for completeness, it would need to be added at the end of
Section 3.5 as well.

> appears (again, this may well be too pedantic/utterly

`FR Header' does refer to the `Q.922 Address field'. This clarification
would possibly be helpful in the second paragraph of Section 4.1, where
the FR Header is referenced in (as stated) "IETF notation".

Thanks !!

--Carlos.

-- 
--Carlos.
Escalation RTP - cisco Systems

---

From: Scott Wainner <[email-masked]>
Date: Thu, 26 May 2005 13:03:56 -0400

Comments in line

>LCCEs participating in LMI is a MUST or more likely a MAY.
I think this should be a MAY.  The PE and CE may disable LMI on the 
port.  Of
course, the granularity of PVC state is restricted to the state of the 
entire port to which the AC's
are attached.

Scott Wainner