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

"John G. Scudder" <jgs@juniper.net> Thu, 01 May 2008 14:52 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 1F2D83A69EE; Thu, 1 May 2008 07:52:22 -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 34C513A69B0 for <idr@core3.amsl.com>; Thu, 1 May 2008 07:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.962
X-Spam-Level:
X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.637, 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 dCHgDlToX7Pn for <idr@core3.amsl.com>; Thu, 1 May 2008 07:52:19 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 22CEB3A69EE for <idr@ietf.org>; Thu, 1 May 2008 07:51:43 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 01 May 2008 07:51:35 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 07:51:43 -0700
Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m41Epgx79222; Thu, 1 May 2008 07:51:42 -0700 (PDT) (envelope-from jgs@juniper.net)
Message-Id: <4E4EA46F-24B0-468C-9C10-67E8E3F07031@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: Paul Jakma <paul@clubi.ie>
In-Reply-To: <alpine.LFD.1.10.0805011147290.12891@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 1 May 2008 10:51:41 -0400
References: <200804301333.m3UDX4x97759@magenta.juniper.net> <4818ACAF.6000306@cisco.com> <52EEA4F2-1AC8-4625-9922-9558B39253B5@bgp.nu> <alpine.LFD.1.10.0805011147290.12891@localhost.localdomain>
X-Mailer: Apple Mail (2.919.2)
X-OriginalArrivalTime: 01 May 2008 14:51:43.0476 (UTC) FILETIME=[DF010B40:01C8AB9A]
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 Paul,

The paragraph actually refers to the "Capabilities Optional Parameter"  
itself within the OPEN message, i.e. OPEN parameter type 2.  RFC 4271  
and its predecessors don't fully specify the handling of OPEN optional  
parameters, and in specific are silent as to whether a given OPEN  
optional parameter can appear more than once, so Enke's suggestion  
amounts to doing that here, which seems reasonable under the  
circumstances.

Here's a revised paragraph, see if it's clearer:

   The Capabilities Optional Parameter (OPEN parameter type 2) 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 as TLVs within
   a single 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 TLVs.  The set of
   capabilities should be processed the same in either case, whether it
   is enumerated within a single Capabilities Optional Parameter of the
   OPEN message, or split across multiple.

Thanks for the feedback!

--John

On May 1, 2008, at 6:51 AM, Paul Jakma wrote:

> Hi John,
>
> Could it be made slightly clearer that it means the same parameter  
> type? (Yeah, seems obvious once you think about it, but it could  
> perhaps make a difference to tired readers :) ). E.g. something like:
>
> On Wed, 30 Apr 2008, 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
>                                             ^
>                                          for a given type
>
>
>>  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.
>                                                      ^
>                                                  , for a given type
>
> regards,
> -- 
> Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr