Subject: [ANCP] Redundant extension block length value in base protocol document

From: Tom Taylor <[email-masked]>
Date: Tue, 16 Feb 2010 11:36:12 -0500

I'm trying to understand how to set the Block Length field following Tech Type 
in the Port Management message. This field is specified in section 5.4.1.1 of 
the base ANCP protocol document. Since this field is only eight bits wide, it 
limits the extension block length to 255 bytes.

The first word of the Extension Value also has a block length field, this time 
16 bits wide. Presumably this has a maximum value of 251 (255 bytes minus the 
Extension Value header width of 4 bytes). Can this be confirmed?

This length limit for the Extension Block has consequences for the stuff that 
has to fit in there. In particular, the multicast extensions document currently 
says that the Multicast-Service-Profile-Name value is limited to 255 bytes. 
Taking the above limits into account, that drops to 247 bytes (accounting for 
the TLV header). We probably want to drop this limit further to make sure there 
is enough space in the Extension Block for other service data that needs to be 
configured.

Alternatively, the Block Length field following the Tech Type field can be 
deprecated, allowing the Extension Block to be much larger.

Tom Taylor

---

From: Sidd Aanand <[email-masked]>
Date: Tue, 16 Feb 2010 12:07:49 -0500

Tom,

The Block length field seems redundant. The base document says the following:

***
First 2 byte of the "Extension Value" contains the number
of TLVs that follow.  The next 2 bytes contain the total length of
the TLVs carried in the extension block in bytes (existing "Block
Length" field in the GSMP message is limited to 255 bytes and is not
sufficient). 
***

So, it seems like the whole idea behind the extension block length was to work around the 255-byte-max limit.

Even the Extension block length is redundant too, in my mind. The information contained is # of TLVs, along with the length field in each TLV is sufficient for the receiver of the message to parse and read all the TLVs. Isn't it? So, what is the benefit of having the extension block length?

Anyway, I am okay with deprecating the block-length field.

Thanks,
Sidd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Tuesday, February 16, 2010 11:36 AM
To: [email-masked]
Subject: [ANCP] Redundant extension block length value in base protocol document

I'm trying to understand how to set the Block Length field following Tech Type in the Port Management message. This field is specified in section 5.4.1.1 of the base ANCP protocol document. Since this field is only eight bits wide, it limits the extension block length to 255 bytes.

The first word of the Extension Value also has a block length field, this time
16 bits wide. Presumably this has a maximum value of 251 (255 bytes minus the Extension Value header width of 4 bytes). Can this be confirmed?

This length limit for the Extension Block has consequences for the stuff that has to fit in there. In particular, the multicast extensions document currently says that the Multicast-Service-Profile-Name value is limited to 255 bytes. 
Taking the above limits into account, that drops to 247 bytes (accounting for the TLV header). We probably want to drop this limit further to make sure there is enough space in the Extension Block for other service data that needs to be configured.

Alternatively, the Block Length field following the Tech Type field can be deprecated, allowing the Extension Block to be much larger.

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

---

From: "Shridhar Rao (shrirao)" <[email-masked]>
Date: Thu, 25 Feb 2010 14:03:10 +0530

https://datatracker.ietf.org/doc/draft-ancp-restart/

Hello,
We are working on a update for this draft (which I will publish after
the Anaheim meeting) and like to get any feedback from the Working group
so I can consider them before publishing the new revision. 
Please send your comments if any.
Regards,
-shridhar