Subject: Re: [ANCP] Comments on draft-ietf-ancp-protocol-12.txt

From: Tom Taylor <[email-masked]>
Date: Sun, 02 Jan 2011 21:18:00 -0500

Thanks once again for your comments. My dispositions indicated below.

On 05/10/2010 10:16 AM, Bocci, Matthew (Matthew) wrote:
> Authors,
>
> As a part of my role as shepherd for the ANCP protocol draft, I have reviewed it and provide comments in the attached. Many of these are just editorial, but some also pertain to, and probably overlap with the other comments that have been provided so far regarding clarification of what is mandatory and what is optional.
>
> My comments are prefixed by 'MB>'.
>
> Please can you address these comments in an new version of the draft before I forward to the IESG for publication.
>
> Best regards
>
> Matthew
>
> ------------------------------------------------------
>
>
>
>
> Network Working Group                                         S.  Wadhwa
> Internet-Draft                                                J. Moisand
> Intended status: Standards Track                        Juniper Networks
> Expires: February 25, 2011                                      T.  Haag
>                                                          Deutsche Telekom
>                                                                  N. Voigt
>                                                    Nokia Siemens Networks
>                                                            T. Taylor, Ed.
>                                                       Huawei Technologies
>                                                           August 24, 2010
>
> MB>  Please update Sanjay's affiliation to Alcatel-Lucent

[PTT] Done.

...
>
> 2.1.  Terminology
>
>     Access Node (AN):  Network device, usually located at a service
>        provider central office or street cabinet that terminates access
>        (local) loop connections from subscribers.  In case the access
>        loop is a Digital Subscriber Line (DSL), the Access Node provides
>        DSL signal termination, and is referred to as a DSL Access
>        Multiplexer (DSLAM).
>
>     Network Access Server (NAS):  Network element which aggregates
>        subscriber traffic from a number of Access Nodes.  The NAS is an
>        injection point for policy management and IP QoS in the access
>        ^^^^^^^^^
> MB>  I would suggest using ther term 'enforcement' rather than 'injection'.

[PTT] Done.

>
>        network.  It is also referred to as a Broadband Network Gateway
>        (BNG) or Broadband Remote Access Server (BRAS).
>
>
>     Home Gateway (HGW):  Network element that connects subscriber devices
>        to the Access Node and the access network.  In the case of DSL,
>        the Home Gateway is a DSL network termination that may operate
>        either as a layer 2 bridge or as a layer 3 router.  In the latter
>        case, such a device is also referred to as a Routing Gateway (RG).
>
>     Net Data Rate:  portion of the total data rate of the DSL line that
>        can be used to transmit actual user information (e.g.  ATM cells
>        of Ethernet frames).  It excludes overhead that pertains to the
>        ^^
> MB>s/of/or
>

[PTT] Done.

>        physical transmission mechanism (e.g. trellis coding in case of
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011               [Page 6]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>        DSL).  This is defined in section 3.39 of ITU-T G.993.2.
>
>     DSL line (synch) rate:  the total data rate of the DSL line,
>        including the overhead attributable to the physical transmission
>        mechanism.
>
>     DSL multi-pair bonding:  method for bonding (or aggregating) multiple
>        xDSL lines into a single bi-directional logical link, henceforth
>        referred to in this draft as "DSL bonded circuit".  DSL "multi-
>        pair" bonding allows an operator to combine the data rates on two
>        or more copper pairs, and deliver the aggregate data rate to a
>        single customer.  ITU-T recommendations G.998.1 and G.998.2
>        respectively describe ATM and Ethernet based multi-pair bonding.
>
>     Type-Length-Value (TLV):  a data structure consisting of a sixteen-
>        bit type field, a sixteen-bit length field, and a variable-length
>        value field padded to the nearest 32-bit word boundary, as
>        described in Section 4.6.2.  The value field of a TLV can contain
>        other TLVs.  An IANA registry is maintained for values of the ANCP
>        TLV Type field.
>
>     ANCP Protocol Capability:  A detailed specification of ANCP messages,
>        message content, and procedures required to implement a specific
>        use case or set of use cases.  ANCP capabilities may be specific
>        to one access technology or technology independent.  The set of
>        capabilities applicable to a given ANCP session are negotiated
>        during session startup.
>
>     ANCP session (also called an adjacency):  A session between a NAS and
>        an Access Node, beginning with the initiation of the transport
>        connection by the AN, passing through adjacency negotiation,
>        discovery and provisioning stages, and continuing with service
>        control and possible OAM operations until the transport connection
>        is terminated.  There may be more than one ANCP session active
>        between the NAS and a given AN due to partitioning.
>
> MB>  Please add formal references to the ITU-T Recommendations mentioned above.

[PTT] Done.

>
> 3.   Broadband Access Aggregation
>
> 3.1.  ATM-based broadband aggregation
>
>     The end to end DSL network consists of network service provider (NSP)
>     and application service provider (ASP) networks, regional/access
>     network, and customer premises network.  Figure 1 shows ATM broadband
>     access network components.
>
>     The regional/access network consists of the regional network, Network
>     Access Server (NAS), and the access network as shown in Figure 1.
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011               [Page 7]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>     Its primary function is to provide end-to-end transport between the
>     customer premises and the NSP or ASP.
>
>     The Access Node terminates the DSL signal.  It may be in the form of
>     a DSLAM in the central office, or a remote DSLAM, or a Remote Access
>     Multiplexer (RAM).  The Access Node is the first point in the network
>     where traffic on multiple DSL lines will be aggregated onto a single
>     network.
>
>     The NAS performs multiple functions in the network.  The NAS is the
>     aggregation point for subscriber traffic.  It provides aggregation
>     capabilities (e.g.  IP, PPP, ATM) between the Regional/Access Network
>     and the NSP or ASP.  These include traditional ATM-based offerings
>     and newer, more native IP-based services.  This includes support for
>     Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet
>     (PPPoE), as well as direct IP services encapsulated over an
>     appropriate layer 2 transport.
>
>     Beyond aggregation, the NAS is also the injection point for policy
>                                             ^^^^^^^^^
> MB>

                                          enforcement?

[PTT] Done.

>     management and IP QoS in the regional/access networks.  To allow IP
>     QoS support over an existing non-IP-aware layer 2 access network
>     without using multiple layer 2 QoS classes, a mechanism based on
>     hierarchical scheduling is used.  This mechanism, defined in
>     [TR_059], preserves IP QoS over the ATM network between the NAS and
>     the routing gateway (RG) at the edge of the subscriber network, by
>     carefully controlling downstream traffic in the NAS, so that
>     significant queuing and congestion does not occur further down the
>     ATM network.  This is achieved by using a diffserv-aware hierarchical
>     scheduler in the NAS that will account for downstream trunk
>     bandwidths and DSL synch rates.
>
>     [RFC5851] provides detailed definition and functions of each network
>     element in the broadband reference architecture.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011               [Page 8]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>                                Access                   Customer
>                         <--- Aggregation -->   <------- Premises ------->
>                                Network                   Network
>
>                         +------------------+ +--------------------------+
>     +---------+   +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
> NSP|         | +-|NAS|-| |ATM  |-|Access| --||DSL  |-|HGW|-|Subscriber||
> ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices   ||
>     |Broadband| | +---+ |         +------+ | |+-----+       +----------+|
> ASP|Network  |-+-|NAS| +--------------|---+ +--------------------------+
> ---+         | | +---+                |     +--------------------------+
>     |         | | +---+                |     |+-----+ +---+ +----------+|
>     +---------+ +-|NAS|                +-----|| DSL |-|HGW|-|Subscriber||
>                   +---+                      ||Modem| +---+ |Devices   ||
>                                              |+-----+       +----------+|
>                                              +--------------------------+
>   HGW   : Home Gateway
>   NAS   : Network Access Server
>
>
>                 Figure 1: ATM Broadband Aggregation Topology
>
> 3.2.  Ethernet-based broadband aggregation
>
>     The Ethernet aggregation network architecture builds on the Ethernet
>     bridging/switching concepts defined in IEEE 802.  The Ethernet
>     aggregation network provides traffic aggregation, class of service
>     distinction, and customer separation and traceability.  VLAN tagging
>     defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as
>     standard virtualization mechanism in the Ethernet aggregation
>     network.  The aggregation devices are "provider edge bridges" defined
>     in IEEE 802.ad.
>
>     Stacked VLAN tags provide one possible way to create equivalent of
>     "virtual paths" and "virtual circuits" in the aggregation network.
>     The "outer" vlan can be used to create a form of "virtual path"
>     between a given DSLAM and a given NAS.  "Inner" VLAN tags create a
>     form of "virtual circuit" on a per DSL line basis.  This is the 1:1
>     VLAN allocation model.  An alternative model is to bridge sessions
>     from multiple subscribers behind a DSLAM into a single VLAN in the
>     aggregation network.  This is the N:1 VLAN allocation model.
>     Architectural and topological models of an Ethernet aggregation
>     network in context of DSL aggregation are defined in [TR_101].
>
> MB>  Please add specific references to the Ethernet concepts described above.
>
[PTT] Replaced the final sentence with:

"Section 1.6 of <xref target="TR-101"/> provides brief definitions of
these two models, while section 2.5.1 describes them in more detail."

...
>
> 4.5.2.  ANCP Adjacency Procedures
>
>     The NAS MUST set the M-flag in the SYN message (signifying it is the
>     master).  Once the adjacency is established, periodic adjacency
>     messages (type ACK) MUST be exchanged.  The default for the ACK
>     interval to be advertised in the adjacency messages is 25 seconds for
>     ANCP.  The actual value SHOULD be configurable and is an
>     implementation choice.  It is RECOMMENDED that both ends specify the
>     ^^^^^^^^^^^^^^
> MB>  If it is configurable, then it is a deployment choice rather than an
>      implementation choice.
>
[PTT] Fixed as suggested.
>
>
>   Wadhwa, et al.         Expires February 25, 2011              [Page 15]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>     same timer value; to achieve this, each end SHOULD compare the timer
>     value in the first adjacency message it receives with its own
>     preferred value and agree to use the higher of the two values.  That
>     is, the node that receives a higher timer value than its own SHOULD
>     reply in its subsequent adjacency messages (such as SYNACK, ACK) with
>     the higher timer value.
>
>     In the adjacency protocol the version and sub-version fields are used
>     for version negotiation.  The version negotiation is performed before
>     synchronisation is achieved.  In a SYN message the version/
>     sub-version fields always contain the highest version understood by
>     the sender.  A receiver receiving a SYN message with a version/
>     sub-version higher than it understands MUST silently discard that
>     message.  A receiver receiving a SYN message with a version/
>     sub-version within the range of versions that it understands MUST
>     reply with a SYNACK with the version/sub- version from the received
>     SYN in its ANCP version/sub-version fields.  This defines the
>     version/sub-version of the ANCP protocol to be used while the
>     adjacency remains synchronised.  All other ANCP messages within the
>     session MUST use the agreed version in the version/sub-version
>     fields.
>
>     The semantics and suggested values for the Code, Sender Name,
>     Receiver Name, Sender Instance, and Receiver Instance fields are as
>     defined in Section 11 of [RFC3292].  The Sender Port, and Receiver
>     Port SHOULD be set to 0 by both ends.  The pType field SHOULD be set
>     to 0 (No Partition).  The pFlag SHOULD be set to 1 (New Adjacency).
>
>     If the adjacency times out on either end, due to not receiving an
>     adjacency message for a duration of (3 * Timer value), where the
>     timer value is specified in the adjacency message, all the state
>     received from the ANCP neighbor SHOULD be cleaned up, and the TCP
>     connection SHOULD be closed.  The NAS MUST continue to listen for new
>     connection requests.  The AN MUST try to re-establish the TCP
>     connection and both sides MUST attempt to re-establish the adjacency.
>
>     The handling defined above will need some modifications when ANCP
>     graceful restart procedures are defined.  These procedures will be
>     defined in a separate document.
>
> MB>  The above paragraph should be removed as we do not currently have an
> MB>  active GR draft. It is up to any future GR document to state
> MB>  whether it modifies/updates the procedures in this document.
>
[PTT] Done.

>     Both the NAS and the Access Node MUST advertise supported
>     capabilities in the adjacency messages they send.  The same message
>     MAY advertise capabilities for any mixture of access technologies.
>     If a received adjacency message indicates no support for a capability
>     that is supported by the receiving device, it MUST turn off the
>                                                        ^^^^^^^^
> MB>                                                    disable?
>
[PTT] Done.

>     capability locally and MUST send an updated adjacency message with
>     the corresponding capability field omitted to match the received
>     capability set.  This process will eventually result in both sides
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011              [Page 16]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>     agreeing on the maximal common set of supported capabilities.  The
>     adjacency MUST NOT come up if that common set is empty.
>
>     After initial synchronization, if at any time a capability mismatch
>     is detected, the adjacency MUST be brought down (RSTACK MUST be
>     generated by the device detecting the mismatch), and synchronization
>     MUST be re-attempted.
>
> 4.6.  ANCP General Message Formats
>
>     This section describes the general format of ANCP messages other than
>     the adjacency messages.
>
>     The GSMPv3 general message format, used by all GSMP messages other
>     than adjacency protocol messages, is defined in Section 3.1.1 of
>     GSMPv3 [RFC3292].  ANCP modifies this base GSMPv3 message format as
>     shown in Figure 5.
>
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Vers  |  Sub  | Message Type  | Result|        Code           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Partition ID  |            Transaction Identifier             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |I|      SubMessage Number      |           Length              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        ~                          Message Payload                      ~
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                     Figure 5: ANCP General Message Format
>
> 4.6.1.  The ANCP Message Header
>
> MB>  A geneal comment on this section:
>      - Please clarify what is mandatory and what is optional. e.g.
>        It is unclear whether a sender MUST support result codes, and what
>        a receiver MUST do with them. Are they just logged in a MIB, or somehting else?
>        Please calrify,
>
[PTT] As far as general support, you'll find the "MUSTs" in the 
descriptions of the individual messages. Example from the documentation 
of the Provisioning message:
"The message header field settings given below are REQUIRED in the
    Provisioning message.  The remaining message header fields MUST be
    set as specified in Section 3.6.1."
As you know, the documentation of Code values has been much expanded.

>     The immediately visible differences from GSMPv3 are the subdivision
>     of the Version field into version and sub-version, and the
>     reallocation of space between Result and Code to enlarge the range
>     for Code.  The 8-bit version field in the base GSMPv3 message header
>     is split into two 4 bit fields for carrying the version and a sub-
>     version of the ANCP protocol.  The Result field in the message header
>     has been modified to be 4 bits long, and the Code field to be 12 bits
>     long.
>
>     A complete explanation of the header fields is as follows:
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011              [Page 17]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>     Version and Sub-version:  The version of the ANCP protocol that was
>        agreed for the session during adjacency negotiation.  For the
>        values that must be placed into these fields, see Section 4.1.
>
>     Message Type:  The ANCP message type.  Message type values are
>        registered in a common GSMPv3/ANCP IANA registry.
>
>     Result:  The Result field is derived from GSMPv3 [RFC3292].  Ignore
>        (0x0) is a new value added by ANCP.  The remaining Result values
>        below are a subset of those defined for GSMPv3.  GSMPv3 expected
>        the sender of a request to choose between NAck (0x1) and AckAll
>        (0x2) according to its needs.  ANCP specifies what Result value
>        each request should have.  Responses indicate either Success (0x3)
>        or Failure (0x4) as the case may be.
>
>        Ignore:  Res = 0x0 - Ignore this field on receipt and follow the
>           procedures specified for the received message type.
>
>        Nack:  Res = 0x1 - Result code indicating that no response is
>           expected to the message other than in cases of failure caused
>           during the processing of the message contents or of the
>           contained directive(s).
>
>        AckAll:  Res = 0x2 - Result code indicating that a response to the
>           message is requested in all cases.
>
>        Success:  Res = 0x3 - Set in a response message by the receiver of
>           a request to indicate successful execution of all directives in
>           the corresponding request message.
>
>        Failure:  Res = 0x4 - Set in a response message by the receiver of
>           a request to indicate either that there was an error in the
>           content of the request message or that one or more directives
>           in the corresponding request could not be executed
>           successfully.
>
>     Code:  This field gives further information concerning the result in
>        a response message.  It is mostly used to pass an error code in a
>        failure response but can also be used to give further information
>        in a success response message or an event message.  In a request
>        message, the Code field is not used and MUST be set to zero.
>
>        ANCP implementations MAY use any of the Code values specified in
>        the IANA registry "Global Switch Management Protocol version 3
>        (GSMPv3) Failure Response Message Name Space" if they appear
>        applicable.  In particular, the values:
>
>
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011              [Page 18]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>        2  Invalid request message (i.e., a properly formed message which
>           violates the protocol through its timing or direction of
>           transmission)
>
>        4  One or more of the specified ports do not exist
>
>        6  One or more of the specified ports are down
>
>        7  Invalid Partition ID
>
>        19 Out of resources (e.g. memory exhausted, etc.)
>
>        30 The limit on the maximum number of point-to-multipoint
>           connections that the switch can support has been reached
>
>        31 The limit on the maximum number of branches that the specified
>           point-to-multipoint connection can support has been reached
>
>        may unfortunately apply to ANCP usage, where "Port" is interpreted
>        to mean an access line or a Target as defined in Section 6.2.1.
>
>        Instead of the value:
>
>        3  The specified request is not implemented on this switch
>
>        specified by [RFC3292], this specification defines a new value:
>
>        81 Request message type not implemented
>
> MB>    Please use normative specification language. I assume that this
> MB>    means that 3 MUST NOT be used, and instead ANCP MUST use 81?

[PTT] Currently the document says: "3 or 81 (latter preferred)".
>
>        This value MAY be sent in a failure response from either the AN or
>        the NAS.  This specification also defines the additional values:
>
>        82 Transaction identifier out of sequence
>
>        83 Malformed message
>
>        84 TLV or value not supported by negotiated capability set
>
>
>        ANCP extensions defining new code values SHOULD use the range 256
>        (0x100) through 511 (0x1FF) for this purpose.
>
>        The range of values from 256 to 4095 is reserved for IETF use.
>
> MB>  It is not clear what the above means. Do you mean that ANCP uses 256 -
> MB>  511, and that the allocation procedure for 256-511 is IETF consensus?
>
[PTT] Changed to "IETF Consensus".

>
>
>     Partition ID:  This field is a 8 bit number which signifies a
>        partition on the AN.
>
>        The AN and NAS may agree on the partition ID using one of the
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011              [Page 19]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>        following possible options:
>
>        1 -  The partition ID may be configured on the AN and learned by
>           the NAS in the adjacency message;
>
>        2 -  The partition ID may be statically configured on the NAS as
>           part of configuring the neighbor information.
>
>     Transaction ID:  24-bit field set by the sender of a request message
>        to associate a response message with the original request message.
>        Unless otherwise specified for a given message type, the
>        Transaction ID in request messages MUST be set to a value in the
>        range (1, 2^24 - 1).  When used in this manner, the Transaction ID
>        sequencing MUST be maintained independently for each ANCP
>        adjacency and per message type.  Furthermore, it SHOULD be
>        incremented linearly for each new message of the given type,
>        cycling back to 1 after running the full range.  Each Transaction
>        ID sequence SHOULD be reinitialized to a random non-zero value
>        when an adjacency is negotiated.  For event messages, the
>        Transaction ID SHOULD be set to zero.
>
>        Unless otherwise specified, the default behaviour for all ANCP
>        responses is that the value of the Transaction ID MUST be copied
>        from the corresponding request message.
>
>     I flag and SubMessage Number:  An ANCP implementation SHOULD set the
>        I Flag and subMessage Number fields to 1 to signify no
>        fragmentation.
>
>     Length:  Length of the ANCP message including its header fields and
>        defined ANCP message body.
>
> 4.6.2.  The ANCP Message Body
>
>     The detailed contents of the message payload portion of a given ANCP
>     message may vary with the capability in the context of which it is
>     being used.  However, the general format consists of zero or more
>     fixed fields, followed by a variable amount of data in the form of
>     Type-Length-Value (TLV) data structures.
>
>     The general format of a TLV is shown in Figure 6:
>
>
>
>
>
>
>
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011              [Page 20]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |     Type (IANA registered)    |          Length               |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                                                               |
>         ~                            Value                              ~
>         ~                                                               ~
>         |                                                               |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                         Figure 6: General TLV Format
>
>     The fields of a TLV are defined as follows:
>
>     Type:  The TLV Type is a 16-bit unsigned value identifying the TLV
>        type and nature of its contents.  An IANA registry has been
>        established for ANCP TLV Type codes.
>
>     Length:  The number of bytes of data in the Value field of the TLV,
>        excluding any padding required to bring this TLV to a 4-byte word
>        boundary (see "Value" below).  If a TLV contains other TLVs, any
>        padding in the contained TLVs MUST be included in the value of
>        Length.
>
>           If the TLV contains another TLV followed by other data, the
>           outer TLV will not be properly parsable unless Length is set as
>           indicated; if the interior padding is omitted from Length, as
>           many bytes of data at the end of the outer TLV will be missed.
>           If the outer TLV contains another TLV as its final field it
>           requires no padding of its own (since the contained TLV
>           including padding ends on a 4-byte boundary).  In this case the
>           issue is one of consistency rather than parsability, since the
>           padding of that final TLV could be omitted from Length without
>           loss of data.
>
> MB>  the above paragraph seems redundant. I suggest removing it.

[PTT] Done.
>
>        Depending on the specification of the TLV, the value of Length may
>        be zero, a constant for all instances of the TLV, or a varying
>        quantity.
>
>     Value  The actual data carried by the TLV, if any.  The value field
>        in each TLV MUST be padded with zeroes as required to align with a
>        4-byte word boundary.  The Value field of a TLV may include fixed
>        fields and/or other TLVs.
>
>     Unless otherwise specified, TLVs MAY be added to a message in any
>     order.  If the recipient of a message does not understand a
>     particular TLV, it MUST silently ignore it.
>
>
>
>
>   Wadhwa, et al.         Expires February 25, 2011              [Page 21]
>
> Internet-Draft                ANCP Protocol                  August 2010
>
>
>     A number of TLVs are specified in the remainder of this document.
>
>
> 5.  ANCP Capabilities For Digital Subscriber Lines (DSL)
>
> 5.1.   Overview
>
> MB>  This section should be simplified and should reference RFC5851. i think it
> MB>  would be better if this section simply summarised the pertinent
> MB>  points from the framework.

[PTT] Did a major truncation, then pulled the definition of the access 
identifiers into this sectionb for common use by all the DSL capabilities.
...
>
> 5.2.  ANCP Based DSL Topology Discovery
>
> 5.2.1.   Goals
>
> MB>  Again, it would be better if this section simply refereced the framework
> MB>  with some summary text.

[PTT] Done.
...
>
> 5.2.3.2.1.  Procedures
>
> MB>  It is not clear what is mandatory to implement (i.e. MUST) if you support
> MB>  this use case. Please clarify the minimum to implement (i.e. MUST)
> MB>  and optional (i.e. SHOULD/MAY etc).

[PTT] I think that is done with the new text.
...

---

From: <[email-masked]>
Date: Mon, 3 Jan 2011 11:42:58 +0100

Tom,
thanx for this detailed work.

I checked chapter 8.5.1.

Here I found a comment from Immo Wetzel NSN(12th of Nov 2010)mentioning that length should be changed from 2 to 4 bytes. 

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tom Taylor
Gesendet: Montag, 3. Januar 2011 03:18
An: Bocci, Matthew (Matthew)
Cc: Wadhwa, Sanjay (Sanjay); [email-masked]; [email-masked]
Betreff: Re: [ANCP] Comments on draft-ietf-ancp-protocol-12.txt

[PTT] Done.

...

[PTT] Done.

[PTT] Done.

[PTT] Done.

                                          enforcement?

[PTT] Done.

...
[PTT] Done.

[PTT] Done.

[PTT] Done.

...

[PTT] Done.
...

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 03 Jan 2011 08:33:04 -0500

Unfortunately that directly contradicts the definition of length for a 
TLV. The definition excludes padding. Take a look at the 
Access-Loop-Encapsulation TLV for another example.

...