Subject: Questions about draft-ietf-l2tpext-atmext-04.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 09 Aug 2001 00:20:08 +0100

I have 2 issues about the atmext extensions draft. Apologies for an inexcusable
delay in posting these to the list explicitly. Let me reiterate that there are
many very good things in this document that need standardizing, but I still have
some issues (2) that have not been fully resolved in my mind. If WG consensus is
for me to shut up and go away about this, I will, but I cannot in good faith
give this doc my personal blessing at the moment.

Here are the issues:

Issue #1

   "Within the ICRQ, the LAC MUST indicate a broadband bearer in the
   Bearer Type AVP (B bit set to 1), MAY include the Service Category
   AVP, and MAY include the Service Name AVP. If the LNS would not
   support the B Bearer bit, it will return an error on the ICRQ
   message. In such a case, the implementation MAY decide to fall back
   to digital bearer capability, and SHOULD refrain from using the
   extensions defined within this document. "

I suspect that interoperabilty with the bearer capability bits here is or will
be an issue. I mentioned a long time ago that I was concerned about relying on
this, and that concern has only become stronger. This text assumes that an
implementation will return an error if it does not understand the B bit. I doubt
that is truly the case in all of our implementations today. In fact, we decided
at a bakeoff sometime ago to relegate the Bearer Capabilties bits to only be
relevant for outgoing calls. It seems you are suggesting on relying on the
Capabilities bits for more than this.

Many people have implemented PPPoATM to PPPoL2TP tunneling, I am curious how
many implementations actually care if the B bit is set, or even set it
themselves?

It seems that the only real use for the B bit here is to identify whether or not
the additional AVPs in this doc will be understood or not. To some extent, I'm
not sure why that is an issue since if the AVPs are non-mandatory they will be
ignored anyway. You don't really need these extensions to properly process the
L2TP data packets at the LNS. Even so, if you want to advertise the existance of
a particular feature (in this case, the ability to understand these new AVPs) it
is probably better to use the presence of an AVP (mandatory if you don't want to
continue if the feature is not present) to advertise this. The AVP parsing
methods have been through far more interoperability testing, and the result of
new AVPs is far more deterministic now than a bit in the Capabilities AVP. B
bits for Capability advertisement are best left to outgoing call support only.
In this regard, setting a B bit here is fine, I just don't see any reason to
depend on it for incoming calls, to ever tear down the session if it is not
present, or tie it to whether or not to use the other AVPs identified in this
document.

Further, the actual location of the B bit in the mask is defined in the
document, where it should actually be a "TBD" for IANA to assign. There is
already a conflict, l2tp-bis defines a "V-bit" in the same spot and should
follow the same advice I state here (and we will).

Issue #2  Service Category AVP - A 16-bit mask is used here. I have since
learned that bits are a real pain for IANA to assign. Could we just use an
integer (or byte?).

Thanks,

- Mark