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

Enke Chen <enkechen@cisco.com> Wed, 30 April 2008 21:48 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 7E4213A6A4E; Wed, 30 Apr 2008 14:48:12 -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 8EE263A6A23 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 14:48:11 -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 jzISdKF+Wii8 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 14:48:10 -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 0F6393A6961 for <idr@ietf.org>; Wed, 30 Apr 2008 14:48:10 -0700 (PDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2008 14:48:12 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3ULmCkR008734; Wed, 30 Apr 2008 14:48:12 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3ULmCNK003793; Wed, 30 Apr 2008 21:48:12 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 14:48:12 -0700
Received: from [10.21.69.88] ([10.21.69.88]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 14:48:11 -0700
Message-ID: <4818E960.70107@cisco.com>
Date: Wed, 30 Apr 2008 14:49:20 -0700
From: Enke Chen <enkechen@cisco.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "John G. Scudder" <jgs@bgp.nu>
References: <200804301333.m3UDX4x97759@magenta.juniper.net> <4818ACAF.6000306@cisco.com> <52EEA4F2-1AC8-4625-9922-9558B39253B5@bgp.nu>
In-Reply-To: <52EEA4F2-1AC8-4625-9922-9558B39253B5@bgp.nu>
X-OriginalArrivalTime: 30 Apr 2008 21:48:12.0031 (UTC) FILETIME=[E2EE30F0:01C8AB0B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5159; t=1209592092; x=1210456092; c=relaxed/simple; s=sjdkim2002; 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=T+55zSlPMeZGgyUzgkxxCOxMJ+ifsVpw6W+mFtDg4QE=; b=sz8fDbnsGcvb9gcA90DAMBa6Ksr/CrkIW9YF8/vCR5qfi/okxUAC5H3yWN rSeECPjCnCM9UuoqoMV45OP0S0aA9khDxf6NhZUsgMj1zrk7M+FjfUXQun5T eu67UhG4PR;
Authentication-Results: sj-dkim-2; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
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

Hi,. John:

It looks good.

Thanks.   -- Enke

John G. Scudder wrote:
> 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