Subject: [ANCP] Mandatory TLVs in draft-ietf-ancp-protocol proposal

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 23 Apr 2008 14:53:49 +0200

Hi All,

Continuing with the series of e-mails regarding basic protocol issues
still to be addressed, I now would now like to ask your feedback
regarding the distinction the protocol places on mandatory TLVs. Given
the length of this mail I'll first cut to the proposal, and after it you
can find the problem description.

The proposal which I am putting in front of the WG is to define a new
TLV format which contains at a minimum a Mandatory flag (much like
Radius VSAs do). We could have this TLV Flag be defined only for new
applications.
A second proposal would be try to make this flag work with existing ones
by for example defining the highest order bit of the TLV# field to mean
"Mandatory" when set to "0". This would be invisible to exiting
implementations, but newer ones may have problems in communicating with
older ones when the latter do not send all TLVs. But that can also be
addressed by simply forming the set of mandatory TLVs to be the ones
that all implementations currently send by default.

Without additional feedback, I will assume that the WG is fine with the
first proposal, and also with the 2nd one conditional on deriving a
suitable "commonly used" TLV set.

The problem in more detail: 

Currently the situation is that Mandatory TLVs are only stated to be as
such in the body of the protocol draft spec, with an implementer having
to scour fairly attentively the text. Eg "Type (Access-Loop-Circuit-ID =
0x01): This is a mandatory TLV", etc.

The behaviour of an implementation that receives a message with a
missing mandatory TLV is not defined at all, and the opposite is handled
but not very robustly, i.e. when receiving a TLV but not recognizing it,
and implementation is free to discard it (even if it is mandatory!).
This is a recipe for interoperability problems and an implementation
mine field.
This problem is complicated by different applications. For example the
current OAM section states the following regarding TLVs that are to be
carried in the request message (my italics):
"
Following TLVs can appear in this message: 

       o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1

       o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 
         section 5.4.1. 
 
       o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
section 
         5.4.1.  

       o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related
to  
         loopback test. This is an optional TLV. If this TLV is not
present 
         in the request message, the DSLAM SHOULD use locally determined

         default values for the test parameters.  
"
(NOTE: The last "SHOULD" appears to be inappropriate. If the TLV is
missing, the DSLAM MUST have some default parameters, or return an
error)

The "can" above indicates that they're all optional, while clearly the
application cannot run its course without one or more of these fields.
Here we have a case where one could have a perfectly compliant
implementation that ignores all these TLVs...

-Woj.

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp