Subject: RE: [ANCP] comments on draft-ietf-ancp-protocol-01

From: "Sanjay Wadhwa" <[email-masked]>
Date: Mon, 29 Oct 2007 02:59:25 -0400

Hi Stefaan
  Thanks for the comments. I think this fell through and most likely
didn't get a response earlier. Picking it now (responses inline). 

Regards
-Sanjay

>-----Original Message-----
>From: Stefaan DE CNODDER [mailto:[email-masked]]
>Sent: Monday, August 27, 2007 3:21 AM
>To: [email-masked]
>Subject: [ANCP] comments on draft-ietf-ancp-protocol-01
>
>
>
>Hi,
>
>I have a number of comments on draft-ietf-ancp-protocol-01:
>
>1) There are some inconsistencies in terminology with the framework
>document:  The framework talks about CPE and HGW while the protocol
>draft uses the terms DSL modem, RG, and subscriber devices (see fig.1).
>  Best to allign with the framework document.  Also in section  4.5,
>second paragraph the term CPE is used while this is called the HGW in
>the framework document and in the framework, CPE means something else.

Agreed, we will allign with the framework draft.

>2) although the draft is not anymore based on
>draft-ietf-gsmp-v3-base-spec but on RFC 3292 instead, it is still using
>a number of extensions defined in that draft, which do not make sense
>anymore:

Far as I can see, nothing below impacts existing protocol operation.
However, some of the changes/additions will make the spec better. Where
ever it makes sense, we will consider changing/clarifying in the next
rev.

>2a) Tech type in section 5.4.1.1: tech type 1-4 were defined in
>draft-ietf-gsmp but not in RFC 3292 so it makes no sense in saying that
>these are already in use by other technologies.  Just make them
>reserved.  Also tech type 0xff is not in use by the base spec (which is
>RFC 3292).

We know for a fact that type 1-4 have been reserved for use by other
technologies (such as L2 switching). I don't see a drawback in
explicitly calling it out.

>2b) Message format on page 24: The "block length" field was defined in
>draft-ietf-gsmp but not in RFC 3292.  Since this field is only 1 byte
>and not sufficient for ANCP, the ANCP protocol draft defines a new
>length field of 2 bytes.  Since the GSMP draft does not exist anymore,
>it makes no sense in keeping the original 1-byte "block length" field.
>Better to call this 1-byte field now "Reserved"

This shouldn't have any impact on existing implementations. If there are
no objections, we can change the field to be called "reserved" in the
next rev.

>2c) The X-Function field on page 32 is not used by ANCP and is also not
>defined by RFC 3292.  It looks better to me to use the original GSMP
>message format in this case by using a 2 byte Function field.

This could be of use in the future to pass any "function" specific data.
1 byte for the main function field seems sufficient. We would prefer to
leave this alone.

>2d) Like the message on page 24, also the message format on page 32 has
>a 1-byte Block length field that is better renamed to "Reserved".

Same comment as 2b.

>3) Section 5.2 says that the pType field should be set to 0.  Is this
>also the case when partitions are used?  The framework mentions
>partitions and I believe the protocols spec should support 
>partitions as
>well.

We need to allow setting the pType appropriately (including non-zero) to
control partition-ID assignment as specified in the GSMPv3 RFC.  

>4) Section 5.3: ANCP should be extensible to support multiple
>technologies but I do not see how the capability message can 
>be extended
>with multiple technologies because it looks that only 1 techtype can be
>put in the message.  Is it the intention that when there is a second
>technogoly, then there are 2 independent capability 
>negotiations (with 2
>different messages?  This comment does not apply to other messages
>because for instance in a PORT UP, there will always only be 1 
>technology.

Not sure this is an issue. Capability TLVs are carried in the adjacency
message. Adjacency is between BNG and AN (or a partition on an AN). We
are stipulating an AN (or partition on AN) to pertain to a particular
technology type, which seems reasonable (and is typical).

>5) Related to bulk transaction messages:
>
>5a) For the bulk transaction message, what should be the result if 1 
>message fails?  I guess the whole bulk message would fail but 
>is there a 
>specific code for it?

Each message specific response in the bulk transaction message would
contain individual code and result field to signify success or failure
for that message (same as what would have been sent for each message if
there was no bulking). Individual failure is not construed as a failure
of the bulk transaction message. 

>
>5b) can PORT UP or DOWN messages also be part of a bulk transaction? 
>And what about OAM?  I believe the bulk transaction is only for Line 
>configuration messages?

Port up or down messages can also be part of bulk transaction.

>6) For line configuration, an unknown TLV is to be ignored.  Would it 
>not be better for these TLVs to have a result field per TLV such that 
>the NAS knows which configuration is done, and which not?  For PORT UP 
>it is not relevant because the AN does not have to know what 
>the NAS is 
>doing with the information but for line configuration this 
>looks different.

Ideally whatever has been successfully set should be exposed via the MIB
(and made visible to the EMS). 
However, the port-mgmt messages can request a response. For an unknown
TLV (which is silently ignored on the AN), we can set an appropriate
error code, and the response message can contain the unknown TLV
(reflected back). If there is agreement, this can be added.

>7) action 0x8 defined in section 5.4.3 is already in use by RFC 3292

Good catch. We will need to change this in the draft.

>8) The IANA considerations section looks incomplete to me:
>
>8a) Besides of defining new numbers for Tech-type, ..., also a 
>complete 
>new name space has to be defined and maintained by IANA.

Yes. A value ("DSL") and type (number = 0x05) needs to be reserved.

>8b) the name spaces for result field and code field should be modified 
>because ANCP is changing the length of these fields, and hence 
>also the 
>numbers that can be assigned for it.  The name spaces "failure 
>response 
>message" and "Result type" have to be redefined.

Yes, the result and code values need to be reserved with IANA. Whatever
is defined in the RFC fits the size for the result field as defined in
the darft, and we will attempt to retain those values. Same for the
code.

>8c) 0x81 failure code to be assigned by IANA, also the OAM codes.

Yes, these need to be added to IANA consideration section explicitly
(section 5.4.4 does call out for reserving the OAM codes with IANA). 

>
>regards,
>Stefaan
>
>
>
>_______________________________________________
>ANCP mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ancp
>

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