Subject: [Idr] draft-rekhter-rfc4760bis-01

From: Yakov Rekhter <[email-masked]>
Date: Wed, 6 Oct 2010 09:00:59 -0700

Folks,

I'd like to ask the IDR WG to accept draft-rekhter-rfc4760bis-01 as
an IDR WG item.

Yakov.
------- Forwarded Message

Date:    Wed, 06 Oct 2010 08:46:52 -0700
From:    IETF I-D Submission Tool <[email-masked]>
To:      [email-masked]
cc:      [email-masked], [email-masked], [email-masked]
Subject: New Version Notification for draft-rekhter-rfc4760bis-01 

A new version of I-D, draft-rekhter-rfc4760bis-01.txt has been successfully sub
mitted by Yakov Rekhter and posted to the IETF repository.

Filename:	 draft-rekhter-rfc4760bis
Revision:	 01
Title:		 Multiprotocol Extensions for BGP-4
Creation_date:	 2010-10-06
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, L3VPN, etc...). The extensions are backward compatible - a
router that supports the extensions can interoperate with a router
that doesn't support the extensions.

The IETF Secretariat.

------- End of Forwarded Message

---

From: Enke Chen <[email-masked]>
Date: Wed, 06 Oct 2010 09:07:10 -0700

Support.

-- Enke

On 10/6/10 9:00 AM, Yakov Rekhter wrote:
> From:    IETF I-D Submission Tool<[email-masked]>
> To:      [email-masked]
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "iLya" <[email-masked]>
Date: Wed, 6 Oct 2010 18:10:45 +0200

support

/iLya

--------------------------------------------------
From: "Yakov Rekhter" <[email-masked]>
Sent: Wednesday, October 06, 2010 6:00 PM
To: <[email-masked]>
Subject: [Idr] draft-rekhter-rfc4760bis-01

---

From: John Scudder <[email-masked]>
Date: Wed, 6 Oct 2010 10:04:59 -0700

Folks,

Please send your comments by October 21.

Thanks,

--John

---

From: Heath Jones <[email-masked]>
Date: Wed, 6 Oct 2010 18:34:44 +0100

Support.

---

From: Marco Rodrigues <[email-masked]>
Date: Wed, 6 Oct 2010 22:24:29 -0400

Support.

On 10/6/10 12:00 PM, "Yakov Rekhter" <[email-masked]> wrote:

Folks,

Yakov.

Abstract:

The IETF Secretariat.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 7 Oct 2010 07:43:35 +0200

support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marco Rodrigues
Sent: donderdag 7 oktober 2010 4:24
To: [email-masked]
Cc: Yakov Rekhter
Subject: Re: [Idr] draft-rekhter-rfc4760bis-01

Support.

Folks,

Yakov.

Abstract:

The IETF Secretariat.

---

From: Mohan Nanduri <[email-masked]>
Date: Thu, 7 Oct 2010 21:23:03 -0400

Support.

---

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 11 Oct 2010 06:40:55 +0000

> I'd like to ask the IDR WG to accept draft-rekhter-rfc4760bis-01 as

+1

-- 
	Aleksi Suhonen, Researcher
	Department of Communications Engineering
	Tampere University of Technology

---

From: Jie Dong <[email-masked]>
Date: Mon, 11 Oct 2010 19:36:46 +0800

Hi Yakov,

Some small nits:

1. Section 10, the first paragraph, the second "MP_REACH_NLRI" should be
"MP_UNREACH_NLRI"

2. Section 10, the first paragraph, s/ NLIR/ NLRI

Besides, I note that the description about the reserved field in Capability
Advertisement (Section 8) is unchanged:

        " Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender
         and ignored by the receiver.

         Note that not setting the field value to 0 may create issues
         for a receiver not ignoring the field. In addition this
         definition is problematic if it is ever attempted to redefine
         the field."

I'm not sure if there is some implementation which can cause issues with
this field not setting to zero. But this description makes it impossible to
redefine this field. If there is no such inappropriate implementation, I
would recommend not to forbid the redefining of this field.

Best regards,
Jie

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yakov
> Rekhter
> Sent: Thursday, October 07, 2010 12:01 AM
> To: [email-masked]
> A new version of I-D, draft-rekhter-rfc4760bis-01.txt has been
successfully
> sub

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 12 Oct 2010 07:18:38 -0700

Jie,

> 1. Section 10, the first paragraph, the second "MP_REACH_NLRI" should be

Fixed.

> 2. Section 10, the first paragraph, s/ NLIR/ NLRI

Fixed.

> would recommend not to forbid the redefining of this field.

Are you proposing that we delete the whole paragraph starting with "Note that
not setting..." ? If yes, then I would like to get more comments on
this topic from other folks before actually making the change.

Yakov.

---

From: John Scudder <[email-masked]>
Date: Tue, 12 Oct 2010 09:13:50 -0700

> would recommend not to forbid the redefining of this field.

Seems to me as though this can be addressed by changing the SHOULD to a MUST: "MUST be set to 0 by the sender and MUST be ignored by the receiver."  As far as I'm concerned the "note that" paragraph is entirely optional.  In any case it's informative, not normative.  For that matter I don't think "this definition is problematic if it is ever attempted to redefine the field", it seems to have the same characteristics as any other set of flags.  Since the paragraph seems to be confusing, maybe it should just be removed.

As usual, the way you would introduce new flags to the field is by revising the spec.  The "MUST be ignored" is what makes this (reasonably) safe.

--John

---

From: Jie Dong <[email-masked]>
Date: Wed, 13 Oct 2010 09:19:26 +0800

> Seems to me as though this can be addressed by changing the SHOULD to a
> MUST: "MUST be set to 0 by the sender and MUST be ignored by the
receiver."
 
Agreed. 

> As far as I'm concerned the "note that" paragraph is entirely optional.
In any
> case it's informative, not normative.  For that matter I don't think "this
> definition is problematic if it is ever attempted to redefine the field",
it seems
> to have the same characteristics as any other set of flags.  Since the
paragraph
> seems to be confusing, maybe it should just be removed.

> As usual, the way you would introduce new flags to the field is by
revising the
> spec.  The "MUST be ignored" is what makes this (reasonably) safe.

Agreed, IMO this reserved field could have the same characteristics with
reserved fields in other specifications, so the "note that" paragraph may
just be removed.

Best regards,
Jie

---

From: Jie Dong <[email-masked]>
Date: Wed, 13 Oct 2010 09:28:16 +0800

Hi Yakov,

> this topic from other folks before actually making the change.

I agree with John's thoughts on this, maybe it would be better to change the
'SHOULD' to 'MUST', and remove 'note that' paragraph, as long as it would
not affect existing implementations.

Best regards,
Jie

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 13 Oct 2010 03:31:57 +0000

> Please send your comments by October 21.

I support adoption of this draft as a WG item.

-- Jeff

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 13 Oct 2010 11:48:35 +0200

> 1. Section 10, the first paragraph, the second "MP_REACH_NLRI" should be

The first paragraph of section 10 is still confusing:
   This document explicitly spells out that receiving an UPDATE message
   that carried MP_REACH_NLRI or MP_UNREACH_NLRI that carries no NLRI must
   not be treated as an error.

On my first read I was not sure if "that carries no NLRI" belongs to the
MP_REACH_NLRI or MP_UNREACH_NLRI attributes or the UPDATE itself. Sure the
typo in the draft may have added a lot of additional confusion. Still
this paragraph should probably be reworded.

The last paragraph of section 7 is confusing as well:

   If a BGP speaker receives from a neighbor an UPDATE message that
   contains a valid MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if
   the speaker determines that the attribute is received with no NLRI,
   the speaker MUST NOT treat this UPDATE message as a BGP error, and
   specifically MUST NOT terminate the BGP session over which the UPDATE
   was received, and MUST NOT ignore all the subsequent routes received
   over that session with the AFI/SAFI carried in the attribute.  This
   is irrespective of whether the received message contains any non-
   empty Withdrawn Routes, and/or non-empty Network Layer Reachability
   Information fields.

Again it is confusing if NLRI means the MP NLRI in the attribute ot the
IPv4 NLRI after the attributes. In the first sentence it should be made
clear that no NLRI means no NLRI in the MP attribute (e.g. an emtpy
MP_UNREACH_NLRI).
And I think the last sentence should have a "contains any non-empty
non-multiprotocol ..." since this seems to be there to cover the non MP
case.

-- 
:wq Claudio