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

Enke Chen <enkechen@cisco.com> Wed, 30 April 2008 17:29 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 3ABF53A69C9; Wed, 30 Apr 2008 10:29:16 -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 4F73C3A680C for <idr@core3.amsl.com>; Wed, 30 Apr 2008 10:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ukyMjS6bk--D for <idr@core3.amsl.com>; Wed, 30 Apr 2008 10:29:13 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8E55E3A6849 for <idr@ietf.org>; Wed, 30 Apr 2008 10:29:13 -0700 (PDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2008 10:29:16 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3UHTGq1003985; Wed, 30 Apr 2008 10:29:16 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3UHTGsD013508; Wed, 30 Apr 2008 17:29:16 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 10:29:15 -0700
Received: from [10.21.69.88] ([10.21.69.88]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 10:29:15 -0700
Message-ID: <4818ACAF.6000306@cisco.com>
Date: Wed, 30 Apr 2008 10:30:23 -0700
From: Enke Chen <enkechen@cisco.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Yakov Rekhter <yakov@juniper.net>
References: <200804301333.m3UDX4x97759@magenta.juniper.net>
In-Reply-To: <200804301333.m3UDX4x97759@magenta.juniper.net>
X-OriginalArrivalTime: 30 Apr 2008 17:29:15.0369 (UTC) FILETIME=[B65BB590:01C8AAE7]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3747; t=1209576556; x=1210440556; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20<enkechen@cisco.com> |Subject:=20Re=3A=20[Idr]=20Fwd=3A=20New=20Version=20Notifi cation=20for=09draft-scudder-idr-rfc3392-bis- |Sender:=20; bh=DAoe0ca1d1R+KDgoiGTONe/EXkU+MrZLJwn75HH0bq0=; b=uJAWlUqXtEr1Sci1bGiKv9i6J/i3rPFGHOYXYvnJPQrY7GYO/G5H1RT5qA b98nw72Z3yvr8XLkwYsiSvec5xbTzSCET6T1+K/4TDN2xaxSpeNKf5JN6zg8 iNwVKXkf2kBP82wEwnP/dH9n74LGXHv9kE/wzUNhXchWlJ5y1FzA8=;
Authentication-Results: sj-dkim-1; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: 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

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