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

From: Yakov Rekhter <[email-masked]>
Date: Wed, 30 Apr 2008 06:33:04 -0700

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" <[email-masked]>
To:      idr <[email-masked]>
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 <[email-masked]>
> Date: April 29, 2008 2:41:21 PM GMT-04:00
> To: [email-masked]
> Cc: [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Danny McPherson <[email-masked]>
Date: Wed, 30 Apr 2008 08:02:37 -0600

> as an IDR WG item. Please send your comments to the list. The deadline

I support this as an IDR WG item.

One minor comment..   I think we should rename "Unsupported Capability"
to "Required Capability Missing", and given that the codepoint itself  
isn't
changing, just the descriptor, there should be no issues here.

-danny

---

From: Enke Chen <[email-masked]>
Date: Wed, 30 Apr 2008 10:30:23 -0700

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

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 Apr 2008 17:30:44 -0400

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

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 Apr 2008 17:31:11 -0400

> changing, just the descriptor, there should be no issues here.

Clearly this is OK by me if the WG is happy with it.

--John

---

From: Enke Chen <[email-masked]>
Date: Wed, 30 Apr 2008 14:49:20 -0700

Hi,. John:

It looks good.

Thanks.   -- Enke

John G. Scudder wrote:
>    capabilities in the OPEN message, it SHOULD do so as discussed above,
>    multiple Capabilities Optional Parameters, each of which contains one
>>> The draft is at 
>>> http://www.ietf.org/internet-drafts/draft-scudder-idr-rfc3392-b
>>> is-00.txt
>>> .
>>>