From idr-bounces@ietf.org Mon Oct 01 11:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcN2c-000828-4U; Mon, 01 Oct 2007 11:18:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcN2b-00081t-76 for idr@ietf.org; Mon, 01 Oct 2007 11:18:37 -0400 Received: from exprod7og58.obsmtp.com ([64.18.2.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcN2a-0005QW-R7 for idr@ietf.org; Mon, 01 Oct 2007 11:18:37 -0400 Received: from source ([66.129.224.36]) by exprod7ob58.obsmtp.com ([64.18.6.12]) with SMTP; Mon, 01 Oct 2007 08:18:35 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 08:17:36 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l91FHWn72177; Mon, 1 Oct 2007 08:17:32 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200710011517.l91FHWn72177@magenta.juniper.net> To: idr@ietf.org Subject: [Idr] IETF 70 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41521.1191251852.1@juniper.net> Date: Mon, 01 Oct 2007 08:17:32 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 01 Oct 2007 15:17:36.0437 (UTC) FILETIME=[32A75650:01C8043E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: skh@nexthop.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, Its about time to start thinking about agenda items for the next IETF. Please forward any IDR agenda items you might have to Sue and myself. The deadline is November 20, 2007. And if you plan to make a presentation, please also keep in mind the rule "no Internet Draft - no time slot". Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Oct 16 10:17:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihn7Y-000616-RM; Tue, 16 Oct 2007 10:10:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihn7T-0005vm-0m; Tue, 16 Oct 2007 10:10:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihn7S-00057k-GT; Tue, 16 Oct 2007 10:10:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6B5022AC5D; Tue, 16 Oct 2007 14:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ihn7S-0004Ju-6T; Tue, 16 Oct 2007 10:10:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 16 Oct 2007 10:10:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-v4nlri-v6nh-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --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 : Advertising an IPv4 NLRI with an IPv6 Next Hop Author(s) : F. Le Faucheur, E. Rosen Filename : draft-ietf-idr-v4nlri-v6nh-01.txt Pages : 10 Date : 2007-10-16 MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising an IPv4 Network Layer Reachability Information (NLRI) or a VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-v4nlri-v6nh-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-v4nlri-v6nh-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-v4nlri-v6nh-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 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-16100341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-v4nlri-v6nh-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-v4nlri-v6nh-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-16100341.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Tue Oct 16 11:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhodT-00069E-Ip; Tue, 16 Oct 2007 11:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhodR-00064J-9O for idr@ietf.org; Tue, 16 Oct 2007 11:47:09 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhodP-00013P-Ux for idr@ietf.org; Tue, 16 Oct 2007 11:47:09 -0400 X-IronPort-AV: E=Sophos;i="4.21,284,1188770400"; d="scan'208";a="155887521" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2007 17:47:07 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9GFl7Zr000923 for ; Tue, 16 Oct 2007 17:47:07 +0200 Received: from xbh-ams-331.emea.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 l9GFl6Uv028049 for ; Tue, 16 Oct 2007 15:47:07 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 17:47:06 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 17:47:06 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B2A5BC6-CB10-4A37-898E-1480B08BF779@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Tue, 16 Oct 2007 17:47:01 +0200 To: idr@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Oct 2007 15:47:06.0486 (UTC) FILETIME=[CDE1A160:01C8100B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15486.001 X-TM-AS-Result: No--24.506300-8.000000-1 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3674; t=1192549627; x=1193413627; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20I-D=20Action=3Adraft-ietf-idr-v4nlri-v6nh-01.txt=20 |Sender:=20; bh=9SQXKu4jUYn3FsNG0phAgBHInSn7BL23FDyp2gcaRCU=; b=L7+CjpkGJH82j/hbyLpWo2OqEKnXBRW0hWQpM3fQZrIHlWYkFVjnP4c0ATcMPpOGlMkIJ85+ UAGtg5+S9D/3ECKcDeC0bUIlmDZGj1+h0cMK2bq9ZJy5UJ9sUFPkHp/P; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Francois Le Faucheur IMAP Subject: [Idr] Re: I-D Action:draft-ietf-idr-v4nlri-v6nh-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello, For information, this version is identical to the previous one, with the exception of updated references. Cheers Francois On 16 Oct 2007, at 16:10, Internet-Drafts@ietf.org wrote: > 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 : Advertising an IPv4 NLRI with an IPv6 Next Hop > Author(s) : F. Le Faucheur, E. Rosen > Filename : draft-ietf-idr-v4nlri-v6nh-01.txt > Pages : 10 > Date : 2007-10-16 > > MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer > protocols to which the address carried in the Next Hop field may > belong is determined by the Address Family Identifier (AFI) and the > Subsequent Address Family Identifier (SAFI). The current AFI/SAFI > definitions for the IPv4 address family only have provisions for > advertising a Next Hop address that belongs to the IPv4 protocol when > advertising an IPv4 Network Layer Reachability Information (NLRI) or > a VPN-IPv4 NLRI. This document specifies the extensions necessary to > allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop > address that belongs to the IPv6 protocol. This comprises an > extension of the AFI/SAFI definitions to allow the address of the > Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 > protocol, the encoding of the Next Hop in order to determine which of > the protocols the address actually belongs to, and a new BGP > Capability allowing MP-BGP Peers to dynamically discover whether they > can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-v4nlri-v6nh-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org 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-v4nlri-v6nh-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: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-idr-v4nlri-v6nh-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. > Content-Type: text/plain > Content-ID: <2007-10-16100341.I-D\@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Oct 18 03:46:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiPwG-0002Am-8F; Thu, 18 Oct 2007 03:37:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiPwE-00025m-Jv for idr@ietf.org; Thu, 18 Oct 2007 03:37:02 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiPwD-0004vn-PB for idr@ietf.org; Thu, 18 Oct 2007 03:37:02 -0400 X-IronPort-AV: E=Sophos;i="4.21,293,1188770400"; d="scan'208,217";a="155954793" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2007 09:36:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9I7aqB9001726; Thu, 18 Oct 2007 09:36:52 +0200 Received: from xbh-ams-331.emea.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 l9I7adUx016627; Thu, 18 Oct 2007 07:36:52 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 09:36:32 +0200 Received: from [10.0.0.42] ([10.61.81.43]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 09:36:27 +0200 In-Reply-To: <47166061.609@gmail.com> References: <47166061.609@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <577EB899-DB24-4342-8CE7-4CDFD647FD9E@cisco.com> From: Francois Le Faucheur IMAP Date: Thu, 18 Oct 2007 09:36:20 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Oct 2007 07:36:28.0192 (UTC) FILETIME=[981DF200:01C81159] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.001 X-TM-AS-Result: No--25.166100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9447; t=1192693012; x=1193557012; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20I-D=20Action=3Adraft-ietf-idr-v4nlri-v6nh-01.txt |Sender:=20; bh=V64tzqZH0ljqi+t6Kotb7Ir9xylGiZkkPhtTumrJ8+E=; b=AYmvgcijMp1U8MJ+CD3SOgw19dyXr+sA+ilKkw2kauKmH+9jG0z1s2alscrnEDqKorIOBoWD IKBUUmX55jj26sheg59eZDhjUCOpi5IvyS4aZuK/WUPqkYFXlSqXChCU; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: idr@ietf.org, Francois Le Faucheur IMAP , erosen@cisco.com Subject: [Idr] Re: I-D Action:draft-ietf-idr-v4nlri-v6nh-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195296382==" Errors-To: idr-bounces@ietf.org --===============0195296382== Content-Type: multipart/alternative; boundary=Apple-Mail-57--362584653 --Apple-Mail-57--362584653 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Brian and all, On 17 Oct 2007, at 21:20, Brian E Carpenter wrote: > Francois, Eric, > > Is there a reason you allocate 2 bytes for SAFIs > in a BGP Capability Advertisement? > SAFIs are defined in RFC 4760 as one byte. I think the SAFI field should really be one byte. RFC4760 (section 8) pads the 1-byte SAFI with a 1-byte Reserved field when encoding AFI/SAFI for BGP Capability Advertisement (presumably for alignment/extensibility purposes): " 0 7 15 23 31 +-------+-------+-------+-------+ | AFI | Res. | SAFI | +-------+-------+-------+-------+ " I would propose to apply a similar approach to v4nlri-v6nh, which would give us: " +-----------------------------------------------------+ | NLRI AFI - 1 (2 octets) | +-----------------------------------------------------+ | Reserved (1 octet) | NLRI SAFI - 1 (1 octets) | +-----------------------------------------------------+ | Nexthop AFI - 1 (2 octets) | +-----------------------------------------------------+ | ..... | +-----------------------------------------------------+ | NLRI AFI - N (2 octets) | +-----------------------------------------------------+ | Reserved (1 octet) | NLRI SAFI - N (1 octet) | +-----------------------------------------------------+ | Nexthop AFI - N (2 octets) | +-----------------------------------------------------+ " Please let us know if you have comments/concerns. Thanks for catching this Brian. Francois > > If it's a conscious choice to allow for possible > expansion, it would be good to say so. In any case > you need to specify where the SAFI byte is aligned > in the two bytes. > > Brian --Apple-Mail-57--362584653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Brian and all,

On 17 Oct 2007, = at 21:20, Brian E Carpenter wrote:

Francois, Eric,

Is there a reason you allocate 2 = bytes for SAFIs
in a BGP Capability = Advertisement?
SAFIs are defined in RFC 4760 as = one byte.

I think the SAFI field = should really be one byte.

RFC4760 (section 8) pads the = 1-byte SAFI with a 1-byte Reserved field when encoding AFI/SAFI for BGP = Capability Advertisement (presumably for alignment/extensibility = purposes):=A0
"
=A0=A0 =A0=A0 =A0=A0 =A0=A0 =A00=A0 =A0 =A0=A0 7=A0 =A0 = =A0 15=A0 =A0 =A0 23=A0 =A0 =A0 31
=A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0+-------+-------+-------+-------+
=A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0|=A0 =A0 =A0 AFI=A0 =A0 =A0 | Res.=A0 | SAFI=A0 = |
=A0=A0= =A0=A0 =A0=A0 =A0=A0 = =A0+-------+-------+-------+-------+
"

I would propose to apply a = similar approach to v4nlri-v6nh, which would give = us:
"
=A0 =A0=A0 =A0=A0 = =A0+-----------------------------------------------------+
=A0 =A0 =A0 =A0=A0 = |=A0 =A0=A0 =A0=A0 =A0=A0 =A0NLRI AFI - 1 (2 octets)=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0|
=A0 =A0 =A0 =A0=A0 = +-----------------------------------------------------+
<= FONT class=3D"Apple-style-span" face=3D"Courier">=A0 =A0 =A0 =A0=A0 | =A0 = =A0 Reserved (1 octet)=A0=A0| =A0NLRI SAFI - 1 (1 octets) = |
=A0 = =A0 =A0 =A0=A0 = +-----------------------------------------------------+
<= FONT class=3D"Apple-style-span" face=3D"Courier">=A0 =A0 =A0 =A0=A0 |=A0 = =A0 =A0=A0 =A0=A0 =A0Nexthop AFI - 1 (2 octets) =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0|
=A0 =A0 =A0 =A0=A0 = +-----------------------------------------------------+
<= FONT class=3D"Apple-style-span" face=3D"Courier">=A0 =A0 =A0 =A0=A0 | =A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0.....=A0 =A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=A0 =A0 =A0 =A0=A0 = +-----------------------------------------------------+
<= FONT class=3D"Apple-style-span" face=3D"Courier">=A0 =A0 =A0 =A0=A0 |=A0 = =A0=A0 =A0=A0 =A0=A0 =A0NLRI AFI - N (2 octets)=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0|
=A0 =A0 =A0 =A0=A0 = +-----------------------------------------------------+
<= FONT class=3D"Apple-style-span" face=3D"Courier">=A0 =A0 =A0 =A0=A0 |=A0 = =A0 =A0Reserved (1 octet)=A0=A0| NLRI SAFI - N (1 octet)=A0 = =A0|
=A0= =A0 =A0 =A0=A0 = +-----------------------------------------------------+
<= FONT class=3D"Apple-style-span" face=3D"Courier">=A0 =A0 =A0 =A0=A0 |=A0 = =A0 =A0=A0 =A0=A0 =A0Nexthop AFI - N (2 octets) =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0|
=A0 =A0 =A0 =A0=A0 = +-----------------------------------------------------+
<= FONT class=3D"Apple-style-span" face=3D"Courier">"

Please let us know if you = have comments/concerns.

Thanks for catching this = Brian.

Francois




If it's = a conscious choice to allow for possible
you need to specify where the SAFI byte is = aligned
in the two bytes.

=A0 =A0 Brian
=
= --Apple-Mail-57--362584653-- --===============0195296382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0195296382==-- From idr-bounces@ietf.org Tue Oct 23 06:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHHm-0004OI-0O; Tue, 23 Oct 2007 06:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHHi-0004G3-OC for idr@ietf.org; Tue, 23 Oct 2007 06:46:54 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkHHY-0000z0-C9 for idr@ietf.org; Tue, 23 Oct 2007 06:46:50 -0400 Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1IkHGt-0006xr-Br for idr@ietf.org; Tue, 23 Oct 2007 12:46:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Oct 2007 12:46:02 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240130461E@paul.adoffice.local.de.easynet.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification for section 9.1.2 of rfc4271 Thread-Index: AcgVYegLb0mZP18RRwy9XBy/dFYjFA== From: "Ilya Varlashkin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Idr] Clarification for section 9.1.2 of rfc4271 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, in the section 9.1.2 of RFC4271 third paragraph has phrase: "..., or if it would become unresolvable if the route was installed in the routing table, the BGP route MUST be excluded from the Phase 2 decision function." Consider a BGP router (say, router C) that received prefix 192.2.1.1/32 from two different iBGP neighbours as follow: 1) neighbour A set NEXT_HOP to itself and local-pref for this prefix is 100; this update was received first (in time) 2) neighbour B preserved original next-hop, which happened to be 192.2.1.1 and local-pref for this prefix is 150 (this update was received later) There are no any other routing information (whether via BGP or any other protocol) known to router C. Router C at the moment has 192.2.1.1/32 prefix in it's RIB pointing to router A's address. In this condition, does update from router B falls under cited requirement "would become unresolvable" and should it be excluded from further consideration or is it permissible (per RFC) to select such update as best and install it to the RIB? Kind regards, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Oct 23 11:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLWb-0006JB-3z; Tue, 23 Oct 2007 11:18:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLWY-0006H7-6G for idr@ietf.org; Tue, 23 Oct 2007 11:18:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkLWX-00039E-Ph for idr@ietf.org; Tue, 23 Oct 2007 11:18:30 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2007 08:18:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9NFITsJ023518; Tue, 23 Oct 2007 08:18:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9NFHrxh001526; Tue, 23 Oct 2007 15:18:27 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 08:18:14 -0700 Received: from [192.168.0.110] ([10.21.66.47]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 08:18:14 -0700 In-Reply-To: <7000E71D8C525042A815432358B2F1240130461E@paul.adoffice.local.de.easynet.net> References: <7000E71D8C525042A815432358B2F1240130461E@paul.adoffice.local.de.easynet.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DA1F668-C05D-41BD-BE77-D390133342B9@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Clarification for section 9.1.2 of rfc4271 Date: Tue, 23 Oct 2007 08:18:02 -0700 To: Ilya Varlashkin X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Oct 2007 15:18:14.0624 (UTC) FILETIME=[EE80B600:01C81587] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1288; t=1193152709; x=1194016709; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Clarification=20for=20section=209.1.2=20of=20 rfc4271 |Sender:=20; bh=IzC5MlKl3Lf/oRagt1TmMkX4YL9sw/TAAS9a4gu67eo=; b=a+s8uea7dUUh3Y3kXNgPSx7ewm9QpdUUPdbHpnzK4h86lgFuRJdWFtbqqCYZl8UC2VEeJcBw 1rfMyjA+62iMOlqhyIetwa9Ucl7k+FeCfS4KVPTLmNwzhIN8rtCzP4xO; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Oct 23, 2007, at 3:46 AM, Ilya Varlashkin wrote: > Hi, > > in the section 9.1.2 of RFC4271 third paragraph has phrase: > > "..., or if it would become unresolvable if the route was installed in > the routing table, the BGP route MUST be excluded from the Phase 2 > decision function." > > Consider a BGP router (say, router C) that received prefix > 192.2.1.1/32 > from two different iBGP neighbours as follow: > > 1) neighbour A set NEXT_HOP to itself and local-pref for this > prefix is > 100; this update was received first (in time) > 2) neighbour B preserved original next-hop, which happened to be > 192.2.1.1 and local-pref for this prefix is 150 (this update was > received later) > > There are no any other routing information (whether via BGP or any > other > protocol) known to router C. > > Router C at the moment has 192.2.1.1/32 prefix in it's RIB pointing to > router A's address. In this condition, does update from router B falls > under cited requirement "would become unresolvable" and should it be > excluded from further consideration or is it permissible (per RFC) to > select such update as best and install it to the RIB? Yes, that would result in recursive resolution and as such would not be resolvable. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr