headers
Yakov Rekhter | 1 Oct 2007 17:17
Favicon

IETF 70

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 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 16 Oct 2007 16:10
Picon
Favicon

I-D Action:draft-ietf-idr-v4nlri-v6nh-01.txt

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Francois Le Faucheur IMAP | 16 Oct 2007 17:47
Picon
Favicon

Re: I-D Action:draft-ietf-idr-v4nlri-v6nh-01.txt

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 <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois Le Faucheur IMAP | 18 Oct 2007 09:36
Picon
Favicon

Re: I-D Action:draft-ietf-idr-v4nlri-v6nh-01.txt

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

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Ilya Varlashkin | 23 Oct 2007 12:46

Clarification for section 9.1.2 of rfc4271

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 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Tony Li | 23 Oct 2007 17:18
Picon
Favicon

Re: Clarification for section 9.1.2 of rfc4271


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 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |

Gmane