Subject: [CCAMP] Can format of BGP-4 Capabilities Advertisement be used in LMP-behavior negotiation?

From: Dan Li <[email-masked]>
Date: Thu, 11 Nov 2010 11:29:37 +0800

Hi all,

During the meeting, Lou suggested to consider if the format of BGP-4 capabilities advertisement could be used in LMP-behavior negotiation draft.

Comparing the format of BGP Capabilities Option Parameter with the format defined in LMP-behavior draft, the only difference is "Capability Value" which is the description of the Capabilities. So the question is: Do we need the description of LMP behavior?

If yes, we will go the format of RFC 3392.
Otherwise, we should keep the current format defined in LMP-Behavior draft.

Any other comments?

Thanks,

Dan and Daniele

I have captured the relevant section from RFC3392: 
==========
4. Capabilities Optional Parameter (Parameter Type 2):

   This is an Optional Parameter that is used by a BGP speaker to convey
   to its BGP peer the list of capabilities supported by the speaker.

   The parameter contains one or more triples <Capability Code,
   Capability Length, Capability Value>, where each triple is encoded as
   shown below:

       +------------------------------+
       | Capability Code (1 octet)    |
       +------------------------------+
       | Capability Length (1 octet)  |
       +------------------------------+
       | Capability Value (variable)  |
       +------------------------------+

   The use and meaning of these fields are as follows:

      Capability Code:

         Capability Code is a one octet field that unambiguously
         identifies individual capabilities.
      Capability Length:

         Capability Length is a one octet field that contains the length
         of the Capability Value field in octets.

      Capability Value:

         Capability Value is a variable length field that is interpreted
         according to the value of the Capability Code field.

   BGP speakers SHOULD NOT include more than one instance of a
   capability with the same Capability Code, Capability Length, and
   Capability Value.  Note however, that processing of multiple
   instances of such capability does not require special handling, as
   additional instances do not change the meaning of announced
   capability.

   BGP speakers MAY include more than one instance of a capability (as
   identified by the Capability Code) with non-zero Capability Length
   field, but with different Capability Value, and either the same or
   different Capability Length.  Processing of these capability
   instances is specific to the Capability Code and MUST be described in
   the document introducing the new capability.
==========

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Nov 2010 12:38:37 +0800

Dan,
     Just a slight clarification. I suggested 3392 *style* capabilities 
advertisement, and do not think we must use the identical format.

That said, I agree with you on the basic question, i.e.:
   Does LMP need to exchange configuration parameters in a generic fashion?

Lou

On 11/11/2010 11:29 AM, Dan Li wrote:
>     The parameter contains one or more triples<Capability Code,

---

From: Dan Li <[email-masked]>
Date: Thu, 11 Nov 2010 15:07:44 +0800

Lou,

Yes, you're right! It's not required to use the identical format which is defined in 3392.

But we need answer the question: Does LMP need to exchange configuration parameters in a generic fashion?

Thanks,

Dan

在 2010-11-11，下午12:38， Lou Berger 写道：

> Dan,
>     Just a slight clarification. I suggested 3392 *style* capabilities advertisement, and do not think we must use the identical format.
>