RE: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt

["Jan Novak \(janovak\)" <[e-mail]>]

 

> 
> On Thu, 23 Sep 2004, Manav Bhatia wrote:
> > > This seems to change the way BGP works in a relatively fundamental
> > > way, and I don't see sufficient justification for the proposed
> > > changes.

I would say that the need for it has been established by the "industry"
over the pass few years already (just that apparently not that easy to
resolve) - few examples could be different VPNv4
scenarios with RRs, the possible say generic IPv4 routing non-optimality
when
RR in use and also possible resolution of BGP oscillation problems
reported
in several RR/confed scenarios just as a list from the top of one's
head.

> AS-paths and nexthops, because the nexthops are being used.  I ask you
> which spec says there will be multiple BGP next-hops to begin with.

Nothing to be specified it just happens in the networks ??

Jan

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA27970 for <[e-mail]>; Thu, 30 Sep 2004 08:07:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCzh6-0001c6-W7; Thu, 30 Sep 2004 08:05:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCzdO-0000pC-1O for [e-mail]; Thu, 30 Sep 2004 08:02:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13580 for <[e-mail]>; Thu, 30 Sep 2004 08:02:04 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCzlb-0005kU-TX for [e-mail]; Thu, 30 Sep 2004 08:10:37 -0400
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Sep 2004 14:10:36 +0200
X-BrightmailFiltered: true
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8UC10Va011933; Thu, 30 Sep 2004 14:01:29 +0200 (MEST)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0);  Thu, 30 Sep 2004 14:01:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Date: Thu, 30 Sep 2004 14:01:20 +0200
Message-ID: <[e-mail]>
Thread-Topic: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Thread-Index: AcSkhZNnKa5JeWWMSB6h4Lq23uNlDwCXqwTQ
From: "Jan Novak \(janovak\)" <[e-mail]>
To: "Pekka Savola" <[e-mail]>, "Manav Bhatia" <[e-mail]>
X-OriginalArrivalTime: 30 Sep 2004 12:01:21.0698 (UTC) FILETIME=[339EC020:01C4A6E5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id IAA27970

 

> 
> On Thu, 23 Sep 2004, Manav Bhatia wrote:
> > > This seems to change the way BGP works in a relatively fundamental
> > > way, and I don't see sufficient justification for the proposed
> > > changes.

I would say that the need for it has been established by the "industry"
over the pass few years already (just that apparently not that easy to
resolve) - few examples could be different VPNv4
scenarios with RRs, the possible say generic IPv4 routing non-optimality
when
RR in use and also possible resolution of BGP oscillation problems
reported
in several RR/confed scenarios just as a list from the top of one's
head.

> AS-paths and nexthops, because the nexthops are being used.  I ask you
> which spec says there will be multiple BGP next-hops to begin with.

Nothing to be specified it just happens in the networks ??

Jan

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA22296 for <[e-mail]>; Wed, 29 Sep 2004 20:23:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCoa0-0000Xt-DR; Wed, 29 Sep 2004 20:13:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCo5W-00073m-Ki for [e-mail]; Wed, 29 Sep 2004 19:42:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02735 for <[e-mail]>; Wed, 29 Sep 2004 19:42:19 -0400 (EDT)
Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCoDd-0006La-QZ for [e-mail]; Wed, 29 Sep 2004 19:50:47 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id ACE10AB58D2; Wed, 29 Sep 2004 16:42:13 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11062-05; Wed, 29 Sep 2004 16:42:13 -0700 (PDT)
Received: from fall.redback.com (fall.redback.com [155.53.44.81]) by prattle.redback.com (Postfix) with ESMTP id 5651FAB58D3; Wed, 29 Sep 2004 16:42:13 -0700 (PDT)
Received: from redback.com (localhost [127.0.0.1]) by fall.redback.com (8.11.0/8.8.8/null redback bsdclient) with ESMTP id i8TNgDm25754; Wed, 29 Sep 2004 16:42:13 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail]
Date: Wed, 29 Sep 2004 16:42:13 -0700
From: Enke Chen <[e-mail]>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: [e-mail], [e-mail]
Subject: [Idr] draft-chen-bgp-group-path-update-02.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi, folks:

We have revised the draft to take care of the comments and suggestions
received from the last IDR WG meeting. Please let us know if you have
any comments or suggestions about the revised version.

Regards,  -- Enke


------- Forwarded Message

Message-Id: <[e-mail]>
To: [e-mail]
From: [e-mail]
Date: Wed, 29 Sep 2004 15:29:12 -0400
Subject: I-D ACTION:draft-chen-bgp-group-path-update-02.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Advertisement of the Group Best Paths in BGP
	Author(s)	: E. Chen, N. Chen
	Filename	: draft-chen-bgp-group-path-update-02.txt
	Pages		: 14
	Date		: 2004-9-29
	
In this document we first identify the (neighbor-AS based) Group Best
   Paths for an address prefix as the sufficient subset that can be
   advertised by a BGP route reflector or a BGP confederation ASBR to
   eliminate the MED-type route oscillations in a network.  We then
   propose a BGP extension to support the advertisement of the Group
   Best Paths by a route reflector or a confederation ASBR.  The
   extension also allows the advertisement of all the paths in a group
   that survive the MED comparison, thus achieving the same routing
   consistency as the full IBGP mesh.  The proposed mechanisms are
   designed such that the vast majority of the BGP speakers in a network
   need only minor software changes in order to deploy the mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-group-path-update-02.txt

------- End of Forwarded Message


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA17413 for <[e-mail]>; Wed, 29 Sep 2004 10:14:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCf8G-0002sS-NM; Wed, 29 Sep 2004 10:08:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCere-0005DM-LY for [e-mail]; Wed, 29 Sep 2004 09:51:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04346 for <[e-mail]>; Wed, 29 Sep 2004 09:51:24 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCezh-00072S-Hc for [e-mail]; Wed, 29 Sep 2004 09:59:46 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i8TDot954354;  Wed, 29 Sep 2004 06:50:55 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i8TDone91586; Wed, 29 Sep 2004 06:50:50 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] note to authors/editors - new boilerplate 
In-Reply-To: Your message of "Tue, 28 Sep 2004 14:15:15 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 29 Sep 2004 06:50:49 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Eric,

> Yakov,
> 
>     As much as it is obvious that some effort has been made to 
> "generalize" this example,
> I assume we don't have to list "Wijnen" as the author at the bottom left 
> hand side of every
> page. 

Correct.

> Perhaps this would be clearer, if you included a sample of the 
> output as well as the
> nroff source.

Attached is a sample of the output.

>     Also, I interpret the nroff you provide to indicate the "none" now 
> goes where "Network Working Group" used to go. Is this true generally, 
> or is it only true for this example?

To the best of my knowledge this is true generally.

Yakov.
------------------------------------------------------------------------






none                                                          F. Surname
Internet-Draft                                         Some Organization
Expires: March 2, 2005                                    September 2004


                         Title of your document
                      draft-somemorenaming-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   Your abstract









Surname                   Expires March 2, 2005                 [Page 1]





Internet-Draft       Textual Conventions for VLAN-ID      September 2004


   body of your document


















































Surname                   Expires March 2, 2005                 [Page 2]





Internet-Draft       Textual Conventions for VLAN-ID      September 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Surname                   Expires March 2, 2005                 [Page 3]





Internet-Draft       Textual Conventions for VLAN-ID      September 2004





















































Surname                   Expires March 2, 2005                 [Page 4]



_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09352 for <[e-mail]>; Tue, 28 Sep 2004 17:53:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPpz-0000Sk-6T; Tue, 28 Sep 2004 17:48:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCPfU-0007D5-EC for [e-mail]; Tue, 28 Sep 2004 17:37:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25767 for <[e-mail]>; Tue, 28 Sep 2004 17:37:49 -0400 (EDT)
Received: from host19.ipowerweb.com ([66.235.218.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCPnO-0003ST-FL for [e-mail]; Tue, 28 Sep 2004 17:46:03 -0400
Received: from [12.119.142.26] (helo=[127.0.0.1]) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 1CCPes-0001YC-00; Tue, 28 Sep 2004 14:37:14 -0700
Message-ID: <[e-mail]>
Date: Tue, 28 Sep 2004 14:15:15 -0400
From: Eric Gray <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] note to authors/editors - new boilerplate
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host19.ipowerweb.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - GraIyMage.com
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Yakov,

    As much as it is obvious that some effort has been made to 
"generalize" this example,
I assume we don't have to list "Wijnen" as the author at the bottom left 
hand side of every
page. Perhaps this would be clearer, if you included a sample of the 
output as well as the
nroff source.

    Also, I interpret the nroff you provide to indicate the "none" now 
goes where "Network
Working Group" used to go. Is this true generally, or is it only true 
for this example?

--
Eric Gray

Yakov Rekhter wrote:

>Folks,
>
>Please be aware that enforcement of the new draft boilerplate starts
>today (09.28.2004).
>
>Yakov.
>
>P.S. Attached is the nroff source for the new boilerplate
>
>------------ boilerplate nroff for Internet Drafts
>
>.\" automatically generated by xml2rfc v1.26 on 28 Sep 2004 15:16:24 +0000
>.\" 
>.pl 10.0i
>.po 0
>.ll 7.2i
>.lt 7.2i
>.nr LL 7.2i
>.nr LT 7.2i
>.ds LF Wijnen
>.ds RF FORMFEED[Page %]
>.ds CF Expires March 2, 2005
>.ds LH Internet-Draft
>.ds RH september 2004
>.ds CH Textual Conventions for VLAN-ID
>.hy 0
>.nh
>.ad l
>.nf
>none                                                          F. Surname
>\%Internet-Draft                                        Some Organization
>Expires: March 2, 2005                                    september 2004
>
>
>.ce
>Title of your document
>.ce
>\%draft-somemorenaming-01.txt
>
>.in 3
>.ti 0
>Status of this Memo
>
>.fi
>This document is an \%Internet-Draft and is subject to all provisions
>of section 3 of RFC 3667.  By submitting this \%Internet-Draft, each
>author represents that any applicable patent or other IPR claims of
>which he or she is aware have been or will be disclosed, and any of
>which he or she become aware will be disclosed, in accordance with
>RFC 3668.
>
>\%Internet-Drafts are working documents of the Internet Engineering
>Task Force (IETF), its areas, and its working groups.  Note that
>other groups may also distribute working documents as
>\%Internet-Drafts.
>
>\%Internet-Drafts are draft documents valid for a maximum of six months
>and may be updated, replaced, or obsoleted by other documents at any
>time.  It is inappropriate to use \%Internet-Drafts as reference
>material or to cite them other than as "work in progress."
>
>The list of current \%Internet-Drafts can be accessed at
>\%http://www.ietf.org/ietf/1id-abstracts.txt.
>
>The list of \%Internet-Draft Shadow Directories can be accessed at
>http://www.ietf.org/shadow.html.
>
>This \%Internet-Draft will expire on March 2, 2005.
>
>.ti 0
>Copyright Notice
>
>Copyright (C) The Internet Society (2004).
>
>.ti 0
>Abstract
>
>Your abstract
>.bp
>
>body of your documen
>
>.bp
>.ti 0
>Intellectual Property Statement
>
>.fi
>The IETF takes no position regarding the validity or scope of any
>Intellectual Property Rights or other rights that might be claimed to
>pertain to the implementation or use of the technology described in
>this document or the extent to which any license under such rights
>might or might not be available; nor does it represent that it has
>made any independent effort to identify any such rights.  Information
>on the procedures with respect to rights in RFC documents can be
>found in BCP 78 and BCP 79.
>
>Copies of IPR disclosures made to the IETF Secretariat and any
>assurances of licenses to be made available, or the result of an
>attempt made to obtain a general license or permission for the use of
>such proprietary rights by implementers or users of this
>specification can be obtained from the IETF \%on-line IPR repository at
>http://www.ietf.org/ipr.
>
>The IETF invites any interested party to bring to its attention any
>copyrights, patents or patent applications, or other proprietary
>rights that may cover technology that may be required to implement
>this standard.  Please address the information to the IETF at
>\[e-mail].
>
>
>.ti 0
>Disclaimer of Validity
>
>This document and the information contained herein are provided on an
>"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
>ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
>INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
>INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>.ti 0
>Copyright Statement
>
>Copyright (C) The Internet Society (2004).  This document is subject
>to the rights, licenses and restrictions contained in BCP 78, and
>except as set forth therein, the authors retain all their rights.
>
>
>.ti 0
>Acknowledgment
>
>Funding for the RFC Editor function is currently provided by the
>Internet Society.
>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr
>
>
>
>
>  
>



_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06213 for <[e-mail]>; Tue, 28 Sep 2004 12:00:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCKNc-0001Pe-ET; Tue, 28 Sep 2004 11:59:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCKGx-0000B6-2G for [e-mail]; Tue, 28 Sep 2004 11:52:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01153 for <[e-mail]>; Tue, 28 Sep 2004 11:52:08 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCKOl-0003x0-5n for [e-mail]; Tue, 28 Sep 2004 12:00:18 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i8SFpaBm068135 for <[e-mail]>; Tue, 28 Sep 2004 08:51:36 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i8SFpae08948 for <[e-mail]>; Tue, 28 Sep 2004 08:51:36 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 28 Sep 2004 08:51:36 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Subject: [Idr] note to authors/editors - new boilerplate
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

Please be aware that enforcement of the new draft boilerplate starts
today (09.28.2004).

Yakov.

P.S. Attached is the nroff source for the new boilerplate

------------ boilerplate nroff for Internet Drafts

.\" automatically generated by xml2rfc v1.26 on 28 Sep 2004 15:16:24 +0000
.\" 
.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Wijnen
.ds RF FORMFEED[Page %]
.ds CF Expires March 2, 2005
.ds LH Internet-Draft
.ds RH september 2004
.ds CH Textual Conventions for VLAN-ID
.hy 0
.nh
.ad l
.nf
none                                                          F. Surname
\%Internet-Draft                                        Some Organization
Expires: March 2, 2005                                    september 2004


.ce
Title of your document
.ce
\%draft-somemorenaming-01.txt

.in 3
.ti 0
Status of this Memo

.fi
This document is an \%Internet-Draft and is subject to all provisions
of section 3 of RFC 3667.  By submitting this \%Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.

\%Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as
\%Internet-Drafts.

\%Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use \%Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current \%Internet-Drafts can be accessed at
\%http://www.ietf.org/ietf/1id-abstracts.txt.

The list of \%Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This \%Internet-Draft will expire on March 2, 2005.

.ti 0
Copyright Notice

Copyright (C) The Internet Society (2004).

.ti 0
Abstract

Your abstract
.bp

body of your documen

.bp
.ti 0
Intellectual Property Statement

.fi
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF \%on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
\[e-mail].


.ti 0
Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


.ti 0
Copyright Statement

Copyright (C) The Internet Society (2004).  This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.


.ti 0
Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05983 for <[e-mail]>; Tue, 28 Sep 2004 11:30:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJpK-0000ev-78; Tue, 28 Sep 2004 11:23:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCJgu-0007TU-Vk for [e-mail]; Tue, 28 Sep 2004 11:14:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28945 for <[e-mail]>; Tue, 28 Sep 2004 11:14:54 -0400 (EDT)
Received: from dns.nexthop.com ([65.247.36.216] heloª-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCJoi-0003F2-IQ for [e-mail]; Tue, 28 Sep 2004 11:23:03 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 127782D49AB; Tue, 28 Sep 2004 11:14:20 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 89572-01-38; Tue, 28 Sep 2004 11:14:18 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D87B32D49B0; Tue, 28 Sep 2004 11:14:18 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i8SFEIf21541; Tue, 28 Sep 2004 11:14:18 -0400 (EDT)
Date: Tue, 28 Sep 2004 11:14:18 -0400
From: Jeffrey Haas <[e-mail]>
To: Tulip Rasputin <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Tulip,

On Thu, Sep 23, 2004 at 01:05:37PM -0400, Tulip Rasputin wrote:
> I am wondering. Why would an implementation put an IPv4/Unicast route inside MP_REACH_NLRI path
> attribute? 

It's an implementation choice.  Nothing precludes it.

The fact that you can represent the same information two different
ways within a given BGP packet is the source for potential problems.

Thankfully, all of the implementations I've seen choose to put it
in one spot consistently.

> Tulip

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24788 for <[e-mail]>; Mon, 27 Sep 2004 12:59:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CByh7-0006sz-Oj; Mon, 27 Sep 2004 12:49:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBycP-0005nU-8b for [e-mail]; Mon, 27 Sep 2004 12:44:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11793 for <[e-mail]>; Mon, 27 Sep 2004 12:44:49 -0400 (EDT)
Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CByk3-0000xR-49 for [e-mail]; Mon, 27 Sep 2004 12:52:47 -0400
Received: (qmail 44528 invoked from network); 27 Sep 2004 16:44:34 -0000
Received: from dialup-4.156.48.213.dial1.boston1.level3.net (HELO laptoy770.faster-light.net) (4.156.48.213) by relay.pair.com with SMTP; 27 Sep 2004 16:44:34 -0000
X-pair-Authenticated: 4.156.48.213
Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i8RGm2IS009887; Mon, 27 Sep 2004 12:48:03 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "john smith" <[e-mail]>
Subject: Re: [Idr] ADJ RIB IN queries 
In-reply-to: Your message of "Mon, 27 Sep 2004 14:17:24 -0000." <[e-mail]> 
Date: Mon, 27 Sep 2004 12:48:02 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"john smith" writes:
>  
> Thanks,
>  
> while a, may have an advantage of relying on TCP backpressure (depending on 
> the underlying TCP stack in use), it  would imply extra memory consumption 
> on the receivers side as it would either have to store up the incoming 
> messages or make multiple copies of the adj_rib_in if the sender too is 
> churning.


Lets not get silly here.  There is no such thing as a TCP
implementation that does not apply backpressure (ie: doesn't withhold
the ACKs if the reader hasn't emptied the buffer) and it is also a
violation of the protocol to tell the other side that your receive
buffer is bigger than it really is.

So the TCP flow is always bufferred on the receive side in the socket
layer (or whatever it is called in some other implementation) and the
sending side always stops sending due to lack of ACKs.  If not
someone's TCP implementation is broken and needs to be fixed.


> I saw the end of RIB marker and the FT state bit  in of the other drafts and 
> was wondering if that may have usage in this case. In other words,  one 
> would have to ack the receipt for an End of RIB marker/FT state intact 
> eitherways for that feature to be implementable.
>  
> Changing keepalive timers to get the behaviour seems like another option....
>  
> thanks again,


If the socket is stalled for 90-180 seconds you've got a real problem
on your hands.  You should be sending keepalives anyway and should not
declare that the session is dead on the basis that you haven't read
from the socket in 90-180 seconds.

All of this is implementation details and not really in scope for
discussion of the protocol on this list.  Plus it has come up numerous
times in the last 10-12 years and has been discussed, sometimes in
great detail, and answered numerous times.

This is not a mailing list for newbie questions.  If you need a review
of basic TCP operation this is not the place for it.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23630 for <[e-mail]>; Mon, 27 Sep 2004 10:25:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwLr-0002t2-EQ; Mon, 27 Sep 2004 10:19:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwKr-0002ab-6o for [e-mail]; Mon, 27 Sep 2004 10:18:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02009 for <[e-mail]>; Mon, 27 Sep 2004 10:18:34 -0400 (EDT)
Received: from bay17-f33.bay17.hotmail.com ([64.4.43.83] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwST-0006p9-0z for [e-mail]; Mon, 27 Sep 2004 10:26:30 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Sep 2004 07:18:03 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 27 Sep 2004 14:17:24 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: [Idr] ADJ RIB IN queries
Date: Mon, 27 Sep 2004 14:17:24 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 27 Sep 2004 14:18:03.0826 (UTC) FILETIME=[CD3AE920:01C4A49C]
X-Spam-Score: 1.9 (+)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Thanks,

while a, may have an advantage of relying on TCP backpressure (depending on 
the underlying TCP stack in use), it  would imply extra memory consumption 
on the receivers side as it would either have to store up the incoming 
messages or make multiple copies of the adj_rib_in if the sender too is 
churning.

I saw the end of RIB marker and the FT state bit  in of the other drafts and 
was wondering if that may have usage in this case. In other words,  one 
would have to ack the receipt for an End of RIB marker/FT state intact 
eitherways for that feature to be implementable.

Changing keepalive timers to get the behaviour seems like another option....

thanks again,


>From: Michael Dell <[e-mail]>
>To: 'john smith' <[e-mail]>, [e-mail]
>Subject: RE: [Idr] ADJ RIB IN queries
>Date: Mon, 27 Sep 2004 14:35:13 +0100
>
>John
>
>I would have said that how a stack deals with receiving an update whilst 
>the
>Adj-RIB-In(ARI) is locked is an implementation issue.  Received updates 
>that
>the stack is not yet able to process as it is already processing an update
>(which is when the ARI would be locked) would probably be buffered by the
>sockets layer, and this can apply back-pressure if your BGP implementation
>is not reading the data fast enough - but that's just 1 approach.
>
>There is no defined method within the BGP protocol to request that a peer
>hold off advertising updates to you.
>
>Adj-RIBs-In would be the plural of Adj-RIB-In.
>
>Regards
>
>Mike Dell
>
>-----Original Message-----
>From: john smith [mailto:[e-mail]]
>Sent: 27 September 2004 11:53
>To: [e-mail]
>Subject: [Idr] ADJ RIB IN queries
>
>
>Hi folks,
>
>Would appreciate if someone could clarify,
>
>Incase the ADJ RIB IN is locked, and an update message arrives, is it
>
>a. stored in a message queue for sequential processing?
>or
>b. allowed to modify the RIB? (does not seem to make sense)
>or
>c. is there a way to notify adjacent peers that the RIB is locked hence
>updates should not be sent till a status change is sent to peers.
>
>In other words, there has to be one more abstraction/queue prior to the
>ADJ_RIB_IN, if my understanding is correct?
>
>And incase it is a, can withdraws and implicit withdraws be applied to the
>queue in a, rather than at the ADJ_RIB_IN if such a situation arises,
>(though the whole queue would be processed at once but just an
>optimization)?
>
>Another clarification I would like to seek,
>is it adj_RIB*s*_IN or adj_RIB_IN?
>
>-thanks
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?pageþatures/junkmail
>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid963


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA23298 for <[e-mail]>; Mon, 27 Sep 2004 09:43:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBvkU-00010E-JC; Mon, 27 Sep 2004 09:41:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBvfS-0000SS-LT for [e-mail]; Mon, 27 Sep 2004 09:35:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28934 for <[e-mail]>; Mon, 27 Sep 2004 09:35:48 -0400 (EDT)
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBvn4-000638-IX for [e-mail]; Mon, 27 Sep 2004 09:43:43 -0400
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id <R0RAZW37>; Mon, 27 Sep 2004 14:35:15 +0100
Message-ID: <[e-mail]>
From: Michael Dell <[e-mail]>
To: "'john smith'" <[e-mail]>, [e-mail]
Subject: RE: [Idr] ADJ RIB IN queries
Date: Mon, 27 Sep 2004 14:35:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 1.1 (+)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

John

I would have said that how a stack deals with receiving an update whilst the
Adj-RIB-In(ARI) is locked is an implementation issue.  Received updates that
the stack is not yet able to process as it is already processing an update
(which is when the ARI would be locked) would probably be buffered by the
sockets layer, and this can apply back-pressure if your BGP implementation
is not reading the data fast enough - but that's just 1 approach.

There is no defined method within the BGP protocol to request that a peer
hold off advertising updates to you.  

Adj-RIBs-In would be the plural of Adj-RIB-In.

Regards

Mike Dell

-----Original Message-----
From: john smith [mailto:[e-mail]]
Sent: 27 September 2004 11:53
To: [e-mail]
Subject: [Idr] ADJ RIB IN queries


Hi folks,

Would appreciate if someone could clarify,

Incase the ADJ RIB IN is locked, and an update message arrives, is it

a. stored in a message queue for sequential processing?
or
b. allowed to modify the RIB? (does not seem to make sense)
or
c. is there a way to notify adjacent peers that the RIB is locked hence 
updates should not be sent till a status change is sent to peers.

In other words, there has to be one more abstraction/queue prior to the 
ADJ_RIB_IN, if my understanding is correct?

And incase it is a, can withdraws and implicit withdraws be applied to the 
queue in a, rather than at the ADJ_RIB_IN if such a situation arises, 
(though the whole queue would be processed at once but just an 
optimization)?

Another clarification I would like to seek,
is it adj_RIB*s*_IN or adj_RIB_IN?

-thanks

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA22285 for <[e-mail]>; Mon, 27 Sep 2004 07:30:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtfL-0002bG-32; Mon, 27 Sep 2004 07:27:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBtZe-00027E-Ic for [e-mail]; Mon, 27 Sep 2004 07:21:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20521 for <[e-mail]>; Mon, 27 Sep 2004 07:21:41 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBthF-0003Pb-PH for [e-mail]; Mon, 27 Sep 2004 07:29:34 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8RBKu004091; Mon, 27 Sep 2004 14:20:59 +0300
Date: Mon, 27 Sep 2004 14:20:55 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: Manav Bhatia <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
In-Reply-To: <02b501c4a164$70a99520$100218ac@pfloyd>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Thu, 23 Sep 2004, Manav Bhatia wrote:
> > This seems to change the way BGP works in a relatively fundamental
> > way, and I don't see sufficient justification for the proposed
> > changes.
> 
> Could you elaborate on what you mean by changing the way BGP works in a
> "relatively fundamental way"?

I said so because BGP builds on the concept of best route and just one
next-hop, not multiple ones.  Change there would seem to be
fundamental.
 
> All this draft says is that a router should advertise all its equal cost BGP
> routes to its IBGP peers *if* its using them. The reason why its advertising
> these routes is because its *using* them itself. YOu dont want routing and
> forwarding to go different ways. Then, since you are using multiple paths,
> you ought to tell everybody else of this. So, you construct a synthetic
> as-path and advertise that to your EBGP peers.

You asked me why not adapt BGP to advertise multiple syntentic
AS-paths and nexthops, because the nexthops are being used.  I ask you
which spec says there will be multiple BGP next-hops to begin with.

The whole concept of multiple next-hops seems questionable to me.  
For simplicity, BGP should have only one next-hop.  Whatever happens
below BGP (e.g., whether that next-hop address is anycasted,
loadbalanced using IGPs, recursively resolved or whatever) should be
irrelevant to the BGP advertisements themselves.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA21960 for <[e-mail]>; Mon, 27 Sep 2004 06:56:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBt9S-00084W-Ts; Mon, 27 Sep 2004 06:54:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBt8T-00080O-S3 for [e-mail]; Mon, 27 Sep 2004 06:53:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18777 for <[e-mail]>; Mon, 27 Sep 2004 06:53:34 -0400 (EDT)
Received: from bay17-f7.bay17.hotmail.com ([64.4.43.57] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBtG4-0002vb-3w for [e-mail]; Mon, 27 Sep 2004 07:01:29 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 Sep 2004 03:53:02 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 27 Sep 2004 10:52:49 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Date: Mon, 27 Sep 2004 10:52:49 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 27 Sep 2004 10:53:02.0255 (UTC) FILETIME=[28EC23F0:01C4A480]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Idr] ADJ RIB IN queries
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi folks,

Would appreciate if someone could clarify,

Incase the ADJ RIB IN is locked, and an update message arrives, is it

a. stored in a message queue for sequential processing?
or
b. allowed to modify the RIB? (does not seem to make sense)
or
c. is there a way to notify adjacent peers that the RIB is locked hence 
updates should not be sent till a status change is sent to peers.

In other words, there has to be one more abstraction/queue prior to the 
ADJ_RIB_IN, if my understanding is correct?

And incase it is a, can withdraws and implicit withdraws be applied to the 
queue in a, rather than at the ADJ_RIB_IN if such a situation arises, 
(though the whole queue would be processed at once but just an 
optimization)?

Another clarification I would like to seek,
is it adj_RIB*s*_IN or adj_RIB_IN?

-thanks

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA09195 for <[e-mail]>; Thu, 23 Sep 2004 13:28:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXK5-0000ZO-4v; Thu, 23 Sep 2004 13:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAX2o-0005LH-QN for [e-mail]; Thu, 23 Sep 2004 13:06:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01534 for <[e-mail]>; Thu, 23 Sep 2004 13:06:07 -0400 (EDT)
Received: from web60701.mail.yahoo.com ([216.109.117.224]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAX9d-0004dl-HM for [e-mail]; Thu, 23 Sep 2004 13:13:14 -0400
Message-ID: <[e-mail]>
Received: from [202.144.106.188] by web60701.mail.yahoo.com via HTTP; Thu, 23 Sep 2004 13:05:37 EDT
Date: Thu, 23 Sep 2004 13:05:37 -0400 (EDT)
From: Tulip Rasputin <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
To: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

 
> WD_NLRI: NULL
> Path Attributes:
>   + Origin - IGP
>   + AS_PATH - 65535
>   + NEXT_HOP - 192.168.1.1
>   + MP_REACH_NLRI
>     o AFI - 1 (ipv4)
>     o SAFI - 1 (unicast)
>     o MP_NEXTHOP - 192.168.1.2
>     o MP_NLRI - 10.0.1/24
> NLRI: 10.0.0/24

I am wondering. Why would an implementation put an IPv4/Unicast route inside MP_REACH_NLRI path
attribute? 

Tulip


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08343 for <[e-mail]>; Thu, 23 Sep 2004 11:39:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVQA-0007Je-TL; Thu, 23 Sep 2004 11:22:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAVKm-0005sQ-5c for [e-mail]; Thu, 23 Sep 2004 11:16:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21769 for <[e-mail]>; Thu, 23 Sep 2004 11:16:33 -0400 (EDT)
Received: from dns.nexthop.com ([65.247.36.216] heloª-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAVRZ-0001jK-9T for [e-mail]; Thu, 23 Sep 2004 11:23:38 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E6AC12D49E9; Thu, 23 Sep 2004 11:16:02 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 72943-01-83; Thu, 23 Sep 2004 11:16:01 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B7E172D49C1; Thu, 23 Sep 2004 11:16:01 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i8NFG1f08360; Thu, 23 Sep 2004 11:16:01 -0400 (EDT)
Date: Thu, 23 Sep 2004 11:16:01 -0400
From: Jeffrey Haas <[e-mail]>
To: Enrico Salazar <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Manav Bhatia <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Enrico,

On Thu, Sep 23, 2004 at 07:21:33AM -0700, Enrico Salazar wrote:
>    An UPDATE message SHOULD NOT include the same address prefix (of the
>    same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN
>    ROUTES field, Network Reachability Information fields, MP_REACH_NLRI
>    field, and MP_UNREACH_NLRI field. The processing of an UPDATE message
>    in this form is un-defined.

I am referring to different prefixes with differing nexthops.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07722 for <[e-mail]>; Thu, 23 Sep 2004 10:29:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUVV-0004FD-OS; Thu, 23 Sep 2004 10:23:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUU2-00043d-67 for [e-mail]; Thu, 23 Sep 2004 10:22:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16578 for <[e-mail]>; Thu, 23 Sep 2004 10:22:03 -0400 (EDT)
Received: from web52505.mail.yahoo.com ([206.190.39.126]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAUao-0000Jr-Kp for [e-mail]; Thu, 23 Sep 2004 10:29:08 -0400
Message-ID: <[e-mail]>
Received: from [207.17.136.150] by web52505.mail.yahoo.com via HTTP; Thu, 23 Sep 2004 07:21:33 PDT
Date: Thu, 23 Sep 2004 07:21:33 -0700 (PDT)
From: Enrico Salazar <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
To: Jeffrey Haas <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: Manav Bhatia <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="=======26455326="
Sender: [e-mail]
Errors-To: [e-mail]

--=======26455326=
Content-Type: multipart/alternative; boundary="0-1167923857-1095949293=:43467"

--0-1167923857-1095949293=:43467
Content-Type: text/plain; charset=us-ascii

Jeffrey,
 
I am referring to the following paragraph:
 
   An UPDATE message SHOULD NOT include the same address prefix (of the
   same <AFI, SAFI>) in more than one of the following fields: WITHDRAWN
   ROUTES field, Network Reachability Information fields, MP_REACH_NLRI
   field, and MP_UNREACH_NLRI field. The processing of an UPDATE message
   in this form is un-defined.

Enrico.

Jeffrey Haas <[e-mail]> wrote:
Enrico,

On Tue, Sep 21, 2004 at 09:17:36AM -0700, Enrico Salazar wrote:
> Jeffrey,
> 
> It is NOT valid to encode IPv4 unicast data both within the original BGP NLRI fields and the NEXT_HOP path attribute simultaneously with the information in the MP_(UN)REACH_NLRI fields - see draft-ietf-idr-rfc2858bis-06.txt Section 6 last paragraph.

If you are referring to the following:

: An UPDATE message that contains the MP_UNREACH_NLRI is not required
: to carry any other path attributes.

This is considerably different than SHALL NOT or MUST NOT.

This caveat in 2858-bis is present to make it allowable to send
an UPDATE message with just a single path attribute, which would be
illegal under draft-25 style BGP-4 since it is missing mandatory
path attributes.

This doesn't preclude sending other reachability or non-reachability.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-1167923857-1095949293=:43467
Content-Type: text/html; charset=us-ascii

<DIV>Jeffrey,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I am referring to the following paragraph:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; An UPDATE message SHOULD NOT include the same address prefix (of the<BR>&nbsp;&nbsp; same &lt;AFI, SAFI&gt;) in more than one of the following fields: WITHDRAWN<BR>&nbsp;&nbsp; ROUTES field, Network Reachability Information fields, MP_REACH_NLRI<BR>&nbsp;&nbsp; field, and MP_UNREACH_NLRI field. The processing of an UPDATE message<BR>&nbsp;&nbsp; in this form is un-defined.<BR><BR>Enrico.</DIV>
<DIV><BR><B><I>Jeffrey Haas &lt;[e-mail]&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Enrico,<BR><BR>On Tue, Sep 21, 2004 at 09:17:36AM -0700, Enrico Salazar wrote:<BR>&gt; Jeffrey,<BR>&gt; <BR>&gt; It is NOT valid to encode IPv4 unicast data both within the original BGP NLRI fields and the NEXT_HOP path attribute simultaneously with the information in the MP_(UN)REACH_NLRI fields - see draft-ietf-idr-rfc2858bis-06.txt Section 6 last paragraph.<BR><BR>If you are referring to the following:<BR><BR>: An UPDATE message that contains the MP_UNREACH_NLRI is not required<BR>: to carry any other path attributes.<BR><BR>This is considerably different than SHALL NOT or MUST NOT.<BR><BR>This caveat in 2858-bis is present to make it allowable to send<BR>an UPDATE message with just a single path attribute, which would be<BR>illegal under draft-25 style BGP-4 since it is missing mandatory<BR>path attributes.<BR><BR>This doesn't preclude sending other reachability or
 non-reachability.<BR><BR>-- <BR>Jeff Haas <BR>NextHop Technologies<BR><BR>_______________________________________________<BR>Idr mailing list<BR>[e-mail]<BR>https://www1.ietf.org/mailman/listinfo/idr<BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-1167923857-1095949293=:43467--


--=======26455326=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--=======26455326=--



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA06556 for <[e-mail]>; Thu, 23 Sep 2004 08:02:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASFu-00070I-Qj; Thu, 23 Sep 2004 07:59:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CASF8-0006sj-7Y for [e-mail]; Thu, 23 Sep 2004 07:58:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04308 for <[e-mail]>; Thu, 23 Sep 2004 07:58:31 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CASLs-0006E9-N2 for [e-mail]; Thu, 23 Sep 2004 08:05:33 -0400
Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id EAA22679; Thu, 23 Sep 2004 04:57:59 -0700 (PDT)
Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Sep 2004 04:57:12 -0700
Received: from pfloyd ([172.24.2.16]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Sep 2004 04:57:11 -0700
Message-ID: <02b501c4a164$70a99520$100218ac@pfloyd>
From: "Manav Bhatia" <[e-mail]>
To: "Pekka Savola" <[e-mail]>
References: <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Date: Thu, 23 Sep 2004 17:26:59 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 23 Sep 2004 11:57:11.0878 (UTC) FILETIME=[75D2FE60:01C4A164]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

>
> This seems to change the way BGP works in a relatively fundamental
> way, and I don't see sufficient justification for the proposed
> changes.

Could you elaborate on what you mean by changing the way BGP works in a
"relatively fundamental way"?

All this draft says is that a router should advertise all its equal cost BGP
routes to its IBGP peers *if* its using them. The reason why its advertising
these routes is because its *using* them itself. YOu dont want routing and
forwarding to go different ways. Then, since you are using multiple paths,
you ought to tell everybody else of this. So, you construct a synthetic
as-path and advertise that to your EBGP peers.

Manav


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA06435 for <[e-mail]>; Thu, 23 Sep 2004 07:46:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAS1d-0004uc-8u; Thu, 23 Sep 2004 07:44:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CARuf-000418-Iy for [e-mail]; Thu, 23 Sep 2004 07:37:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02835 for <[e-mail]>; Thu, 23 Sep 2004 07:37:24 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAS1R-0005i6-B6 for [e-mail]; Thu, 23 Sep 2004 07:44:26 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8NBaWZ06434; Thu, 23 Sep 2004 14:36:33 +0300
Date: Thu, 23 Sep 2004 14:36:32 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: Manav Bhatia <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Wed, 8 Sep 2004, Manav Bhatia wrote:
> This is the revised draft that was presented in 57th IETF. We would like
> this draft to be discussed in the IDR WG to see if it's a sensible work item
> for this working group.

FWIW,

This seems to change the way BGP works in a relatively fundamental 
way, and I don't see sufficient justification for the proposed 
changes.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA05873 for <[e-mail]>; Thu, 23 Sep 2004 06:23:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAQj7-0004Y7-NB; Thu, 23 Sep 2004 06:21:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAQij-0004Tz-Sq for [e-mail]; Thu, 23 Sep 2004 06:21:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28488 for <[e-mail]>; Thu, 23 Sep 2004 06:20:59 -0400 (EDT)
Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAQpL-0004Xb-G9 for [e-mail]; Thu, 23 Sep 2004 06:28:01 -0400
Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <R0RAM6MG>; Thu, 23 Sep 2004 11:20:28 +0100
Message-ID: <[e-mail]>
From: Michael Dell <[e-mail]>
To: "'Enke Chen'" <[e-mail]>
Date: Thu, 23 Sep 2004 11:20:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: "'[e-mail]'" <[e-mail]>
Subject: [Idr] Feedback on draft-chen-bgp-group-path-update-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Enke

I had a couple of comments on your draft 'Advertisement of the Group Best
Paths in BGP'.

1.  If I understand your proposals correctly, then your draft relies on the
BGP decision process implementing the feature commonly known as
Deterministic MED, and also relies on the feature commonly known as 'Always
Compare MED' being disabled.  Have I understood this correctly?  If so, then
I think it would be helpful to state this explicitly.  I know these are
features which are not formally defined in a draft (so far as I am aware),
but they are features which are commonly available, and so allowance should
be made for them.

2.  From an implementation point of view, I think it would be helpful to
clarify what a BGP speaker should do if it wants to replace the previous set
of best paths with a single new one.  I believe that your current proposal
would require that speaker to send 2 update messages, with the first
containing a withdrawal for the prefix with the neighbor-AS set to 0 and the
2nd containing the single replacement route.  Since these two pieces of
information are carried in different sections of the BGP update message, it
might be simpler to allow them to be carried in the same message, although I
believe this requires explicit description to allow it.

Regards

Mike Dell
Networking Protocols Group
Data Connection Ltd
Tel: [phone]
Fax: [phone]
E-mail: mailto:[e-mail]
Web: http://www.dataconnection.com



_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA05442 for <[e-mail]>; Thu, 23 Sep 2004 05:18:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPj3-0002bJ-UG; Thu, 23 Sep 2004 05:17:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPaB-0000zJ-Ap for [e-mail]; Thu, 23 Sep 2004 05:08:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24409 for <[e-mail]>; Thu, 23 Sep 2004 05:07:59 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAPgq-0003Kh-Ow for [e-mail]; Thu, 23 Sep 2004 05:15:01 -0400
Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA01670; Thu, 23 Sep 2004 02:07:28 -0700 (PDT)
Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Sep 2004 02:06:42 -0700
Received: from pfloyd ([172.24.2.16]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Sep 2004 02:06:40 -0700
Message-ID: <019501c4a14c$9eb4ec20$100218ac@pfloyd>
From: "Manav Bhatia" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Date: Thu, 23 Sep 2004 14:36:29 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 23 Sep 2004 09:06:41.0050 (UTC) FILETIME=[A3C687A0:01C4A14C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Jeff,

> WD_NLRI: NULL
> Path Attributes:
>   + Origin - IGP
>   + AS_PATH - 65535
>   + NEXT_HOP - 192.168.1.1
>   + MP_REACH_NLRI
>     o AFI - 1 (ipv4)
>     o SAFI - 1 (unicast)
>     o MP_NEXTHOP - 192.168.1.2
>     o MP_NLRI - 10.0.1/24
> NLRI: 10.0.0/24
>
> If one wanted to insert an IPv4/Unicast ECMP nexthop set here, which
> NLRI set would it apply to?

Like the other path attributes ORIGIN, AS_PATH, etc. ECMP_NEXT_HOP too
applies to all the NLRIs listed in an UPDATE message. If in this case you
had an additional next-hop for only 10.0.0/24, you could announce this
information in the following two ways.

Let the additional NEXT_HOP be 192.168.1.3

(i) In addition to the above UPDATE message you could announce another one
containing

WD_NLRI: NULL
Path Attributes:
  + Origin - IGP
  + AS_PATH - 65535
  + ECMP_NEXT_HOP
    o AFI - 1 (ipv4)
    o SAFI - 1 (unicast)
    o NUM NEXTHOPs - 1
    o LENGTH - 4
    o MP_NEXTHOP - 192.168.1.3
NLRI: 10.0.0/24

The IBGP peer upon receiving this UPDATE message will know that it needs to
append this route rather than replace.

(ii) You could announce the following two UPDATE messages.

WD_NLRI: NULL
Path Attributes:
  + Origin - IGP
  + AS_PATH - 65535
  + NEXT_HOP - 192.168.1.1
  + ECMP_NEXT_HOP
    o AFI - 1 (ipv4)
    o SAFI - 1 (unicast)
    o NUM NEXTHOPs - 1
    o LENGTH - 4
    o MP_NEXTHOP - 192.168.1.3
NLRI: 10.0.0/24

and

WD_NLRI: NULL
Path Attributes:
  + Origin - IGP
  + AS_PATH - 65535
  + MP_REACH_NLRI
    o AFI - 1 (ipv4)
    o SAFI - 1 (unicast)
    o MP_NEXTHOP - 192.168.1.2
    o MP_NLRI - 10.0.1/24

How you advertise the routes depends upon the time (apart from your
implementation) at which the information about this additional NEXT_HOP is
known to the originating router.

[..]
> > Put the NLRI in MP_REACH_NLRI. Set the length and the address of the MP
> > nexthop as Zero. Put this MP nexthop info in ECMP_NEXT_HOP and advertise
> > this to your IBGP peer. It will append this route, as it has been
advertised
> > with ECMP_NEXT_HOP.
>
> I think what makes me uncomfortable with this mechanism is implicitly
> using the normal NEXT_HOP as a reset mechanism.  Just from a coding
> standpoint, I'd rather see either no normal nexthop and a set of
> ECMP nexthops which always have an implicit withdrawal behavior
> or no ECMP nexthops at all.

Could you elaborate on why using the ordinary NEXT_HOP for implicit
withdrawls makes you feel uneasy? We think having such a mechanism in place,
makes it easier to understand the new capability (everybody is familiar with
how implicit withdrawls work) and introduces no additional burden on the
implementation. The way it works is that any time you receive an UPDATE
message with ECMP_NEXT_HOP, you know that the route needs to be appended and
not replaced!

Let me explain what i think you are suggesting. Correct me if i am wrong.

Lets assume we have two next-hops N1 and N2 for a NLRI. Say after some
point, we get another one N3. You suggest that we should now announce
ECMP_NEXT_HOP N1, N2 and N3. That way, whenever you receive a new UPDATE,
you always treat that as an implicit withdraw, the way BGP works now. Is
that it?

I would prefer the former approach because there can be cases (L3 VPN NLRIs,
etc) where the NLRI may be clubbed with some information (labels, etc) that
may make it non unique. In such cases, its much easier to use the mechanism
that we have described. This'll become clearer when i explain how ECMP can
work with 3107.

>
> > IMO a PE can do load splitting in whatever manner it wants to. It
> doesn't
> > need to inform the other PE that there is more than one next-hop
> available
> > to reach a destination. Basically its something similar to what we have
> done
> > for EBGP peers.
>
> Yes, it could do whatever it wanted to.  However, RFC 3107 implicitly
> expects that you only get one nexthop.  If you get more than one,
> this will potentially affect the behavior.  The change in behavior
> should be discussed somewhere - and I think that your draft is probably
> the right place to do that.
>

I may be missing something, but isn't this more of an implementation
specific issue?

Anyways, there isn't anything in this draft that precludes this.

Assume that a PE router has two next-hops to reach some NLRI x.y.z.w. Let L1
and L2 be the labels associated with these next-hops. It could send this
information the following way

WD_NLRI: NULL
Path Attributes:
  + Origin - IGP
  + AS_PATH - 65535
  + MP_REACH_NLRI
    o AFI - IPv4
    o SAFI - VPN
    o MP_NEXTHOP - 0::192.168.1.2
    o MP_NLRI - L1:RD:x.y.z.w

and

WD_NLRI: NULL
Path Attributes:
  + Origin - IGP
  + AS_PATH - 65535
  + MP_REACH_NLRI
    o AFI - IPv4
    o SAFI - VPN
    o MP_NEXTHOP - 0
    o MP_NLRI - L2:RD:x.y.z.w
 + ECMP_NEXT_HOP
    o AFI - IPv4
    o SAFI - VPN
    o NUM NEXTHOPs - 1
    o LENGTH - 4
    o MP_NEXTHOP - 0::192.168.1.3

> > ]I'm most concerned about the synthesized AS_PATH.
> > ] o In some circumstances, particularly with large AS_SETs, it will not
> > ]   be possible to preserve path length.
> >
> > Could you give me an example to illustrate this?
>
> 10/8 NH a Path 1 2 [<255 ASes>]
> 10/8 NH b Path 3 4 [<255 ASes>]

I believe, the above means that each AS_PATH contains 2 ASes in AS_SEQ and
one large AS_SET containing 255 ASes against, each path having 257 ASes in
AS_SEQ.

>
> Resulting advertisement:
> 10/8 ECMP NH a,b Path [1 3] [2 4] [<first part of first path/second path>]
> [<second part of first path/second path>]

Refer to Sec. 16.1 on how we construct the synthetic AS Paths in cases where
the contributing AS Paths consist of AS_SETs.

Resulting advertisement will be:
10/8 ECMP NH a,b Path [1 3] [2 4] [<255 ASes from the first path> <255 ASes
in the second path>]

The problem of over flowing that will occur in constructing this extremely
large AS_SET is also present in ordinary BGP, and yes, something that we
need to work upon!

>
> Note that this presumes that the set elements in the original
> advertisement are disjoint and thus not prone to merging.
>
> The path is thus lengthened.

Yes. If we have more than 255 ASes present in the AS_SET, then we may need
to prepend a new segment of type AS_SET, which will increase the path
length, as each AS_SET is counted as 1, irrespective of the number of ASes
present in the set.

However, this can be easily avoided by introducing a new path segment type
AS_EXT_SET (value 3) which will have exactly the same semantics as the
existing AS_SET, except that it wont be considered when counting the AS_PATH
length.

>
> > ] o Processing ECMP routes into paths of equivalent length with many
> > ]   AS_SETs will impact AS_PATH regular expression engines.
> > ] o The set merging rules of BGP (9.2.2.2, draft 25) can result
> > ]   in the AS_PATH being shortened.
> >
> > I am sorry, I didn't get this!
>
> As for the first:
>
> I get [1 3] [2 4] (rest)
>
> Previously I would have gotten 1 2 (rest) or 3 4 (rest).
>
> I can do a regular expression that says "Match 1 2 .*$" and prefer this
> path.

You really cant run your regular expression here that says "match 1 2 .$"
because now your traffic will be split across paths "1 2 (rest)" and "3 4
(rest)". Moreover, this seems to be an implementation issue and i am sure
vendors can find clever ways to do this.

> Per the aggregation rules, one would typically not see sets such as
> [1 3] [2 4] in the net.  An implementation would typically create
> [1 2 3 4] as part of aggregation.  Generating separate sets is a deviation
> from the specification, but not a mandatory one:
>
>             - for each pair of adjacent tuples in the aggregated
>             AS_PATH, if both tuples have the same type, merge them
>             together, as long as doing so will not cause a segment with
>             length greater than 255 to be generated.
>
> The multiple set element encoding doesn't break BGP, but it makes a
> presumption that really isn't all that clear in -25.

I am not sure if we can call this as "deviating" from the base spec.
Multiprotocol extensions did something similar for NEXT_HOP attribute.

> That presumption
> is that an implementation will not take adjacent set elements and
> merge them.  Also, it presumes that an implementation wont choose
> to clean up sets of the form:
>
> [1 2] [3 4] [3 4]
>
> where the original was:
> 1 3 3
> 2 4 4
>
> As by the aggregation rules, a given set element should exist within
> the AS_PATH only once.
>
> I suspect it would be ... instructive to find out what various
implementations
> do with odd AS_PATHs as would be generated by the synthetic AS_PATH.

Definitely.

Cheers,
Manav


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26645 for <[e-mail]>; Wed, 22 Sep 2004 11:31:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA91K-0001yG-B2; Wed, 22 Sep 2004 11:27:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA8r1-0008NF-F9 for [e-mail]; Wed, 22 Sep 2004 11:16:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16224 for <[e-mail]>; Wed, 22 Sep 2004 11:16:20 -0400 (EDT)
Received: from dns.nexthop.com ([65.247.36.216] heloª-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA8xc-0000sC-6G for [e-mail]; Wed, 22 Sep 2004 11:23:12 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7C8142D480C; Wed, 22 Sep 2004 11:15:51 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21739-01-85; Wed, 22 Sep 2004 11:15:49 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 63FA52D4840; Wed, 22 Sep 2004 11:15:49 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i8MFFn104276; Wed, 22 Sep 2004 11:15:49 -0400 (EDT)
Date: Wed, 22 Sep 2004 11:15:49 -0400
From: Jeffrey Haas <[e-mail]>
To: Manav Bhatia <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Manav,

On Wed, Sep 22, 2004 at 03:05:50PM +0530, Manav Bhatia wrote:
> Sure. This works here too. You can differentiate between the different
> next-hops in ECMP_NEXT_HOP also. <AFI=1, SAFI=1> in ECMP_NEXT_HOP would
> correspond to the BGP NLRI and the additional next-hops, while matching
> values of <AFI,SAFI> in ECMP_NEXT_HOP will match MP_(UN)REACH_NLRI. 

Consider the following case:

WD_NLRI: NULL
Path Attributes:
  + Origin - IGP
  + AS_PATH - 65535
  + NEXT_HOP - 192.168.1.1
  + MP_REACH_NLRI
    o AFI - 1 (ipv4)
    o SAFI - 1 (unicast)
    o MP_NEXTHOP - 192.168.1.2
    o MP_NLRI - 10.0.1/24
NLRI: 10.0.0/24

If one wanted to insert an IPv4/Unicast ECMP nexthop set here, which
NLRI set would it apply to?

> Scenario 1:
> 
> Say you have 2 equal cost paths for an IPv6 prefix with similar path
> attributes. These can be advertised as follows:
> 
> You put the first MP nexthop and the NLRI in MP_REACH_NLRI. You are now left
> with another MP nexthop. You use ECMP_NEXT_HOP path attribute for this. Put
> the same AFI, SAFI, length and network address of the MP nexthop in
> ECMP_NEXT_HOP and advertise this to the remote peer.

Right.  In this case the MP_NEXTHOP is being using to "reset" the
nexthops for the prefix and the ECMP_NEXTHOP is being used to add 
additional ones.

> Scenario 2:
> 
> You have already advertised one MP_REACH_NLRI and you receive another equal
> cost BGP route for the same NLRI (possibly with a different set of path
> attributes). You now encode the new information the following way:
> 
> Put the NLRI in MP_REACH_NLRI. Set the length and the address of the MP
> nexthop as Zero. Put this MP nexthop info in ECMP_NEXT_HOP and advertise
> this to your IBGP peer. It will append this route, as it has been advertised
> with ECMP_NEXT_HOP.

I think what makes me uncomfortable with this mechanism is implicitly
using the normal NEXT_HOP as a reset mechanism.  Just from a coding
standpoint, I'd rather see either no normal nexthop and a set of
ECMP nexthops which always have an implicit withdrawal behavior
or no ECMP nexthops at all.

> ]It's somewhat unclear whether a length of zero in the 
> ]MP nexthop case is the proper mechanism.
> 
> This needs to be added.

That would clarify things.

> ]Interactions with RFC 3107 Sect. 4, if any,  would be good to 
> ]have in this document.
> 
> You mean, receiving a prefix with multiple labels?

Yes.

> IMO a PE can do load splitting in whatever manner it wants to. It doesn't
> need to inform the other PE that there is more than one next-hop available
> to reach a destination. Basically its something similar to what we have done
> for EBGP peers.

Yes, it could do whatever it wanted to.  However, RFC 3107 implicitly
expects that you only get one nexthop.  If you get more than one,
this will potentially affect the behavior.  The change in behavior
should be discussed somewhere - and I think that your draft is probably
the right place to do that.

> ]I'm most concerned about the synthesized AS_PATH.
> ] o In some circumstances, particularly with large AS_SETs, it will not
> ]   be possible to preserve path length.
> 
> Could you give me an example to illustrate this?

10/8 NH a Path 1 2 [<255 ASes>]
10/8 NH b Path 3 4 [<255 ASes>]

Resulting advertisement:
10/8 ECMP NH a,b Path [1 3] [2 4] [<first part of first path/second path>] [<second part of first path/second path>]

Note that this presumes that the set elements in the original
advertisement are disjoint and thus not prone to merging.

The path is thus lengthened.

> ] o Processing ECMP routes into paths of equivalent length with many
> ]   AS_SETs will impact AS_PATH regular expression engines.
> ] o The set merging rules of BGP (9.2.2.2, draft 25) can result
> ]   in the AS_PATH being shortened.
> 
> I am sorry, I didn't get this!

As for the first:

I get [1 3] [2 4] (rest)

Previously I would have gotten 1 2 (rest) or 3 4 (rest).

I can do a regular expression that says "Match 1 2 .*$" and prefer this
path.

The behavior of AS Path regular expressions in the presence of sets
is ambiguous at best and not really documented.  However, adjacency
tests don't make clear sense in the presence of sets, especially
given the merging rules.

Per the aggregation rules, one would typically not see sets such as
[1 3] [2 4] in the net.  An implementation would typically create
[1 2 3 4] as part of aggregation.  Generating separate sets is a deviation
from the specification, but not a mandatory one:

            - for each pair of adjacent tuples in the aggregated
            AS_PATH, if both tuples have the same type, merge them
            together, as long as doing so will not cause a segment with
            length greater than 255 to be generated.

The multiple set element encoding doesn't break BGP, but it makes a
presumption that really isn't all that clear in -25.  That presumption
is that an implementation will not take adjacent set elements and
merge them.  Also, it presumes that an implementation wont choose
to clean up sets of the form:

[1 2] [3 4] [3 4]

where the original was:
1 3 3
2 4 4

As by the aggregation rules, a given set element should exist within
the AS_PATH only once.

I suspect it would be ... instructive to find out what various implementations
do with odd AS_PATHs as would be generated by the synthetic AS_PATH.

> Manav

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA23967 for <[e-mail]>; Wed, 22 Sep 2004 05:46:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3hD-0008HA-E2; Wed, 22 Sep 2004 05:45:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA3a3-0006i2-O9 for [e-mail]; Wed, 22 Sep 2004 05:38:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17536 for <[e-mail]>; Wed, 22 Sep 2004 05:38:26 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA3gZ-0002Y4-2r for [e-mail]; Wed, 22 Sep 2004 05:45:15 -0400
Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA24969; Wed, 22 Sep 2004 02:37:55 -0700 (PDT)
Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Sep 2004 02:37:09 -0700
Received: from Floyd ([172.24.2.233]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Sep 2004 02:37:08 -0700
From: "Manav Bhatia" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, <[e-mail]>
Subject: RE: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Date: Wed, 22 Sep 2004 15:05:50 +0530
Organization: Riverstone Networks
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Thread-Index: AcSfWuyvwpk+JUhiSj+aVULnbmxTUgBKeGcQ
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 22 Sep 2004 09:37:08.0852 (UTC) FILETIME=[BAD13B40:01C4A087]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Jeff,

]MP-BGP encoding issues:
]RFC 2858 documents the MP-BGP format.  While I'm not aware of 
]any implementations that do this, one valid interpretation of 
]RFC 2858 is that it is legal to encode IPv4 unicast data both 
]within the original BGP NLRI fields and the NEXT_HOP path 
]attribute simultaneously with the information in the 
]MP_(UN)REACH_NLRI fields and have the information be different.

Sure. This works here too. You can differentiate between the different
next-hops in ECMP_NEXT_HOP also. <AFI=1, SAFI=1> in ECMP_NEXT_HOP would
correspond to the BGP NLRI and the additional next-hops, while matching
values of <AFI,SAFI> in ECMP_NEXT_HOP will match MP_(UN)REACH_NLRI. 

]
]Aside from the somewhat contrived issue above, could you 
]clarify the behavior for MP-BGP processing for the MP nexthop? 

Scenario 1:

Say you have 2 equal cost paths for an IPv6 prefix with similar path
attributes. These can be advertised as follows:

You put the first MP nexthop and the NLRI in MP_REACH_NLRI. You are now left
with another MP nexthop. You use ECMP_NEXT_HOP path attribute for this. Put
the same AFI, SAFI, length and network address of the MP nexthop in
ECMP_NEXT_HOP and advertise this to the remote peer.

Scenario 2:

You have already advertised one MP_REACH_NLRI and you receive another equal
cost BGP route for the same NLRI (possibly with a different set of path
attributes). You now encode the new information the following way:

Put the NLRI in MP_REACH_NLRI. Set the length and the address of the MP
nexthop as Zero. Put this MP nexthop info in ECMP_NEXT_HOP and advertise
this to your IBGP peer. It will append this route, as it has been advertised
with ECMP_NEXT_HOP.

] What I would suspect from reading this document is that when 
]the MP nexthop is specified (length of nexthop != 0) that it 
]should also behave as an implicit withdrawal of the ECMP 
]paths.  

Yes, if an implementation receives an UPDATE message with MP nexthop inside
MP_REACH_NLRI, then it shall consider this as an implicit withdrawal of the
previous advertised paths.

]It's somewhat unclear whether a length of zero in the 
]MP nexthop case is the proper mechanism.

This needs to be added.

]
]I would suggest some additional language noting that the 
]implicit withdrawal case (advertise a withdrawal and new NLRI 
]simultaneously) should be processed as just implicit 
]withdrawals.  This may cause churn in some implementations 
]that may process the unfeasible routes component of an update 
]and then the feasible routes separately.
]
]Similarly, this would suggest that implementations will need 
]to carry MP_REACH_NLRI and MP_UNREACH_NLRI simultaneously.  
]Some implementations do not appear to do this currently.
]
]Interactions with RFC 3107 Sect. 4, if any,  would be good to 
]have in this document.

You mean, receiving a prefix with multiple labels?

IMO a PE can do load splitting in whatever manner it wants to. It doesn't
need to inform the other PE that there is more than one next-hop available
to reach a destination. Basically its something similar to what we have done
for EBGP peers.

]
]I'm most concerned about the synthesized AS_PATH.
] o In some circumstances, particularly with large AS_SETs, it will not
]   be possible to preserve path length.

Could you give me an example to illustrate this?

] o Processing ECMP routes into paths of equivalent length with many
]   AS_SETs will impact AS_PATH regular expression engines.
] o The set merging rules of BGP (9.2.2.2, draft 25) can result
]   in the AS_PATH being shortened.

I am sorry, I didn't get this!

Manav


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA17332 for <[e-mail]>; Tue, 21 Sep 2004 16:31:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9qXU-0000oQ-GM; Tue, 21 Sep 2004 15:43:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9qTU-0007PG-Q3; Tue, 21 Sep 2004 15:38:52 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14176; Tue, 21 Sep 2004 15:38:51 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Tue, 21 Sep 2004 15:38:50 -0400
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-identifier-04.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: AS-wide Unique BGP Identifier for BGP-4
	Author(s)	: E. Chen, J. Yuan
	Filename	: draft-ietf-idr-bgp-identifier-04.txt
	Pages		: 5
	Date		: 2004-9-21
	
To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-identifier-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-identifier-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-identifier-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-identifier-04.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA15901 for <[e-mail]>; Tue, 21 Sep 2004 13:26:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9oL0-0006zK-Tp; Tue, 21 Sep 2004 13:21:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9o5R-0003bH-G6 for [e-mail]; Tue, 21 Sep 2004 13:05:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02350 for <[e-mail]>; Tue, 21 Sep 2004 13:05:50 -0400 (EDT)
Received: from dns.nexthop.com ([65.247.36.216] heloª-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9oBn-0007NT-9x for [e-mail]; Tue, 21 Sep 2004 13:12:30 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 98DFD2D487E; Tue, 21 Sep 2004 13:04:17 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74957-01-98; Tue, 21 Sep 2004 13:04:15 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0D17E2D4801; Tue, 21 Sep 2004 13:04:15 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i8LH4Ea12026; Tue, 21 Sep 2004 13:04:14 -0400 (EDT)
Date: Tue, 21 Sep 2004 13:04:14 -0400
From: Jeffrey Haas <[e-mail]>
To: Enrico Salazar <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Manav Bhatia <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Enrico,

On Tue, Sep 21, 2004 at 09:17:36AM -0700, Enrico Salazar wrote:
> Jeffrey,
>  
> It is NOT valid to encode IPv4 unicast data both within the original BGP NLRI fields and the NEXT_HOP path attribute simultaneously with the information in the MP_(UN)REACH_NLRI fields - see draft-ietf-idr-rfc2858bis-06.txt Section 6 last paragraph.

If you are referring to the following:

:   An UPDATE message that contains the MP_UNREACH_NLRI is not required
:   to carry any other path attributes.

This is considerably different than SHALL NOT or MUST NOT.

This caveat in 2858-bis is present to make it allowable to send
an UPDATE message with just a single path attribute, which would be
illegal under draft-25 style BGP-4 since it is missing mandatory
path attributes.

This doesn't preclude sending other reachability or non-reachability.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA15798 for <[e-mail]>; Tue, 21 Sep 2004 13:12:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9o0R-0001yM-V8; Tue, 21 Sep 2004 13:00:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9nva-0000RS-Ty for [e-mail]; Tue, 21 Sep 2004 12:55:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01609 for <[e-mail]>; Tue, 21 Sep 2004 12:55:40 -0400 (EDT)
Received: from web52501.mail.yahoo.com ([206.190.39.122]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C9o1y-0007BX-G5 for [e-mail]; Tue, 21 Sep 2004 13:02:20 -0400
Message-ID: <[e-mail]>
Received: from [207.17.136.150] by web52501.mail.yahoo.com via HTTP; Tue, 21 Sep 2004 09:17:36 PDT
Date: Tue, 21 Sep 2004 09:17:36 -0700 (PDT)
From: Enrico Salazar <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
To: Jeffrey Haas <[e-mail]>, Manav Bhatia <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="=======47975162="
Sender: [e-mail]
Errors-To: [e-mail]

--=======47975162=
Content-Type: multipart/alternative; boundary="0-1007956245-1095783456=:41282"

--0-1007956245-1095783456=:41282
Content-Type: text/plain; charset=us-ascii

Jeffrey,
 
It is NOT valid to encode IPv4 unicast data both within the original BGP NLRI fields and the NEXT_HOP path attribute simultaneously with the information in the MP_(UN)REACH_NLRI fields - see draft-ietf-idr-rfc2858bis-06.txt Section 6 last paragraph.
 
Enrico.
 


Jeffrey Haas <[e-mail]> wrote:Manav,

On Wed, Sep 08, 2004 at 10:17:51AM +0530, Manav Bhatia wrote:
> This is the revised draft that was presented in 57th IETF. We would like
> this draft to be discussed in the IDR WG to see if it's a sensible work item
> for this working group.

I have some concerns about this draft.

MP-BGP encoding issues:
RFC 2858 documents the MP-BGP format. While I'm not aware of any
implementations that do this, one valid interpretation of RFC 2858
is that it is legal to encode IPv4 unicast data both within the
original BGP NLRI fields and the NEXT_HOP path attribute simultaneously
with the information in the MP_(UN)REACH_NLRI fields and have
the information be different.

Aside from the somewhat contrived issue above, could you clarify
the behavior for MP-BGP processing for the MP nexthop? What I
would suspect from reading this document is that when the MP nexthop
is specified (length of nexthop != 0) that it should also behave
as an implicit withdrawal of the ECMP paths. It's somewhat unclear
whether a length of zero in the MP nexthop case is the proper
mechanism.

I would suggest some additional language noting that the implicit 
withdrawal case (advertise a withdrawal and new NLRI simultaneously)
should be processed as just implicit withdrawals. This may cause
churn in some implementations that may process the unfeasible routes
component of an update and then the feasible routes separately.

Similarly, this would suggest that implementations will need to
carry MP_REACH_NLRI and MP_UNREACH_NLRI simultaneously. Some
implementations do not appear to do this currently.

Interactions with RFC 3107 Sect. 4, if any, would be good to have
in this document.

I'm most concerned about the synthesized AS_PATH.
o In some circumstances, particularly with large AS_SETs, it will not
be possible to preserve path length.
o Processing ECMP routes into paths of equivalent length with many
AS_SETs will impact AS_PATH regular expression engines.
o The set merging rules of BGP (9.2.2.2, draft 25) can result
in the AS_PATH being shortened.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!
--0-1007956245-1095783456=:41282
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>Jeffrey,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is NOT valid to encode IPv4 unicast data both within the original BGP NLRI fields and the NEXT_HOP path attribute simultaneously with the information in the MP_(UN)REACH_NLRI fields - see draft-ietf-idr-rfc2858bis-06.txt Section 6 last paragraph.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Enrico.</DIV>
<DIV>&nbsp;</DIV><BR><BR><B><I>Jeffrey Haas &lt;[e-mail]&gt;</I></B> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Manav,<BR><BR>On Wed, Sep 08, 2004 at 10:17:51AM +0530, Manav Bhatia wrote:<BR>&gt; This is the revised draft that was presented in 57th IETF. We would like<BR>&gt; this draft to be discussed in the IDR WG to see if it's a sensible work item<BR>&gt; for this working group.<BR><BR>I have some concerns about this draft.<BR><BR>MP-BGP encoding issues:<BR>RFC 2858 documents the MP-BGP format. While I'm not aware of any<BR>implementations that do this, one valid interpretation of RFC 2858<BR>is that it is legal to encode IPv4 unicast data both within the<BR>original BGP NLRI fields and the NEXT_HOP path attribute simultaneously<BR>with the information in the MP_(UN)REACH_NLRI fields and have<BR>the information be different.<BR><BR>Aside from the somewhat contrived issue above, could you clarify<BR>the behavior for MP-BGP processing for the MP nexthop? What I<BR>would suspect from !
 reading
 this document is that when the MP nexthop<BR>is specified (length of nexthop != 0) that it should also behave<BR>as an implicit withdrawal of the ECMP paths. It's somewhat unclear<BR>whether a length of zero in the MP nexthop case is the proper<BR>mechanism.<BR><BR>I would suggest some additional language noting that the implicit <BR>withdrawal case (advertise a withdrawal and new NLRI simultaneously)<BR>should be processed as just implicit withdrawals. This may cause<BR>churn in some implementations that may process the unfeasible routes<BR>component of an update and then the feasible routes separately.<BR><BR>Similarly, this would suggest that implementations will need to<BR>carry MP_REACH_NLRI and MP_UNREACH_NLRI simultaneously. Some<BR>implementations do not appear to do this currently.<BR><BR>Interactions with RFC 3107 Sect. 4, if any, would be good to have<BR>in this document.<BR><BR>I'm most concerned about the synthesized AS_PATH.<BR>o In some circumstances, particu!
 larly
 with large AS_SETs, it will not<BR>be possible to preserve path length.<BR>o Processing ECMP routes into paths of equivalent length with many<BR>AS_SETs will impact AS_PATH regular expression engines.<BR>o The set merging rules of BGP (9.2.2.2, draft 25) can result<BR>in the AS_PATH being shortened.<BR><BR>-- <BR>Jeff Haas <BR>NextHop Technologies<BR><BR>_______________________________________________<BR>Idr mailing list<BR>[e-mail]<BR>https://www1.ietf.org/mailman/listinfo/idr<BR></BLOCKQUOTE></DIV><p>
		<hr size=1>Do you Yahoo!?<br><a
href="http://vote.yahoo.com">vote.yahoo.com</a> - Register online to vote today!
--0-1007956245-1095783456=:41282--


--=======47975162=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--=======47975162=--



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA06429 for <[e-mail]>; Mon, 20 Sep 2004 17:43:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9VeZ-0002Mc-Aj; Mon, 20 Sep 2004 17:24:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9Usf-0004QV-UW for [e-mail]; Mon, 20 Sep 2004 16:35:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13240 for <[e-mail]>; Mon, 20 Sep 2004 16:35:23 -0400 (EDT)
Received: from dns.nexthop.com ([65.247.36.216] heloª-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9Uyt-0007vh-Au for [e-mail]; Mon, 20 Sep 2004 16:41:51 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4725F2D4819; Mon, 20 Sep 2004 16:34:53 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28097-02-82; Mon, 20 Sep 2004 16:34:52 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 2FEF22D480C; Mon, 20 Sep 2004 16:34:52 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i8KKYpp09956; Mon, 20 Sep 2004 16:34:51 -0400 (EDT)
Date: Mon, 20 Sep 2004 16:34:51 -0400
From: Jeffrey Haas <[e-mail]>
To: Manav Bhatia <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Manav,

On Wed, Sep 08, 2004 at 10:17:51AM +0530, Manav Bhatia wrote:
> This is the revised draft that was presented in 57th IETF. We would like
> this draft to be discussed in the IDR WG to see if it's a sensible work item
> for this working group.

I have some concerns about this draft.

MP-BGP encoding issues:
RFC 2858 documents the MP-BGP format.  While I'm not aware of any
implementations that do this, one valid interpretation of RFC 2858
is that it is legal to encode IPv4 unicast data both within the
original BGP NLRI fields and the NEXT_HOP path attribute simultaneously
with the information in the MP_(UN)REACH_NLRI fields and have
the information be different.

Aside from the somewhat contrived issue above, could you clarify
the behavior for MP-BGP processing for the MP nexthop?  What I
would suspect from reading this document is that when the MP nexthop
is specified (length of nexthop != 0) that it should also behave
as an implicit withdrawal of the ECMP paths.  It's somewhat unclear
whether a length of zero in the MP nexthop case is the proper
mechanism.

I would suggest some additional language noting that the implicit 
withdrawal case (advertise a withdrawal and new NLRI simultaneously)
should be processed as just implicit withdrawals.  This may cause
churn in some implementations that may process the unfeasible routes
component of an update and then the feasible routes separately.

Similarly, this would suggest that implementations will need to
carry MP_REACH_NLRI and MP_UNREACH_NLRI simultaneously.  Some
implementations do not appear to do this currently.

Interactions with RFC 3107 Sect. 4, if any,  would be good to have
in this document.

I'm most concerned about the synthesized AS_PATH.
 o In some circumstances, particularly with large AS_SETs, it will not
   be possible to preserve path length.
 o Processing ECMP routes into paths of equivalent length with many
   AS_SETs will impact AS_PATH regular expression engines.
 o The set merging rules of BGP (9.2.2.2, draft 25) can result
   in the AS_PATH being shortened.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA03653 for <[e-mail]>; Mon, 20 Sep 2004 12:08:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9QZm-0000Gs-Bp; Mon, 20 Sep 2004 11:59:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9QSP-0006x9-Mn for [e-mail]; Mon, 20 Sep 2004 11:52:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14630 for <[e-mail]>; Mon, 20 Sep 2004 11:51:59 -0400 (EDT)
Received: from bay17-f31.bay17.hotmail.com ([64.4.43.81] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9QYa-0000YQ-1b for [e-mail]; Mon, 20 Sep 2004 11:58:25 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 20 Sep 2004 08:41:42 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 20 Sep 2004 15:41:42 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: [Idr] Re: weights in BGP
Date: Mon, 20 Sep 2004 15:41:42 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Sep 2004 15:41:42.0794 (UTC) FILETIME=[53E066A0:01C49F28]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi Manav,

awaiting a reply,

Do you also suggest I should use local_pref on incoming eBGP peering? That 
would have the same effect, would it not?

Incase you are not clear as to what I am saying:

>>](1)
>>]AS2---AS_PATH: AS4
>>
>>No. If you have configured a weight on AS2 which prefers routes from AS3,
>>then it will choose the path from AS3 as the best against the one it
>>receives directly from AS4.

What about the time when there is no prefix for AS4 coming from AS3 to AS2?
Will it ignore all prefixes coming directly from AS4 in that case?

>>
>>Thus the best path in AS2 is still "AS3 AS4".

-best rgds

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA27532 for <[e-mail]>; Fri, 17 Sep 2004 09:57:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8JCb-0002LS-Vo; Fri, 17 Sep 2004 09:55:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8J2x-00014H-5V for [e-mail]; Fri, 17 Sep 2004 09:45:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05017 for <[e-mail]>; Fri, 17 Sep 2004 09:45:05 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8J8T-0001wQ-Nx for [e-mail]; Fri, 17 Sep 2004 09:50:51 -0400
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i8HDj3Ow000030 for <[e-mail]>; Fri, 17 Sep 2004 08:45:03 -0500 (CDT)
Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <R7VPR17K>; Fri, 17 Sep 2004 09:45:03 -0400
Message-ID: <[e-mail]>
From: "Busschbach, Peter B (Peter)" <[e-mail]>
To: [e-mail]
Date: Fri, 17 Sep 2004 09:44:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Subject: [Idr] One AFI for ATM-related addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Draft-ck-bgp-atm-nlri-00.txt proposes to use MP-BGP to exchange ATM address information between independent ATM sub-networks. In particular, it proposes to use a single AFI/SAFI combination (AFI=TBD; SAFI=VPN) and to use an "ATM Reachability Type" field in the NLRI to distinguish between different types of ATM addresses: NSAP, E.164, etc.

After this draft was presented in San Diego, we received questions why there is a need for a new AFI considering that there are already existing AFIs for NSAP, E.164 and X.121.

We would like to solicit input from the mailing list on this issue.

In our opinion, the use of a new AFI/SAFI value for a combination of ATM addresses is justified. ATM is used as the unifying protocol for carrying Frame Relay, SMDS and other traffic. As a consequence, over time, ATM has incorporated multiple address families like X.121, SMDS-related addresses and vendor-proprietary addresses. In fact, PNNI messages use an "ATM AFI" to distinguish between these different address families, and Call Control functionality in ATM Switches generally uses a single address data base integrating different types of addresses.

For this reason, as far as MP-BGP is concerned, it makes more sense to treat all addresses exchanged between ATM Switches as a single family, rather than as a collection of separate families. Or, in other words, it makes more sense to use a single AFI/SAFI value than to use multiple.

As we are currently working on a new version of the draft, we would appreciate your input on whether we can move ahead with our proposal for a new AFI/SAFI for ATM addresses.

Thanks,

CK,
Chris Metz,
Peter Busschbach

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA24404 for <[e-mail]>; Fri, 17 Sep 2004 03:12:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8Cr2-0001Pj-Jg; Fri, 17 Sep 2004 03:08:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8Ciy-0008LD-Cf for [e-mail]; Fri, 17 Sep 2004 03:00:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10882 for <[e-mail]>; Fri, 17 Sep 2004 03:00:02 -0400 (EDT)
Received: from bay17-f44.bay17.hotmail.com ([64.4.43.94] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8CoR-0001HV-JC for [e-mail]; Fri, 17 Sep 2004 03:05:44 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Sep 2004 23:59:31 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 17 Sep 2004 06:59:31 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: [Idr] Re: weights in BGP
Date: Fri, 17 Sep 2004 06:59:31 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 17 Sep 2004 06:59:31.0869 (UTC) FILETIME=[E1F364D0:01C49C83]
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

What about the time when there is no prefix for AS4 coming from AS3?
Will it ignore all prefixes coming directly from AS4 in that case?

>From: "Manav Bhatia" <[e-mail]>
>Reply-To: <[e-mail]>
>To: "'john smith'" <[e-mail]>, <[e-mail]>
>Subject: RE: [Idr] Re: weights in BGP
>Date: Thu, 16 Sep 2004 15:41:18 +0530
>
>John,
>
>]
>](1)
>]AS2---AS_PATH: AS4
>
>No. If you have configured a weight on AS2 which prefers routes from AS3,
>then it will choose the path from AS3 as the best against the one it
>receives directly from AS4.
>
>Thus the best path in AS2 is still "AS3 AS4".
>
>Regards,
>Manav
>
>]AS3---AS_PATH: AS4
>]AS1--no path
>]
>]>
>]>AS3 has with it one route to X, with AS_PATH AS4.
>]
>]yes
>]and AS2 has AS_PATH AS4 too. is that correct?
>]
>]>It advertises this to AS1 and AS2
>]>
>]>AS2 will receive two UPDATEs, one from AS3 and the other from AS1 and
>]>will thus have the following AS_PATHs.
>]>
>]>AS_PATH1: AS3 AS4
>]>AS_PATH2: AS1 AS3 AS4
>]
>]
>]=>
>]you missed:
>]AS_PATH3: AS4  here.
>]
>]eitherways
>]AS2 would have received that prior to the update from AS3
>]directly from AS4??
>]
>]AS2 would also have advertised this to AS1 in the time that
>]AS3 converges.
>]Is that correct/incorrect??
>]I believe there is nothing which says this is incorrect?
>]
>]>
>]>Because of the weight configured on AS2, it will select the
>]route from AS3.
>]>The best selected route is thus AS_PATH1 and it advertises this to AS1
>]
>]So now AS1 would have (only best paths)
>](2)
>]AS1:--AS_PATH: AS2 AS4.
>]AS2:--AS_PATH: AS3 AS4
>]AS3:--AS_PATH: AS4
>]
>]>
>]>AS1 now has two routes, one which it received from AS2 and the other
>]>from AS3.
>]>AS_PATH1: AS2 AS3 AS4
>]>AS_PATH2: AS3 AS4
>]>
>]>Because of the weight, it will select the one from AS2.
>]
>]see (2) above.
>]
>]After this the progression as I see it should be:
>](3)
>]AS1--AS_PATH: AS2 AS3 AS4
>]AS2--AS_PATH: AS3 AS4
>]AS3--AS_PATH: AS1 AS2 AS4
>]
>]>
>]>It will send an implicit withdraw to AS2, replacing "AS1 AS3
>]AS4" with
>]>"AS1
>]>AS2 AS3 AS4". AS2 upon receiving this UPDATE will find its
>]own AS, and
>]>will ignore this.
>]>
>]yes and no.
>]
>]>AS1 also advertises it best route to AS3.
>]>
>]>Thus AS3 now has the following routes.
>]>
>]>AS_PATH1: AS1 AS2 AS3 AS4
>]>AS_PATH2: AS4
>]
>]the next state as I see it should be:
>]
>](4)
>]AS1--AS_PATH: AS2 AS3 AS4
>]AS2--AS_PATH: AS4
>]AS3--AS_PATH: AS4
>]This will take me back to (1)
>]
>]>
>]>It will ignore the first UPDATE because it will find its own
>]AS number
>]>in the AS_PATH and will select the path it learnt from AS4. Note that
>]>it overrides your weight configuration. But then, weight only works
>]>when you have two feasible candidate routes, and in this case
>]there is
>]>only one feasible route. The other is not considered because
>]of the AS loop.
>]>
>]>The network will thus converge!
>]
>]I do not quite grasp how it will... perhaps you could point
>]out where I am wrong in the above?
>]>
>]>]I fail to understand which router detects the loop in what ]case, as
>]>mentioned by you below.
>]>
>]>Hope this helps!
>]>
>]
>]hope i clarified my question?
>]
>]>Regards,
>]>Manav
>]>
>]
>]_________________________________________________________________
>]The new MSN 8: advanced junk mail protection and 2 months
>]FREE* http://join.msn.com/?pageþatures/junkmail
>]
>

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA14192 for <[e-mail]>; Thu, 16 Sep 2004 06:23:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7tOa-0003t5-Vq; Thu, 16 Sep 2004 06:21:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7tH0-00020P-Al for [e-mail]; Thu, 16 Sep 2004 06:13:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28514 for <[e-mail]>; Thu, 16 Sep 2004 06:13:50 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7tMH-0002jt-9b for [e-mail]; Thu, 16 Sep 2004 06:19:22 -0400
Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id DAA29093; Thu, 16 Sep 2004 03:13:20 -0700 (PDT)
Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Sep 2004 03:12:34 -0700
Received: from Floyd ([172.24.2.233]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Sep 2004 03:12:33 -0700
From: "Manav Bhatia" <[e-mail]>
To: "'john smith'" <[e-mail]>, <[e-mail]>
Subject: RE: [Idr] Re: weights in BGP
Date: Thu, 16 Sep 2004 15:41:18 +0530
Organization: Riverstone Networks
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcSbxPr9ltpNOHqcRLW+bUJmBtUGbAAD+AGA
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Sep 2004 10:12:34.0138 (UTC) FILETIME=[AF1BA3A0:01C49BD5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

John,

]
](1)
]AS2---AS_PATH: AS4

