Subject: [ANCP] Guided tour through the latest protocol draft

From: Tom Taylor <[email-masked]>
Date: Tue, 04 Jan 2011 13:43:29 -0500

draft-ietf-ancp-protocol-13 has now been submitted. The biggest changes 
are the ones we discussed on the list:

  -- defining a boundary between the protocol and the control 
application, and removing material that specified behaviour at the level 
of the control application

-- much fuller description of what to do if particular Code values are 
received.

However, there have been lots of smaller changes throughout the 
document, so this is a section-by-section guided tour. I'll use the 
section numbers of version -13 in describing those changes.

Here is the section-by-section review.

1. Introduction

Technical: added the architectural model for the protocol, as proposed 
and agreed on the list. An "oops" just below that -- TLS is mentioned, 
but the Security Considerations section now calls for IPsec instead.

Added the terms "AN-side ANCP agent" and "NAS-side ANCP agent" to denote 
the implementations of the protocol on the AN and NAS respectively.

Editorial: included the "Requirements Language" section in the 
Introduction. We'll see if IDNits lets us do that. Added requirements 
terminology for interaction between the ANCP agent and the control 
application.

In the Terminology subsection, changed the order of the definitions so 
they pass from architecture through protocol to specific technology. 
Changed some of the definitions of terms already defined in the 
framework document to quote directly from that document. Modified the 
RFC 5851 definition of adjacency to use the more specific terminology of 
the present document.

2. Broadband Access Aggregation

Unchanged from old Section 3 except for more specific TR-101 references 
at the end, as requested by Matthew Bocci.

3. Access Node Control Protocol -- General Aspects

This was section 4. Deleted the detailed list of changes from GSMPv3 -- 
I figured this document was addressed to ANCP implementors, not people 
who had implemented GSMP and were modifying it.

Subsections 3.1 through 3.4: no changes.

Subsection 3.5 Use of the GSMPv3 Adjacency Protocol

3.5.1: Moved the text describing the settings of the legacy fields in 
the messages from the procedures subsection to this section. Corrected 
the pType setting as indicated in the reply to Stefaan De Cnodder.

3.5.2: Added text on interactions between the ANCP agent and control 
application, at the beginning and end of the section. Moved timeout 
handling down, to follow logically after negotiation is complete.

Subsection 3.6 ANCP General Message Formats

3.6.1.4: greatly expanded Code field descriptions. Removed Code values 3 
and 4 in favour of 81 and 1280. An "oops" here: 3 and 4 still appear in 
the introductory text. Removed 30 and 31 except in the introductory 
text. Removed 83 because it doesn't seem necessary for the receiver to 
track Transaction IDs, as discussed on the list. Changed 84 to Mandatory 
TLV missing, per Stefaan De Cnodder's comment about the former 
descriptione being inconsistent with the instruction to silently ignore 
unknown TLVs. Added 85.

3.6.1.6: Simplified the requirements for management of Transaction IDs. 
Actually, as far as I can see, the only real requirement is that 
Transaction IDs for the current set of outstanding requests have to be 
unique. We could modify the subsection to say that if people agree.

3.6.1.7: added a little explanation.

3.6.1.8: expanded the definition of Length slightly.

3.6.2: deleted the note in the definition of TLV length, as suggested by 
Matthew Bocci.

Subsection 3.7  General Principles for the Design of ANCP Messages

Moved up from old 6.1.1. Decided that instructions to specification 
writers have to have capitalized SHOULD and MUST, just like instructions 
to protocol implementors, after experience with an AD review of another 
document I'm editing.

4.  Generally Useful ANCP Messages and TLVs

Moved up from old Section 6. It seemed logical to move from the general 
(facilities for all capabilities) to the particular (DSL capabilities).

4.1 Provisioning Message

Added a statement that support of the message is optional except as part 
of a capability the ANCP agent claims to support. Added a statement that 
the message can carry information for more than one capability at once.

4.2 Generic Response Message

Made support of the Generic Response message mandatory. Added access 
line identifying TLVs at the top level (copied from the original request 
if present there). Have a couple of glitches to fix in the figure. Added 
that the contents of the Status-Info depend also on the Code value. 
Prohibited a response to a Generic Response because of an error in the 
latter.

4.3. Target TLV and 4.4. Command TLV

Added a statement that support of the TLV is optional except as part of 
a capability the ANCP agent claims to support.

4.5. Status-Info TLV

Made support of the Status-Info TLV mandatory. Dropped the 
recommendations of what it should contain for given Code values, since 
that is now covered by Code value documentation.

5. Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL)

Made this a separate section to reduce the depth of the header numbers 
in succeeding text. Greatly shortened the introduction because of 
overlap with RFC 5851.

5.1.  DSL Access Line Identification

Created this new subsection because line identifiers are common to all 
of the DSL capabilities.

5.1.1 Control Context
Added a new informative section to describe what the different 
identifier TLVs mean and what the control applications will do with 
them. Gave specific TR-101 references on format but didn't get specific 
on the format itself in this document.

5.1.2 TLVs For DSL Access Line Identification
Gave normative constraints on the identifiers that have to be present in 
a message. Gave the TLV specifications, removing the parts that are the 
responsibility of the control applications. Made the sender-side choice 
between Access-Aggregation-Circuit-ID -Binary and -ASCII an 
implementation decision, on the grounds that they carry the same 
information when everything is taken into account. The receiver has to 
be able to parse both. Added more detail on the construction of the 
-Binary form.

6.  ANCP Based DSL Topology Discovery

Rewritten as discussed on the list. Because of the move of the 
identifier TLVs, the protocol requirements now include a normative 
reference to section 5.1.2.

Made Figure 14 clearer by labelling unused fields and showing the 
identifier TLVs separately from the DSL-Line-Attributes TLV.

7.  ANCP based DSL Line Configuration

Rewritten in a similar spirit to the topology capability. I note that 
the definition of Function doesn't treat the access line identifiers 
properly (assumes there is always just one TLV). I'll fix that.

Tech Type has been removed. The DSL-specific aspect is really the access 
line identifier TLV types. I'm expecting that other access technologies 
may have to introduce new identifier TLV types.

Added a couple of paragraphs at the end of the message description 
(section 7.3) describing reuse of the Port Management message for other 
capabilities. Of course, I have multicast in mind.

Added a statement that line configuration can be done in any line state.

Added a statement that the AN-side agent MUST wait for the AN control 
application to indicate success before replying. This was really to make 
handling of the message consistent with the handling of the Port 
Management (OAM) message, where the delay in replying is essential.

8.  ANCP-Based DSL Remote Line Connectivity Testing

Rewritten in a similar spirit to the topology capability. A lot of 
procedural material previously in the TLV definitions has been moved to 
the Control Context section, since it is the responsibility of the 
control application.

Added a figure for the Port Management (OAM) message, even though it is 
almost the same as the Port Management (line configuration).

Did not add text on reuse for other access technologies -- they probably 
have their own TLVs for line identification and for test parameters.

Added that testing can be attempted regardless of the state of the line, 
but could fail in some states.

Added that the AN-side agent MUST wait for the result from the control 
application before replying.

I need help on the "DSL line status" code values. Are they successes or 
failures? I assume "DSL line integrity error" is a failure, but wasn't 
100% sure. (The testing was successful but the line failed the test.) 
Opinions?

9. IANA Considerations

Deleted a couple of Editor's Notes and updated the Code registry (i.e., 
the Failure Response Message Name registry).

10. Security Considerations

Expanded to list the requirements from RFC 5713, note the vulnerability 
of adjancies to attacks on the TCP session, and describe the IPsec solution.

Tom Taylor