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

[Carlos Pignataro <[e-mail]>]

Mark L.,

Please find my comments inline.

Circa 5/26/2005 8:27 AM, W. Mark Townsley said the following:
> 
> 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 <[e-mail]>
> Reply-To: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> 
> 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.’

Please see my comments to this on item #2.

> 
> 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.’ ??

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.

> 
> 
> 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.’

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.

> 
> 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??
> 

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.

> 
> 
> 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?).

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.

> 
> 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!).

`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.

> 
> 
> Anyway, hope that helps,
> 
> Mark
> 
> 
> 
> 
> _______________________________________________
> L2tpext mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

-- 
--Carlos.
Escalation RTP - cisco Systems

_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext