Subject: [ANCP] Comment on draft-ietf-ancp-protocol-05.txt

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 16 Mar 2009 16:26:59 +0100

Sanjay, Roberta,

I have some comments on the latest ANCP protocol draft, specifically
related to protocol versioning.

I know that we discussed this a while ago and decided that we would use
the GSMPv3.1 versioning convention of a 4-bit version field and a 4-bit
sub-version. This gives a header that looks like the following:

 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, the protocol draft is very explicit that ANCP is based on
GSMPv3, but the header for GSMPv3 is:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    | Message Type  |    Result     |     Code      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Clearly the version numbers are completely incompatible. This means that
not only is an ANCP implementation not interoperable with GSMPv3 and it
is not clear what an ANCP implementation will do with a GSMP v3 message
if it receives it.

Section 5 provides some guidance as to what to set the version and
sub-version fields to. However, since this is the first use of this
version format, I think it would be helpful to define an IANA registry
for the version and sub-version values.

Please can you also add a statement early in the document (e.g. in the
introduction) that although ANCP is based on GSMPv3, it is not
interoperable with GSMPv3 defined in RFC3292.

Also, in Section 6, please correct "Global Switch Management Protocol
version 3 (GSMPv3)" to "General Switch Management Protocol version 3
(GSMPv3)".

Regards

Matthew

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 17 Mar 2009 11:51:44 +0100

Hello Matthew,
     thanks for your comments, please see answers in line [RM].
Regards,
Roberta
________________________________________
From: BOCCI Matthew [mailto:[email-masked]]
Sent: Monday, March 16, 2009 4:27 PM
To: Sanjay Wadhwa; Maglione Roberta
Cc: [email-masked]
Subject: Comment on draft-ietf-ancp-protocol-05.txt

Sanjay, Roberta,
I have some comments on the latest ANCP protocol draft, specifically related to protocol versioning.
I know that we discussed this a while ago and decided that we would use the GSMPv3.1 versioning convention of a 4-bit version field and a 4-bit sub-version. This gives a header that looks like the following:
 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           |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
However, the protocol draft is very explicit that ANCP is based on GSMPv3, but the header for GSMPv3 is:
 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  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    | Message Type  |    Result     |     Code      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clearly the version numbers are completely incompatible. This means that not only is an ANCP implementation not interoperable with GSMPv3 and it is not clear what an ANCP implementation will do with a GSMP v3 message if it receives it.
Section 5 provides some guidance as to what to set the version and sub-version fields to. However, since this is the first use of this version format, I think it would be helpful to define an IANA registry for the version and sub-version values.

[RM] Ok we will add ANCP specific IANA registry for the version and sub-version values in next version of the draft.

Please can you also add a statement early in the document (e.g. in the introduction) that although ANCP is based on GSMPv3, it is not interoperable with GSMPv3 defined in RFC3292.
[RM] Ok  we will add this clarification in the introduction.

Also, in Section 6, please correct "Global Switch Management Protocol version 3 (GSMPv3)" to "General Switch Management Protocol version 3 (GSMPv3)".
[RM] Ok, thanks.

Regards
Matthew

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Shridhar Rao (shrirao)" <[email-masked]>
Date: Fri, 20 Mar 2009 14:44:39 +0530

Hi Francois ,  et al , 
 
Queries/comments/observations :

1. Program limit (I guess the number of multicast flows allowed for a
subscriber ) - It is mentioned only once in the draft. There is no TLV
mentioned for this. Is this to be configured locally on AN? 

2. Timing of bandwidth reallocation and multicast admission control
messages : if AN is waiting for a response to bandwidth reallocation can
it send MCAST admission control in the middle (for the same subscriber
port)? What happens if the NAS answers positively to the Mcast Admission
control message (i.e. Access Control is OK) but responds negatively to
the Bandwidth Allocation message (and thus AN has to reject flow).

The draft mentions running a timer at AN after it sends a Multicast
admission control but how long can we wait at AN for bandwidth
reallocation response?

3. What would happen when bandwidth delegation control TLV is turned on
whereas the capability negotiated between AN and NAS through
transactional multicast cap. is only 2 (meaning no bandwidth delegation
but only admission control) ?

If the negotiated Capability is not equal to 3, then NAS should not send
bandwidth delegation TLV to activate it.

4. Discovering IPV6 multicast joins/leaves:  Perhaps it wouldn't hurt to
replace "IGMP" by "IGMP/MLD" everywhere so we keep it clear.

Thanks and regards,

-shridhar-