Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-

"John G. Scudder" <jgs@bgp.nu> Wed, 30 April 2008 21:30 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE193A6BA4; Wed, 30 Apr 2008 14:30:51 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34C03A6D81 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 14:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Level:
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ3oYFSb4K3O for <idr@core3.amsl.com>; Wed, 30 Apr 2008 14:30:50 -0700 (PDT)
Received: from bgp.nu (bgp.nu [64.27.28.76]) by core3.amsl.com (Postfix) with ESMTP id E89D53A694A for <idr@ietf.org>; Wed, 30 Apr 2008 14:30:49 -0700 (PDT)
Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 72D3A53E1B5; Wed, 30 Apr 2008 17:30:52 -0400 (EDT)
X-Virus-Scanned: amavisd-new at bgp.nu
Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id nmNSeLESSbL4; Wed, 30 Apr 2008 17:30:46 -0400 (EDT)
Received: from [172.16.13.201] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 86E6353E1AF; Wed, 30 Apr 2008 17:30:45 -0400 (EDT)
Message-Id: <52EEA4F2-1AC8-4625-9922-9558B39253B5@bgp.nu>
From: "John G. Scudder" <jgs@bgp.nu>
To: Enke Chen <enkechen@cisco.com>
In-Reply-To: <4818ACAF.6000306@cisco.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 17:30:44 -0400
References: <200804301333.m3UDX4x97759@magenta.juniper.net> <4818ACAF.6000306@cisco.com>
X-Mailer: Apple Mail (2.919.2)
Cc: Yakov Rekhter <yakov@juniper.net>, idr@ietf.org
Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-rfc3392-bis-
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Enke,

Would adding this paragraph at the end of section 4 cover your point?

    The Capabilities Optional Parameter SHOULD only be included in the
    OPEN message once.  If the BGP speaker wishes to include multiple
    capabilities in the OPEN message, it SHOULD do so as discussed  
above,
    by listing all those capabilities within the same Capabilities
    Optional Parameter.  However, for backward compatibility a BGP
    speaker MUST be prepared to receive an OPEN message which contains
    multiple Capabilities Optional Parameters, each of which contains  
one
    or more capabilities.  The set of capabilities should be processed
    the same in either case, whether the it is listed within a single
    Capabilities Optional Parameter, or within multiple.

Thanks,

--John

On Apr 30, 2008, at 1:30 PM, Enke Chen wrote:

> Hi, folks:
>
> While we are at it, I suggest that we also clarify on the encoding of
> the capabilities.  Currently there exist two encodings for  
> capabilities
> in the "Optional Parameters" field of the OPEN message, and both are
> deployed:
>
> (1) List the capabilities in one "optional parameter":
>
>      Parm. Type - capability
>      Parm. Length
>      cap_1, cap_1_len, cap_1_value
>      ...
>      cap_n, cap_n_len, cap_n_value
>
> (2) List the capabilities in multiple "optional parameters":
>
>      Parm. Type - capability
>      Parm. Length
>      cap_1, cap_1_len, cap_1_value
>      ...
>      Parm. Type - capability
>      Parm. Length
>      cap_n, cap_n_len, cap_n_value
>
> Ideally #1 is more correct for TLV encoding.  But we started with  
> #2 :-(
>
> I suggest that we add some text in the document to point out their
> existence and state that both types MUST be accepted.
>
> Thanks.   -- Enke
>
> Yakov Rekhter wrote:
>> Folks,
>>
>> There is a request (see attached) to accept draft-scudder-idr- 
>> rfc3392-bis
>> as an IDR WG item. Please send your comments to the list. The  
>> deadline
>> for comments is May 14.
>>
>> Yakov.
>> ------- Forwarded Message
>>
>> Date:    Tue, 29 Apr 2008 14:51:16 -0400
>> From:    "John G. Scudder" <jgs@bgp.nu>
>> To:      idr <idr@ietf.org>
>> Subject: [Idr] Fwd: New Version Notification for draft-scudder-idr- 
>> rfc3392-bis-
>> 	  00
>>
>> Folks,
>>
>> I've done some minor updates to the Capabilities Advertisement
>> specification to address confusion about the "Unsupported Capability"
>> NOTIFICATION message:
>>
>> 	Appendix B.  Comparison with RFC 3392
>> 	
>> 	   In addition to minor editorial changes, this document also  
>> clarifies
>> 	   the use of the Unsupported Optional Parameter NOTIFICATION  
>> message,
>> 	   and updates references to the base BGP-4 specification  
>> [RFC4271] and
>> 	   security analysis [RFC4272].
>>
>> The draft is at http://www.ietf.org/internet-drafts/draft-scudder-idr-rfc3392-b
>> is-00.txt
>> .
>>
>> Comments welcome.  One thing that occurred to me was to rename
>> "Unsupported Capability" to "Required Capability Missing", however
>> that might do more harm than good by renaming an existing code point,
>> so I didn't.
>>
>> I'd like to propose this as a WG item (if indeed such a request is
>> even required for an update to an existing WG document?).
>>
>> Thanks,
>>
>> - --John
>>
>> Begin forwarded message:
>>
>>
>>> From: IETF I-D Submission Tool <idsubmission@ietf.org>
>>> Date: April 29, 2008 2:41:21 PM GMT-04:00
>>> To: jgs@juniper.net
>>> Cc: rchandra@sonoasystems.com
>>> Subject: New Version Notification for draft-scudder-idr-rfc3392- 
>>> bis-00
>>>
>>>
>>> A new version of I-D, draft-scudder-idr-rfc3392-bis-00.txt has been
>>> successfuly submitted by John Scudder and posted to the IETF
>>> repository.
>>>
>>> Filename:	 draft-scudder-idr-rfc3392-bis
>>> Revision:	 00
>>> Title:		 Capabilities Advertisement with BGP-4
>>> Creation_date:	 2008-04-29
>>> WG ID:		 Independent Submission
>>> Number_of_pages: 7
>>>
>>> Abstract:
>>> This document defines an Optional Parameter, called Capabilities,
>>> that is expected to facilitate the introduction of new capabilities
>>> in the Border Gateway Protocol (BGP) by providing graceful  
>>> capability
>>> advertisement without requiring that BGP peering be terminated.   
>>> This
>>> document obsoletes RFC 3392.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>> ------- End of Forwarded Message
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr