Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
draft-ietf-l2tpext-pwe3-fr-07

[Ballot comment]
Said it needed an applicability statement (fidelity to the link behavior) as per the PWE3 charter.
On clearing wrote:

Mark, Carlos, Ron, Margaret,

The new applicability statements are quite good, and
I've clear my Discusses. I just have a question.

They both end by saying that the capabilities of the LCCE (which
I think means RFC 3991) and the underlying PSN may provide
QoS to support features.  In FR: CIR, bc, be, and HDLC: better
faithfulness.

My question is for my better future understanding:  what is the
plane of interaction with the PSN; what RFC 3991 feature or other
channel exists through which the underlying QoS support is possible?
For FR, is support even good for FECN and BECN and DE.  I need
enlightenment here:  I don't have a clear picture about L2TPv3
capability of gathering congestion information from the underlying
PSN.

I'm removing my Discuss because I think the applicability
statements don't make claims that these features are faithfully
provided so much as they state that someone deploying could
do engineering to get some emulation into place.  This is
good enough.  But I'd be curious about the basic approach if
anyone has time to enlighten me :)

Thanks very much for the new sections!

[Ballot discuss]
The Security Considerations in draft-ietf-l2tpext-pwe3-atm-03.txt says:
  >
  > For generic security issues regarding PWs and ATMPWs, this document
  > will eventually refer to documents from the PWE3 WG.
  >
  Clearly, the ATMPW stuff is not applicable to this document, but this
  sentence makes me think that RFC 3931 does not contain all of the
  information about PW security that an implementor needs.

IANA Last Call Comments:
Upon approval of this document the IANA will register a L2TPv3 Pseudowire Type, 3 new Result Code AVP (Attribute Type 1) Values, and a Control Message Attribute Value Pairs in the following registry:
http://www.iana.org/assignments/l2tp-parameters

IETF LC Review:

From: Mark Lewis
To: mark@townsley.net
Cc: iesg@ietf.org
Subject: draft-ietf-l2tpext-pwe3-fr-05.txt

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