Subject: [Idr] BGP 1771 follow-on draft : Scalability,etc

From: Erblichs <[email-masked]>
Date: Mon, 28 Feb 2005 19:53:00 -0800

Group, here are a few suggestions to this document
	that deal with scalability and minimizing convergence
	timeframes.

	6.5 Hold Timer Expired error Handling
	--------------------------------------

	A) If a situation occurs that prevents the
	reception of a KEEPALIVE at Router-B from
	Router-A, delayed or retransmitted by IP/TCP
	for UPDATES will keep the connection open...

		AND

	B) With the current situation to decrease bandwidth
	the non-transmiting of KEEPALIVES will have no
	effect as long as UPDATES are sent within the HOLD
	Timer interval

		AND
	
	C) KEEPALIVES that are incorrectly configured will
	seem to keep a connection alive as long as UPDATES
	are recieved from the same neighbor

		AND

	D) If a NOTIFICATION is recieved, since the connection
	is closed after sending it, the reciept of this forces
	the connection to stay open HOLD TIME interval longer
	without the connection being 2-way.

	Thus with the proper handling of KEEPALIVES specified
	lower in this set of suggestions, only the KEEPALIVE
	is needed to be processed to keep the connection open.

	TCP / BGP Interactions
	----------------------
	Even though BGP uses TCP as its transport protocol,
	the formation of large BGP protocol packets that are
	multiple MTU sizes will force IP to fragment it into
	multiple MTU sized packets. The loss of just one
	fragment will cause the entire original large packet
	to be resent. Each fragment will be handled and
	routed independently. The over-head of fragmenting
	and then re-assembling of the packet will also
	delay reception of the packet at the BGP destination,
	due to the fact that all the fragments must be
	recieved before being handed to BGP.

	Default TCP behaviour is to initially probe for bandwidth
	availablity, during what is known as slow start. This
	initial slow-start is normally set at 4 MTUs/segments.If a
	burst of TCP data is required that is greater than what
	is the current window transmit capability, the transmitter
	will wait for acknowledgements or a large timeout
	before transmitting additional data. These acknowledgements
	will come in approximate 1 round-trip time frame. 

	This situation also
	occurs after idle times, which prevents burst of data.

	Lastly, current TCP implimentations will back-off window
	sizes, if the current applications are not using the max
	size of the transmit window. Thus is known as application
	versus network bandwidth limited.

	Thus, in some/many environments, the limiting of the size of
	a packet to within the MTU size and sending multiple full
	 header packets versus sending 1 large packet os preferable.
	This almost gurantees that packets are recieved within
	1 round trip time verus 5 or more RTTs for large fragmentated
	packets.

	Neighbor Scalability
	--------------------
	(ex:Update message storm)
	Under some environments,  KEEPALIVE messages can be recieved
	and not processed within Hold Timer intervals. If these
	messages are not handled in such a way that they are
	guranteed to be processed before the timer expires,
	the neighbor adjacency will normally be dropped. One possible
	suggestion is to mark the input control packet queue
	as to the current end of the queue when the timer expires,
	and to process to that mark before processing the
	functions that deal with this timer.

	If the queue is being filled and KEEPALIVES are being dropped
	due tail-drops, then their is a small chance that a UPDATE
	from the same BGP-router as the KEEPALIVE would be present.

	Neighbor Flapping
	------------------
	Under some circumstances including short Hold Timers,
	neighbors may be repeatedly dropped. Any updates/routes/etc
	could/SHOULD be placed on a delay queue. A interval
	timer should be set to X and to not exceeed 2x the max
	time frame between past flaps of the neighbor. After
	this timer / time interval has passed, it is less likely 
	to flap in the near time frame.

Mitchell Erblich

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

Date: Mon, 28 Feb 2005 19:53:00 -0800
From: Erblichs <[email-masked]>
To: [email-masked]
Subject: [Idr] BGP 1771 follow-on draft : Scalability,etc
Sender: [email-masked]

	Group, here are a few suggestions to this document
	that deal with scalability and minimizing convergence
	timeframes.

	6.5 Hold Timer Expired error Handling
	--------------------------------------

	A) If a situation occurs that prevents the
	reception of a KEEPALIVE at Router-B from
	Router-A, delayed or retransmitted by IP/TCP
	for UPDATES will keep the connection open...

		AND

	B) With the current situation to decrease bandwidth
	the non-transmiting of KEEPALIVES will have no
	effect as long as UPDATES are sent within the HOLD
	Timer interval

		AND
	
	C) KEEPALIVES that are incorrectly configured will
	seem to keep a connection alive as long as UPDATES
	are recieved from the same neighbor

		AND

	D) If a NOTIFICATION is recieved, since the connection
	is closed after sending it, the reciept of this forces
	the connection to stay open HOLD TIME interval longer
	without the connection being 2-way.

	Thus with the proper handling of KEEPALIVES specified
	lower in this set of suggestions, only the KEEPALIVE
	is needed to be processed to keep the connection open.

	TCP / BGP Interactions
	----------------------
	Even though BGP uses TCP as its transport protocol,
	the formation of large BGP protocol packets that are
	multiple MTU sizes will force IP to fragment it into
	multiple MTU sized packets. The loss of just one
	fragment will cause the entire original large packet
	to be resent. Each fragment will be handled and
	routed independently. The over-head of fragmenting
	and then re-assembling of the packet will also
	delay reception of the packet at the BGP destination,
	due to the fact that all the fragments must be
	recieved before being handed to BGP.

	Default TCP behaviour is to initially probe for bandwidth
	availablity, during what is known as slow start. This
	initial slow-start is normally set at 4 MTUs/segments.If a
	burst of TCP data is required that is greater than what
	is the current window transmit capability, the transmitter
	will wait for acknowledgements or a large timeout
	before transmitting additional data. These acknowledgements
	will come in approximate 1 round-trip time frame. 

	This situation also
	occurs after idle times, which prevents burst of data.

	Lastly, current TCP implimentations will back-off window
	sizes, if the current applications are not using the max
	size of the transmit window. Thus is known as application
	versus network bandwidth limited.

	Thus, in some/many environments, the limiting of the size of
	a packet to within the MTU size and sending multiple full
	 header packets versus sending 1 large packet os preferable.
	This almost gurantees that packets are recieved within
	1 round trip time verus 5 or more RTTs for large fragmentated
	packets.

	Neighbor Scalability
	--------------------
	(ex:Update message storm)
	Under some environments,  KEEPALIVE messages can be recieved
	and not processed within Hold Timer intervals. If these
	messages are not handled in such a way that they are
	guranteed to be processed before the timer expires,
	the neighbor adjacency will normally be dropped. One possible
	suggestion is to mark the input control packet queue
	as to the current end of the queue when the timer expires,
	and to process to that mark before processing the
	functions that deal with this timer.

	If the queue is being filled and KEEPALIVES are being dropped
	due tail-drops, then their is a small chance that a UPDATE
	from the same BGP-router as the KEEPALIVE would be present.

	Neighbor Flapping
	------------------
	Under some circumstances including short Hold Timers,
	neighbors may be repeatedly dropped. Any updates/routes/etc
	could/SHOULD be placed on a delay queue. A interval
	timer should be set to X and to not exceeed 2x the max
	time frame between past flaps of the neighbor. After
	this timer / time interval has passed, it is less likely 
	to flap in the near time frame.

Mitchell Erblich

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

From: "Alok" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Idr] BGP as an IGP
Date: Tue, 1 Mar 2005 00:11:22 +0530
Sender: [email-masked]

Thank you all for your responses and the references.

I am not talking about recursive resolution.

However, I am still at loss to comprehend what is wrong with static to
"adjacent" loopbacks (topology being physical full mesh or not)

Perhaps I should clarify this offlist.

-thanks
Alok

----- Original Message ----- 
From: "Robert Raszuk" <[email-masked]>
To: "Alok" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 28, 2005 10:04 PM
Subject: Re: [Idr] BGP as an IGP

> Alok,
>
> Using BGP as an IGP works well when the number of routers involved is
> less or equal then two. When you have real network you are much better
> using real IGP to resolve bgp next hops as opposed to multi level BGP
> recursion or whole bunch of static routes.
>
> Once we get on the same page there then we can move to selecting bgp
> route distribution scheme :). Either one listed below has pros & cons.
>
> Cheers,
> R.
>
> PS. Btw that sounds more like a question to isp-bgp list then to idr.
>
>  > Alok wrote:
>  >
> > Hi,
> >
> >
> > Are there any good references to using BGP as an IGP in the following
> > scenarios:
> >
> > a. using RRs. (topology being a ring)
> > b. using Full mesh. (topology being full mesh)
> > c. using confederations (topology being triangles joined together)
> >
> > In terms of scalability, what is the most recommended?
> >
> > -thanks
> > Alok
> >
> > _______________________________________________
> > Idr mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/idr
> >

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

Date: Mon, 28 Feb 2005 08:34:30 -0800
From: Robert Raszuk <[email-masked]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Alok <[email-masked]>
Subject: Re: [Idr] BGP as an IGP
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Alok,

Using BGP as an IGP works well when the number of routers involved is 
less or equal then two. When you have real network you are much better 
using real IGP to resolve bgp next hops as opposed to multi level BGP 
recursion or whole bunch of static routes.

Once we get on the same page there then we can move to selecting bgp 
route distribution scheme :). Either one listed below has pros & cons.

Cheers,
R.

PS. Btw that sounds more like a question to isp-bgp list then to idr.

 > Alok wrote:
 >
> Hi,
> 
> 
> Are there any good references to using BGP as an IGP in the following
> scenarios:
> 
> a. using RRs. (topology being a ring)
> b. using Full mesh. (topology being full mesh)
> c. using confederations (topology being triangles joined together)
> 
> In terms of scalability, what is the most recommended?
> 
> -thanks
> Alok
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
> 

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

Date: Mon, 28 Feb 2005 09:09:07 -0500 (EST)
From: Rich Fulton <[email-masked]>
To: Alok <[email-masked]>
Subject: Re: [Idr] BGP as an IGP
Cc: [email-masked]
Sender: [email-masked]

> Are there any good references to using BGP as an IGP in the following
> scenarios:
> a. using RRs. (topology being a ring)
> b. using Full mesh. (topology being full mesh)
> c. using confederations (topology being triangles joined together)

http://www.amazon.com/exec/obidos/ASIN/1562056522/002-8674552-3904820

> In terms of scalability, what is the most recommended?

that is a loaded question.  typically RRs will 
win the scalability debate.  but it really 
depends on your topology.

   /rf

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

From: "Alok" <[email-masked]>
To: <[email-masked]>
Date: Mon, 28 Feb 2005 18:59:58 +0530
Subject: [Idr] BGP as an IGP
Sender: [email-masked]

Hi,

Are there any good references to using BGP as an IGP in the following
scenarios:

a. using RRs. (topology being a ring)
b. using Full mesh. (topology being full mesh)
c. using confederations (topology being triangles joined together)

In terms of scalability, what is the most recommended?

-thanks
Alok

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

Date: Mon, 28 Feb 2005 02:48:20 +0000 (GMT)
From: Acharya <[email-masked]>
Subject: Re: [Idr] BGP nexthop calculation question
To: Jeffrey Haas <[email-masked]>, [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Jeff,

Infact, since the latest versions of BSD, and Linux
since the start, allow IF-address configuration as in:
eth1 = 10.10.10.1/24 and eth2 = 10.10.10.2/24, its
next to imppossible to actually detect, on the RUT,
whether two Nbrs have direct connectivity or not.
Infact, this change in behaviour, in BSD, is to allow
for IPv6-LinkLocal addresses, which by default reside
in the same subnet.

So, Id like to suggest that, in the latest BGP-draft,
we add a sentence saying:

"The default behaviour for directly connected subnets
is that the NextHop goes unchanged (whether
advertisement is to an EBGP or IBGP neighbor), but it
is the administrators responsibility to ensure that
the router specified as the Nexthop is infact directly
reachable to the advertised neighbor. If the Nexthop
is not directly reachable to the advertised neighbor,
it MUST be configurable to set the Nexthop to the
address of the interface that is used to reach the
neighbor".

The above statement makes the provision of a command
akin to "nexthop-self" mandatory.

This would become a requirement if both TR2 and TR1,
in Cleary's example, are IPv6-Link-local neighbors
which donot have direct reachability to each other.
Then its impossible for the RUT to check whether "the
router" is reachable for the neighbor!

I feel that the NextHop related statements in MP-BGP
RFC 2858 (which just reflected the statements in the
then BGP-draft) are far more messed up than the ones
we have here in draft-26 and need to be re-worked as
well.

Acharya.

 --- Jeffrey Haas <[email-masked]> wrote: 
> Mike,
> 
> On Fri, Feb 25, 2005 at 08:10:54AM -0500,
> [email-masked] wrote:
> > Should RUT advertise this route to the iBGP peer
> with the nexthop set 
> > to itself
> > also?
> 
> In general:
> 
> If the nexthop on a router is being sent to a BGP
> peer (internal or
> external) and it shares a logical subnet with that
> nexthop, it MAY
> send the BGP update with the original nexthop.
> 
> If the nexthop on a router is being sent to an eBGP
> peer and
> the nexthop is not on the same logical subnet, it
> will in almost
> every case announce the route as a first party
> nexthop and thus
> use the IP address of the local end of the peering
> session with the eBGP
> peer as the nexthop.  (An exception is multihop eBGP
> peering and the
> behavior is somewhat out of spec.)
> 
> If the nexthop on a router is being sent to an iBGP
> peer, then the
> nexthop is typically sent unaltered.  This behavior
> may be modified
> via a "next-hop-self" feature.  
> 
> Confederation behavior is slightly different.  It is
> permissable
> for nexthops to be sent unaltered (like iBGP) in a
> confederation.
> This means if the implementation chooses to enforce
> nexthop on subnet
> on a confederation eBGP peering session, it is
> conformant.  However,
> this is atypical behavior.
> 
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
>  

Send instant messages to your online friends http://uk.messenger.yahoo.com 

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

Date: Mon, 28 Feb 2005 01:38:37 +0000 (GMT)
From: Acharya <[email-masked]>
Subject: Re: [Idr] BGP nexthop calculation question
To: Mike Cleary <[email-masked]>, Nader Salehi <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

"the router" is TR3 in your topology. And your right
in saying that the NH should be 10.10.10.X in
advertisements to both TR1 and TR2. If NHSelf is
configured on RUT for Nbr TR2&/TR1, the NH will be
changed to RUT's IF-addresses accordingly.

Acharya

 --- Mike Cleary <[email-masked]> wrote: 
> Nader,
> What is the case when this route is being advertised
> to an IBGP peer? 
>  This quote from section 5.1.3 is a little
> confusing:
> 
>       When announcing a locally 
>       originated route to an internal peer, the BGP
> speaker SHOULD use
>       as the NEXT_HOP the interface address of the
> router through which
>       the announced network is reachable for the
> speaker; if the route
>       is directly connected to the speaker, or the
> interface address of
>       the router through which the announced network
> is reachable for
>       the speaker is the internal peer's address,
> then the BGP speaker
>       SHOULD use for the NEXT_HOP attribute its own
> IP address (the
>       address of the interface that is used to reach
> the peer).
> 
> Take my example where RUT is originating a static
> route with the nexthop 
> set to TR3 (10.10.10.X), is "the router" from the
> first part of the 
> sentance refering to TR3 or is it refering to RUT? 
> If this is refering 
> to TR3 than the nexthop should be 10.10.10.X right?
> Thanks,
> ~Mike
> 
> Nader Salehi wrote:
> 
> >Mike,
> >
> >Assuming that TR1, RUT, and TR3 are not on a
> multi-access media
> >(Ethernet, Frame Relay), this is a correct
> behavior.  RUT advertises
> >2.2.2/24 to an eBGP peer, so the next hop will be
> the IP address of
> >the RUT.
> >
> >As for your other question, if you source a route
> into BGP --via
> >either the 'network' or the 'redistribute'
> commands-- the route is
> >considered local and is advertised to peers as
> such.  The only
> >difference between 'network' and 'redistribute'
> commands is in the
> >ORIGIN attribute.  The former sets the origin to
> IGP whereas the
> >latter sets the origin to Unknown.
> >
> >Hope this helps.
> >
> >Nader
> >
> >
> >Mike Cleary writes:
> >
> >>Hello,
> >>I have a question with regards to the nexthop of
> BGP updates.  See the 
> >>attached diagram.  As noted in the Diagram TR1 is
> connected to RUT via 
> >>external BGP on network 10.10.10.0/24, TR2 is
> connected to RUT via 
> >>Internal BGP.  RUT has a static route to network
> 2.2.2.0/24 with the 
> >>nexthop set to TR3's network 0 ip address
> (10.10.10.36).  RUT is 
> >>configured to redistribute static routes to BGP. 
> RUT uses itself on 
> >>network 0 (10.10.10.Y) as the nexthop when
> advertising this route to TR1 
> >>and TR2 even though nexthop self is not set to
> enabled.  I was 
> >>wondering, is this behavior is correct?  I looked
> at section 5.1.3 of 
> >>draft-ietf-bgp4-26 for this information and found
> the wording to be a 
> >>little confusing.  Are static routes considered
> locally originated?
> >>Thanks,
> >>~Mike
> >>
> >>-- 
> >>*********************************************
> >>Michael Cleary     Email: [email-masked]
> >>IPv4 Consortium      UNH InterOperability Lab
> >>121 Technology Dr., Suite 2, Durham, NH 03824
> >>Phone: 603-862-3941    http://www.iol.unh.edu
> >>*********************************************
> >>
> >>
> >>_______________________________________________
> >>Idr mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/idr
> >>
> >
> 
> 
> -- 
> *********************************************
> Michael Cleary     Email: [email-masked]
> IPv4 Consortium      UNH InterOperability Lab
> 121 Technology Dr., Suite 2, Durham, NH 03824
> Phone: 603-862-3941    http://www.iol.unh.edu
> *********************************************
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
>  

Send instant messages to your online friends http://uk.messenger.yahoo.com 

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

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Mon, 31 Jan 2005 10:55:08 -0500
Cc: idr chair <[email-masked]>, idr mailing list <[email-masked]>, idr chair <[email-masked]>, Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>
Subject: [Idr] Protocol Action: 'A Border Gateway Protocol 4 (BGP-4)' to  Draft Standard 
Sender: [email-masked]

The IESG has approved the following documents:

- 'Definitions of Managed Objects for the Fourth Version of Border Gateway 
   Protocol (BGP-4) '
   <draft-ietf-idr-bgp4-mib-15.txt> as a Proposed Standard
- 'BGP Security Vulnerabilities Analysis '
   <draft-ietf-idr-bgp-vuln-01.txt> as an Informational RFC
- 'BGP-4 Protocol Analysis '
   <draft-ietf-idr-bgp-analysis-07.txt> as an Informational RFC
- 'Experience with the BGP-4 Protocol '
   <draft-ietf-idr-bgp4-experience-protocol-05.txt> as an Informational RFC
- 'BGP MIB V1 implementation survey '
   <draft-ietf-idr-bgp-mibagent-survey-02.txt> as an Informational RFC
- 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 
   2385) and the BGP-4 Specification '
   <draft-iesg-tcpmd5app-01.txt> as an Informational RFC
- 'BGP 4 Implementation Report '
   <draft-ietf-idr-bgp-implementation-02.txt> as an Informational RFC
- 'A Border Gateway Protocol 4 (BGP-4) '
   <draft-ietf-idr-bgp4-26.txt> as a Draft Standard

These documents are products of the Inter-Domain Routing Working Group. 

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
 The documents included in this package provide the technical specification,
 the MIB module description and the supporting documentation for the revision
 of the BGPv4 protocol. BGPv4 is a path-vector routing protocol currently used
 in the Internet for classless IPv4 inter-domain routing. The protocol allows 
 a certain degree of policy routing among the domains.
 
Working Group Summary
 
 The WG has been working on the revised version of the protocol specification
 for the last few years. Discussions on specific issues and related consensus
 assessment have been documented. Documents in the package have passed the WG
 LC, and are now ready for the IESG review.
 
Protocol Quality
 
 BGPv4 is widely implemented and deployed. The implementations are tested for
 interoperability between different vendors on a regular basis. The
 specification has been reviewed thoroughly my numerous WG participants,
 members of the Routing Area directorate, and Area Directors.

RFC Editor Note

draft-ietf-idr-bgp-analysis-06.txt:

Abstract:

OLD:
   The purpose of this report 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).

NEW:
   The purpose of this report is to document how the requirements for
   publication of a routing protocol as an Internet Draft Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

Section 1 "Introduction"

OLD:
    BGP-4 is an inter-autonomous system routing protocol designed for
    TCP/IP internets. Version 1 of the BGP-4 protocol was published in
    [RFC1105]. Since then BGP versions 2, 3, and 4 have been developed.
    Version 2 was documented in [RFC1163]. Version 3 is documented in

NEW:
    BGP-4 is an inter-autonomous system routing protocol designed for
    TCP/IP internets. Version 1 of the BGP protocol was published in
    [RFC1105]. Since then BGP versions 2, 3, and 4 have been developed.
    Version 2 was documented in [RFC1163]. Version 3 is documented in

draft-ietf-idr-bgp4-experience-protocol:

Abstract:

OLD:
   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).

NEW:
   The purpose of this memo is to document how the requirements for
   publication of a routing protocol as an Internet Draft Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

Change all instances of "Potatoe" to "potato"

draft-iesg-tcpmd5app-01.txt:

Section 6 "Security Considerations"

OLD:
    The IESG believes that the variance described here will not affect
    the security of the Internet.

NEW:
    The IESG believes that the variance described here will not adversely
    affect the security of the Internet.

draft-ietf-idr-bgp4-26.txt:

Move the following reference--

   [RFC2474] Nichols, K., et al.,"Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474,
   December 1998

--to the non-normative part.

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

Date: Fri, 25 Feb 2005 10:46:55 -0500
From: Mike Cleary <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] BGP nexthop calculation question
Cc: [email-masked]
Sender: [email-masked]

Jeffrey,
So if the nexthop self feature is not enabled than it should send the 
original nexthop to an iBGP peer right?
~Mike

Jeffrey Haas wrote:

>Mike,
>
>On Fri, Feb 25, 2005 at 08:10:54AM -0500, [email-masked] wrote:
>
>>Should RUT advertise this route to the iBGP peer with the nexthop set 
>>to itself
>>also?
>>
>
>In general:
>
>If the nexthop on a router is being sent to a BGP peer (internal or
>external) and it shares a logical subnet with that nexthop, it MAY
>send the BGP update with the original nexthop.
>
>If the nexthop on a router is being sent to an eBGP peer and
>the nexthop is not on the same logical subnet, it will in almost
>every case announce the route as a first party nexthop and thus
>use the IP address of the local end of the peering session with the eBGP
>peer as the nexthop.  (An exception is multihop eBGP peering and the
>behavior is somewhat out of spec.)
>
>If the nexthop on a router is being sent to an iBGP peer, then the
>nexthop is typically sent unaltered.  This behavior may be modified
>via a "next-hop-self" feature.  
>
>Confederation behavior is slightly different.  It is permissable
>for nexthops to be sent unaltered (like iBGP) in a confederation.
>This means if the implementation chooses to enforce nexthop on subnet
>on a confederation eBGP peering session, it is conformant.  However,
>this is atypical behavior.
>
>

-- 
*********************************************
Michael Cleary     Email: [email-masked]
IPv4 Consortium      UNH InterOperability Lab
121 Technology Dr., Suite 2, Durham, NH 03824
Phone: 603-862-3941    http://www.iol.unh.edu
*********************************************

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

Date: Fri, 25 Feb 2005 09:40:37 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] BGP nexthop calculation question
Cc: [email-masked]
Sender: [email-masked]

Mike,

On Fri, Feb 25, 2005 at 08:10:54AM -0500, [email-masked] wrote:
> Should RUT advertise this route to the iBGP peer with the nexthop set 
> to itself
> also?

In general:

If the nexthop on a router is being sent to a BGP peer (internal or
external) and it shares a logical subnet with that nexthop, it MAY
send the BGP update with the original nexthop.

If the nexthop on a router is being sent to an eBGP peer and
the nexthop is not on the same logical subnet, it will in almost
every case announce the route as a first party nexthop and thus
use the IP address of the local end of the peering session with the eBGP
peer as the nexthop.  (An exception is multihop eBGP peering and the
behavior is somewhat out of spec.)

If the nexthop on a router is being sent to an iBGP peer, then the
nexthop is typically sent unaltered.  This behavior may be modified
via a "next-hop-self" feature.  

Confederation behavior is slightly different.  It is permissable
for nexthops to be sent unaltered (like iBGP) in a confederation.
This means if the implementation chooses to enforce nexthop on subnet
on a confederation eBGP peering session, it is conformant.  However,
this is atypical behavior.

-- 
Jeff Haas 
NextHop Technologies

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

Date: Fri, 25 Feb 2005 10:01:54 -0500
From: Mike Cleary <[email-masked]>
To: Nader Salehi <[email-masked]>
Subject: Re: [Idr] BGP nexthop calculation question
Cc: [email-masked]
Sender: [email-masked]

Nader,
What is the case when this route is being advertised to an IBGP peer? 
 This quote from section 5.1.3 is a little confusing:

      When announcing a locally 
      originated route to an internal peer, the BGP speaker SHOULD use
      as the NEXT_HOP the interface address of the router through which
      the announced network is reachable for the speaker; if the route
      is directly connected to the speaker, or the interface address of
      the router through which the announced network is reachable for
      the speaker is the internal peer's address, then the BGP speaker
      SHOULD use for the NEXT_HOP attribute its own IP address (the
      address of the interface that is used to reach the peer).

Take my example where RUT is originating a static route with the nexthop 
set to TR3 (10.10.10.X), is "the router" from the first part of the 
sentance refering to TR3 or is it refering to RUT?  If this is refering 
to TR3 than the nexthop should be 10.10.10.X right?
Thanks,
~Mike

Nader Salehi wrote:

>Mike,
>
>Assuming that TR1, RUT, and TR3 are not on a multi-access media
>(Ethernet, Frame Relay), this is a correct behavior.  RUT advertises
>2.2.2/24 to an eBGP peer, so the next hop will be the IP address of
>the RUT.
>
>As for your other question, if you source a route into BGP --via
>either the 'network' or the 'redistribute' commands-- the route is
>considered local and is advertised to peers as such.  The only
>difference between 'network' and 'redistribute' commands is in the
>ORIGIN attribute.  The former sets the origin to IGP whereas the
>latter sets the origin to Unknown.
>
>Hope this helps.
>
>Nader
>
>
>Mike Cleary writes:
>
>>Hello,
>>I have a question with regards to the nexthop of BGP updates.  See the 
>>attached diagram.  As noted in the Diagram TR1 is connected to RUT via 
>>external BGP on network 10.10.10.0/24, TR2 is connected to RUT via 
>>Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the 
>>nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is 
>>configured to redistribute static routes to BGP.  RUT uses itself on 
>>network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1 
>>and TR2 even though nexthop self is not set to enabled.  I was 
>>wondering, is this behavior is correct?  I looked at section 5.1.3 of 
>>draft-ietf-bgp4-26 for this information and found the wording to be a 
>>little confusing.  Are static routes considered locally originated?
>>Thanks,
>>~Mike
>>
>>-- 
>>*********************************************
>>Michael Cleary     Email: [email-masked]
>>IPv4 Consortium      UNH InterOperability Lab
>>121 Technology Dr., Suite 2, Durham, NH 03824
>>Phone: 603-862-3941    http://www.iol.unh.edu
>>*********************************************
>>
>>
>>_______________________________________________
>>Idr mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/idr
>>
>

-- 
*********************************************
Michael Cleary     Email: [email-masked]
IPv4 Consortium      UNH InterOperability Lab
121 Technology Dr., Suite 2, Durham, NH 03824
Phone: 603-862-3941    http://www.iol.unh.edu
*********************************************

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

From: [email-masked]
Date: Fri, 25 Feb 2005 08:10:54 -0500
To: Nader Salehi <[email-masked]>
Subject: Re: [Idr] BGP nexthop calculation question
Cc: [email-masked]
Sender: [email-masked]

Should RUT advertise this route to the iBGP peer with the nexthop set 
to itself
also?

Quoting Nader Salehi <[email-masked]>:

> Mike,
>
> Assuming that TR1, RUT, and TR3 are not on a multi-access media
> (Ethernet, Frame Relay), this is a correct behavior.  RUT advertises
> 2.2.2/24 to an eBGP peer, so the next hop will be the IP address of
> the RUT.
>
> As for your other question, if you source a route into BGP --via
> either the 'network' or the 'redistribute' commands-- the route is
> considered local and is advertised to peers as such.  The only
> difference between 'network' and 'redistribute' commands is in the
> ORIGIN attribute.  The former sets the origin to IGP whereas the
> latter sets the origin to Unknown.
>
> Hope this helps.
>
> Nader
>
>
> Mike Cleary writes:
>> Hello,
>> I have a question with regards to the nexthop of BGP updates.  See the
>> attached diagram.  As noted in the Diagram TR1 is connected to RUT via
>> external BGP on network 10.10.10.0/24, TR2 is connected to RUT via
>> Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the
>> nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is
>> configured to redistribute static routes to BGP.  RUT uses itself on
>> network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1
>> and TR2 even though nexthop self is not set to enabled.  I was
>> wondering, is this behavior is correct?  I looked at section 5.1.3 of
>> draft-ietf-bgp4-26 for this information and found the wording to be a
>> little confusing.  Are static routes considered locally originated?
>> Thanks,
>> ~Mike
>>
>> --
>> *********************************************
>> Michael Cleary     Email: [email-masked]
>> IPv4 Consortium      UNH InterOperability Lab
>> 121 Technology Dr., Suite 2, Durham, NH 03824
>> Phone: 603-862-3941    http://www.iol.unh.edu
>> *********************************************
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>

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

From: Nader Salehi <[email-masked]>
Date: Thu, 24 Feb 2005 17:00:16 -0800
To: Mike Cleary <[email-masked]>
Subject: Re: [Idr] BGP nexthop calculation question
Cc: [email-masked]
Sender: [email-masked]

Mike,

Assuming that TR1, RUT, and TR3 are not on a multi-access media
(Ethernet, Frame Relay), this is a correct behavior.  RUT advertises
2.2.2/24 to an eBGP peer, so the next hop will be the IP address of
the RUT.

As for your other question, if you source a route into BGP --via
either the 'network' or the 'redistribute' commands-- the route is
considered local and is advertised to peers as such.  The only
difference between 'network' and 'redistribute' commands is in the
ORIGIN attribute.  The former sets the origin to IGP whereas the
latter sets the origin to Unknown.

Hope this helps.

Nader

Mike Cleary writes:
> Hello,
> I have a question with regards to the nexthop of BGP updates.  See the 
> attached diagram.  As noted in the Diagram TR1 is connected to RUT via 
> external BGP on network 10.10.10.0/24, TR2 is connected to RUT via 
> Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the 
> nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is 
> configured to redistribute static routes to BGP.  RUT uses itself on 
> network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1 
> and TR2 even though nexthop self is not set to enabled.  I was 
> wondering, is this behavior is correct?  I looked at section 5.1.3 of 
> draft-ietf-bgp4-26 for this information and found the wording to be a 
> little confusing.  Are static routes considered locally originated?
> Thanks,
> ~Mike
> 
> -- 
> *********************************************
> Michael Cleary     Email: [email-masked]
> IPv4 Consortium      UNH InterOperability Lab
> 121 Technology Dr., Suite 2, Durham, NH 03824
> Phone: 603-862-3941    http://www.iol.unh.edu
> *********************************************
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr

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

Date: Thu, 24 Feb 2005 15:19:51 -0500
From: Mike Cleary <[email-masked]>
To: [email-masked]
Subject: [Idr] BGP nexthop calculation question
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010406010708020803050906
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello,
I have a question with regards to the nexthop of BGP updates.  See the 
attached diagram.  As noted in the Diagram TR1 is connected to RUT via 
external BGP on network 10.10.10.0/24, TR2 is connected to RUT via 
Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the 
nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is 
configured to redistribute static routes to BGP.  RUT uses itself on 
network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1 
and TR2 even though nexthop self is not set to enabled.  I was 
wondering, is this behavior is correct?  I looked at section 5.1.3 of 
draft-ietf-bgp4-26 for this information and found the wording to be a 
little confusing.  Are static routes considered locally originated?
Thanks,
~Mike

-- 
*********************************************
Michael Cleary     Email: [email-masked]
IPv4 Consortium      UNH InterOperability Lab
121 Technology Dr., Suite 2, Durham, NH 03824
Phone: 603-862-3941    http://www.iol.unh.edu
*********************************************

--------------010406010708020803050906
Content-Type: image/jpeg;
 name="diagram.jpg"
Content-Disposition: inline;
 filename="diagram.jpg"
Content-Transfer-Encoding: base64

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

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

--------------010406010708020803050906--

Content-class: urn:content-classes:message
Subject: RE: [Idr] Implementation Report on draft-ooms-v6ops-bgp-tunnel-04.txt
Date: Wed, 9 Feb 2005 21:30:10 +0100
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked], "Francois Le Faucheur \(flefauch\)" <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked], Susan Hares <[email-masked]>
Sender: [email-masked]

Hello,

For information, below is the statement of compliance for Cisco IOS implementation of draft-ooms-v6ops-bgp-tunnel-04.txt.

Francois

STATEMENT OF COMPLIANCE TO draft-ooms-v6ops-bgp-tunnel-04.txt
=============================================================

2. Protocol Overview

"
The 6PE router MUST be dual stack IPv4 and IPv6.
"
==> Does your implementation comply?: Y

"
The 6PE router MUST be configurable with at least one IPv4 address on
the IPv4 side and at least one IPv6 address on the IPv6 side.
"
==> Does your implementation comply?: Y

"
The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as
per [MP-BGP-v6] running over IPv4.
"
==> Does your implementation comply?: Y

"
The MP-BGP AFI used MUST be IPv6 (value 2). 
"
==> Does your implementation comply?: Y

"
Therefore, the IPv4 address of the egress 6PE router MUST be encoded as
an IPv4-mapped IPv6 address in the BGP Next Hop field.
"
==> Does your implementation comply?: Y

"
In addition, the 6PE MUST bind a label to the IPv6 prefix as per
[LABEL]. 
"
==> Does your implementation comply?: Y

"
The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in
[LABEL]. 
"
==> Does your implementation comply?: Y

"
The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP
towards the Egress 6PE router identified by the IPv4 address advertised
in the IPv4-mapped IPv6 address of the BGP Next Hop for the
corresponding IPv6 prefix.
"
==> Does your implementation comply?: Y

3. Transport over IPv4-signaled LSPs and IPv6 label binding

"
When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than
successively prepend an IPv4 header and then perform label imposition
based on the IPv4 header, the ingress 6PE Router MUST directly perform
label imposition of the IPv6 header without prepending any IPv4 header. 
"
==> Does your implementation comply?: Y

"
The (outer) label imposed MUST correspond to the IPv4-signaled LSP
starting on the ingress 6PE Router and ending on the egress 6PE Router.
"
==> Does your implementation comply?: Y

"
This label advertised by the Egress 6PE Router with MP-BGP MAY be an
arbitrary label value which identifies an IPv6 routing context or
outgoing interface to send the packet to, or MAY be the IPv6 Explicit
Null Label. 
"
==> Does your implementation comply and advertise an "arbitrary label
value"?: Y
==> Does your implementation comply and advertise "IPv6 Explicit Null
Label"?: N

"
An Ingress 6PE Router MUST be able to accept any such advertised label.
"
==> Does your implementation comply and accept an "arbitrary label
value"?: Y
==> Does your implementation comply and accept "IPv6 Explicit Null
Label"?: Y

4. Crossing Multiple IPv4 Autonomous Systems

"
(a) EBGP redistribution of IPv6 routes from AS to neighboring AS
The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6].
"
==> Does your implementation support (a)?: Y
==> If yes, does it comply?: Y

"
(b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS
When peering over IPv6, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL]. 
"
==> Does your implementation support (b)?: Y
==> If yes, does it comply?: Y

"
When peering over IPv4, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4
address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop
field.
"
==> Does your implementation comply?: Y

5. Security Considerations

"
To this end an ASBR 6PE SHOULD only accept labeled packets from its peer
ASBR 6PE if the topmost label is a label that it has explicitly signaled
to that peer ASBR 6PE.
"
==> Does your implementation comply?: N (under development)

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: lundi 7 février 2005 17:11
>> To: [email-masked]
>> Cc: Bill Fenner; [email-masked]; [email-masked]; 
>> [email-masked]; Susan Hares
>> Subject: [Idr] Implementation Report on 
>> draft-ooms-v6ops-bgp-tunnel-04.txt 
>> 
>> Hello,
>> 
>> A Last Call has been issued on Jan 31 in IDR for
>> draft-ooms-v6ops-bgp-tunnel-04.txt.
>> 
>> In line with the requirements for progressing a Routing document
>> (RFC1264), an implementation report needs to be submitted to 
>> the IESG on
>> draft-ooms-v6ops-bgp-tunnel-04.txt.
>> 
>> As an input to this report, we would like to gather information on
>> existing implementations of 
>> draft-ooms-v6ops-bgp-tunnel-04.txt. Hence,
>> could those who have implemented these extensions provide:
>> 	-1- identification of the implementation
>> 	-2- statement of compliance (provide all the Yes/No answers in
>> statement below which is based on all the MUST/SHOULD/MAY of
>> draft-ooms-v6ops-bgp-tunnel-04.txt)
>> 	-3- statement as to whether you allow that information to be
>> made public or want it to be kept confidential.
>> 
>> You can either respond onto the list (assuming you are happy 
>> to have the
>> info public) or respond in private to myself or to the WG chairs.
>> 
>> Thank you 
>> 
>> Francois
>> 
>> 
>> 
>> STATEMENT OF COMPLIANCE TO draft-ooms-v6ops-bgp-tunnel-04.txt
>> =============================================================
>> 
>> 2. Protocol Overview
>> 
>> "
>> The 6PE router MUST be dual stack IPv4 and IPv6.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The 6PE router MUST be configurable with at least one IPv4 address on
>> the IPv4 side and at least one IPv6 address on the IPv6 side.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP 
>> sessions as
>> per [MP-BGP-v6] running over IPv4.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The MP-BGP AFI used MUST be IPv6 (value 2). 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> Therefore, the IPv4 address of the egress 6PE router MUST be 
>> encoded as
>> an IPv4-mapped IPv6 address in the BGP Next Hop field.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> In addition, the 6PE MUST bind a label to the IPv6 prefix as per
>> [LABEL]. 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) 
>> as defined in
>> [LABEL]. 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The Ingress 6PE router MUST forward IPv6 data over the 
>> IPv4-signaled LSP
>> towards the Egress 6PE router identified by the IPv4 address 
>> advertised
>> in the IPv4-mapped IPv6 address of the BGP Next Hop for the
>> corresponding IPv6 prefix.
>> "
>> ==> Does your implementation comply?: Y/N
>>  
>> 
>> 3. Transport over IPv4-signaled LSPs and IPv6 label binding
>> 
>> "
>> When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than
>> successively prepend an IPv4 header and then perform label imposition
>> based on the IPv4 header, the ingress 6PE Router MUST 
>> directly perform
>> label imposition of the IPv6 header without prepending any 
>> IPv4 header. 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The (outer) label imposed MUST correspond to the IPv4-signaled LSP
>> starting on the ingress 6PE Router and ending on the egress 
>> 6PE Router.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> This label advertised by the Egress 6PE Router with MP-BGP MAY be an
>> arbitrary label value which identifies an IPv6 routing context or
>> outgoing interface to send the packet to, or MAY be the IPv6 Explicit
>> Null Label. 
>> "
>> ==> Does your implementation comply and advertise an "arbitrary label
>> value"?: Y/N
>> ==> Does your implementation comply and advertise "IPv6 Explicit Null
>> Label"?: Y/N
>> 
>> 
>> "
>> An Ingress 6PE Router MUST be able to accept any such 
>> advertised label.
>> "
>> ==> Does your implementation comply and accept an "arbitrary label
>> value"?: Y/N
>> ==> Does your implementation comply and accept "IPv6 Explicit Null
>> Label"?: Y/N
>> 
>> 
>> 4. Crossing Multiple IPv4 Autonomous Systems
>> 
>> "
>> (a) EBGP redistribution of IPv6 routes from AS to neighboring AS
>> The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6].
>> "
>> ==> Does your implementation support (a)?: Y/N
>> ==> If yes, does it comply?: Y/N
>> 
>> "
>> (b) EBGP redistribution of labeled IPv6 routes from AS to 
>> neighboring AS
>> When peering over IPv6, the exchange of labeled IPv6 routes MUST be
>> carried out as per [MP-BGP-v6] and [LABEL]. 
>> "
>> ==> Does your implementation support (b)?: Y/N
>> ==> If yes, does it comply?: Y/N
>> 
>> "
>> When peering over IPv4, the exchange of labeled IPv6 routes MUST be
>> carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4
>> address of the ASBR as an IPv4-mapped IPv6 address in the 
>> BGP Next Hop
>> field.
>> "
>> ==> Does your implementation comply?: Y/N
>>  
>> 
>> 5. Security Considerations
>> 
>> "
>> To this end an ASBR 6PE SHOULD only accept labeled packets 
>> from its peer
>> ASBR 6PE if the topmost label is a label that it has 
>> explicitly signaled
>> to that peer ASBR 6PE.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 

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

From: "Vivian Lu" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Wed, 9 Feb 2005 14:37:32 -0500 
Cc: [email-masked]
Subject: [Idr] RE: Prefix-list ORF sequence number question
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0168393085==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50EDE.CC802B4C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C50EDE.CC802B4C
Content-Type: text/plain

Thanks for the clarification.

Vivian.

> -----Original Message-----
> From: Enke Chen (enkechen) [mailto:[email-masked]] 
> Sent: Wednesday, February 09, 2005 1:38 PM
> To: Lu, Vivian [BL60:SF21:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Prefix-list ORF sequence number question
> 
> 
> Hi, Vivian:
> 
> Please see my comments inlined.
> 
> > -----Original Message-----
> > From: Vivian Lu [mailto:[email-masked]]
> > Sent: Wednesday, February 09, 2005 6:12 AM
> > To: Vivian Lu; [email-masked]'; [email-masked]'
> > Cc: [email-masked]'
> > Subject: Prefix-list ORF sequence number question
> > 
> > Hi,
> > 
> > I have a question regarding prefix-list ORF draft,
> > draft-ietf-idr-bgp-prefix-orf-00.txt. 
> > 
> > The "sequence" field as specified in the draft is the following, 
> >         "The 'Sequence' field is a number that specifies the
> > relative ordering of the entry." 
> > 
> > What is the scope to which the statement is referring that
> > makes the ordering significant? 
> 
> The "Sequence" field is used in Sect 6. Address Prefix ORF 
> Matching when multiple ORF entries match a particular NLRI.
> 
> We can add some text to the definition in the next revision.
> 
> > 
> > Is the scope
> > 
> > 	*	per bgp peer session? 
> > 
> > 		-- That is, sequence number is continuously
> > incremented for each orf entry through out the peer session. 
> > 		-- Sequence number gets reset when the peer 
> > session is reset. 
> > 	*	per ORF message? 
> > 
> > 		-- That is, sequence number is continuously
> > incremented for each orf entry within an ORF message. 
> > 		-- Sequence number gets reset when a new ORF 
> > message is created. 
> > 	*	per ORF type block in the orf message ?
> > 
> > 		-- That is, sequence number is continuously
> > incremented for each orf entry within an ORF type block 
> > inside an ORF message.
> > 
> > 		-- Sequence number gets reset when a new ORF
> > type block is written. 
> > 
> > We are wondering which one is what you intended and the
> > industry may agree with. 
> 
> Per the base ORF spec., ORFs are exchanged on a per peer
> basis, and the life time of an ORF is the duration of the session.
> 
> The scope of the sequence number is within the prefix-ORF
> type exchanged over the session.  It is a local matter
> (on the sender) how the sequenece number is assigned for
> the intended semantics "relative ordering").
> 
> -- Enke
> 

------_=_NextPart_001_01C50EDE.CC802B4C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: Prefix-list ORF sequence number question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thanks for the clarification.</FONT>
</P>

<P><FONT SIZE=3D2>Vivian.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Enke Chen (enkechen) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, February 09, 2005 1:38 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Lu, Vivian [BL60:SF21:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Prefix-list ORF sequence number =
question</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi, Vivian:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please see my comments inlined.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Vivian Lu [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, February 09, 2005 6:12 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Vivian Lu; [email-masked]'; =
[email-masked]'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: [email-masked]'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Prefix-list ORF sequence number =
question</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have a question regarding prefix-list =
ORF draft,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; draft-ietf-idr-bgp-prefix-orf-00.txt. =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The &quot;sequence&quot; field as =
specified in the draft is the following, </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The =
'Sequence' field is a number that specifies the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; relative ordering of the entry.&quot; =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What is the scope to which the statement =
is referring that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; makes the ordering significant? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The &quot;Sequence&quot; field is used in Sect =
6. Address Prefix ORF </FONT>
<BR><FONT SIZE=3D2>&gt; Matching when multiple ORF entries match a =
particular NLRI.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We can add some text to the definition in the =
next revision.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Is the scope</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per bgp peer session? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- That is, sequence number =
is continuously</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; incremented for each orf entry through out =
the peer session. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Sequence number gets =
reset when the peer </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; session is reset. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per ORF message? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- That is, sequence number =
is continuously</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; incremented for each orf entry within an =
ORF message. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Sequence number gets =
reset when a new ORF </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; message is created. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per ORF type block in the orf =
message ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- That is, sequence number =
is continuously</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; incremented for each orf entry within an =
ORF type block </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; inside an ORF message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Sequence number gets =
reset when a new ORF</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; type block is written. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We are wondering which one is what you =
intended and the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; industry may agree with. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Per the base ORF spec., ORFs are exchanged on a =
per peer</FONT>
<BR><FONT SIZE=3D2>&gt; basis, and the life time of an ORF is the =
duration of the session.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The scope of the sequence number is within the =
prefix-ORF</FONT>
<BR><FONT SIZE=3D2>&gt; type exchanged over the session.&nbsp; It is a =
local matter</FONT>
<BR><FONT SIZE=3D2>&gt; (on the sender) how the sequenece number is =
assigned for</FONT>
<BR><FONT SIZE=3D2>&gt; the intended semantics &quot;relative =
ordering&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- Enke</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C50EDE.CC802B4C--

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

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

--===============0168393085==--

From: "Enke Chen \(enkechen\)" <[email-masked]>
To: "'Vivian Lu'" <[email-masked]>
Date: Wed, 9 Feb 2005 10:38:06 -0800
Cc: [email-masked], [email-masked]
Subject: [Idr] RE: Prefix-list ORF sequence number question
Reply-To: [email-masked]
Sender: [email-masked]

Hi, Vivian:

Please see my comments inlined.

> -----Original Message-----
> From: Vivian Lu [mailto:[email-masked]] 
> Sent: Wednesday, February 09, 2005 6:12 AM
> To: Vivian Lu; [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: Prefix-list ORF sequence number question
> 
> Hi, 
> 
> I have a question regarding prefix-list ORF draft, 
> draft-ietf-idr-bgp-prefix-orf-00.txt. 
> 
> The "sequence" field as specified in the draft is the following, 
>         "The 'Sequence' field is a number that specifies the 
> relative ordering of the entry." 
> 
> What is the scope to which the statement is referring that 
> makes the ordering significant? 

The "Sequence" field is used in Sect 6. Address Prefix ORF Matching
when multiple ORF entries match a particular NLRI.

We can add some text to the definition in the next revision.

> 
> Is the scope 
> 
> 	*	per bgp peer session? 
> 
> 		-- That is, sequence number is continuously 
> incremented for each orf entry through out the peer session. 
> 		-- Sequence number gets reset when the peer 
> session is reset. 
> 	*	per ORF message? 
> 
> 		-- That is, sequence number is continuously 
> incremented for each orf entry within an ORF message. 
> 		-- Sequence number gets reset when a new ORF 
> message is created. 
> 	*	per ORF type block in the orf message ?
> 
> 		-- That is, sequence number is continuously 
> incremented for each orf entry within an ORF type block 
> inside an ORF message.
> 
> 		-- Sequence number gets reset when a new ORF 
> type block is written. 
> 
> We are wondering which one is what you intended and the 
> industry may agree with. 

Per the base ORF spec., ORFs are exchanged on a per peer
basis, and the life time of an ORF is the duration of the
session.

The scope of the sequence number is within the prefix-ORF
type exchanged over the session.  It is a local matter
(on the sender) how the sequenece number is assigned for
the intended semantics "relative ordering").

-- Enke

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

From: "Vivian Lu" <[email-masked]>
To: "Vivian Lu" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 9 Feb 2005 09:12:02 -0500 
Cc: "[email-masked]'" <[email-masked]>
Subject: [Idr] Prefix-list ORF sequence number question
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0594236792==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50EB1.53748E78"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C50EB1.53748E78
Content-Type: text/plain

Hi, 

I have a question regarding prefix-list ORF draft,
draft-ietf-idr-bgp-prefix-orf-00.txt. 

The "sequence" field as specified in the draft is the following, 
	"The 'Sequence' field is a number that specifies the relative
ordering of the entry." 

What is the scope to which the statement is referring that makes the
ordering significant? 

Is the scope 
*	per bgp peer session? 
		-- That is, sequence number is continuously incremented for
each orf entry through out the peer session. 
		-- Sequence number gets reset when the peer session is
reset. 
*	per ORF message? 
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF message. 
		-- Sequence number gets reset when a new ORF message is
created. 
*	per ORF type block in the orf message ?
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF type block inside an ORF message.
		-- Sequence number gets reset when a new ORF type block is
written. 

We are wondering which one is what you intended and the industry may agree
with. 

Thanks. 
Vivian. 

------_=_NextPart_001_01C50EB1.53748E78
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>Prefix-list ORF sequence number question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a question regarding =
prefix-list ORF</FONT><FONT SIZE=3D2 FACE=3D"Arial"> draft, =
draft-ietf-idr-bgp-prefix-orf-00.txt</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The &quot;sequence&quot; field as =
specified in the draft is the following, </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&quot;The 'Sequence' field is a number that specifies =
the relative ordering of the entry.&quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What is the scope to which the =
statement is referring that makes the ordering significant? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is the scope </FONT>
<UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">per bgp peer session? =
</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry through out the peer =
session. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when =
the peer session is reset. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">per ORF message? </FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF message. =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF message is created. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">p</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">er ORF type block in the orf message ?</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF type block =
inside an ORF message.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF type block is written. </FONT>
</P>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">We are wondering which one is</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">what</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">you intended and the industry may agree with. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Vivian. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C50EB1.53748E78--

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

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

--===============0594236792==--

From: "Vivian Lu" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 9 Feb 2005 09:10:40 -0500 
Cc: "[email-masked]'" <[email-masked]>
Subject: [Idr] (no subject)
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0282134737==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50EB1.024A609A"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C50EB1.024A609A
Content-Type: text/plain

Hi, 

I have a question regarding prefix-list ORF draft,
draft-ietf-idr-bgp-prefix-orf-00.txt. 

The "sequence" field as specified in the draft is the following, 
	"The 'Sequence' field is a number that specifies the relative
ordering of the entry." 

What is the scope to which the statement is referring that makes the
ordering significant? 

Is the scope 
*	per bgp peer session? 
		-- That is, sequence number is continuously incremented for
each orf entry through out the peer session. 
		-- Sequence number gets reset when the peer session is
reset. 
*	per ORF message? 
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF message. 
		-- Sequence number gets reset when a new ORF message is
created. 
*	per ORF type block in the orf message ?
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF type block inside an ORF message.
		-- Sequence number gets reset when a new ORF type block is
written. 

We are wondering which one is what you intended and the industry may agree
with. 

Thanks. 
Vivian. 

------_=_NextPart_001_01C50EB1.024A609A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a question regarding =
prefix-list ORF</FONT><FONT SIZE=3D2 FACE=3D"Arial"> draft, =
draft-ietf-idr-bgp-prefix-orf-00.txt</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The &quot;sequence&quot; field as =
specified in the draft is the following, </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&quot;The 'Sequence' field is a number that specifies =
the relative ordering of the entry.&quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What is the scope to which the =
statement is referring that makes the ordering significant? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is the scope </FONT>
<UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">per bgp peer session? =
</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry through out the peer =
session. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when =
the peer session is reset. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">per ORF message? </FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF message. =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF message is created. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">p</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">er ORF type block in the orf message ?</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF type block =
inside an ORF message.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF type block is written. </FONT>
</P>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">We are wondering which one is</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">what</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">you intended and the industry may agree with. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Vivian. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C50EB1.024A609A--

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

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

--===============0282134737==--

Content-class: urn:content-classes:message
Date: Mon, 7 Feb 2005 17:10:42 +0100
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: <[email-masked]>
Cc: Bill Fenner <[email-masked]>, [email-masked], [email-masked], [email-masked], Susan Hares <[email-masked]>
Subject: [Idr] Implementation Report on draft-ooms-v6ops-bgp-tunnel-04.txt 
Sender: [email-masked]

Hello,

A Last Call has been issued on Jan 31 in IDR for
draft-ooms-v6ops-bgp-tunnel-04.txt.

In line with the requirements for progressing a Routing document
(RFC1264), an implementation report needs to be submitted to the IESG on
draft-ooms-v6ops-bgp-tunnel-04.txt.

As an input to this report, we would like to gather information on
existing implementations of draft-ooms-v6ops-bgp-tunnel-04.txt. Hence,
could those who have implemented these extensions provide:
	-1- identification of the implementation
	-2- statement of compliance (provide all the Yes/No answers in
statement below which is based on all the MUST/SHOULD/MAY of
draft-ooms-v6ops-bgp-tunnel-04.txt)
	-3- statement as to whether you allow that information to be
made public or want it to be kept confidential.

You can either respond onto the list (assuming you are happy to have the
info public) or respond in private to myself or to the WG chairs.

Thank you 

Francois

STATEMENT OF COMPLIANCE TO draft-ooms-v6ops-bgp-tunnel-04.txt
=============================================================

2. Protocol Overview

"
The 6PE router MUST be dual stack IPv4 and IPv6.
"
==> Does your implementation comply?: Y/N

"
The 6PE router MUST be configurable with at least one IPv4 address on
the IPv4 side and at least one IPv6 address on the IPv6 side.
"
==> Does your implementation comply?: Y/N

"
The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as
per [MP-BGP-v6] running over IPv4.
"
==> Does your implementation comply?: Y/N

"
The MP-BGP AFI used MUST be IPv6 (value 2). 
"
==> Does your implementation comply?: Y/N

"
Therefore, the IPv4 address of the egress 6PE router MUST be encoded as
an IPv4-mapped IPv6 address in the BGP Next Hop field.
"
==> Does your implementation comply?: Y/N

"
In addition, the 6PE MUST bind a label to the IPv6 prefix as per
[LABEL]. 
"
==> Does your implementation comply?: Y/N

"
The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in
[LABEL]. 
"
==> Does your implementation comply?: Y/N

"
The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP
towards the Egress 6PE router identified by the IPv4 address advertised
in the IPv4-mapped IPv6 address of the BGP Next Hop for the
corresponding IPv6 prefix.
"
==> Does your implementation comply?: Y/N

3. Transport over IPv4-signaled LSPs and IPv6 label binding

"
When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than
successively prepend an IPv4 header and then perform label imposition
based on the IPv4 header, the ingress 6PE Router MUST directly perform
label imposition of the IPv6 header without prepending any IPv4 header. 
"
==> Does your implementation comply?: Y/N

"
The (outer) label imposed MUST correspond to the IPv4-signaled LSP
starting on the ingress 6PE Router and ending on the egress 6PE Router.
"
==> Does your implementation comply?: Y/N

"
This label advertised by the Egress 6PE Router with MP-BGP MAY be an
arbitrary label value which identifies an IPv6 routing context or
outgoing interface to send the packet to, or MAY be the IPv6 Explicit
Null Label. 
"
==> Does your implementation comply and advertise an "arbitrary label
value"?: Y/N
==> Does your implementation comply and advertise "IPv6 Explicit Null
Label"?: Y/N

"
An Ingress 6PE Router MUST be able to accept any such advertised label.
"
==> Does your implementation comply and accept an "arbitrary label
value"?: Y/N
==> Does your implementation comply and accept "IPv6 Explicit Null
Label"?: Y/N

4. Crossing Multiple IPv4 Autonomous Systems

"
(a) EBGP redistribution of IPv6 routes from AS to neighboring AS
The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6].
"
==> Does your implementation support (a)?: Y/N
==> If yes, does it comply?: Y/N

"
(b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS
When peering over IPv6, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL]. 
"
==> Does your implementation support (b)?: Y/N
==> If yes, does it comply?: Y/N

"
When peering over IPv4, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4
address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop
field.
"
==> Does your implementation comply?: Y/N

5. Security Considerations

"
To this end an ASBR 6PE SHOULD only accept labeled packets from its peer
ASBR 6PE if the topmost label is a label that it has explicitly signaled
to that peer ASBR 6PE.
"
==> Does your implementation comply?: Y/N

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

Content-class: urn:content-classes:message
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Fri, 4 Feb 2005 17:06:51 +0100
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: "Jeffrey Haas" <[email-masked]>, "Pedro Roque Marques" <[email-masked]>
Cc: [email-masked], "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Sender: [email-masked]

Jeffrey, Pedro,

The proposed updated text actually stays away from discussing what is the right "policy" to decide whether IPv6 VPN traffic should be transported over v4 or v6. It basically just says, "if IPv6 VPN traffic is to be transported over vN, then you shall include a next-hop that looks like vN"; For example:
"
3.2.1.1 BGP speaker requesting IPv6 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
...blablabla 
"

Personally, I think it is probably beyond the scope of this particular IPv6 VPN document to prescribe what policies may/should/must be used by operators for selection of transport vs BGP stack. So, my proposal would be to :
	- keep the proposed updated text that we discussed
	- add a couple of sentences that point out potential operational issues involved in transporting traffic over vN when the corresponding BGP advertisements are carried themselves over vM (instead of vN).

Would that be acceptable?
Pedro, would you be willing to craft the couple of additional sentences?

Cheers

Francois

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Jeffrey Haas
>> Sent: jeudi 3 février 2005 11:41
>> To: Pedro Roque Marques
>> Cc: [email-masked]
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> On Mon, Mar 24, 1975 at 10:06:56AM -0800, Pedro Roque Marques wrote:
>> > The point is that it does. If ibgp transport between PE1 
>> and PE2 uses
>> > the forwarding LSP between PE1 and PE2 then a silent (in control
>> > plane) forwarding failure will cause the BGP transport 
>> session to come
>> > down.
>> 
>> Right.  But this is a generic MP-BGP issue rather than one specific
>> to this particular protocol extention.
>> 
>> > > I will agree with you 100% that there are operational 
>> practices that
>> > > will provide better survivability in certain failure 
>> scenarios.  Do
>> > > these belong in this protocol extention?  Probably not.
>> > 
>> > I thought so... but i conceed that it is a matter of opinion.
>> 
>> I objected to the SHALL.  It sounds like you believe a SHOULD is the
>> solution.  Propose new text - that's what last call is all about. :-)
>> 
>> I wouldn't object to a SHOULD.
>> 
>> >   Pedro.
>> 
>> -- 
>> Jeff Haas 
>> NextHop Technologies
>> 
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 

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

content-class: urn:content-classes:message
Subject: RE: [Idr] RFC 2858 erratum
Date: Fri, 4 Feb 2005 09:55:22 -0500
From: "Susan Hares" <[email-masked]>
To: "Tom Petch" <[email-masked]>, "idr" <[email-masked]>
Cc: 
Sender: [email-masked]

Please do.  

Sue

-----Original Message-----
From: Tom Petch [mailto:[email-masked]] 
Sent: Friday, February 04, 2005 4:45 AM
To: idr
Subject: [Idr] RFC 2858 erratum

In RFC 2858, Multiprotocol Extensions for BGP-4, it says in

8. IANA Considerations

 "...  The SAFI name space is defined in Section 9...."

In fact, Section 9 is

9. Comparison with RFC 2283

I suspect this reference should be to Section 5 ie

5. Subsequent Address Family Identifier

The RFC editor pages list no errata for this RFC.  Are you ok if I
report this
to the
RFC Editor?

Tom Petch

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

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

Date: Fri, 4 Feb 2005 09:24:57 +2244
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: [email-masked]
Sender: [email-masked]

On Mon, Mar 24, 1975 at 10:06:56AM -0800, Pedro Roque Marques wrote:
> The point is that it does. If ibgp transport between PE1 and PE2 uses
> the forwarding LSP between PE1 and PE2 then a silent (in control
> plane) forwarding failure will cause the BGP transport session to come
> down.

Right.  But this is a generic MP-BGP issue rather than one specific
to this particular protocol extention.

> > I will agree with you 100% that there are operational practices that
> > will provide better survivability in certain failure scenarios.  Do
> > these belong in this protocol extention?  Probably not.
> 
> I thought so... but i conceed that it is a matter of opinion.

I objected to the SHALL.  It sounds like you believe a SHOULD is the
solution.  Propose new text - that's what last call is all about. :-)

I wouldn't object to a SHOULD.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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

From: "Tom Petch" <[email-masked]>
To: "idr" <[email-masked]>
Date: Fri, 4 Feb 2005 10:45:18 +0100
Subject: [Idr] RFC 2858 erratum
Reply-To: Tom Petch <[email-masked]>
Sender: [email-masked]

In RFC 2858, Multiprotocol Extensions for BGP-4, it says in

8. IANA Considerations

 "...  The SAFI name space is defined in Section 9...."

In fact, Section 9 is

9. Comparison with RFC 2283

I suspect this reference should be to Section 5 ie

5. Subsequent Address Family Identifier

The RFC editor pages list no errata for this RFC.  Are you ok if I report this
to the
RFC Editor?

Tom Petch

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

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 3 Feb 2005 13:51:50 -0800
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: [email-masked]
Sender: [email-masked]

Jeffrey Haas writes:

> In at least one of the scenarios you have proposed - a label change
> fails to propagate - even running the same nexthop AF as your
> peering session wont protect you.

The point is that it does. If ibgp transport between PE1 and PE2 uses
the forwarding LSP between PE1 and PE2 then a silent (in control
plane) forwarding failure will cause the BGP transport session to come
down.

> I will agree with you 100% that there are operational practices that
> will provide better survivability in certain failure scenarios.  Do
> these belong in this protocol extention?  Probably not.

I thought so... but i conceed that it is a matter of opinion.

  Pedro.

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

Date: Thu, 3 Feb 2005 16:24:00 -0500
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: [email-masked]
Sender: [email-masked]

Pedro,

On Thu, Feb 03, 2005 at 10:32:28AM -0800, Pedro Roque Marques wrote:
> But by using a next-hop that matches the transport, if there is a
> silent forwarding failure on the path (no control info), the BGP
> session will come down due to keepalive failure.

In at least one of the scenarios you have proposed - a label change
fails to propagate - even running the same nexthop AF as your
peering session wont protect you.

> As i mentioned, some networks have as a requirement that, iBGP VPN
> sessions are carried over the LSPs so that forwarding failures will
> also affect the control plane.

I will agree with you 100% that there are operational practices
that will provide better survivability in certain failure scenarios.
Do these belong in this protocol extention?  Probably not.

Did it belong in the base protocol specification?  Perhaps.
(And it might be there.  I haven't read 2547bis in some time.)

> If i remember correctly, you objected to the spec including a SHOULD
> "use next-hops in this way"... there is a reason to prefer one method
> of doing things. i.e. a justification.

No, my original objection was to the SHALL use them this way.
The response of the authors was essentially, "no, we didn't mean it
quite this way".

> Example: LDP LSP between 2 PEs; control plane is fine; some label
> change didn't get propagated down to the forwarding engines; traffic
> gets dropped sillently.

If this is a common event, it sounds like the implementation isn't very
robust.   Then again, one could simply run BFD across your LSP/tunnel
of choice and stop worrying about it. :-)

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 3 Feb 2005 10:32:28 -0800
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: [email-masked]
Sender: [email-masked]

Jeffrey Haas writes:

> In this particular case, the MP-BGP nexthop is meant to serve as a
> way to select an LSP that will allow the each end of the VPN to
> reach the tunneled reachability.  The nexthop will select whether we
> try to use/create an LSP that is an IPv4 or an IPv6 LSP.

> If BGP was being used as the label distribution protocol for the LSP
> endpoints, I can see making a strong association between the BGP
> transport session and the MP-BGP reachability.  However, it is as
> likely (or more likely?) that a second protocol such as LDP or RSVP
> will be used to signal the LSP.

Jeff,
I don't agree with that line of reasoning. On ibgp, BGP is not used to
determine interior routing... some other protocol is.

But by using a next-hop that matches the transport, if there is a
silent forwarding failure on the path (no control info), the BGP
session will come down due to keepalive failure.

As i mentioned, some networks have as a requirement that, iBGP VPN
sessions are carried over the LSPs so that forwarding failures will
also affect the control plane.

> If implementors want to force the AF to match the transport session,
> nothing stops them from implementing it this way.  I believe that
> many implementations will do exactly that.

> I don't find a need to enforce this in the protocol given that some
> people will want to be able to do what I had commented on.

If i remember correctly, you objected to the spec including a SHOULD
"use next-hops in this way"... there is a reason to prefer one method
of doing things. i.e. a justification.

Then there is the question of should a standard allow as much freedom
as possible or nail down the most common option that implementations
should support and let vendors expand on top of this minimum common
set. There is no perfect answer to that.

>> It matters. If the type matches, i can forward the transport
>> session on top of the LSP and have it drop if the LSP goes
>> dead. Not everyone runs their BGP sessions this way, but some
>> network operators choose to do so... usually after past negative
>> experiences with sillent mpls forwarding failures.

> That's an interesting comment.  A labeled BGP route (or VPN route)
> is supposed to become unresolvable if there is no LSP to the
> end-point.  Perhaps I misunderstand you.

Example: LDP LSP between 2 PEs; control plane is fine; some label
change didn't get propagated down to the forwarding engines; traffic
gets dropped sillently.

Also, if LDP is used in "black-hole creation mode"
(a.k.a. independent-control) this kind of mismatch between control and
forwarding plane can occur quite easily.

  Pedro.

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

Date: Thu, 3 Feb 2005 10:09:10 -0500
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: [email-masked]
Sender: [email-masked]

Pedro,

On Wed, Feb 02, 2005 at 05:12:13PM -0800, Pedro Roque Marques wrote:
> imho transport and forwarding to next-hop should be tied together
> whenever possible.

I generally agree.

I specifically disagree in this case.

In this particular case, the MP-BGP nexthop is meant to serve as
a way to select an LSP that will allow the each end of the VPN to
reach the tunneled reachability.  The nexthop will select whether
we try to use/create an LSP that is an IPv4 or an IPv6 LSP.

If BGP was being used as the label distribution protocol for the LSP
endpoints, I can see making a strong association between the BGP
transport session and the MP-BGP reachability.  However, it is as likely
(or more likely?) that a second protocol such as LDP or RSVP will
be used to signal the LSP.  

> The standard example being a network with v4 and v6 forwarding /
> transport capabilities. Forwarding can break independently by AF. Using
> v4 transport for v6 next-hops can lead to undetected blackholes...

True.  This is why we will still have a IPv6-based IGP running along-side
our IPv6 label distribution protocol in most cases.  Normal BGP
nexthop resolution will continue to work.

> AF of NLRI has nothing to do w/ nexthop or transport. af of next-hop
> should correspond to transport.

But then you immediately say:

> >  When carrying information for a different address family
> > (e.g.  an ipv4 transport session carrying ipv6 reachability)
> 
> You really shouldn't do that. :-) It is allowed but frowned upon. The
> entire reason it is allowed is because some implementations wanted
> this "transition" mode as a way to ramp up... 

And the wording that I commented on precluded this sort of mechanism.

If implementors want to force the AF to match the transport session,
nothing stops them from implementing it this way.  I believe that 
many implementations will do exactly that.

I don't find a need to enforce this in the protocol given that some people
will want to be able to do what I had commented on.

> It matters. If the type matches, i can forward the transport session
> on top of the LSP and have it drop if the LSP goes dead. Not everyone
> runs their BGP sessions this way, but some network operators choose to
> do so... usually after past negative experiences with sillent mpls
> forwarding failures.

That's an interesting comment.  A labeled BGP route (or VPN route)
is supposed to become unresolvable if there is no LSP to the end-point.
Perhaps I misunderstand you.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

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

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 2 Feb 2005 17:12:13 -0800
To: Jeffrey Haas <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: [email-masked]
Sender: [email-masked]

Jeffrey Haas writes:

> I have a concern with regards to the MP-BGP nexthops for this draft:
> This draft ties the MP-BGP nexthop associated with VPN-IPv6
> reachability to the BGP Speaker's transport session type.

Sounds like a feature. :-)

imho transport and forwarding to next-hop should be tied together
whenever possible.

The standard example being a network with v4 and v6 forwarding /
transport capabilities. Forwarding can break independently by AF. Using
v4 transport for v6 next-hops can lead to undetected blackholes...

>  I.e. an
> IPv6 transport session will require IPv6 VPN-IPv6 nexthops and an
> IPv4 transport session will require IPv4 VPN-IPv4 nexthops.

I guess you mean an LSP identified by a IPvX address...
That would be desirable. yes.

> MP-BGP allows for different address families to be carried across
> the same BGP session regardless of the form of the transport
> session.

AF of NLRI has nothing to do w/ nexthop or transport. af of next-hop
should correspond to transport.

>  When carrying information for a different address family
> (e.g.  an ipv4 transport session carrying ipv6 reachability)

You really shouldn't do that. :-) It is allowed but frowned upon. The
entire reason it is allowed is because some implementations wanted
this "transition" mode as a way to ramp up... 

> it is
> necessary to configure additional information about the endpoints of
> the session for reachability calculations.

And necessary to keep in mind that forwarding may break silently.

>  This draft appears to
> try to preclude this option in some capacities for VPN-IPv6.

Good.

> I would suspect that regardless of the transport session type, as
> long as it was clear if the nexthop was v4 or v6 that as long as a
> label-switched path could be established between the two BGP
> speakers it shouldn't matter what kind of transport session is being
> used.

It matters. If the type matches, i can forward the transport session
on top of the LSP and have it drop if the LSP goes dead. Not everyone
runs their BGP sessions this way, but some network operators choose to
do so... usually after past negative experiences with sillent mpls
forwarding failures.

cheers,
  Pedro.

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

To: [email-masked]
From: [email-masked]
Date: Wed, 02 Feb 2005 15:36:35 -0500
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-07.txt
Sender: [email-masked]

--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		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-07.txt
	Pages		: 4
	Date		: 2005-2-2
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-aspath-orf-07.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-aspath-orf-07.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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-aspath-orf-07.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

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

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

--NextPart--

Date: Tue, 1 Feb 2005 17:12:09 -0500
From: Jeffrey Haas <[email-masked]>
To: "Francois Le Faucheur (flefauch)" <[email-masked]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Cc: [email-masked], [email-masked], Ronald Bonica <[email-masked]>, Ross Callon <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Francois,

On Tue, Feb 01, 2005 at 11:13:49AM +0100, Francois Le Faucheur (flefauch) wrote:
> 1) The following text:
> "
> 3.2.1 BGP Next Hop encoding
> The encoding of the BGP Next Hop depends on whether the IPv6 VPN reachability is advertised between BGP speakers using IPv6 connectivity (''BGP speakers with IPv6 connectivity'') or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
> "
> be replaced by something like:
> "
> 3.2.1 BGP Next Hop encoding
> The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 transport'') or using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
> "

This seems reasonable.

> 2) The following text:
> "
> 3.2.1.1 BGP speakers with IPv6 connectivity
> When using IPv6 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
> "
> be replaced by something like:
> "
> 3.2.1.1 BGP speaker requesting IPv6 transport
> When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:

Also reasonable.

> 3) The following text:
> "
> 3.2.1.2 BGP Speakers with IPv4 connectivity
> When using IPv4 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
> "
> be replaced by something like:
> "
> 3.2.1.2 BGP Speakers requesting IPv4 transport
> When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:

Also good.

> Would those sort of changes address the problem?

I think that does it.

-- 
Jeff Haas 
NextHop Technologies

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

To: [email-masked]
From: [email-masked]
Date: Tue, 01 Feb 2005 15:49:33 -0500
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-ext-communities-08.txt
Sender: [email-masked]

--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		: BGP Extended Communities Attribute
	Author(s)	: S. Sangli, et al.
	Filename	: draft-ietf-idr-bgp-ext-communities-08.txt
	Pages		: 14
	Date		: 2005-2-1
	
This document describes an extension to BGP [BGP-4] which may be used
to provide flexible control over the distribution of routing
information.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-ext-communities-08.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-08.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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-08.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

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

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

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Tue, 1 Feb 2005 16:54:41 -0000
From: "Michael Dell" <[email-masked]>
To: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Cc: NextHop - Susan Hares <[email-masked]>, [email-masked], Jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>, Ross Callon <[email-masked]>, Ronald Bonica <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Francois

Thanks for the reply.  Yes, I think that it would be helpful to make it clear that it is up to the user/implementation to configure policy to define what the BGP next-hop should be.

On reflection, I would agree that defining how this should be configured is probably an implementation matter.

Mike Dell
Data Connection Ltd.

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: 01 February 2005 16:22
To: Michael Dell
Cc: NextHop - Susan Hares; [email-masked]; Yakov Rekhter; Ross Callon;
Ronald Bonica; [email-masked]; [email-masked]; Jeffrey
Haas; Francois Le Faucheur (flefauch)
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04

Hello Michael,

>> -----Original Message-----
>> From: Michael Dell [mailto:[email-masked]] 
>> Sent: mardi 1 février 2005 13:14
>> To: Francois Le Faucheur (flefauch); Jeffrey Haas
>> Cc: NextHop - Susan Hares; [email-masked]; Yakov Rekhter; Ross 
>> Callon; Ronald Bonica; [email-masked]; [email-masked]
>> Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> Francois
>> 
>> I have a question about your proposed change to the BGP next 
>> hop encoding.
>> 
>> If I understand you correctly, you say that the way the BGP 
>> next hop of an IPv6-VPN route is constructed should not 
>> depend on the transport type of the BGP session between the 
>> speakers, but rather on the transport type of the tunnel 
>> over which data will be passed. 
>> 
>> For example, if the two speakers share an IPv6 BGP session, 
>> but will transport data over an IPv4 MPLS LSP, then the BGP 
>> next hop of an IPv6-VPN NLRI should be constructed from the 
>> IPv6-mapped IPv4 version of the advertising speaker's IPv4 
>> address (the egress address of the LSP), rather than its 
>> IPv6 address (the session's local address).

yes.
 
>> This sounds sensible, and probably what was originally 
>> intended.  However, I am uncertain how the BGP speaker is 
>> supposed to select which BGP next hop to use.  If two 
>> speakers with an IPv6 session are to forward data over an 
>> IPv4 tunnel, is it up to the user to configure policy so 
>> that the correct next hops are used when advertising routes 
>> to each other?  

Yes. That is the intent.
Should we add a clarifying sentence to that effect?

>> This could be achieved by some 
>> implementation specific policy to set the next-hop of VPNv6 
>> routes,

Right.

>> but should there perhaps be a more standardised way 
>> of defining how this should work, such as within the 
>> mplsL3VpnVrfTable MIB table?  (This is probably more a 
>> question for the L3VPN WG I guess).
 
I think this would be beyond the scope of draft-ietf-l3vpn-bgp-ipv6.
With respect to a specific MIB knob, I don't have the right expertise to follow it up, but it is not clear to me this would naturally map into as a single binary MIB knob since using IPv4 or IPv6 type Next Hop could be the resultant of several configuration knobs (eg "route map" forcing the nexthop).

Thanks

Francois

>> Regards
>> 
>> Mike Dell
>> Data Connection Ltd
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: 01 February 2005 10:14
>> To: Jeffrey Haas
>> Cc: NextHop - Susan Hares; [email-masked]; Francois Le Faucheur
>> (flefauch); Yakov Rekhter; Ross Callon; Ronald Bonica;
>> [email-masked]; [email-masked]
>> Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> 
>> Hello Jeffrey,
>> 
>> >> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> >> reachability to the BGP Speaker's transport session type.
>> 
>> This was not the intent, but I looked back at the current 
>> text and I have to agree it precisely (and incorrectly) does that.
>> This needs to be fixed. How about the following sort of changes:
>> 
>> 
>> 1) The following text:
>> "
>> 3.2.1 BGP Next Hop encoding
>> The encoding of the BGP Next Hop depends on whether the IPv6 
>> VPN reachability is advertised between BGP speakers using 
>> IPv6 connectivity (''BGP speakers with IPv6 connectivity'') 
>> or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
>> "
>> be replaced by something like:
>> "
>> 3.2.1 BGP Next Hop encoding
>> The encoding of the BGP Next Hop depends on whether the 
>> policy of the BGP Speaker is to request that IPv6 VPN 
>> traffic be transported to that BGP Next Hop using IPv6 
>> tunneling (''BGP speaker requesting IPv6 transport'') or 
>> using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
>> "
>> 
>> 
>> 2) The following text:
>> "
>> 3.2.1.1 BGP speakers with IPv6 connectivity
>> When using IPv6 connectivity to the other BGP speaker for 
>> advertisement of the IPv6 VPN reachability, a BGP speaker 
>> SHALL advertise a Next Hop Network Address field containing 
>> a VPN-IPv6 address:
>> "
>> be replaced by something like:
>> "
>> 3.2.1.1 BGP speaker requesting IPv6 transport
>> When the IPv6 VPN traffic is to be transported to the BGP 
>> speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, 
>> IPsec-protected IPv6 tunnels), the BGP speaker SHALL 
>> advertise a Next Hop Network Address field containing a 
>> VPN-IPv6 address:
>> "
>> 
>> 
>> 3) The following text:
>> "
>> 3.2.1.2 BGP Speakers with IPv4 connectivity
>> When using IPv4 connectivity to the other BGP speaker for 
>> advertisement of the IPv6 VPN reachability, a BGP speaker 
>> SHALL advertise to its peer a Next Hop Network Address field 
>> containing a VPN-IPv6 address:
>> "
>> be replaced by something like:
>> "
>> 3.2.1.2 BGP Speakers requesting IPv4 transport
>> When the IPv6 VPN traffic is to be transported to the BGP 
>> speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, 
>> IPsec-protected IPv4 tunnels), the BGP speaker SHALL 
>> advertise to its peer a Next Hop Network Address field 
>> containing a VPN-IPv6 address:
>> "
>> 
>> Would those sort of changes address the problem?
>> 
>> I will also re-read all the relevant text to try determine 
>> if additional changes are needed in other places. Please, 
>> let us know if you've already identified other text needing 
>> correction.
>> 
>> 
>> Thanks a lot for this comment.
>> 
>> Francois
>> 
>> 
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]] On 
>> >> Behalf Of Jeffrey Haas
>> >> Sent: mardi 1 février 2005 00:04
>> >> To: Yakov Rekhter
>> >> Cc: Ross Callon; [email-masked]; [email-masked]; 
>> >> [email-masked]; Ronald Bonica
>> >> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> >> 
>> >> I have a concern with regards to the MP-BGP nexthops for 
>> this draft:
>> >> 
>> >> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> >> reachability
>> >> to the BGP Speaker's transport session type.  I.e. an IPv6 
>> >> transport session
>> >> will require IPv6 VPN-IPv6 nexthops and an IPv4 transport 
>> >> session will
>> >> require IPv4 VPN-IPv4 nexthops.
>> >> 
>> >> Why is this a SHALL?
>> >> 
>> >> MP-BGP allows for different address families to be carried across
>> >> the same BGP session regardless of the form of the 
>> transport session.
>> >> When carrying information for a different address family (e.g.
>> >> an ipv4 transport session carrying ipv6 reachability) it 
>> is necessary
>> >> to configure additional information about the endpoints of 
>> >> the session
>> >> for reachability calculations.  This draft appears to try 
>> to preclude
>> >> this option in some capacities for VPN-IPv6.
>> >> 
>> >> I would suspect that regardless of the transport session type, as
>> >> long as it was clear if the nexthop was v4 or v6 that as long as
>> >> a label-switched path could be established between the two 
>> >> BGP speakers
>> >> it shouldn't matter what kind of transport session is being used.
>> >> 
>> >> On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
>> >> > Folks,
>> >> > 
>> >> > This message begins a last call on 
>> >> draft-ietf-l3vpn-bgp-ipv6-04. Last
>> >> > call ends on Feb 1 at midnight UTC.
>> >> > 
>> >> > Yakov.
>> >> > 
>> >> > P.S. this is a combined last call with the L3VPN WG.
>> >> > 
>> >> > _______________________________________________
>> >> > Idr mailing list
>> >> > [email-masked]
>> >> > https://www1.ietf.org/mailman/listinfo/idr
>> >> 
>> >> -- 
>> >> Jeff Haas 
>> >> NextHop Technologies
>> >> 
>> >> _______________________________________________
>> >> Idr mailing list
>> >> [email-masked]
>> >> https://www1.ietf.org/mailman/listinfo/idr
>> >> 
>> 
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 

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

Content-class: urn:content-classes:message
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Tue, 1 Feb 2005 12:13:56 -0000
From: "Michael Dell" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Jeffrey Haas" <[email-masked]>
Cc: NextHop - Susan Hares <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>, Ross Callon <[email-masked]>, Ronald Bonica <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Francois

I have a question about your proposed change to the BGP next hop encoding.

If I understand you correctly, you say that the way the BGP next hop of an IPv6-VPN route is constructed should not depend on the transport type of the BGP session between the speakers, but rather on the transport type of the tunnel over which data will be passed. 

For example, if the two speakers share an IPv6 BGP session, but will transport data over an IPv4 MPLS LSP, then the BGP next hop of an IPv6-VPN NLRI should be constructed from the IPv6-mapped IPv4 version of the advertising speaker's IPv4 address (the egress address of the LSP), rather than its IPv6 address (the session's local address).

This sounds sensible, and probably what was originally intended.  However, I am uncertain how the BGP speaker is supposed to select which BGP next hop to use.  If two speakers with an IPv6 session are to forward data over an IPv4 tunnel, is it up to the user to configure policy so that the correct next hops are used when advertising routes to each other?  This could be achieved by some implementation specific policy to set the next-hop of VPNv6 routes, but should there perhaps be a more standardised way of defining how this should work, such as within the mplsL3VpnVrfTable MIB table?  (This is probably more a question for the L3VPN WG I guess).

Regards

Mike Dell
Data Connection Ltd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 01 February 2005 10:14
To: Jeffrey Haas
Cc: NextHop - Susan Hares; [email-masked]; Francois Le Faucheur
(flefauch); Yakov Rekhter; Ross Callon; Ronald Bonica;
[email-masked]; [email-masked]
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04

Hello Jeffrey,

>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability to the BGP Speaker's transport session type.

This was not the intent, but I looked back at the current text and I have to agree it precisely (and incorrectly) does that.
This needs to be fixed. How about the following sort of changes:

1) The following text:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the IPv6 VPN reachability is advertised between BGP speakers using IPv6 connectivity (''BGP speakers with IPv6 connectivity'') or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
"
be replaced by something like:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 transport'') or using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
"

2) The following text:
"
3.2.1.1 BGP speakers with IPv6 connectivity
When using IPv6 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.1 BGP speaker requesting IPv6 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"

3) The following text:
"
3.2.1.2 BGP Speakers with IPv4 connectivity
When using IPv4 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.2 BGP Speakers requesting IPv4 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"

Would those sort of changes address the problem?

I will also re-read all the relevant text to try determine if additional changes are needed in other places. Please, let us know if you've already identified other text needing correction.

Thanks a lot for this comment.

Francois

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Jeffrey Haas
>> Sent: mardi 1 février 2005 00:04
>> To: Yakov Rekhter
>> Cc: Ross Callon; [email-masked]; [email-masked]; 
>> [email-masked]; Ronald Bonica
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> I have a concern with regards to the MP-BGP nexthops for this draft:
>> 
>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability
>> to the BGP Speaker's transport session type.  I.e. an IPv6 
>> transport session
>> will require IPv6 VPN-IPv6 nexthops and an IPv4 transport 
>> session will
>> require IPv4 VPN-IPv4 nexthops.
>> 
>> Why is this a SHALL?
>> 
>> MP-BGP allows for different address families to be carried across
>> the same BGP session regardless of the form of the transport session.
>> When carrying information for a different address family (e.g.
>> an ipv4 transport session carrying ipv6 reachability) it is necessary
>> to configure additional information about the endpoints of 
>> the session
>> for reachability calculations.  This draft appears to try to preclude
>> this option in some capacities for VPN-IPv6.
>> 
>> I would suspect that regardless of the transport session type, as
>> long as it was clear if the nexthop was v4 or v6 that as long as
>> a label-switched path could be established between the two 
>> BGP speakers
>> it shouldn't matter what kind of transport session is being used.
>> 
>> On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
>> > Folks,
>> > 
>> > This message begins a last call on 
>> draft-ietf-l3vpn-bgp-ipv6-04. Last
>> > call ends on Feb 1 at midnight UTC.
>> > 
>> > Yakov.
>> > 
>> > P.S. this is a combined last call with the L3VPN WG.
>> > 
>> > _______________________________________________
>> > Idr mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/idr
>> 
>> -- 
>> Jeff Haas 
>> NextHop Technologies
>> 
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 

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

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

Content-class: urn:content-classes:message
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Tue, 1 Feb 2005 11:13:49 +0100
From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
To: "Jeffrey Haas" <[email-masked]>
Cc: [email-masked], [email-masked], "Francois Le Faucheur \(flefauch\)" <[email-masked]>, Yakov Rekhter <[email-masked]>, Ross Callon <[email-masked]>, Ronald Bonica <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Hello Jeffrey,

>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability to the BGP Speaker's transport session type.

This was not the intent, but I looked back at the current text and I have to agree it precisely (and incorrectly) does that.
This needs to be fixed. How about the following sort of changes:

1) The following text:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the IPv6 VPN reachability is advertised between BGP speakers using IPv6 connectivity (''BGP speakers with IPv6 connectivity'') or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
"
be replaced by something like:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 transport'') or using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
"

2) The following text:
"
3.2.1.1 BGP speakers with IPv6 connectivity
When using IPv6 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.1 BGP speaker requesting IPv6 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"

3) The following text:
"
3.2.1.2 BGP Speakers with IPv4 connectivity
When using IPv4 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.2 BGP Speakers requesting IPv4 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"

Would those sort of changes address the problem?

I will also re-read all the relevant text to try determine if additional changes are needed in other places. Please, let us know if you've already identified other text needing correction.

Thanks a lot for this comment.

Francois

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Jeffrey Haas
>> Sent: mardi 1 février 2005 00:04
>> To: Yakov Rekhter
>> Cc: Ross Callon; [email-masked]; [email-masked]; 
>> [email-masked]; Ronald Bonica
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> I have a concern with regards to the MP-BGP nexthops for this draft:
>> 
>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability
>> to the BGP Speaker's transport session type.  I.e. an IPv6 
>> transport session
>> will require IPv6 VPN-IPv6 nexthops and an IPv4 transport 
>> session will
>> require IPv4 VPN-IPv4 nexthops.
>> 
>> Why is this a SHALL?
>> 
>> MP-BGP allows for different address families to be carried across
>> the same BGP session regardless of the form of the transport session.
>> When carrying information for a different address family (e.g.
>> an ipv4 transport session carrying ipv6 reachability) it is necessary
>> to configure additional information about the endpoints of 
>> the session
>> for reachability calculations.  This draft appears to try to preclude
>> this option in some capacities for VPN-IPv6.
>> 
>> I would suspect that regardless of the transport session type, as
>> long as it was clear if the nexthop was v4 or v6 that as long as
>> a label-switched path could be established between the two 
>> BGP speakers
>> it shouldn't matter what kind of transport session is being used.
>> 
>> On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
>> > Folks,
>> > 
>> > This message begins a last call on 
>> draft-ietf-l3vpn-bgp-ipv6-04. Last
>> > call ends on Feb 1 at midnight UTC.
>> > 
>> > Yakov.
>> > 
>> > P.S. this is a combined last call with the L3VPN WG.
>> > 
>> > _______________________________________________
>> > Idr mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/idr
>> 
>> -- 
>> Jeff Haas 
>> NextHop Technologies
>> 
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 

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