No. If you have configured a weight on AS2 which prefers routes from AS3,
then it will choose the path from AS3 as the best against the one it
receives directly from AS4. 

Thus the best path in AS2 is still "AS3 AS4".

Regards,
Manav

]AS3---AS_PATH: AS4
]AS1--no path
]
]>
]>AS3 has with it one route to X, with AS_PATH AS4.
]
]yes
]and AS2 has AS_PATH AS4 too. is that correct?
]
]>It advertises this to AS1 and AS2
]>
]>AS2 will receive two UPDATEs, one from AS3 and the other from AS1 and 
]>will thus have the following AS_PATHs.
]>
]>AS_PATH1: AS3 AS4
]>AS_PATH2: AS1 AS3 AS4
]
]
]=>
]you missed:
]AS_PATH3: AS4  here.
]
]eitherways
]AS2 would have received that prior to the update from AS3 
]directly from AS4??
]
]AS2 would also have advertised this to AS1 in the time that 
]AS3 converges. 
]Is that correct/incorrect??
]I believe there is nothing which says this is incorrect?
]
]>
]>Because of the weight configured on AS2, it will select the 
]route from AS3.
]>The best selected route is thus AS_PATH1 and it advertises this to AS1
]
]So now AS1 would have (only best paths)
](2)
]AS1:--AS_PATH: AS2 AS4.
]AS2:--AS_PATH: AS3 AS4
]AS3:--AS_PATH: AS4
]
]>
]>AS1 now has two routes, one which it received from AS2 and the other 
]>from AS3.
]>AS_PATH1: AS2 AS3 AS4
]>AS_PATH2: AS3 AS4
]>
]>Because of the weight, it will select the one from AS2.
]
]see (2) above.
]
]After this the progression as I see it should be:
](3)
]AS1--AS_PATH: AS2 AS3 AS4
]AS2--AS_PATH: AS3 AS4
]AS3--AS_PATH: AS1 AS2 AS4
]
]>
]>It will send an implicit withdraw to AS2, replacing "AS1 AS3 
]AS4" with 
]>"AS1
]>AS2 AS3 AS4". AS2 upon receiving this UPDATE will find its 
]own AS, and 
]>will ignore this.
]>
]yes and no.
]
]>AS1 also advertises it best route to AS3.
]>
]>Thus AS3 now has the following routes.
]>
]>AS_PATH1: AS1 AS2 AS3 AS4
]>AS_PATH2: AS4
]
]the next state as I see it should be:
]
](4)
]AS1--AS_PATH: AS2 AS3 AS4
]AS2--AS_PATH: AS4
]AS3--AS_PATH: AS4
]This will take me back to (1)
]
]>
]>It will ignore the first UPDATE because it will find its own 
]AS number 
]>in the AS_PATH and will select the path it learnt from AS4. Note that 
]>it overrides your weight configuration. But then, weight only works 
]>when you have two feasible candidate routes, and in this case 
]there is 
]>only one feasible route. The other is not considered because 
]of the AS loop.
]>
]>The network will thus converge!
]
]I do not quite grasp how it will... perhaps you could point 
]out where I am wrong in the above?
]>
]>]I fail to understand which router detects the loop in what ]case, as 
]>mentioned by you below.
]>
]>Hope this helps!
]>
]
]hope i clarified my question?
]
]>Regards,
]>Manav
]>
]
]_________________________________________________________________
]The new MSN 8: advanced junk mail protection and 2 months 
]FREE* http://join.msn.com/?pageþatures/junkmail
]


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA13331 for <[e-mail]>; Thu, 16 Sep 2004 04:26:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7rWw-00037q-Lc; Thu, 16 Sep 2004 04:22:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7rON-00021O-Sx for [e-mail]; Thu, 16 Sep 2004 04:13:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21361 for <[e-mail]>; Thu, 16 Sep 2004 04:13:21 -0400 (EDT)
Received: from bay17-f30.bay17.hotmail.com ([64.4.43.80] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7rTf-0000jM-In for [e-mail]; Thu, 16 Sep 2004 04:18:51 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Sep 2004 00:34:24 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 16 Sep 2004 07:34:24 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: [Idr] Re: weights in BGP
Date: Thu, 16 Sep 2004 07:34:24 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Sep 2004 07:34:24.0733 (UTC) FILETIME=[96FB58D0:01C49BBF]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi,


Let us look further down


>Hi John,
>
>]AS1-----AS2
>]\         /       |
>]\       /         |
>]   AS3       |
>]     |            |
>]    AS4-----
>]
>
>[clipped]
>
>]
>]As far as I understand, weights are not propogated,(which you
>]have confirmed is correct), but I do know that only those
>]routes from BGP which enter the forwarding plane can be sent
>]to peers. Is that not correct to?
>
>Yes.
>
>This kind of topology will eventually converge. Assume AS4 advertises a
>prefix X to AS3.

Perhaps you miunderstood the topology

AS4 is connected to AS3 and AS2.

so AS4 advertises this to AS3 && to AS2. Why would it advertise it to one 
and wait for it to converge and then choose the other?
so we have (best paths):

(1)
AS2---AS_PATH: AS4
AS3---AS_PATH: AS4
AS1--no path

>
>AS3 has with it one route to X, with AS_PATH AS4.

yes
and AS2 has AS_PATH AS4 too. is that correct?

>It advertises this to AS1 and AS2
>
>AS2 will receive two UPDATEs, one from AS3 and the other from AS1 and will
>thus have the following AS_PATHs.
>
>AS_PATH1: AS3 AS4
>AS_PATH2: AS1 AS3 AS4


=>
you missed:
AS_PATH3: AS4  here.

eitherways
AS2 would have received that prior to the update from AS3 directly from 
AS4??

AS2 would also have advertised this to AS1 in the time that AS3 converges. 
Is that correct/incorrect??
I believe there is nothing which says this is incorrect?

>
>Because of the weight configured on AS2, it will select the route from AS3.
>The best selected route is thus AS_PATH1 and it advertises this to AS1

So now AS1 would have (only best paths)
(2)
AS1:--AS_PATH: AS2 AS4.
AS2:--AS_PATH: AS3 AS4
AS3:--AS_PATH: AS4

>
>AS1 now has two routes, one which it received from AS2 and the other from
>AS3.
>AS_PATH1: AS2 AS3 AS4
>AS_PATH2: AS3 AS4
>
>Because of the weight, it will select the one from AS2.

see (2) above.

After this the progression as I see it should be:
(3)
AS1--AS_PATH: AS2 AS3 AS4
AS2--AS_PATH: AS3 AS4
AS3--AS_PATH: AS1 AS2 AS4

>
>It will send an implicit withdraw to AS2, replacing "AS1 AS3 AS4" with "AS1
>AS2 AS3 AS4". AS2 upon receiving this UPDATE will find its own AS, and will
>ignore this.
>
yes and no.

>AS1 also advertises it best route to AS3.
>
>Thus AS3 now has the following routes.
>
>AS_PATH1: AS1 AS2 AS3 AS4
>AS_PATH2: AS4

the next state as I see it should be:

(4)
AS1--AS_PATH: AS2 AS3 AS4
AS2--AS_PATH: AS4
AS3--AS_PATH: AS4
This will take me back to (1)

>
>It will ignore the first UPDATE because it will find its own AS number in
>the AS_PATH and will select the path it learnt from AS4. Note that it
>overrides your weight configuration. But then, weight only works when you
>have two feasible candidate routes, and in this case there is only one
>feasible route. The other is not considered because of the AS loop.
>
>The network will thus converge!

I do not quite grasp how it will... perhaps you could point out where I am 
wrong in the above?
>
>]I fail to understand which router detects the loop in what
>]case, as mentioned by you below.
>
>Hope this helps!
>

hope i clarified my question?

>Regards,
>Manav
>

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA12982 for <[e-mail]>; Thu, 16 Sep 2004 03:41:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7qp3-0004eY-Hm; Thu, 16 Sep 2004 03:36:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7qfF-0003kZ-L6 for [e-mail]; Thu, 16 Sep 2004 03:26:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18352 for <[e-mail]>; Thu, 16 Sep 2004 03:26:43 -0400 (EDT)
Received: from bay17-f35.bay17.hotmail.com ([64.4.43.85] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7qkW-0008Ff-SK for [e-mail]; Thu, 16 Sep 2004 03:32:13 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Sep 2004 23:30:38 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 15 Sep 2004 13:59:31 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: RE: [Idr] weights in BGP
Date: Wed, 15 Sep 2004 13:59:31 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Sep 2004 06:30:38.0511 (UTC) FILETIME=[AE6033F0:01C49BB6]
X-Spam-Score: 2.3 (++)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi,

Am sorry if I am wasting the time of the WG with this,
just one final post on the topic.

I am not saying weights are advertised.
All I am saying is that weights are used to select the best route on a given 
node to insert into the local_rib.
And the impelementation should advertise only what is inserted into the 
local_rib? isnt that correct?
So
a. if i do not know what my neighbours are doing
b. I use weights to choose routes.
c. I advertise routes based on what goes into the local_rib, and such a 
scenario does occur, as individual ASes do not know what each one is doing,
can we not end up in a unstable topology.

Many thanks for your replies!


>From: Michael Dell <[e-mail]>
>To: 'john smith' <[e-mail]>, [e-mail]
>Subject: RE: [Idr] weights in cisco
>Date: Wed, 15 Sep 2004 14:09:27 +0100
>
>John
>
>Weights are a Cisco feature.  See
>http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a00800
>c95bb.shtml#weight for some discussion on weights.
>
>The important point to note is that the weight of a route is purely local 
>to
>a router - it is assigned via a route map, but is not advertised to peers 
>in
>any way.
>
>Regards
>
>Mike Dell
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf Of
>john smith
>Sent: 15 September 2004 13:35
>To: [e-mail]
>Subject: [Idr] weights in cisco
>
>
>Hi folks,
>
>I do not see weights in the BGP base spec.
>However, I have seen it on a number of routers
>
>I would liek to know how people use the metric across different ASes.
>
>Consider the following case:
>
>AS1----AS2...
>\      /
>\   /       |
>   AS3
>    |         |
>   AS4.........
>
>
>
>AS1 makes a route map to prefer via weights  (* AS2)
>AS3 makes a route map to prefer via weights  (* AS1)
>AS2 weights  (* AS3)
>
>AS4 comes up now/flaps up after a reboot.
>
>Will this converge?
>-JS
>
>_________________________________________________________________
>The new MSN 8: advanced junk mail protection and 2 months FREE*
>http://join.msn.com/?pageþatures/junkmail
>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA12699 for <[e-mail]>; Thu, 16 Sep 2004 03:14:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7qNG-0000tS-6Z; Thu, 16 Sep 2004 03:08:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7qCS-0007dl-Du for [e-mail]; Thu, 16 Sep 2004 02:57:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16359 for <[e-mail]>; Thu, 16 Sep 2004 02:56:57 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7qHh-0007g1-HQ for [e-mail]; Thu, 16 Sep 2004 03:02:26 -0400
Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id XAA05415; Wed, 15 Sep 2004 23:56:26 -0700 (PDT)
Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Sep 2004 23:55:40 -0700
Received: from Floyd ([172.24.2.233]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 23:55:39 -0700
From: "Manav Bhatia" <[e-mail]>
To: "'john smith'" <[e-mail]>, <[e-mail]>
Subject: RE: [Idr] Re: weights in BGP
Date: Thu, 16 Sep 2004 12:24:24 +0530
Organization: Riverstone Networks
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcSbtyJMewedsUc4R7S7X63fbm0InAAAQ6RA
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Sep 2004 06:55:39.0958 (UTC) FILETIME=[2D4ED560:01C49BBA]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi John,

]AS1-----AS2---------
]\         /             |
]\       /              |
]   AS3                |
]     |                  |
]    AS4--------------
]

[clipped]

]
]As far as I understand, weights are not propogated,(which you 
]have confirmed is correct), but I do know that only those 
]routes from BGP which enter the forwarding plane can be sent 
]to peers. Is that not correct to?

Yes.

This kind of topology will eventually converge. Assume AS4 advertises a
prefix X to AS3.

AS3 has with it one route to X, with AS_PATH AS4.

It advertises this to AS1 and AS2

AS2 will receive two UPDATEs, one from AS3 and the other from AS1 and will
thus have the following AS_PATHs.

AS_PATH1: AS3 AS4
AS_PATH2: AS1 AS3 AS4

Because of the weight configured on AS2, it will select the route from AS3.
The best selected route is thus AS_PATH1 and it advertises this to AS1

AS1 now has two routes, one which it received from AS2 and the other from
AS3.
AS_PATH1: AS2 AS3 AS4
AS_PATH2: AS3 AS4

Because of the weight, it will select the one from AS2.

It will send an implicit withdraw to AS2, replacing "AS1 AS3 AS4" with "AS1
AS2 AS3 AS4". AS2 upon receiving this UPDATE will find its own AS, and will
ignore this.

AS1 also advertises it best route to AS3.

Thus AS3 now has the following routes.

AS_PATH1: AS1 AS2 AS3 AS4
AS_PATH2: AS4

It will ignore the first UPDATE because it will find its own AS number in
the AS_PATH and will select the path it learnt from AS4. Note that it
overrides your weight configuration. But then, weight only works when you
have two feasible candidate routes, and in this case there is only one
feasible route. The other is not considered because of the AS loop.

The network will thus converge!

]I fail to understand which router detects the loop in what 
]case, as mentioned by you below.

Hope this helps!

Regards,
Manav


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA12300 for <[e-mail]>; Thu, 16 Sep 2004 02:33:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7pkz-0002kp-Ph; Thu, 16 Sep 2004 02:28:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7piM-0001Un-J9 for [e-mail]; Thu, 16 Sep 2004 02:25:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14201 for <[e-mail]>; Thu, 16 Sep 2004 02:25:53 -0400 (EDT)
Received: from bay17-f4.bay17.hotmail.com ([64.4.43.54] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7pnb-0007C6-UZ for [e-mail]; Thu, 16 Sep 2004 02:31:21 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Sep 2004 23:06:48 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 16 Sep 2004 06:06:48 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] Re: weights in BGP
Date: Thu, 16 Sep 2004 06:06:48 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Sep 2004 06:06:48.0923 (UTC) FILETIME=[5A4662B0:01C49BB3]
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Nader,

Am aware it is a cisco feature, and am aware others have such "equivalent" 
features too

All I am asking is this:

Assume we have the topology as shown below

AS1-----AS2---------
\         /             |
\       /              |
   AS3                |
     |                  |
    AS4--------------

AS1 makes a route map to prefer via weights  anything from AS2, including 
those that AS2 is transiting (which means prefixes from AS4 and AS3 etc)
AS3 makes a route map to prefer via weights  anything from AS1 including 
those that AS1 is transiting.
AS2 weights  anything from AS3..so on.

As far as I understand, weights are not propogated,(which you have confirmed 
is correct), but I do know that only those routes from BGP which enter the 
forwarding plane can be sent to peers. Is that not correct to?

So if AS 4 withdraws a prefix, can you please tell me the converged state of 
this topology?
I would very much appreciate it if you could take some time to write out the 
states and convince me.

I fail to understand which router detects the loop in what case, as 
mentioned by you below.

I would also like to know how "weight" is actually used on the internet.

-JS

>From: Nader Salehi <[e-mail]>
>To: "john smith" <[e-mail]>
>CC: [e-mail]
>Subject: Re: [Idr] Re: weights in BGP
>Date: Wed, 15 Sep 2004 09:34:15 -0700
>
>John,
>
>Weight is a Cisco-defined attribute and is local to the router.  It is
>not part of the spec.  and Only Cisco routers support this feature.
>For more info, look at
>http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm#1020576.
>
>In your example, convergence will occur.  You are trying to create a
>loop among AS1, AS2, and AS3.  The router which originates a route
>eventually detects the loop condition by finding its own AS in the AS
>PATH attribute of an incoming UPDATE message, and drops the UPDATE.
>
>Nader
>
>
>
>
>
>john smith writes:
> > to clarify a bit:
> >
> > AS1 makes a route map to prefer via weights  anything from AS2
> > AS3 makes a route map to prefer via weights  anything from AS1
> > AS2 weights  anything from AS3
> >
> > AS4 comes up now/flaps up after a reboot.
> >
> > Will this converge?
> > -JS
> >
> > _________________________________________________________________
> > Add photos to your messages with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?pageþatures/featuredemail
> >
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/idr
>

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07369 for <[e-mail]>; Wed, 15 Sep 2004 16:40:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7g0i-00007p-Vp; Wed, 15 Sep 2004 16:04:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7fuo-0005ib-De; Wed, 15 Sep 2004 15:58:06 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04359; Wed, 15 Sep 2004 15:58:04 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Wed, 15 Sep 2004 15:58:03 -0400
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-05.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-ietf-idr-bgp4-experience-protocol-05.txt
	Pages		: 23
	Date		: 2004-9-15
	
The purpose of this memo is to document how the requirements for
   advancing a routing protocol from Draft Standard to full Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

   This report satisfies the requirement for "the second report", as
   described in Section 6.0 of RFC 1264.  In order to fulfill the
   requirement, this report augments RFC 1773 and describes additional
   knowledge and understanding gained in the time between when the
   protocol was made a Draft Standard and when it was submitted for
   Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-experience-protocol-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-experience-protocol-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-experience-protocol-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05898 for <[e-mail]>; Wed, 15 Sep 2004 13:58:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7djj-0007JY-OR; Wed, 15 Sep 2004 13:38:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7dav-00060O-A6 for [e-mail]; Wed, 15 Sep 2004 13:29:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22235 for <[e-mail]>; Wed, 15 Sep 2004 13:29:21 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7dg4-0008P6-2w for [e-mail]; Wed, 15 Sep 2004 13:34:45 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2004 10:39:41 +0000
X-BrightmailFiltered: true
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8FHSopH002160; Wed, 15 Sep 2004 10:28:50 -0700 (PDT)
Received: from salehi-hp.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA02768; Wed, 15 Sep 2004 13:28:45 -0400 (EDT)
From: Nader Salehi <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 2004 10:28:45 -0700
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Re: weights in BGP
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid
X-URL: http://www.cisco.com
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: [e-mail], Nader Salehi <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Jeffrey Haas writes:
> On Wed, Sep 15, 2004 at 09:34:15AM -0700, Nader Salehi wrote:
> > Weight is a Cisco-defined attribute and is local to the router.  It is
> > not part of the spec.  and Only Cisco routers support this feature.
> 
> Other implementations have an analogous feature. :-)
> 

True, but as far as I know, Cisco is the only one which uses the term
"Weight".  Obviously, we don't claim a monopoly on proprietary
features :)

Nader

> -- 
> Jeff Haas 
> NextHop Technologies


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05548 for <[e-mail]>; Wed, 15 Sep 2004 13:29:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7dOn-0004Rp-U6; Wed, 15 Sep 2004 13:16:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7dDY-0002je-AF for [e-mail]; Wed, 15 Sep 2004 13:05:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20643 for <[e-mail]>; Wed, 15 Sep 2004 13:05:12 -0400 (EDT)
Received: from dns.nexthop.com ([65.247.36.216] heloª-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7dIg-0007xM-Rr for [e-mail]; Wed, 15 Sep 2004 13:10:36 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id AFFDA2D484E; Wed, 15 Sep 2004 12:59:47 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36170-01-64; Wed, 15 Sep 2004 12:59:47 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 713582D4835; Wed, 15 Sep 2004 12:59:47 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i8FGxlA17077; Wed, 15 Sep 2004 12:59:47 -0400 (EDT)
Date: Wed, 15 Sep 2004 12:59:47 -0400
From: Jeffrey Haas <[e-mail]>
To: Nader Salehi <[e-mail]>
Subject: Re: [Idr] Re: weights in BGP
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Wed, Sep 15, 2004 at 09:34:15AM -0700, Nader Salehi wrote:
> Weight is a Cisco-defined attribute and is local to the router.  It is
> not part of the spec.  and Only Cisco routers support this feature.

Other implementations have an analogous feature. :-)

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA05276 for <[e-mail]>; Wed, 15 Sep 2004 12:55:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7cph-0006O4-Fv; Wed, 15 Sep 2004 12:40:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7cmL-0004m0-HL for [e-mail]; Wed, 15 Sep 2004 12:37:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18072 for <[e-mail]>; Wed, 15 Sep 2004 12:37:06 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7crT-0007Cd-IN for [e-mail]; Wed, 15 Sep 2004 12:42:29 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2004 09:45:09 +0000
X-BrightmailFiltered: true
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8FGYHwW018136; Wed, 15 Sep 2004 09:34:18 -0700 (PDT)
Received: from salehi-hp.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA00199; Wed, 15 Sep 2004 12:34:16 -0400 (EDT)
From: Nader Salehi <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 2004 09:34:15 -0700
To: "john smith" <[e-mail]>
Subject: Re: [Idr] Re: weights in BGP
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid
X-URL: http://www.cisco.com
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

John,

Weight is a Cisco-defined attribute and is local to the router.  It is
not part of the spec.  and Only Cisco routers support this feature.
For more info, look at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm#1020576.

In your example, convergence will occur.  You are trying to create a
loop among AS1, AS2, and AS3.  The router which originates a route
eventually detects the loop condition by finding its own AS in the AS
PATH attribute of an incoming UPDATE message, and drops the UPDATE.

Nader





john smith writes:
> to clarify a bit:
> 
> AS1 makes a route map to prefer via weights  anything from AS2
> AS3 makes a route map to prefer via weights  anything from AS1
> AS2 weights  anything from AS3
> 
> AS4 comes up now/flaps up after a reboot.
> 
> Will this converge?
> -JS
> 
> _________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months FREE*. 
> http://join.msn.com/?pageþatures/featuredemail
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA03441 for <[e-mail]>; Wed, 15 Sep 2004 09:26:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Ze7-00084R-Te; Wed, 15 Sep 2004 09:16:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7ZYE-0007Gb-FU for [e-mail]; Wed, 15 Sep 2004 09:10:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01102 for <[e-mail]>; Wed, 15 Sep 2004 09:10:20 -0400 (EDT)
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7ZdK-000350-Tp for [e-mail]; Wed, 15 Sep 2004 09:15:40 -0400
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id <R0RA469X>; Wed, 15 Sep 2004 14:09:34 +0100
Message-ID: <[e-mail]>
From: Michael Dell <[e-mail]>
To: "'john smith'" <[e-mail]>, [e-mail]
Subject: RE: [Idr] weights in cisco
Date: Wed, 15 Sep 2004 14:09:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

John

Weights are a Cisco feature.  See
http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a00800
c95bb.shtml#weight for some discussion on weights.

The important point to note is that the weight of a route is purely local to
a router - it is assigned via a route map, but is not advertised to peers in
any way.

Regards

Mike Dell

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of
john smith
Sent: 15 September 2004 13:35
To: [e-mail]
Subject: [Idr] weights in cisco


Hi folks,

I do not see weights in the BGP base spec.
However, I have seen it on a number of routers

I would liek to know how people use the metric across different ASes.

Consider the following case:

AS1----AS2...
\      /
\   /       |
  AS3
   |         |
  AS4.........



AS1 makes a route map to prefer via weights  (* AS2)
AS3 makes a route map to prefer via weights  (* AS1)
AS2 weights  (* AS3)

AS4 comes up now/flaps up after a reboot.

Will this converge?
-JS

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA03350 for <[e-mail]>; Wed, 15 Sep 2004 09:17:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7ZZQ-0007Ru-Sf; Wed, 15 Sep 2004 09:11:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7ZOl-00057N-U4 for [e-mail]; Wed, 15 Sep 2004 09:00:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00354 for <[e-mail]>; Wed, 15 Sep 2004 09:00:34 -0400 (EDT)
Received: from bay17-f13.bay17.hotmail.com ([64.4.43.63] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7ZTs-0002tC-CR for [e-mail]; Wed, 15 Sep 2004 09:05:53 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Sep 2004 05:35:17 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 15 Sep 2004 12:35:17 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Date: Wed, 15 Sep 2004 12:35:17 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 Sep 2004 12:35:17.0863 (UTC) FILETIME=[75129F70:01C49B20]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [Idr] weights in BGP
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi folks,

I do not see weights in the BGP base spec.
However, I have seen it on a number of routers

I would liek to know how people use the metric across different ASes.

Consider the following case:

AS1----AS2...
\      /
\   /       |
  AS3
   |         |
  AS4.........



AS1 makes a route map to prefer via weights  (* AS2)
AS3 makes a route map to prefer via weights  (* AS1)
AS2 weights  (* AS3)

AS4 comes up now/flaps up after a reboot.

Will this converge?
-JS

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA03221 for <[e-mail]>; Wed, 15 Sep 2004 08:55:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Z9R-0002VY-4O; Wed, 15 Sep 2004 08:44:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Z5K-00020n-S5 for [e-mail]; Wed, 15 Sep 2004 08:40:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28762 for <[e-mail]>; Wed, 15 Sep 2004 08:40:29 -0400 (EDT)
Received: from bay17-f19.bay17.hotmail.com ([64.4.43.69] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7ZAR-0002Sf-5p for [e-mail]; Wed, 15 Sep 2004 08:45:48 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Sep 2004 05:39:29 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 15 Sep 2004 12:39:29 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Date: Wed, 15 Sep 2004 12:39:29 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 Sep 2004 12:39:29.0691 (UTC) FILETIME=[0B2C86B0:01C49B21]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: [Idr] Re: weights in BGP
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

to clarify a bit:

AS1 makes a route map to prefer via weights  anything from AS2
AS3 makes a route map to prefer via weights  anything from AS1
AS2 weights  anything from AS3

AS4 comes up now/flaps up after a reboot.

Will this converge?
-JS

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?pageþatures/featuredemail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA03137 for <[e-mail]>; Wed, 15 Sep 2004 08:46:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Z8H-0002N0-Ib; Wed, 15 Sep 2004 08:43:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Z0g-0001US-8k for [e-mail]; Wed, 15 Sep 2004 08:35:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28288 for <[e-mail]>; Wed, 15 Sep 2004 08:35:40 -0400 (EDT)
Received: from bay17-f11.bay17.hotmail.com ([64.4.43.61] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Z5m-0002ML-5j for [e-mail]; Wed, 15 Sep 2004 08:40:59 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Sep 2004 05:35:09 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 15 Sep 2004 12:35:08 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Date: Wed, 15 Sep 2004 12:35:08 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 Sep 2004 12:35:09.0335 (UTC) FILETIME=[6FFD5A70:01C49B20]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [Idr] weights in cisco
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi folks,

I do not see weights in the BGP base spec.
However, I have seen it on a number of routers

I would liek to know how people use the metric across different ASes.

Consider the following case:

AS1----AS2...
\      /
\   /       |
  AS3
   |         |
  AS4.........



AS1 makes a route map to prefer via weights  (* AS2)
AS3 makes a route map to prefer via weights  (* AS1)
AS2 weights  (* AS3)

AS4 comes up now/flaps up after a reboot.

Will this converge?
-JS

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?pageþatures/junkmail


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14021 for <[e-mail]>; Mon, 13 Sep 2004 17:52:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6yVe-0005pb-AF; Mon, 13 Sep 2004 17:37:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6xvP-0002dU-GY for [e-mail]; Mon, 13 Sep 2004 16:59:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10670 for <[e-mail]>; Mon, 13 Sep 2004 16:59:44 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6y0A-00033s-0l for [e-mail]; Mon, 13 Sep 2004 17:04:43 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i8DKxE919744 for <[e-mail]>; Mon, 13 Sep 2004 13:59:14 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i8DKx9e76013 for <[e-mail]>; Mon, 13 Sep 2004 13:59:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 13 Sep 2004 13:59:09 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Subject: [Idr] revised base spec
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

The -25 version reflects the comments we received from the IESG.

Yakov.
------- Forwarded Message

Date:    Mon, 13 Sep 2004 16:05:25 -0400
From:    [e-mail]
To:      [e-mail]
cc:      [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-25.txt

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF
.

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter, S. Hares
	Filename	: draft-ietf-idr-bgp4-25.txt
	Pages		: 100
	Date		: 2004-9-13
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-25.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the mess
age.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-25.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-25.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-25.txt

- --OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-25.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


- --OtherAccess--

- --NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

- --NextPart--




------- End of Forwarded Message


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA13427 for <[e-mail]>; Mon, 13 Sep 2004 16:55:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6xDg-00081C-QH; Mon, 13 Sep 2004 16:14:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6x4q-0002y0-6k; Mon, 13 Sep 2004 16:05:28 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02426; Mon, 13 Sep 2004 16:05:25 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Mon, 13 Sep 2004 16:05:25 -0400
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-25.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter, S. Hares
	Filename	: draft-ietf-idr-bgp4-25.txt
	Pages		: 100
	Date		: 2004-9-13
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-25.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-25.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-25.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-25.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-25.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA29863 for <[e-mail]>; Thu, 9 Sep 2004 22:46:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5bOY-0007Z1-Tt; Thu, 09 Sep 2004 22:44:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5bO0-0007R2-Pc for [e-mail]; Thu, 09 Sep 2004 22:43:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28660 for <[e-mail]>; Thu, 9 Sep 2004 22:43:38 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.199] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5bRw-0003TL-GC for [e-mail]; Thu, 09 Sep 2004 22:47:47 -0400
Received: by mproxy.gmail.com with SMTP id 73so637901rnl for <[e-mail]>; Thu, 09 Sep 2004 19:43:30 -0700 (PDT)
Received: by 10.38.59.62 with SMTP id h62mr1628177rna; Thu, 09 Sep 2004 19:43:30 -0700 (PDT)
Received: by 10.38.102.10 with HTTP; Thu, 9 Sep 2004 19:43:30 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Sep 2004 08:13:30 +0530
From: Glen Kent <[e-mail]>
To: "Joel M. Halpern" <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
In-Reply-To: <5.1.0.14.0.20040909074509.02fac708@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]> <[e-mail]> <5.1.0.14.0.20040909074509.02fac708@localhost>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Content-Transfer-Encoding: 7bit
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Glen Kent <[e-mail]>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Joel,

> Allow me to paraphrase slightly:
> 
> When speaking to an ECMP speaking EBGP peer, we could send the multiple paths.
> There is slightly more information available to the peer if we do
> that.  But not much.
> 
> We still need to define the AS path manipulation so that an entity which is
> using multiple paths (and possibly hearing multiple paths from other
> speakers) will be able to construct usable paths that preserve loop prevention.

Aha .. 

> Thus, we concluded that we need the ugly bits anyway.
> So we used them to avoid adding protocol complexity to EBGP interaction.
> If folks want the multiple paths across the EBGP exchanges, it can probably
> be done.

Yes you can certainly do that, but then how do you deal with routers
that cant parse this new path attribute? I think the current solution
is more backward compatible and easier to roll out.

Looks Good.

Glen.

> 
> Yours,
> Joel
> 
> 
> 
> At 02:59 PM 9/9/2004 +0530, Manav Bhatia wrote:
> >Glen,
> >
> >We don't need to advertise the individual ECMP BGP routes to the EBGP peer,
> >as the EBGP peer always resets the NEXT_HOP to itself. All you need to tell
> >your downstream peers is the ASes that their traffic will be going through
> >if it comes to you.
> >
> >You need to construct the synthetic AS_PATH if you are installing multiple
> >BGP routes in your FIB (for load balancing, etc) because you *have* to
> >advertise whatever you use for your forwarding. Failing to do that can break
> >your routing in interesting ways!
> >
> >Regards,
> >Manav
> >
> >]-----Original Message-----
> >]From: Glen Kent [mailto:[e-mail]]
> >]Sent: Thursday, September 09, 2004 10:43 AM
> >]To: [e-mail]; [e-mail]
> >]Subject: Re: [Idr] FW: I-D
> >]ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
> >]
> >]Hmm ..
> >]
> >]Why dont you advertise the equal cost routes that you have
> >]learnt from other BGP speakers to your EBGP peers? Why go in
> >]for those complex AS_PATH manipulations when advertising
> >]routes to an EBGP peer?
> >]
> >]Glen
> >]
> >]Could be an obvious thing, but its late in the night and my
> >]coffee mug is empty!
> >]
> >]----- Original Message -----
> >]From: "Manav Bhatia" <[e-mail]>
> >]To: <[e-mail]>
> >]Sent: Wednesday, September 08, 2004 10:17 AM
> >]Subject: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
> >]
> >]
> >]> Hi,
> >]>
> >]> This is the revised draft that was presented in 57th IETF.
> >]We would like
> >]> this draft to be discussed in the IDR WG to see if it's a
> >]sensible work item
> >]> for this working group.
> >]>
> >]> Thanks,
> >]> Manav
> >]>
> >]> ----- Original Message -----
> >]> From: <[e-mail]>
> >]> To: <[e-mail]>
> >]> Sent: Wednesday, September 08, 2004 1:26 AM
> >]> Subject: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
> >]>
> >]>
> >]>>A New Internet-Draft is available from the on-line Internet-Drafts
> >]> directories.
> >]>>
> >]>>
> >]>> Title : Advertising Equal Cost MultiPath routes in BGP
> >]>> Author(s) : M. Bhatia,  J. Halpern
> >]>> Filename : draft-bhatia-ecmp-routes-in-bgp-01.txt
> >]>> Pages : 18
> >]>> Date : 2004-9-7
> >]>>
> >]>> This document describes an extensible mechanism that will
> >]allow a BGP
> >]>>   [BGP4] speaker to advertise equal cost multiple BGP routes for a
> >]>>   destination to its peers. A new BGP capability [BGP-CAP],
> >]termed
> >]>>   "Equal Cost Multipath Capability", is defined, which
> >]would allow a
> >]>>   local BGP speaker to express its ability to support
> >]advertisement of
> >]>>   such multiple paths to its peers.
> >]>>
> >]>> A URL for this Internet-Draft is:
> >]>>
> >]http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in
> >]-bgp-01.txt
> >]
> >
> >
> >_______________________________________________
> >Idr mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/idr
> 
>

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA22852 for <[e-mail]>; Thu, 9 Sep 2004 07:54:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5NSG-00023v-T6; Thu, 09 Sep 2004 07:51:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5NPN-0001Nv-0f for [e-mail]; Thu, 09 Sep 2004 07:48:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10051 for <[e-mail]>; Thu, 9 Sep 2004 07:48:07 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5NT8-0000Cf-OF for [e-mail]; Thu, 09 Sep 2004 07:52:07 -0400
Received: from [194.251.170.108] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7538508; Thu, 09 Sep 2004 07:47:10 -0400
Message-Id: <5.1.0.14.0.20040909074509.02fac708@localhost>
X-Sender: [e-mail]@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Sep 2004 07:47:32 -0400
To: [e-mail], <[e-mail]>, <[e-mail]>
From: "Joel M. Halpern" <[e-mail]>
Subject: RE: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Allow me to paraphrase slightly:

When speaking to an ECMP speaking EBGP peer, we could send the multiple paths.
There is slightly more information available to the peer if we do 
that.  But not much.

We still need to define the AS path manipulation so that an entity which is 
using multiple paths (and possibly hearing multiple paths from other 
speakers) will be able to construct usable paths that preserve loop prevention.
Thus, we concluded that we need the ugly bits anyway.
So we used them to avoid adding protocol complexity to EBGP interaction.
If folks want the multiple paths across the EBGP exchanges, it can probably 
be done.

Yours,
Joel

At 02:59 PM 9/9/2004 +0530, Manav Bhatia wrote:
>Glen,
>
>We don't need to advertise the individual ECMP BGP routes to the EBGP peer,
>as the EBGP peer always resets the NEXT_HOP to itself. All you need to tell
>your downstream peers is the ASes that their traffic will be going through
>if it comes to you.
>
>You need to construct the synthetic AS_PATH if you are installing multiple
>BGP routes in your FIB (for load balancing, etc) because you *have* to
>advertise whatever you use for your forwarding. Failing to do that can break
>your routing in interesting ways!
>
>Regards,
>Manav
>
>]-----Original Message-----
>]From: Glen Kent [mailto:[e-mail]]
>]Sent: Thursday, September 09, 2004 10:43 AM
>]To: [e-mail]; [e-mail]
>]Subject: Re: [Idr] FW: I-D
>]ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
>]
>]Hmm ..
>]
>]Why dont you advertise the equal cost routes that you have
>]learnt from other BGP speakers to your EBGP peers? Why go in
>]for those complex AS_PATH manipulations when advertising
>]routes to an EBGP peer?
>]
>]Glen
>]
>]Could be an obvious thing, but its late in the night and my
>]coffee mug is empty!
>]
>]----- Original Message -----
>]From: "Manav Bhatia" <[e-mail]>
>]To: <[e-mail]>
>]Sent: Wednesday, September 08, 2004 10:17 AM
>]Subject: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
>]
>]
>]> Hi,
>]>
>]> This is the revised draft that was presented in 57th IETF.
>]We would like
>]> this draft to be discussed in the IDR WG to see if it's a
>]sensible work item
>]> for this working group.
>]>
>]> Thanks,
>]> Manav
>]>
>]> ----- Original Message -----
>]> From: <[e-mail]>
>]> To: <[e-mail]>
>]> Sent: Wednesday, September 08, 2004 1:26 AM
>]> Subject: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
>]>
>]>
>]>>A New Internet-Draft is available from the on-line Internet-Drafts
>]> directories.
>]>>
>]>>
>]>> Title : Advertising Equal Cost MultiPath routes in BGP
>]>> Author(s) : M. Bhatia,  J. Halpern
>]>> Filename : draft-bhatia-ecmp-routes-in-bgp-01.txt
>]>> Pages : 18
>]>> Date : 2004-9-7
>]>>
>]>> This document describes an extensible mechanism that will
>]allow a BGP
>]>>   [BGP4] speaker to advertise equal cost multiple BGP routes for a
>]>>   destination to its peers. A new BGP capability [BGP-CAP],
>]termed
>]>>   "Equal Cost Multipath Capability", is defined, which
>]would allow a
>]>>   local BGP speaker to express its ability to support
>]advertisement of
>]>>   such multiple paths to its peers.
>]>>
>]>> A URL for this Internet-Draft is:
>]>>
>]http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in
>]-bgp-01.txt
>]
>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA21825 for <[e-mail]>; Thu, 9 Sep 2004 05:36:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5LJj-0008LU-Nm; Thu, 09 Sep 2004 05:34:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5LHQ-0007tY-JX for [e-mail]; Thu, 09 Sep 2004 05:31:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01028 for <[e-mail]>; Thu, 9 Sep 2004 05:31:45 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5LLE-0006IZ-JU for [e-mail]; Thu, 09 Sep 2004 05:35:46 -0400
Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA20250; Thu, 9 Sep 2004 02:31:15 -0700 (PDT)
Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Sep 2004 02:30:28 -0700
Received: from Floyd ([172.24.2.233]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 02:30:28 -0700
From: "Manav Bhatia" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Date: Thu, 9 Sep 2004 14:59:17 +0530
Organization: Riverstone Networks
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcSWK7zjKEI56xMkR8GaLb/fDDVNOgAGng/g
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Sep 2004 09:30:28.0431 (UTC) FILETIME=[A4C715F0:01C4964F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Glen,

We don't need to advertise the individual ECMP BGP routes to the EBGP peer,
as the EBGP peer always resets the NEXT_HOP to itself. All you need to tell
your downstream peers is the ASes that their traffic will be going through
if it comes to you.

You need to construct the synthetic AS_PATH if you are installing multiple
BGP routes in your FIB (for load balancing, etc) because you *have* to
advertise whatever you use for your forwarding. Failing to do that can break
your routing in interesting ways!

Regards,
Manav

]-----Original Message-----
]From: Glen Kent [mailto:[e-mail]] 
]Sent: Thursday, September 09, 2004 10:43 AM
]To: [e-mail]; [e-mail]
]Subject: Re: [Idr] FW: I-D 
]ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
]
]Hmm .. 
]
]Why dont you advertise the equal cost routes that you have 
]learnt from other BGP speakers to your EBGP peers? Why go in 
]for those complex AS_PATH manipulations when advertising 
]routes to an EBGP peer?
]
]Glen
]
]Could be an obvious thing, but its late in the night and my 
]coffee mug is empty!
]
]----- Original Message -----
]From: "Manav Bhatia" <[e-mail]>
]To: <[e-mail]>
]Sent: Wednesday, September 08, 2004 10:17 AM
]Subject: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
]
]
]> Hi,
]> 
]> This is the revised draft that was presented in 57th IETF. 
]We would like
]> this draft to be discussed in the IDR WG to see if it's a 
]sensible work item
]> for this working group.
]> 
]> Thanks,
]> Manav
]> 
]> ----- Original Message ----- 
]> From: <[e-mail]>
]> To: <[e-mail]>
]> Sent: Wednesday, September 08, 2004 1:26 AM
]> Subject: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
]> 
]> 
]>>A New Internet-Draft is available from the on-line Internet-Drafts
]> directories.
]>> 
]>> 
]>> Title : Advertising Equal Cost MultiPath routes in BGP
]>> Author(s) : M. Bhatia,  J. Halpern
]>> Filename : draft-bhatia-ecmp-routes-in-bgp-01.txt
]>> Pages : 18
]>> Date : 2004-9-7
]>> 
]>> This document describes an extensible mechanism that will 
]allow a BGP 
]>>   [BGP4] speaker to advertise equal cost multiple BGP routes for a 
]>>   destination to its peers. A new BGP capability [BGP-CAP], 
]termed   
]>>   "Equal Cost Multipath Capability", is defined, which 
]would allow a 
]>>   local BGP speaker to express its ability to support 
]advertisement of    
]>>   such multiple paths to its peers.
]>> 
]>> A URL for this Internet-Draft is:
]>> 
]http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in
]-bgp-01.txt
]


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA19413 for <[e-mail]>; Thu, 9 Sep 2004 01:15:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5HGJ-0006W9-DP; Thu, 09 Sep 2004 01:14:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5HFD-0006Jp-O0 for [e-mail]; Thu, 09 Sep 2004 01:13:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03515 for <[e-mail]>; Thu, 9 Sep 2004 01:13:15 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.194] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5HIz-0002St-St for [e-mail]; Thu, 09 Sep 2004 01:17:11 -0400
Received: by mproxy.gmail.com with SMTP id 73so522356rnl for <[e-mail]>; Wed, 08 Sep 2004 22:13:12 -0700 (PDT)
Received: by 10.38.86.66 with SMTP id j66mr3263022rnb; Wed, 08 Sep 2004 22:13:12 -0700 (PDT)
Received: by 10.38.102.10 with HTTP; Wed, 8 Sep 2004 22:13:12 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 9 Sep 2004 10:43:12 +0530
From: Glen Kent <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Glen Kent <[e-mail]>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hmm .. 

Why dont you advertise the equal cost routes that you have learnt from
other BGP speakers to your EBGP peers? Why go in for those complex
AS_PATH manipulations when advertising routes to an EBGP peer?

Glen

Could be an obvious thing, but its late in the night and my coffee mug is empty!

----- Original Message ----- 
From: "Manav Bhatia" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 08, 2004 10:17 AM
Subject: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt


> Hi,
> 
> This is the revised draft that was presented in 57th IETF. We would like
> this draft to be discussed in the IDR WG to see if it's a sensible work item
> for this working group.
> 
> Thanks,
> Manav
> 
> ----- Original Message ----- 
> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, September 08, 2004 1:26 AM
> Subject: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
> 
> 
>>A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> 
>> 
>> Title : Advertising Equal Cost MultiPath routes in BGP
>> Author(s) : M. Bhatia,  J. Halpern
>> Filename : draft-bhatia-ecmp-routes-in-bgp-01.txt
>> Pages : 18
>> Date : 2004-9-7
>> 
>> This document describes an extensible mechanism that will allow a BGP 
>>   [BGP4] speaker to advertise equal cost multiple BGP routes for a 
>>   destination to its peers. A new BGP capability [BGP-CAP], termed   
>>   "Equal Cost Multipath Capability", is defined, which would allow a 
>>   local BGP speaker to express its ability to support advertisement of    
>>   such multiple paths to its peers.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-01.txt

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA05455 for <[e-mail]>; Wed, 8 Sep 2004 01:02:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4uWR-0000yI-8d; Wed, 08 Sep 2004 00:57:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4uPY-00082t-NN for [e-mail]; Wed, 08 Sep 2004 00:50:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08658 for <[e-mail]>; Wed, 8 Sep 2004 00:50:18 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4uT5-0007uv-Sk for [e-mail]; Wed, 08 Sep 2004 00:54:04 -0400
Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id VAA16714; Tue, 7 Sep 2004 21:49:49 -0700 (PDT)
Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 21:49:03 -0700
Received: from Floyd ([172.24.2.233]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Sep 2004 21:49:02 -0700
From: "Manav Bhatia" <[e-mail]>
To: <[e-mail]>
Date: Wed, 8 Sep 2004 10:17:51 +0530
Organization: Riverstone Networks
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0044_01C4958D.1B205E50"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcSVXRPOhOD7rNadSUORuzjAmGIbWgAAMFMw
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 08 Sep 2004 04:49:03.0287 (UTC) FILETIME=[2A08D470:01C4955F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Subject: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

This is a multi-part message in MIME format.

------=_NextPart_000_0044_01C4958D.1B205E50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

This is the revised draft that was presented in 57th IETF. We would like
this draft to be discussed in the IDR WG to see if it's a sensible work item
for this working group.

Thanks,
Manav

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 08, 2004 1:26 AM
Subject: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt


>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> Title : Advertising Equal Cost MultiPath routes in BGP
> Author(s) : M. Bhatia,  J. Halpern
> Filename : draft-bhatia-ecmp-routes-in-bgp-01.txt
> Pages : 18
> Date : 2004-9-7
> 
> This document describes an extensible mechanism that will allow a BGP 
>   [BGP4] speaker to advertise equal cost multiple BGP routes for a 
>   destination to its peers. A new BGP capability [BGP-CAP], termed   
>   "Equal Cost Multipath Capability", is defined, which would allow a 
>   local BGP speaker to express its ability to support advertisement of    
>   such multiple paths to its peers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [e-mail] with the word unsubscribe in the body of the
message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-bhatia-ecmp-routes-in-bgp-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-bhatia-ecmp-routes-in-bgp-01.txt".
> 
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

------=_NextPart_000_0044_01C4958D.1B205E50
Content-Type: application/octet-stream;
	name="ATT00019.dat"
Content-Disposition: attachment;
	filename="ATT00019.dat"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-bhatia-ecmp-routes-in-bgp-01.txt

------=_NextPart_000_0044_01C4958D.1B205E50
Content-Type: text/plain;
	name="draft-bhatia-ecmp-routes-in-bgp-01.txt"
Content-Disposition: attachment;
	filename="draft-bhatia-ecmp-routes-in-bgp-01.txt"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <[e-mail]>


------=_NextPart_000_0044_01C4958D.1B205E50
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

------=_NextPart_000_0044_01C4958D.1B205E50--