Subject: Re: (IPng 4552) BGP and renumbering
From: Pedro Marques <[email-masked]>
To: "Matt Crawford" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 30 Sep 1997 12:58:30 -0700 (PDT)

>>>>> "Matt" == Matt Crawford <[email-masked]> writes:

    >> Renumbering the routers is a cinche by comparison to
    >> renumbering the customers served by an ISP (who in most cases
    >> simply refuse).
    >> 
    >> What I'm getting at is that IPv6 needs to solve the end system
    >> problems and don't worry so much about renumbering the
    >> intrastructure because that's not where the problem is.
    >> 
    >> Curtis

    Matt> I believe that the IPNG WG collectively feel that we have
    Matt> that one pretty much licked.

>From the Munich meeting i'd the impression that we still don't know
how to solve the problem of renumbering hosts.

If i remember correctly Erik Nordmark's site-prefixes draft wasn't fully
discussed in the meeting due to lack of time and some of the issues it
raises didn't seam close to be settled. But regardless of the actual
solution, one thing the draft clearly points out is that simply
being able to dynamic learn and reconfigure the addresses that an host
is using is not enought.

Also, talking about renumbering in the IPv6 context is a difficult problem
since everybody seams to have it's own definition of what renumbering means.
It would be nice if the IPng WG could agree on a definition. One could
probably obtain a clear one by answering the questions: "what renumbers ?",
"how often ?" and "why ?".

Maybe it would be useful if we actually step back for a bit and try to
list the problems we must solve in term of address visibility (i.e. what
causes the routing table explosion problem).

Assume for a while that the following list is the smallest list that covers
the problems that really must be solved:
1) Leaf site changing providers.
2) Multihoming of leaf sites.

If we look at multihoming, the requirements are ability to do load-balancing
and fallback. I would argue that this really has nothing to do with
renumbering. Fallback can be accomplished by either injecting the failing
prefix temporarily via the working paths or by changing the addresses in
use by the connection, which are pretty different cenarios from renumbering
a site.

So from the list above, and eliminating multihoming from the problems
renumbering must solve we end up with a pretty simple definition of
renumbering: readdressing of leaf sites when they change provider.
Which is tipically an infrequent operation and can accomodate grace
periods of weeks.

There are several conclusion we can take from this hypothesis:
. Renumbeing eBGP connections is not a problem since changing the eBGP
peering is the reason for renumbering in the first place.
. Operations like off-line resigning all DNS records for a site are
pretty acceptable.
. The focus should pretty much be on being able to perform the real
problem at hands...

Of course none of the above holds if the list of problems to solve is
really much different from what i enumerated but i do believe people
should think twice before adding things to that list. Needless to say
that trying to solve world hunger is not always productive.

    Matt>   Deployment experience will
    Matt> prove it, or will shatter the illusion.

Indeed.

  Pedro.

To: "Matt Crawford" <[email-masked]>
cc: [email-masked], Curtis Villamizar <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4552) BGP and renumbering 
Date: Mon, 29 Sep 1997 17:35:51 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "Matt Crawford" writes:
> > Renumbering the routers is a cinche by comparison to renumbering
> > the customers served by an ISP (who in most cases simply refuse).
> > 
> > What I'm getting at is that IPv6 needs to solve the end system
> > problems and don't worry so much about renumbering the intrastructure
> > because that's not where the problem is.
> > 
> > Curtis
> 
> I believe that the IPNG WG collectively feel that we have that one
> pretty much licked.  Deployment experience will prove it, or will
> shatter the illusion.
> 					Matt

I'm aware of what IPv6 has to offer and I agree on the end system
renumbering point.

I think you are wasting your time considering implications of
dynamicly allocating the AS border (DMZ) addresses to BGP speaking
routers and changing these addresses.  If the "fix" to make thing more
dynamic renumbering friendly takes functionality away from BGP then
its counterproductive since you're solving a non-problem in the first
place.

So please leave the draft-ietf-idr-bgp4-multiprotocol-01.txt draft as
is regarding rewriting next hop.

Curtis

To: [email-masked]
Cc: Curtis Villamizar <[email-masked]>, [email-masked], [email-masked]
From: "Matt Crawford" <[email-masked]>
Subject: Re: (IPng 4552) BGP and renumbering 
Date: Mon, 29 Sep 1997 13:37:29 -0500
Sender: [email-masked]

> Renumbering the routers is a cinche by comparison to renumbering
> the customers served by an ISP (who in most cases simply refuse).
> 
> What I'm getting at is that IPv6 needs to solve the end system
> problems and don't worry so much about renumbering the intrastructure
> because that's not where the problem is.
> 
> Curtis

I believe that the IPNG WG collectively feel that we have that one
pretty much licked.  Deployment experience will prove it, or will
shatter the illusion.
					Matt

To: "Matt Crawford" <[email-masked]>
cc: Paul Traina <[email-masked]>, Curtis Villamizar <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4552) BGP and renumbering 
Date: Mon, 29 Sep 1997 13:46:02 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "Matt Crawford" writes:
> 
> Topology changes will probably be likened someday to tectonic
> motions -- they introduce stress in the routing which can be
> relieved by renumbering.  If you let it go too long, you get a
> Richter 8.0.  Or you can grease up the fault lines with little 1.0
> shocks and not break a teacup.
> 
> 				Matt
> 	  (Hey, at least I didn't use the s10y metaphor!)

With IPv4 there is no significant barrier to renumbering at the ISP
level other than the customers can't really do it.  Renumbering the
routers is a cinche by comparison to renumbering the customers served
by an ISP (who in most cases simply refuse).

What I'm getting at is that IPv6 needs to solve the end system
problems and don't worry so much about renumbering the intrastructure
because that's not where the problem is.

Curtis

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-01.txt
Date: Mon, 29 Sep 1997 09:47:55 -0400
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		: Multiprotocol Extensions for BGP-4
	Author(s)	: D. Katz, Y. Rekhter, T. Bates, R. Chandra
	Filename	: draft-ietf-idr-bgp4-multiprotocol-01.txt
	Pages		: 9
	Date		: 1997-09-26
	
   Currently BGP-4 [BGP-4] is capable of carrying routing information
   only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
   enable it to carry routing information for multiple Network Layer
   protocols (e.g., IPv6, IPX, etc...). The extensions are backward
   compatible - a router that supports the extensions can interoperate
   with a router that doesn't support the extensions.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-multiprotocol-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-01.txt".
	
NOTE:	The mail server at ds.internic.net 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-bgp4-multiprotocol-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-multiprotocol-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

From: Francis Dupont <[email-masked]>
To: "Matt Crawford" <[email-masked]>
cc: [email-masked] (Christian Huitema), [email-masked], [email-masked]
Subject: Re: (IPng 4532) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Sat, 27 Sep 1997 14:36:04 +0200
Sender: [email-masked]

 In your previous mail you wrote:

   > One of the point that was agreed during the Munich meeting of IPv6 is that
   > Site Local addresses should not be used for EGP routing exchanges.
   
   Once again, you make me wonder if we were at the same meeting.  I
   find nothing remotely like your statement above in my memory, my
   notes, or the minutes of the meeting I attended.  (That was in
   Munich, Bavaria, Germany.  Perhaps there are two Munichs?)
   
=> there is no formal agreement but I believe many persons in
the room shared this idea. Christian was closer to the micro...

   However, I think I agree with the above, but not with
   
   > (My personnal feeling is that site local addresses should not be
   > used *at all*, at least in a connected site, because they have all
   > the properties of Net 10 addresses).
   
   and what follows.  However, that topic is out of scope for this
   thread.

=> but we should talk about it (in the ipng mailing list for instance).
Personnally I think the same thing than Christian but obviously
it is not the case for everybody. The (un)usage of site-local
addresses has a real impact on many things, for instance will there be
a monster named a multi-sited node? Then it is out of scope but important!

Regards

[email-masked]

Date: Fri, 26 Sep 1997 16:54:25 -0700
To: Sethurambalaji Kodeswaran <[email-masked]>
From: Bob Hinden <[email-masked]>
Subject: Re: (IPng 4569) Where to start?????
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Balaji,

>I am new graduate student and i would like to know more about IPv6. Can 
>you tell me where to start. I have worked a lot with TCP/IP but am not 
>too familiar with the intricasies of IPv4.  Thanx in advance

See

	http://playground.sun.com/ipng

Bob

Date: Fri, 26 Sep 1997 17:49:17 -0400 (EDT)
From: Sethurambalaji Kodeswaran <[email-masked]>
To: Matt Crawford <[email-masked]>
cc: Paul Traina <[email-masked]>, Curtis Villamizar <[email-masked]>, [email-masked], [email-masked]
Subject: Where to start?????
Sender: [email-masked]

hi,

I am new graduate student and i would like to know more about IPv6. Can 
you tell me where to start. I have worked a lot with TCP/IP but am not 
too familiar with the intricasies of IPv4.Thanx in advance

Bye,
Balaji. 

To: Paul Traina <[email-masked]>, Curtis Villamizar <[email-masked]>
Cc: [email-masked], [email-masked]
From: "Matt Crawford" <[email-masked]>
Subject: Re: (IPng 4552) BGP and renumbering
Date: Fri, 26 Sep 1997 15:38:59 -0500
Sender: [email-masked]

> > The longer term solution is to design renumbering support in the next EGP.
> 
> Not very tough if you can have two addresses during transition.  All
> BGP needs is to allow a timer on routes after the CEASE.  If after the
> CEASE the same peering came up with a different pair of addresses and
> announced all of the routes before the timer expired there would be no
> disruption of service.

Hold on a second ... if your (non-multihop) EBGP connections at an
IX or on a private link run between link-local addresses, your BGP
peerings are immune to renumberings by your peer.

And if your own IBGP connections run between site-local addresses,
those peerings are immune to renumbering of YOUR OWN system.

Topology changes will probably be likened someday to tectonic
motions -- they introduce stress in the routing which can be
relieved by renumbering.  If you let it go too long, you get a
Richter 8.0.  Or you can grease up the fault lines with little 1.0
shocks and not break a teacup.

				Matt
	  (Hey, at least I didn't use the s10y metaphor!)

To: [email-masked]
Subject: Re: WG last call 
Date: Fri, 26 Sep 97 07:08:13 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

In response to the comments we received so far
the Internet Draft is revised as follows:

1.  The following sentence

  When an UPDATE message carries the MP_REACH_NLRI attribute, the
  attribute shall be placed after all other attributes in the message.

is removed.

2. Network Layer Reachability Length field is removed.

3. Unfeasible Routes Length is removed.

The revised Internet Draft is submitted to the IETF secretariat.

Yakov.

P.S. The Last Call is extended for another two weeks (till 10/9)
to allow comments on the revised Internet Draft.

Posted-Date: Fri, 26 Sep 1997 06:26:01 -0700 (PDT)
Date: Fri, 26 Sep 1997 09:24:26 -0400
To: [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4554) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 09:45 PM 9/25/97 -0400, Curtis Villamizar wrote:
>
>The MP_REACH_NLRI Next Hop and BGP4 NEXT_HOP are semantic equivalents
>and in practice the IPv4 and IPv6 networks routing may overlay each
>other in what could be a very long transition.
>
>The functionality for IPv4 and IPv6 should mirror each other.  This
>avoids an iteration of BGP where MP_REACH_NLRI Next Hop is sorta-like
>NEXT_HOP except for a few rules where they are unnessecarily
>different.  Worse yet the route computation could come out differently
>for Ipv4 and IPv6 networks overlaying each other.  This is strictly a
>matter of avoiding operational headaches and making it easier on a
>transition.  It could make coding a bit easier too (and its not like
>bugs in BGP code haven't been a serious problem in practice).
>
>Its a new attribute so in principle you could throw out any IPv4
>preconceptions but IMHO it would be wise to minimize differences
>unless there is good reason for change and I don't see that.
>
>I still think of MP_REACH_NLRI Next Hop as IPv6 equivalent to BGP4
>NEXT_HOP.  The list of SNPAs is similar to what was going to be a new
>attribute in BGP in ancient times (that suggestion dates back to
>before the first NHRP was proposed to ROLC) to accomodate shortcuts.
>Other than the SNPA which previously was suggested as a separate
>attribute, MP_REACH_NLRI is the old BGP4 NLRI and a next hop rolled
>into a new attribute.  What you are telling us is that the Next Hop is
>no longer quite the same as NEXT_HOP and I'm objecting.
>
>Did that make more sense or less sense?
>
Frankly?.. The latter, at least to me.

I can't appreciate you transition concerns.  Comparing to v4, IPv6
addressing has a somewhat different address allocation and delegation
scheme, renumbering assumption, and, subsequently, a higher aggregation
potential. There has been a deliberate effort to move away from the current
addressing mess ASAP and to start with a clean bill of health. So the
prospect that the v6 routing hierarchy will not overlay the v4 routing does
not scare me a bit - just opposite.  The originally proposed v6 address
allocation was practically identical to the current v4 practices and there
were loud complains from the ISP folks that this is not acceptable and does
not provide enough incentives to deploy v6. Well, with help of these folks
I believe it has been greatly improved even if more work is needed to work
out some re-numbering details.  Now I expect you to dismiss it as an
academic nonsense or a wishful thinking ;) I hope not -- time will tell.

Said that, it really has nothing to do with the MP's nexthop. The nexthop
rewrite at AS border is not a novice idea or something that has not been
already widely used. So it does not introduce any unexpected transition
issues.

In the both proposals a link-local address has to be provided in the
attribute. In addition the original proposal mandates that a global scope
address be always provided too - hence two addresses. This by itself makes
this attribute somewhat semantically different from the V4 NEXT_HOP, like
it or not.  If the v6 nexthop is rewritten at the border (as already done
in many v4 deployments), there is zero use for the global nexthop address.
In such cases, I've proposed to allow only the link-local address to be
transmitted in the nexthop in and spare the advertiser from an unnecessary
address administration overhead.

>Curtis

Dimitry

From: Wang Ling <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Beginer of BGP
Date: Fri, 26 Sep 1997 11:58:57 +0800
Sender: [email-masked]

hi:
	i was a beginer of BGP , i had used RIP&OSPF , but had not used
BGP &IGP, i knew it is the superspeard protocal using in internet
backbond ,and i knew it was used to communicate between the AS . i
wanted to know more about it , how to work ?
	So i need your helping .

B.R.G
Wang Ling

To: Dimitry Haskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4550) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 21:45:34 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.1.32.19970925204033.006abda4@pobox>, Dimitry Haskin writes:
> Curtis,
> 
> With all my respect, I'm not sure what you are talking about.  I feel that
> you comments are out of context of the argument at hand.  We are discussing
> the use of the nexthop that is specified in the MP_REACH_NLRI attribute in
> the IPv6 context.  Is it what you're talking about too?
> 
> Dimitry

The MP_REACH_NLRI Next Hop and BGP4 NEXT_HOP are semantic equivalents
and in practice the IPv4 and IPv6 networks routing may overlay each
other in what could be a very long transition.

The functionality for IPv4 and IPv6 should mirror each other.  This
avoids an iteration of BGP where MP_REACH_NLRI Next Hop is sorta-like
NEXT_HOP except for a few rules where they are unnessecarily
different.  Worse yet the route computation could come out differently
for Ipv4 and IPv6 networks overlaying each other.  This is strictly a
matter of avoiding operational headaches and making it easier on a
transition.  It could make coding a bit easier too (and its not like
bugs in BGP code haven't been a serious problem in practice).

Its a new attribute so in principle you could throw out any IPv4
preconceptions but IMHO it would be wise to minimize differences
unless there is good reason for change and I don't see that.

I still think of MP_REACH_NLRI Next Hop as IPv6 equivalent to BGP4
NEXT_HOP.  The list of SNPAs is similar to what was going to be a new
attribute in BGP in ancient times (that suggestion dates back to
before the first NHRP was proposed to ROLC) to accomodate shortcuts.
Other than the SNPA which previously was suggested as a separate
attribute, MP_REACH_NLRI is the old BGP4 NLRI and a next hop rolled
into a new attribute.  What you are telling us is that the Next Hop is
no longer quite the same as NEXT_HOP and I'm objecting.

Did that make more sense or less sense?

Curtis

Posted-Date: Thu, 25 Sep 1997 17:42:13 -0700 (PDT)
Date: Thu, 25 Sep 1997 20:40:33 -0400
To: [email-masked], Dimitry Haskin <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4550) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Curtis,

With all my respect, I'm not sure what you are talking about.  I feel that
you comments are out of context of the argument at hand.  We are discussing
the use of the nexthop that is specified in the MP_REACH_NLRI attribute in
the IPv6 context.  Is it what you're talking about too?

Dimitry

P.S. BTW, no one has proposed to use off subnet address as the nexthop.
 
At 07:44 PM 9/25/97 -0400, Curtis Villamizar wrote:
>
>In message <3.0.32.19970924120126.006d5f64@pobox>, Dimitry Haskin writes:
>> 
>> I'm not ready to say (even if it has crossed my mind ;) that use of the
>> local-scope addresses as the BGP next-hop will be sufficient in all
>> possible cases. Nevertheless I clearly can see and have demonstrated how
>> local-scope addresses can be used to our advantage in many non-exotic
>> cases. At this point I'm just asking to relax the v6 BGP rules imposed on
>> the NEXT_HOP address scope.  This way we don't have to resolve
>> philosophical or whatever dilemmas now but simply to experiment and see.
>
>> Too much to ask?
>Yes!
>
>You need another attribute if you want to put an address in that is
>off subnet.
>
>Routing protocol features which are semantically identical for IPv4
>and IPv6 are a good thing where possible and backward compatibility
>with existing BGP4 implementations is needed for IPv4.
>
>The harder you make the transition the longer it will be before IPv6
>deployment is anything more than a toy.  It makes sense to avoid
>complicating the transition if you don't have a really good reason to
>do so and IMHO you don't have any good reason at all to use NEXT_HOP
>rather than another attribute.
>
>BTW- In paractice, this rule is already relaxed for multihop EBGP with
>non-local addresses and a TTL applied to the peering, but multihop
>EBGP is considered a hack for research peerings (test out routing
>code) and to work around level 2 brain damage (when routers must be
>sort of bridged when they don't support a common media and
>encapsulation - for example RFC1490 and RFC1483 encapsulation on ATM
>requiring a intermediate router that supports both).  It can also be a
>very problematic hack.
>
>Curtis
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [email-masked]
>--------------------------------------------------------------------
>
>

Posted-Date: Thu, 25 Sep 1997 17:12:09 -0700 (PDT)
Date: Thu, 25 Sep 1997 20:10:34 -0400
To: Pedro Marques <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4548) Re: BGP and renumbering.. was /126 or /127 --  neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 03:41 PM 9/25/97 -0700, Pedro Marques wrote:
>>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:
>
>    Dimitry> At 02:14 PM 9/25/97 -0700, Pedro Marques wrote:
>    >> The discussion so far as been on what to carry on a EBGP
>    >> peering on a direct link and my proposal doesn't restrict
>    >> anyone from doing anything they wish.
>
>    Dimitry> I don't get why it so difficult to understand but you're
>    Dimitry> forcing one to assign a global address to the IX
>    Dimitry> interface. That hardly qualifies as "doesn't restrict
>    Dimitry> anyone from doing anything they wish".
>
>That doesn't mean the peer or the interior routers of the peering AS have
>to actually be able to route to that address which seams to be your objection
>in the first place.

Yes, I've pointed out that the global-scope nexthop is unnecessary in many
cases. In such a case I would like to be spared from the burden of
configuring and administering global addresses on my IX interfaces. This
addresses have no value to me.

>
>In other words, the point your are trying to make about renumbering isn't
>in my opinion valid because you can configure things to do what you want.
>
>We have to proposals: one is a superset of the other. And i don't believe you
>have proven that the difference in capabilities you want to dismiss is not
>useful.
>
And what capability do I dismiss? You still can advertise you global
addresses all you want. I assume that you view my proposal as a superset of
yours, don't you?  It addition to your set it requires less address
administration effort in most typical cases.
  
>  Pedro.

Dimitry

To: [email-masked]
cc: [email-masked] (Christian Huitema), Quaizar Vohra <[email-masked]>, Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 17:10:44 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Curtis Villamizar <[email-masked]>
  Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neithe
>>r! 

  This could be done with IPv4 as long as there is a way to send a CEASE
  that results in putting the routes on a withdrawl timer rather than
  immmediately withdrawing them.  You could even static configure the
  BGP peering for this behavior and not change the protocol at all.

A cease with a sanely limited short timer is a damn fine swiss-army knife
for solving a lot of problems.

I feel an ID coming on. :-)

To: Dimitry Haskin <[email-masked]>
cc: [email-masked] (Christian Huitema), [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 19:44:07 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.32.19970924120126.006d5f64@pobox>, Dimitry Haskin writes:
> 
> I'm not ready to say (even if it has crossed my mind ;) that use of the
> local-scope addresses as the BGP next-hop will be sufficient in all
> possible cases. Nevertheless I clearly can see and have demonstrated how
> local-scope addresses can be used to our advantage in many non-exotic
> cases. At this point I'm just asking to relax the v6 BGP rules imposed on
> the NEXT_HOP address scope.  This way we don't have to resolve
> philosophical or whatever dilemmas now but simply to experiment and see.

> Too much to ask?
Yes!

You need another attribute if you want to put an address in that is
off subnet.

Routing protocol features which are semantically identical for IPv4
and IPv6 are a good thing where possible and backward compatibility
with existing BGP4 implementations is needed for IPv4.

The harder you make the transition the longer it will be before IPv6
deployment is anything more than a toy.  It makes sense to avoid
complicating the transition if you don't have a really good reason to
do so and IMHO you don't have any good reason at all to use NEXT_HOP
rather than another attribute.

BTW- In paractice, this rule is already relaxed for multihop EBGP with
non-local addresses and a TTL applied to the peering, but multihop
EBGP is considered a hack for research peerings (test out routing
code) and to work around level 2 brain damage (when routers must be
sort of bridged when they don't support a common media and
encapsulation - for example RFC1490 and RFC1483 encapsulation on ATM
requiring a intermediate router that supports both).  It can also be a
very problematic hack.

Curtis

Date: Thu, 25 Sep 1997 16:39:43 -0700 (PDT)
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG last call
Sender: [email-masked]

>> A pain?  Are you kidding?

    No comment.

Dino

To: Dino Farinacci <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG last call 
Date: Thu, 25 Sep 1997 16:37:10 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Dino Farinacci <[email-masked]>
  Subject: Re: WG last call

      Traditional withdrawn routes make it a pain because they are in front
      of everything else. MP_UNREACH_NLRI will make this a little more
      convenient.

A pain?  Are you kidding?

To: [email-masked] (Christian Huitema)
cc: Quaizar Vohra <[email-masked]>, Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 19:18:55 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Christian Huitema write
s:
> 
> The longer term solution is to design renumbering support in the next EGP.

Not very tough if you can have two addresses during transition.  All
BGP needs is to allow a timer on routes after the CEASE.  If after the
CEASE the same peering came up with a different pair of addresses and
announced all of the routes before the timer expired there would be no
disruption of service.

During the period when the shared interface has two prefixes there
should be two IGP routes for the interface being renumbered, one for
each address on the local interface.  After the BGP transition, one
number is removed from the interface and one IGP route goes away.

Here's the whole procedure:

  1.  add inteface alias to both all peers.  since there are multiple
      parties this could occur over days or longer.

  2.  some time passes after the address is added (something like 60
      seconds).

  3.  the IGP route for the new interface address is propogated.

  4.  routers are reconfigured to accept BGP peerings on either
      interface (passive) but the old peering is still active.

  5.  One end of the BGP peering is "bumped" by configuring the old
      peering down and the new one active.  AS long as routes are not
      withdrawn immediately on the cease this is OK.

  6.  The routes are reannounced on the new peering.  The next hop is
      different.

  7.  The new next hop is propogated to IBGP peers.  Since AS path and
      other attributes have not changed there is no need to propogate
      further unless there is a level 2 shortcut attribute that also
      changed with the address change.

  8.  Since the IGP reachability to either alias on the interface is
      the same, all decisions still come out the same and no FIB
      change is required.

  9.  The unused address can be removed some time after all of the
      peerings have been changed.  With it goes the IGP route.

This could be done with IPv4 as long as there is a way to send a CEASE
that results in putting the routes on a withdrawl timer rather than
immmediately withdrawing them.  You could even static configure the
BGP peering for this behavior and not change the protocol at all.

Curtis

Date: Thu, 25 Sep 1997 15:41:21 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Dimitry Haskin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: (IPng 4540) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    Dimitry> At 02:14 PM 9/25/97 -0700, Pedro Marques wrote:
    >> The discussion so far as been on what to carry on a EBGP
    >> peering on a direct link and my proposal doesn't restrict
    >> anyone from doing anything they wish.

    Dimitry> I don't get why it so difficult to understand but you're
    Dimitry> forcing one to assign a global address to the IX
    Dimitry> interface. That hardly qualifies as "doesn't restrict
    Dimitry> anyone from doing anything they wish".

That doesn't mean the peer or the interior routers of the peering AS have
to actually be able to route to that address which seams to be your objection
in the first place.

In other words, the point your are trying to make about renumbering isn't
in my opinion valid because you can configure things to do what you want.

We have to proposals: one is a superset of the other. And i don't believe you
have proven that the difference in capabilities you want to dismiss is not
useful.

  Pedro.

Posted-Date: Thu, 25 Sep 1997 15:23:54 -0700 (PDT)
Date: Thu, 25 Sep 1997 18:20:32 -0400
To: Pedro Marques <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4540) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 02:14 PM 9/25/97 -0700, Pedro Marques wrote:
>The discussion so far as been on what to carry on a EBGP peering on a direct
>link and my proposal doesn't restrict anyone from doing anything they wish.

I don't get why it so difficult to understand but you're forcing one to
assign a global address to the IX interface. That hardly qualifies as
"doesn't restrict anyone from doing anything they wish".

Dimitry

To: Dimitry Haskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 18:19:40 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.1.32.19970923202359.006a9f20@pobox>, Dimitry Haskin writes:
> >
> I believe we agree on that. To boot, we'd like to achieve it without
> granting permanent ownership of global-scope addresses or imposing undue
> renumbering dependencies between independently administered sites.  To this
> end, we try to utilize v6 local scope addresses -- something that is
> missing in the V4 addressing architecture (well.. except v4 private use
> addresses which are useless for the problem at hand).

V4 private numbering at IX has come up as a real suggestion.  If I
want to reach another provider's address I'd have to do so using the
loopback address (terminology varies with some using virtual).  This
would be fine when routing was up.

Each provider would have the subnet address in the IGP but pass that
no further.  No two exchanges could use the same space, but there
aren't that many exchanges to worry about.

A potential failure here is that a provider's NOC may want to ping the
far end interface to distinguish between a peering going down and a
router disappearing completely.  This is an important distinction if
you are in network operations because it determines the next action of
the NM software, the type of alert, and the action of the NOC
personnel.  [If a peering is down, you have to assume that it could be
your own BGP.  If a router is not pingable but all others on the
interface are, for a while you can assume that the problem is in the
other router but if it persists call the other provider and don't rule
out the possibility of a hideous level 2 problem].

The same functionality is lost with IPv6 local scope addresses unless
those addresses can be propogated all the way back to the NOC of every
provider that participates at the exchange.  My understanding is that
IPv6 local scope addresses would no provide that.  

BTW- In both cases source routing to your own router or to within your
own infrastructure and using the private address would work for the
purpose of determining reachability.  The addresses of IXs would still
have to be non-unique and therefore still not truely local.

Curtis

ps- what century do you plan to start deploying IPv6 in?  For real
rather than 6bone?  If I didn't think you were serious about
renumbering an entire AS dynamically I'd ROTFL.  Maybe in some future
Internet that no longer vaguely resembles this one.  For starters, you
can only renumber an IPv4 free entity.  I don't see there being very
many IPv4 free entities as large as an AS is today.  In fact, by the
time that ever happens I'd expect BGP to be substantially different or
historic.

To: Dimitry Haskin <[email-masked]>
cc: Quaizar Vohra <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 17:47:45 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.1.32.19970923195431.0069fc20@pobox>, Dimitry Haskin writes:
> 
> For purpose of our discussions, a site is a collection of v6 interfaces
> that get their addresses allocated from a single set (aggregate) of site
> local addresses (SLA). That has little to do with geography. [It is
> conceivable albeit probably unlikely for a site to consist from multiple
> ASs but not vise versa.] As I stated earlier in the discussion, I don't see
> how multiple sites can form a single IGP domain (aka AS).  You need to run
> EGP (EBGP in this case) between sites. Naturally, since you running EBGP
> between sites, the NEXT_HOP changes as routes cross site boundaries.

How about if we dispense with the acedemic nonsense and inject some
reality into the discussion.

BGP is used in situations where there are multiple administrative
domains and multiple borders between those domains and/or where an IGP
would no longer scale.  These "sites" are beyond the size where anyone
is willing to dynamicly reallocate and therefore trigger renumbering.

For example, I would not expect a peer provider to take an address
assignment from us through a dynamic protocol and trigger renumbering
of their entire infrastruscture and all of their customers.  I
wouldn't expect most customers to ever agree to this.

Providers infrastructure numbering is always fixed.  A rule of thumb
is to never have any dependency on a higher level service prevent a
network element from doing its job.  No dependency on DNS.  No
dependency on anything to get interface numbering.  I really don't
expect that to change.

I'd be very surprised if within an organization more than perhaps a
building or major department dynamicly numbered.  In practice, this is
a granularity much smaller than an AS.  This is why the whole argument
seems silly.

If numbers are dynamicly assigned and EBGP peers do not share a common
subnet on a direct interface then it should be OK for a replacement of
next hop to be allowed in the BGP protocol.

If there are N AS on a subnet and the local subnet cost was needed,
then each border router on that subet would need N addresses, one for
each "site".  This is a non-issue since it won't ever be used.  In
practice that shared subnet would have a fixed prefix and that one
fixed prefix would be injected in each IGP by virtue of being a subnet
on a direct interface of a router in that IGP.

Curtis

Date: Thu, 25 Sep 1997 14:14:08 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Quaizar Vohra <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: (IPng 4540) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

>>>>> "Quaizar" == Quaizar Vohra <[email-masked]> writes:

    Quaizar> So the DMZ addresses coming from a site's global IPv6
    Quaizar> prefix are not going to be static as in IPv4. Dimitry
    Quaizar> suggested using link-local IPv6 addresses which are *NOT
    Quaizar> DYNAMIC* and are always static.
    >>  Until you have to upgrade your router or switch whatever piece
    >> of harwdware that holds the MAC tokens... that would make
    >> hardware upgrades really fun.

    Quaizar> If I were an administrator I will use my EID part in such
    Quaizar> cases as fixed numbers (not MAC tokens). Even if global
    Quaizar> IPv6 prefixes were used on the subnet with MAC tokens you
    Quaizar> have the same problem.

But then they won't be globally unique anymore. Probably not even unique on
the link...

	[my rant/flame bait on fixed scoped addresses deleted]

    Quaizar> Well they might solve a problem here if you will allow.

The discussion so far as been on what to carry on a EBGP peering on a direct
link and my proposal doesn't restrict anyone from doing anything they wish.
I'll reiterate the point again: you carry two addresses, a global and a
link local address. If the peer decides to ignore the global and rewrite
the global nexthop with any address it chooses this is 100% functionaly
equivalent to what Dimitry has proposed.

So your comment is quite incorrect.

  Pedro.

From: Quaizar Vohra <[email-masked]>
Date: Thu, 25 Sep 1997 14:00:30 -0700 (PDT)
To: Pedro Marques <[email-masked]>
Cc: Quaizar Vohra <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: (IPng 4540) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

 > 
 > Quaizar,

 > That is a religion that not everybody professes. And until it is proven that
 > it can be done and that it is actually a good idea some people will just
 > consider that "the very basis of scalable routing" is just wishful thinking.

Maybe I had a religious tone :-). I would agree that I would try 
avoiding renumbering as long as it is possible. If it becomes 
necessary because I want something else more then I will accept it.
 > 
 >     Quaizar>  So the DMZ addresses coming from a site's
 >     Quaizar> global IPv6 prefix are not going to be static as in
 >     Quaizar> IPv4. Dimitry suggested using link-local IPv6 addresses
 >     Quaizar> which are *NOT DYNAMIC* and are always static.
 > 
 > Until you have to upgrade your router or switch whatever piece of harwdware
 > that holds the MAC tokens... that would make hardware upgrades really fun.

If I were an administrator I will use my EID part in such cases as fixed
numbers (not MAC tokens). Even if global IPv6 prefixes were used
on the subnet with MAC tokens you have the same problem.

 > 
 > Link local address cannot be in DNS either... and since they all look
 > pretty much the same that will make looking into your 40 peer configuration
 > another interestening exercise.

 > 
 > Fixed scope unicast addresses is something that IPv6 introduces that wasn't
 > present in IPv4. It is still to be seen if they really do solve more problems
 > than they do create. In IPv4 you have, presently, no strict relationship
 > between an address and it's routing scope... there are a couple of useful
 > address assigment conventions but as far as the protocols are concerned an
 > addresses is an address. Extremely simple... fixed scope addresses bring us
 > some rules on the necessary scope of addresses that actually make things
 > less flexible.
 > 
 >   Pedro.

Well they might solve a problem here if you will allow.

Quaizar

Posted-Date: Thu, 25 Sep 1997 13:44:36 -0700 (PDT)
Date: Thu, 25 Sep 1997 16:41:13 -0400
To: [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Curtis,
(from two messages)
>
>I think what is missing is the concept of a border interface which is
>in neither "site".  An IX does not below to any of the 50 or so AS
>that sit on that interface and would not be renumbered with the site.
>
I believe the IX concept has been clearly understood.

>You cannot renumber one end of a BGP connection and keep the BGP
>connection up.  Even if you did renumber a "site" you'd have to keep
>two sets of numbers and then reconfig one end to allow connections
>to/from either sets of numbers and then reconfig the other end to
>switch from the old address to the new.  This would be minimally
>disruptive.  We're not talking about renumbering the secretarial pool
>or a bunch of laptops here.  Routers running BGP have different
>requirements to meet.
>
Absolutely.  Fortunately (actually by design), IPv6 link-local addresses
can be used for EBGP connections. Link-local addresses practically never
change -- even when sites renumber. What can be better to meet the BGP
requirements? For some reason, I feel the link-local address concept is
missing in your reasoning. Incidently, we are not trying to address any
IPv4 issues.

>The very fact that a router is running EBGP means that it is sitting
>on an administrative boundary.  Keeping the prefix at the boundary
>staticly allocated is no big deal.

A big deal or not, in V6 it can be no deal at all for a typical BGP IX --
no prefix whatsoever.

>The same applies for a border with a small multihomed customer.  They
>can renumber their site but they had better coordinate renumbering the
>DMZ because it is not theirs alone to renumber.

With the proposed V6-specific approach this is not an issue to even think
about. I'm emphasizing "V6-specific" since I've come to think that you are
applying the V4 addressing model in you reasoning.

Dimitry

Date: Thu, 25 Sep 1997 13:40:58 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Quaizar Vohra <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: (IPng 4540) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

>>>>> "Quaizar" == Quaizar Vohra <[email-masked]> writes:

    >> The very fact that a router is running EBGP means that it is
    >> sitting on an administrative boundary.  Keeping the prefix at
    >> the boundary staticly allocated is no big deal.  For example:
    >> we use subnet's of an MCI aggregate for private peerings.  We
    >> have those subnets in our IGP (no big deal).  If MCI ever
    >> renumbered (**not very likely**) we'd expect them to keep the
    >> DMZ addresses constant and renumber those independently.

    Quaizar> You are very much right. But in IPv6 renumbering being
    Quaizar> the very basis of scalable routing is expected for even a
    Quaizar> large ISP.

Quaizar,
That is a religion that not everybody professes. And until it is proven that
it can be done and that it is actually a good idea some people will just
consider that "the very basis of scalable routing" is just wishful thinking.

    Quaizar>  So the DMZ addresses coming from a site's
    Quaizar> global IPv6 prefix are not going to be static as in
    Quaizar> IPv4. Dimitry suggested using link-local IPv6 addresses
    Quaizar> which are *NOT DYNAMIC* and are always static.

Until you have to upgrade your router or switch whatever piece of harwdware
that holds the MAC tokens... that would make hardware upgrades really fun.

Link local address cannot be in DNS either... and since they all look
pretty much the same that will make looking into your 40 peer configuration
another interestening exercise.

Fixed scope unicast addresses is something that IPv6 introduces that wasn't
present in IPv4. It is still to be seen if they really do solve more problems
than they do create. In IPv4 you have, presently, no strict relationship
between an address and it's routing scope... there are a couple of useful
address assigment conventions but as far as the protocols are concerned an
addresses is an address. Extremely simple... fixed scope addresses bring us
some rules on the necessary scope of addresses that actually make things
less flexible.

  Pedro.

From: Quaizar Vohra <[email-masked]>
Date: Thu, 25 Sep 1997 13:33:52 -0700 (PDT)
To: [email-masked]
Cc: Dimitry Haskin <[email-masked]>, Quaizar Vohra <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

Curtis Villamizar writes:
 > 
 > In message <3.0.32.19970923165544.006d0c40@pobox>, Dimitry Haskin writes:
 > > Quaizar,
 > > 
 > > >
 > > >>From your's and Dimitry's reason I now understand better why
 > > >it is difficult to introduce this new attribute. 
 > > >
 > > >We might still avoid passing the remote peer's global address
 > > >into local AS by using Dimitry's proposal of using link-local
 > > >addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with
 > > >a AS-local IPV6 address before readvertising it in IBGP and
 > > >ensuring that the cost of the IX link could also get accounted for.
 > > >This could be done by using the AS-local IPV6 address assigned to
 > > >the border router on the IX link in the NEXT_HOP attribute.
 > > >
 > > 
 > > You just made a very important observation. You are right: we can account
 > > for the cost of an IX link without introducing a new attribute.  Let me
 > > depict it so it is crisp and clear.
 > > 
 > >          1          1      
 > >     A1 -----s1 B1---------B4
 > >          IX                |
 > >           5          1     |1    
 > >     A2 -----s2 B2---------B3
 > >          IX 
 > > 
 > > Routers A* are in one AS, routers B* are in another AS.  A1 and B1, and A2
 > > and B2 exchange routes via EBGP respectively. When B1 readvertises A1's
 > > routes to its internal BGP peers it uses a site-local address of its
 > > interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a
 > > site-local address of its interface on the IX link to A2, say s2, as the
 > > NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the
 > > same site-local addresses, s1 and s2, are specified as forwarding
 > > addresses.  Both s1 and s2 are injected into IGP with the costs of their
 > > respective link, i.e. 1 and 5 respectively. Now costs of the IX link are
 > > fully accounted in route selection.
 > > 
 > > In the above diagram, if the same external network is reachable via either
 > > border router, every B* sends packets to that external network via the
 > > B1/A1 link as a lower cost path.
 > 
 > 
 > 
 > AS-B injects BGP into OSPF ASEs?  !!!  Are we forgetting about the AS
 > path truncation problems and the severe scaling problems with many
 > implementations?
 > 
 > Router A1 and B1 must have an inteface that shares a common subnet.
 > If so that prefix is in both IGPs of A and B.  The BGP routes are
 > never injected into the IGP.
 > 
 > A renumbering of the subnet containing A1 and B1 would have to involve
 > both A1 and B1 having two addresses (aliases) during the transition.
 > They would both end up on the same subnet when the process is done and
 > again the subnet is in both IGPs.
 > 
 > Curtis

Talking specifically about IPv6 (not applicable to IPv4):

	Routers A1 and B1 have an interface which is on a common layer
2 link. They need not share a global IPv6 prefix. They can do peering
using their link-local IPv6 addresses (if BGP is run over
TCP/IPv6). They can also assign their respective interfaces on the
common link using their own site local prefixes. These site-local
prefixes travel in the respective IGPs and hence allows accounting for
the cost of the common link.
	The current proposal (Dimitry's) is to allow (not mandate)
passing of just link-local IPv6 addresses in EBGP NEXT_HOP attribute
which gets replaced by the site-local IPv6 address of the interface
allocated by the local AS on the common ebgp link when readvertised
in IBGP.
	Link local addresses have the property of being static forever
(practically). 
	This has the potential advantage of not assigning a global IPv6
prefix on the common ebgp link. Which would not be static if it comes
from either ASs (as ASs are likely to renumber in IPv6 more often) OR
would have to come from an administrtive body specially setup to allocate
static global IPv6 address.

Quaizar

From: Quaizar Vohra <[email-masked]>
Date: Thu, 25 Sep 1997 13:09:14 -0700 (PDT)
To: [email-masked]
Cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: (IPng 4540) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

 > 
 > The point is not to change things such that the computation that is
 > made by a router which ignores that attribute could result in a route
 > loop.
 > 
 > If you add a value from a new BGP attribute to the IGP cost (which was
 > the proposed "solution" to not having the IGP cost of the border
 > interface if the near end router replaces the next-hop with its own
 > address) then route loops can form.  The protocol already accommodates
 > that last hop cost so don't break the functionality and then fix it in
 > a way that is incompatible with current practice.

I think we all agree on that

 > 
 > This argument borders on being silly.  
 > 
 > Routers that are running EBGP are not going to be renumbered without a
 > coordinated effort and are not going to be accepting a dynamically
 > assigned address, whether IPv4 or IPv6.
 > 
 > The very fact that a router is running EBGP means that it is sitting
 > on an administrative boundary.  Keeping the prefix at the boundary
 > staticly allocated is no big deal.  For example: we use subnet's of an
 > MCI aggregate for private peerings.  We have those subnets in our IGP
 > (no big deal).  If MCI ever renumbered (**not very likely**) we'd
 > expect them to keep the DMZ addresses constant and renumber those
 > independently.

You are very much right. But in IPv6 renumbering being the very
basis of scalable routing is expected for even a large ISP. So
the DMZ addresses coming from a site's global IPv6 prefix are
not going to be static as in IPv4. Dimitry suggested using 
link-local IPv6 addresses which are *NOT DYNAMIC* and are always
static.

Quaizar

 > 
 > The same applies for a border with a small multihomed customer.  They
 > can renumber their site but they had better coordinate renumbering the
 > DMZ because it is not theirs alone to renumber.
 > 
 > Curtis

To: Dimitry Haskin <[email-masked]>
cc: Quaizar Vohra <[email-masked]>, [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 16:04:33 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.32.19970923165544.006d0c40@pobox>, Dimitry Haskin writes:
> Quaizar,
> 
> >
> >>From your's and Dimitry's reason I now understand better why
> >it is difficult to introduce this new attribute. 
> >
> >We might still avoid passing the remote peer's global address
> >into local AS by using Dimitry's proposal of using link-local
> >addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with
> >a AS-local IPV6 address before readvertising it in IBGP and
> >ensuring that the cost of the IX link could also get accounted for.
> >This could be done by using the AS-local IPV6 address assigned to
> >the border router on the IX link in the NEXT_HOP attribute.
> >
> 
> You just made a very important observation. You are right: we can account
> for the cost of an IX link without introducing a new attribute.  Let me
> depict it so it is crisp and clear.
> 
>          1          1      
>     A1 -----s1 B1---------B4
>          IX                |
>           5          1     |1    
>     A2 -----s2 B2---------B3
>          IX 
> 
> Routers A* are in one AS, routers B* are in another AS.  A1 and B1, and A2
> and B2 exchange routes via EBGP respectively. When B1 readvertises A1's
> routes to its internal BGP peers it uses a site-local address of its
> interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a
> site-local address of its interface on the IX link to A2, say s2, as the
> NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the
> same site-local addresses, s1 and s2, are specified as forwarding
> addresses.  Both s1 and s2 are injected into IGP with the costs of their
> respective link, i.e. 1 and 5 respectively. Now costs of the IX link are
> fully accounted in route selection.
> 
> In the above diagram, if the same external network is reachable via either
> border router, every B* sends packets to that external network via the
> B1/A1 link as a lower cost path.

AS-B injects BGP into OSPF ASEs?  !!!  Are we forgetting about the AS
path truncation problems and the severe scaling problems with many
implementations?

Router A1 and B1 must have an inteface that shares a common subnet.
If so that prefix is in both IGPs of A and B.  The BGP routes are
never injected into the IGP.

A renumbering of the subnet containing A1 and B1 would have to involve
both A1 and B1 having two addresses (aliases) during the transition.
They would both end up on the same subnet when the process is done and
again the subnet is in both IGPs.

Curtis

To: Dimitry Haskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4496) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 14:39:57 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.32.19970923142940.00714894@pobox>, Dimitry Haskin writes:
> >> 
> >> If this is right then why not introduce another attribute which
> >> carries the link cost of the IX link/path. 
> >
> >Because the protocol already covers this case.  Why remove the
> >functionality and put it some other place.  You would then have to
> >determine the total cost by adding the IGP cost to the new BGP
> >attribute.  This would be true for all IGPs and a pain to implement.
> >
> I don't agree that it will be necessary to use the new BGP attribute in all
> IGPs -- at least no more that you'd used MED or LocPref outside of IBGP.
> This would be normally used for route selection when IBGP "hack" is on and
> external routes are not injected into IGP.

The point is not to change things such that the computation that is
made by a router which ignores that attribute could result in a route
loop.

If you add a value from a new BGP attribute to the IGP cost (which was
the proposed "solution" to not having the IGP cost of the border
interface if the near end router replaces the next-hop with its own
address) then route loops can form.  The protocol already accommodates
that last hop cost so don't break the functionality and then fix it in
a way that is incompatible with current practice.

> >> For IPv6 this will atleast remove the need for administering
> >> assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6
> >> addresses to the ebgp peers on their IX interfaces. 
> >> 
> >> Quaizar
> >
> >BGP is not going to be used on dynamicly assigned subnets.  Period.
> >No matter how much the IPv6 research community loves the feature.
> >
> >Provider routers don't even run DNS so their reliability is not
> >reduced by a dependency on something external to the router.
> >
> The point it that in many cases it would be beneficial not assign
> global-scope addresses to external BGP links at all. Unlike v4, v6 has
> different scope addresses that would be nice to take advantage of to reduce
> administrative and renumbering burdens. In case of EBGP, link-local
> addresses may be sufficient enough.

This argument borders on being silly.  

Routers that are running EBGP are not going to be renumbered without a
coordinated effort and are not going to be accepting a dynamically
assigned address, whether IPv4 or IPv6.

The very fact that a router is running EBGP means that it is sitting
on an administrative boundary.  Keeping the prefix at the boundary
staticly allocated is no big deal.  For example: we use subnet's of an
MCI aggregate for private peerings.  We have those subnets in our IGP
(no big deal).  If MCI ever renumbered (**not very likely**) we'd
expect them to keep the DMZ addresses constant and renumber those
independently.

The same applies for a border with a small multihomed customer.  They
can renumber their site but they had better coordinate renumbering the
DMZ because it is not theirs alone to renumber.

Curtis

Date: Thu, 25 Sep 1997 11:20:22 -0700 (PDT)
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG last call
Sender: [email-masked]

>> True, there's no reason it can't give a suggestion, though I think
>> John Stewart and I raised some reasons we think the suggestion in
>> question is a bad one.  The current draft of course doesn't make
>> it a suggestion, it makes it a *requirement*, so it would need to
>> be revised in any case.

    Right.

Dino

To: Dimitry Haskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Thu, 25 Sep 1997 14:18:50 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.32.19970923123217.0068b130@pobox>, Dimitry Haskin writes:
> Curtis,
> 
> >
> >The remote AS routers are on direct interfaces of your own router and
> >normally direct interfaces are included in the IGP.  The only case
> >where this gets a bit sticky is PTP links in BSD/gated style where the
> >two ends of the PTP link are not restricted to the same subnet.  This
> >is still OK if the IGP includes both ends of the PTP link to be in the
> >IGP.  It only a problem for unnumbered PTP links (which don't see much
> >use in this sort of application since other things like SNMP
> >monitoring get unhappy with no address).
> >
> 
> In IPv6 it becomes a bit sticky on all types of directs links due to the
> desire to reduce re-numbering impact of one V6 site on other V6 sites
> ("site" is a more appropriate term than "AS" here but you can mentally
> replace it with "AS" for the discussion at hand).  The IPv6 addressing
> architecture allows two sites to have own independent subnets on the same
> link. If one site (AS) injects a subnet administrated by another site in
> its IGP, it becomes dependent on that site address administration.  One
> solution would be to assign a separate DMZ address prefix that can't be
> renumbered by either site and is not globally advertised but it would
> require someone to administer such assignments. Another solution would be
> to refrain from injecting another site's address prefix into the local IGP.
> 
> >Curtis
> >
> Dimitry

Dimitry,

I think what is missing is the concept of a border interface which is
in neither "site".  An IX does not below to any of the 50 or so AS
that sit on that interface and would not be renumbered with the site.

You cannot renumber one end of a BGP connection and keep the BGP
connection up.  Even if you did renumber a "site" you'd have to keep
two sets of numbers and then reconfig one end to allow connections
to/from either sets of numbers and then reconfig the other end to
switch from the old address to the new.  This would be minimally
disruptive.  We're not talking about renumbering the secretarial pool
or a bunch of laptops here.  Routers running BGP have different
requirements to meet.

[ semi-unrelated: BTW- If we wanted to make this non-diruptive you'd
need some way to indicate a CEASE that would involve keeping the BGP
routes on a timer so another establish can be made.  I proposed
something a while back and it was rejected.  I see that now Cisco has
implemented a soft reset on a BGP peer (which will be soft on one end
only unless there is a delay before sending the cease long enough to
hit return on two routers before either one sees a cease from the
other).  Maybe it's time to revisit that idea since the vendor that
opposed it has implemented it. ]

Curtis

From: "John G. Scudder" <[email-masked]>
Subject: Re: WG last call
To: [email-masked] (Dino Farinacci)
Date: Thu, 25 Sep 1997 14:04:21 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Dino Farinacci writes:
...
>     There is no reason why the 4+ spec can't give an implementation suggestion
>     even though the authors may not want to do this.
...

True, there's no reason it can't give a suggestion, though I think
John Stewart and I raised some reasons we think the suggestion in
question is a bad one.  The current draft of course doesn't make
it a suggestion, it makes it a *requirement*, so it would need to
be revised in any case.

--John

--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (313) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

Date: Thu, 25 Sep 1997 10:25:21 -0700 (PDT)
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG last call
Sender: [email-masked]

>> It is in fact more convenient to have the NLRI at the end because
>> of the fact that import policy is prone to be based on (path atts,
>> NLRI), but this is hardly an insurmountable problem.

    Plus the simple fact that the NLRI is variable and the other attributes
    are really not. That is, before you start your table walk, all attribute
    lengths are known so you can put them in a buffer and just append the
    NLRI as you decide which routes have changed state.

    Traditional withdrawn routes make it a pain because they are in front
    of everything else. MP_UNREACH_NLRI will make this a little more
    convenient.

>> Remove ordering requirement -- I agree.  Resist changing the base
>> spec -- I agree.  Hopefully these points were clear from my original
>> message.  Resist making requirements of the type code -- sure, OK,
>> fine.  (Though since BGP4+ is a [neat] hack anyway, *I* think it
>> would be OK to augment it with one further hack, but whatever.)

    There is no reason why the 4+ spec can't give an implementation suggestion
    even though the authors may not want to do this.

Dino

Date: Thu, 25 Sep 1997 09:32:59 -0700
To: "John G. Scudder" <[email-masked]>
From: John W Stewart III <[email-masked]>
Subject: Re: WG last call
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

we agree .. it's the ordering requirement that i think is broken.
i understand the implementation convenience of having the nlri at
the end, so i don't disagree with that desire.  what i don't like
is the contradiction between the base spec and the MP draft.  so
my main point was to fix this contradiction by removing the order
requirement from the MP draft instead of reaching a compromise by
complicating the iana assignment .. i think it's a poor precedent
to set since we don't know what kinds of attributes are going to
come in the future

/jws

p.s.

>> implementations should be prepared for this to come anywhere in the path
>> attributes (yes that complicates control flow, but that's life in being
>> conservative in what you send)
>
>I think you mean "liberal in what you accept."

you're right, of course.  ooops, sorry

From: "John G. Scudder" <[email-masked]>
Subject: Re: WG last call
To: [email-masked] (John W Stewart III)
Date: Thu, 25 Sep 1997 11:14:59 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

John W Stewart III writes:
> "fixing" this by assigning the attribute a high value seems quite broken ..
> what happens for the next attribute that needs to be at the end? or second
> to the end?

So what's broken again, the "fix" or the idea of requiring an
attribute to be in the last position?  I think you have just argued
that it is the latter.  If so, I agree.  The "fix" is only broken
if the idea of requiring last position is broken.

> it seems to me that (1) the base spec requires that a receiver be able to
> get an UPDATE with stuff in any order, (2) existing implementations "need"
> nlri at the end only because the "real" v4 nlri field is at the end, (3) if

It is in fact more convenient to have the NLRI at the end because
of the fact that import policy is prone to be based on (path atts,
NLRI), but this is hardly an insurmountable problem.

> an implementation doesn't understand the MP_[UN]REACH_NLRI stuff then it
> makes no difference in what order the attribute appears and (3) altered

I disagree that it makes *no* difference.  In any implementation
which wants to keep path attributes in canonical order for storage
efficiency (which I would hope is all of them), getting an out-of-order
path attribute requires non-trivial extra work on behalf of the
receiver to sort it into order.  This is why it is rude to send
path attributes out of order (you know who you are).

But of course, any proper implementation can cope with this case,
and hey! it's only CPU.

> implementations should be prepared for this to come anywhere in the path
> attributes (yes that complicates control flow, but that's life in being
> conservative in what you send)

I think you mean "liberal in what you accept."

> so if people are concerned about the conflict in the "should" vs. "shall,"
> i suggested removing the ordering requirement of the MP_[UN]REACH_NLRI
> stuff but i'd resist both changing the base spec and making requirements of
> the iana assignment

Remove ordering requirement -- I agree.  Resist changing the base
spec -- I agree.  Hopefully these points were clear from my original
message.  Resist making requirements of the type code -- sure, OK,
fine.  (Though since BGP4+ is a [neat] hack anyway, *I* think it
would be OK to augment it with one further hack, but whatever.)

--John

--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (313) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

Date: Wed, 24 Sep 1997 18:20:34 -0700
To: "John G. Scudder" <[email-masked]>, [email-masked] (Yakov Rekhter)
From: John W Stewart III <[email-masked]>
Subject: Re: WG last call
Cc: [email-masked]
Sender: [email-masked]

"fixing" this by assigning the attribute a high value seems quite broken ..
what happens for the next attribute that needs to be at the end? or second
to the end?

it seems to me that (1) the base spec requires that a receiver be able to
get an UPDATE with stuff in any order, (2) existing implementations "need"
nlri at the end only because the "real" v4 nlri field is at the end, (3) if
an implementation doesn't understand the MP_[UN]REACH_NLRI stuff then it
makes no difference in what order the attribute appears and (3) altered
implementations should be prepared for this to come anywhere in the path
attributes (yes that complicates control flow, but that's life in being
conservative in what you send)

so if people are concerned about the conflict in the "should" vs. "shall,"
i suggested removing the ordering requirement of the MP_[UN]REACH_NLRI
stuff but i'd resist both changing the base spec and making requirements of
the iana assignment

my two cents

/jws

At 08:05 PM 9/24/97 -0400, John G. Scudder wrote:
>Yakov Rekhter writes:
>> At the last WG meeting we agreed to move 
>> draft-ietf-idr-bgp4-multiprotocol-00.txt to a Proposed Standard.
>> This is the WG last call. The deadline for comments is 9/24.
>
>Here are a couple:
>
>draft-ietf-idr-bgp4-multiprotocol-00.txt says:
>
>   When an UPDATE message carries the MP_REACH_NLRI attribute, the
>   attribute shall be placed after all other attributes in the message.
>
>(section 4, page 5).  On the other hand, draft-ietf-idr-bgp4-06.txt
>says:
>
>   The sender of an UPDATE message should order path attributes within
>   the UPDATE message in ascending order of attribute type.  The
>   receiver of an UPDATE message must be prepared to handle path
>   attributes within the UPDATE message that are out of order.
>
>(section 5, page 21).  The "shall" in the MP document is clearly
>at odds with the "should" in the BGP4 document.  This seems kind
>of broken.
>
>I understand the convenience value of having the NLRI occur last
>in the update.  There seems an easy way to provide this without
>having to mandate it -- just assign MP_REACH_NLRI a very high type
>code.  Then any implementation which complies with the "should" in
>the BGP4 document will send it last.
>
>Furthermore, any implementation which complies with the BGP4 document
>has to be prepared to receive the MP_REACH_NLRI in any position in
>the path atts anyway -- or is that being thrown out too?  Which 
>document takes precedence?
>
>If one insists on mandating that MP_REACH_NLRI come last, it still
>seems like a good idea to assign it a very high type code, so that
>implementations that actually think keeping stuff in order is a
>good idea are not unduly penalized.
>
>Also a minor editorial comment:  The use of the word "subsequent"
>for the SAFI is rather odd.  Perhaps "subsidiary"?  Or (my preference)
>just "sub"?
>
>Regards,
>
>--John
>
>--
>John G. Scudder                       email:  [email-masked]
>Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
>122 S. Main, Suite 280                fax:    (313) 669-8661
>Ann Arbor, MI  48104                  www:    http://www.ieng.com
>
>

From: "John G. Scudder" <[email-masked]>
Subject: Re: WG last call
To: [email-masked] (Yakov Rekhter)
Date: Wed, 24 Sep 1997 20:05:39 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

Yakov Rekhter writes:
> At the last WG meeting we agreed to move 
> draft-ietf-idr-bgp4-multiprotocol-00.txt to a Proposed Standard.
> This is the WG last call. The deadline for comments is 9/24.

Here are a couple:

draft-ietf-idr-bgp4-multiprotocol-00.txt says:

   When an UPDATE message carries the MP_REACH_NLRI attribute, the
   attribute shall be placed after all other attributes in the message.

(section 4, page 5).  On the other hand, draft-ietf-idr-bgp4-06.txt
says:

   The sender of an UPDATE message should order path attributes within
   the UPDATE message in ascending order of attribute type.  The
   receiver of an UPDATE message must be prepared to handle path
   attributes within the UPDATE message that are out of order.

(section 5, page 21).  The "shall" in the MP document is clearly
at odds with the "should" in the BGP4 document.  This seems kind
of broken.

I understand the convenience value of having the NLRI occur last
in the update.  There seems an easy way to provide this without
having to mandate it -- just assign MP_REACH_NLRI a very high type
code.  Then any implementation which complies with the "should" in
the BGP4 document will send it last.

Furthermore, any implementation which complies with the BGP4 document
has to be prepared to receive the MP_REACH_NLRI in any position in
the path atts anyway -- or is that being thrown out too?  Which 
document takes precedence?

If one insists on mandating that MP_REACH_NLRI come last, it still
seems like a good idea to assign it a very high type code, so that
implementations that actually think keeping stuff in order is a
good idea are not unduly penalized.

Also a minor editorial comment:  The use of the word "subsequent"
for the SAFI is rather odd.  Perhaps "subsidiary"?  Or (my preference)
just "sub"?

Regards,

--John

--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (313) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

From: Quaizar Vohra <[email-masked]>
Date: Wed, 24 Sep 1997 10:37:53 -0700 (PDT)
To: [email-masked] (Christian Huitema)
Cc: Quaizar Vohra <[email-masked]>, Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: (IPng 4530) Re: BGP and renumbering.. was /126 or /127 -- neither!
Sender: [email-masked]

Christian,
 > Dimitry, Quaizar,
 > 
 > One of the point that was agreed during the Munich meeting of IPv6 is that
 > Site Local addresses should not be used for EGP routing exchanges.  One of
 > the reasons is that nobody really knows what is a site, and that there is
 > absolutely zero reason to think that an AS is a single site.  (My
 > personnal feeling is that site local addresses should not be used *at
 > all*, at least in a connected site, because they have all the properties
 > of Net 10 addresses).  Think of what happens when a host or a router
 > belongs to several sites, which would be very easy in mobile environments.
 > 

I would rather say that use site local addresses as long as you can.
Use global addresses if you must. I fully agree with Dimitry that site
local addresses are useful in some situations and one of them being
BGP.

I may not be fully aware of all the bad properties of site-local
address, but one of them being pointed out is that an AS might
be composed of multiple sites (i.e. multiple instances of site-local
addressing). This happens for example when two organizations merge.

In that case a good solution would be to run EBGP among such sites
assigning a psuedo ASs to each such site and forming a confederation
of pseudo ASs which is represented as a single AS outside. Administering
the pseudo ASs is total an internal affair of the AS and is less
impacting then renumbering.

This does not imply that I am mandating this but I think that this will
a cause for less pain.

 > There are two valid lines that can be pursued if we dump site local
 > addresses.  The short term solution is "non renumbered addresses", i.e. an
 > address domain that is only used for interconnections, and is not
 > renumbered at the same time as either AS.  There are two costs to this
 > solutions; one needs to allocate these specific domains, which is an
 > administrative cost, and one needs to carry host routes within the IGP for
 > the remote routers, which is an operational cost.  Neither cost is
 > unbearable.

I don't think there is a a great need for such "non renmbered
addresses".  As I have pointed out that all one needs is to propogate
in the NEXT_HOP is the interface address of the local ebgp peer on the
IX link without loosing any of the functionality provided by the
NEXT_HOP attribute.  This means that I can even use addresses from
within the prefix assigned to the local ebgp speaker's AS.  Since
replacement of the NEXT_HOP can be done dynamically renumbering can at
worst cause a black hole in the small period when the igp route to the new
prefix of the IX link converges.

 > 
 > The longer term solution is to design renumbering support in the next EGP.
 >  Next-hop is a local parameter, which is not propagated in the global
 > Internet.  We should be able to update that parameter without triggering
 > Internet wide route swaps.  If we do that, the cost is some additional
 > complexity in BGP, but we will not need special addresses and we will also
 > not need to carry host routes in the IGP.
 > 
 > 
 > -- 
 > Christian Huitema
 Quaizar

Posted-Date: Wed, 24 Sep 1997 18:01:15 +0200 (MET DST)
Date: Wed, 24 Sep 1997 12:01:26 -0400
To: [email-masked] (Christian Huitema)
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither!
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 10:16 AM 9/24/97 -0400, Christian Huitema wrote:
>Dimitry, Quaizar,
>
>One of the point that was agreed during the Munich meeting of IPv6 is that
>Site Local addresses should not be used for EGP routing exchanges.

The issue was not examined enough in Munich to beside one way or another. I
for one, don't remember agreeing on this.

>One of
>the reasons is that nobody really knows what is a site, and that there is
>absolutely zero reason to think that an AS is a single site.  (My
>personnal feeling is that site local addresses should not be used *at
>all*, at least in a connected site, because they have all the properties
>of Net 10 addresses).  Think of what happens when a host or a router
>belongs to several sites, which would be very easy in mobile environments.
>

I'm not ready to say (even if it has crossed my mind ;) that use of the
local-scope addresses as the BGP next-hop will be sufficient in all
possible cases. Nevertheless I clearly can see and have demonstrated how
local-scope addresses can be used to our advantage in many non-exotic
cases. At this point I'm just asking to relax the v6 BGP rules imposed on
the NEXT_HOP address scope.  This way we don't have to resolve
philosophical or whatever dilemmas now but simply to experiment and see.
Too much to ask?

>There are two valid lines that can be pursued if we dump site local
>addresses.  The short term solution is "non renumbered addresses", i.e. an
>address domain that is only used for interconnections, and is not
>renumbered at the same time as either AS.  There are two costs to this
>solutions; one needs to allocate these specific domains, which is an
>administrative cost, and one needs to carry host routes within the IGP for
>the remote routers, which is an operational cost.  Neither cost is
>unbearable.

Correct... Except that sites that can perfectly get away with the
local-scope addresses don't have to bear that cost. Why to deny them that
possibility?
>

>The longer term solution is to design renumbering support in the next EGP.
> Next-hop is a local parameter, which is not propagated in the global
>Internet.  We should be able to update that parameter without triggering
>Internet wide route swaps.  If we do that, the cost is some additional
>complexity in BGP, but we will not need special addresses and we will also
>not need to carry host routes in the IGP.
>
>
>-- 
>Christian Huitema

Dimitry

To: [email-masked] (Christian Huitema)
Cc: [email-masked], [email-masked]
From: "Matt Crawford" <[email-masked]>
Subject: Re: (IPng 4530) Re: BGP and renumbering.. was /126 or /127 -- neither!
Date: Wed, 24 Sep 1997 10:22:11 -0500
Sender: [email-masked]

> One of the point that was agreed during the Munich meeting of IPv6 is that
> Site Local addresses should not be used for EGP routing exchanges.

Christian,

Once again, you make me wonder if we were at the same meeting.  I
find nothing remotely like your statement above in my memory, my
notes, or the minutes of the meeting I attended.  (That was in
Munich, Bavaria, Germany.  Perhaps there are two Munichs?)

However, I think I agree with the above, but not with

> (My personnal feeling is that site local addresses should not be
> used *at all*, at least in a connected site, because they have all
> the properties of Net 10 addresses).

and what follows.  However, that topic is out of scope for this
thread.
			Matt Crawford

From: "John G. Scudder" <[email-masked]>
Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither!
To: [email-masked] (Christian Huitema)
Date: Wed, 24 Sep 1997 10:50:32 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Christian Huitema writes:
...
>  Next-hop is a local parameter, which is not propagated in the global
> Internet.  We should be able to update that parameter without triggering
> Internet wide route swaps.  If we do that, the cost is some additional
> complexity in BGP, but we will not need special addresses and we will also
> not need to carry host routes in the IGP.
...

But this is how current BGP is specified, insofar as the NEXT_HOP is 
(or is supposed to be) rewritten at every AS boundary.  An EBGP speaker 
is supposed to only advertise a NEXT_HOP to an external peer such that 
"...the interface associated with the IP address of this [NEXT_HOP] 
shares a common subnet with both the local and remote BGP speakers."
This essentially mandates that the NEXT_HOP be an address on the IX.

It seems pretty clear to me that this restricts renumbering information
to only have to be propagated to the ASes immediately bordering a given
IX, not to the big-I Internet.  If some minimal level of operational 
care is taken, nobody else need see a single route hiccup as a result.

So I think this is not a problem.

Regards,

--John

--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (313) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

Date: Wed, 24 Sep 1997 10:16:38 -0400
From: [email-masked] (Christian Huitema)
To: Quaizar Vohra <[email-masked]>, Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither!
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Dimitry, Quaizar,

One of the point that was agreed during the Munich meeting of IPv6 is that
Site Local addresses should not be used for EGP routing exchanges.  One of
the reasons is that nobody really knows what is a site, and that there is
absolutely zero reason to think that an AS is a single site.  (My
personnal feeling is that site local addresses should not be used *at
all*, at least in a connected site, because they have all the properties
of Net 10 addresses).  Think of what happens when a host or a router
belongs to several sites, which would be very easy in mobile environments.

There are two valid lines that can be pursued if we dump site local
addresses.  The short term solution is "non renumbered addresses", i.e. an
address domain that is only used for interconnections, and is not
renumbered at the same time as either AS.  There are two costs to this
solutions; one needs to allocate these specific domains, which is an
administrative cost, and one needs to carry host routes within the IGP for
the remote routers, which is an operational cost.  Neither cost is
unbearable.

The longer term solution is to design renumbering support in the next EGP.
 Next-hop is a local parameter, which is not propagated in the global
Internet.  We should be able to update that parameter without triggering
Internet wide route swaps.  If we do that, the cost is some additional
complexity in BGP, but we will not need special addresses and we will also
not need to carry host routes in the IGP.

-- 
Christian Huitema

Posted-Date: Wed, 24 Sep 1997 09:55:47 -0400 (EDT)
Date: Wed, 24 Sep 1997 09:52:19 -0400
To: "John G. Scudder" <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 --
Cc: [email-masked] (Dimitry Haskin), [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 08:17 PM 9/23/97 -0400, John G. Scudder wrote:
>Dimitry Haskin writes:
>> I don't see how multiple sites can form a single IGP domain (aka AS).  
>  
>This is at least the second time this misconception has come up.
>There's no law of nature that says that a single AS will necessarily
>run a single IGP.  It would be awfully nice if this were always
>true in the real world, but sadly, it ain't.
>
Sorry that are confused you with AS in the parenthesis. I did it for the
sake of simplicity in the contexts of this discussion and first hesitated
to do that (this is why parenthesis) suspecting comments as yours.  All is
really important for this particular discussion that v6 sites need to be
interconnected with EGP, i.e. a given IBGP mesh can't span more than one v6
site.

>For better or for worse, IBGP can be, and is, made to work in an
>AS comprising multiple IGP domains.  All that really needs to happen
>is for all the participating routers to know how to resolve the
>next hops they receive.  The means for doing this can be quite messy.
>
>--John
> 
Dimitry

From: "Sean M. Doran" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: (IPng 4496) Re: BGP and renumbering.. was /126 or /127 --
Cc: [email-masked], [email-masked], [email-masked]
Date: 	Wed, 24 Sep 1997 03:04:12 -0700
Sender: [email-masked]

| Furthermore, if the floor is open for modifying the IBGP selection
| procedure, I'd like to fix this problem in the general case rather
| than applying further special-case kludges.  Do we really want to
| open this can of worms?

Yes!

The catharsis of the vendor-defined selection schemes
is long overdue.

Every iBGP implementation should allow people to configure
precisely the type of bullet with which they will shoot themselves
in the head when acquiring routes from iBGP, and from BGP in general.

Nothing, including choosing the most specific available prefix,
should be considered sacred in solving the general case.

Then the only things wrong with BGP would be a/ terminology and
b/ it's still a bag of vectors, no matter how you slice it.

	Sean.

P.S., yes I am serious, and no I don't preclude people suggesting
	"appropriate" selection criteria or even "default" selection
	criteria in various places like standards documents or manuals.

Posted-Date: Tue, 23 Sep 1997 20:25:38 -0400 (EDT)
Date: Tue, 23 Sep 1997 20:23:59 -0400
To: [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 03:13 PM 9/23/97 -0400, Curtis Villamizar wrote:
>
>I don't see interprovider interconnects using dynamic assigned
>addresses.  These things come up and to the extent possible they are
>not supposed to go down at all or change addresses.
>
I believe we agree on that. To boot, we'd like to achieve it without
granting permanent ownership of global-scope addresses or imposing undue
renumbering dependencies between independently administered sites.  To this
end, we try to utilize v6 local scope addresses -- something that is
missing in the V4 addressing architecture (well.. except v4 private use
addresses which are useless for the problem at hand).

>Curtis

Dimitry

From: "John G. Scudder" <[email-masked]>
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 --
To: [email-masked] (Dimitry Haskin)
Date: Tue, 23 Sep 1997 20:17:12 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Dimitry Haskin writes:
> I don't see how multiple sites can form a single IGP domain (aka AS).  
  
This is at least the second time this misconception has come up.
There's no law of nature that says that a single AS will necessarily
run a single IGP.  It would be awfully nice if this were always
true in the real world, but sadly, it ain't.
 
For better or for worse, IBGP can be, and is, made to work in an
AS comprising multiple IGP domains.  All that really needs to happen
is for all the participating routers to know how to resolve the
next hops they receive.  The means for doing this can be quite messy.

--John
 
--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (313) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

From: Quaizar Vohra <[email-masked]>
Date: Tue, 23 Sep 1997 17:17:00 -0700 (PDT)
To: Dimitry Haskin <[email-masked]>
Cc: Quaizar Vohra <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 --  neither! 
Sender: [email-masked]

 > >
 > >This brings up the issue whether an AS is composed of multiple sites
 > >(wrt to site-local addressing) or a single site ? Which suggests that
 > >either 
 > >
 > >a) A set of geographically distinct sites in the same AS share a single 
 > >   instance of site-local addressing. 
 > >b) Each site gets an AS. The sites join a higher level confederation AS.
 > >   The NEXT_HOP attributes can be readvertised only within a site and
 > >   changes as it changes as the route traverses to another site.
 > >c) We define another scope of IPv6 addresses.
 > >
 > 
 > Wow, I thought we were done with this Site vs AS confusion?!
 > 
 > For purpose of our discussions, a site is a collection of v6 interfaces
 > that get their addresses allocated from a single set (aggregate) of site
 > local addresses (SLA). That has little to do with geography. [It is
 > conceivable albeit probably unlikely for a site to consist from multiple
 > ASs but not vise versa.] As I stated earlier in the discussion, I don't see
 > how multiple sites can form a single IGP domain (aka AS).  You need to run
 > EGP (EBGP in this case) between sites. Naturally, since you running EBGP
 > between sites, the NEXT_HOP changes as routes cross site boundaries.
 > 
 > >Quaizar
 > 
 > Dimitry

Dimitry,
	I think you are right. This might mean that we might see multiple
levels of BGP running, i.e. confederations may become a common case in IPv6.
This also naturally aligns with multiple levels of heirarchy within
the IPv6 address.

Quaizar

Posted-Date: Tue, 23 Sep 1997 19:56:12 -0400 (EDT)
Date: Tue, 23 Sep 1997 19:54:31 -0400
To: Quaizar Vohra <[email-masked]>, Dimitry Haskin <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 --  neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 03:56 PM 9/23/97 -0700, Quaizar Vohra wrote:
>
>>From this whole excercise there seems to be another conclusion that
>in IPv6 global addresses should not be used anywhere within BGP's
>protocol machinary,i.e. as NEXT_HOPs, or for peering, if IPv6 addresses
>ever get used for peering. This will mean some amount of configuration
>on renumbering.
>
>If IPv6 addresses ever get used for peering then it should not use
>global IPv6 address because this will mean a lots of reconfiguration
>on renumbering within ebgp as well as ibgp. One should I guess use
>site-local addresses or some scoped form which is permanent with an
>AS. 
>
>This brings up the issue whether an AS is composed of multiple sites
>(wrt to site-local addressing) or a single site ? Which suggests that
>either 
>
>a) A set of geographically distinct sites in the same AS share a single 
>   instance of site-local addressing. 
>b) Each site gets an AS. The sites join a higher level confederation AS.
>   The NEXT_HOP attributes can be readvertised only within a site and
>   changes as it changes as the route traverses to another site.
>c) We define another scope of IPv6 addresses.
>

Wow, I thought we were done with this Site vs AS confusion?!

For purpose of our discussions, a site is a collection of v6 interfaces
that get their addresses allocated from a single set (aggregate) of site
local addresses (SLA). That has little to do with geography. [It is
conceivable albeit probably unlikely for a site to consist from multiple
ASs but not vise versa.] As I stated earlier in the discussion, I don't see
how multiple sites can form a single IGP domain (aka AS).  You need to run
EGP (EBGP in this case) between sites. Naturally, since you running EBGP
between sites, the NEXT_HOP changes as routes cross site boundaries.

>Quaizar

Dimitry

From: Quaizar Vohra <[email-masked]>
Date: Tue, 23 Sep 1997 15:56:30 -0700 (PDT)
To: Dimitry Haskin <[email-masked]>
Cc: Quaizar Vohra <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

>From this whole excercise there seems to be another conclusion that
in IPv6 global addresses should not be used anywhere within BGP's
protocol machinary,i.e. as NEXT_HOPs, or for peering, if IPv6 addresses
ever get used for peering. This will mean some amount of configuration
on renumbering.

If IPv6 addresses ever get used for peering then it should not use
global IPv6 address because this will mean a lots of reconfiguration
on renumbering within ebgp as well as ibgp. One should I guess use
site-local addresses or some scoped form which is permanent with an
AS. 

This brings up the issue whether an AS is composed of multiple sites
(wrt to site-local addressing) or a single site ? Which suggests that
either 

a) A set of geographically distinct sites in the same AS share a single 
   instance of site-local addressing. 
b) Each site gets an AS. The sites join a higher level confederation AS.
   The NEXT_HOP attributes can be readvertised only within a site and
   changes as it changes as the route traverses to another site.
c) We define another scope of IPv6 addresses.

Quaizar

 > 
 > You just made a very important observation. You are right: we can account
 > for the cost of an IX link without introducing a new attribute.  Let me
 > depict it so it is crisp and clear.
 > 
 >          1          1      
 >     A1 -----s1 B1---------B4
 >          IX                |
 >           5          1     |1    
 >     A2 -----s2 B2---------B3
 >          IX 
 > 
 > Routers A* are in one AS, routers B* are in another AS.  A1 and B1, and A2
 > and B2 exchange routes via EBGP respectively. When B1 readvertises A1's
 > routes to its internal BGP peers it uses a site-local address of its
 > interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a
 > site-local address of its interface on the IX link to A2, say s2, as the
 > NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the
 > same site-local addresses, s1 and s2, are specified as forwarding
 > addresses.  Both s1 and s2 are injected into IGP with the costs of their
 > respective link, i.e. 1 and 5 respectively. Now costs of the IX link are
 > fully accounted in route selection.
 > 
 > In the above diagram, if the same external network is reachable via either
 > border router, every B* sends packets to that external network via the
 > B1/A1 link as a lower cost path.
 > 
 > >Quaizar
 > 
 > Dimitry

Posted-Date: Tue, 23 Sep 1997 17:00:27 -0400 (EDT)
Date: Tue, 23 Sep 1997 16:56:59 -0400
To: Quaizar Vohra <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], Quaizar Vohra <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Quaizar,

>
>>From your's and Dimitry's reason I now understand better why
>it is difficult to introduce this new attribute. 
>
>We might still avoid passing the remote peer's global address
>into local AS by using Dimitry's proposal of using link-local
>addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with
>a AS-local IPV6 address before readvertising it in IBGP and
>ensuring that the cost of the IX link could also get accounted for.
>This could be done by using the AS-local IPV6 address assigned to
>the border router on the IX link in the NEXT_HOP attribute.
>

You just made a very important observation. You are right: we can account
for the cost of an IX link without introducing a new attribute.  Let me
depict it so it is crisp and clear.

         1          1      
    A1 -----s1 B1---------B4
         IX                |
          5          1     |1    
    A2 -----s2 B2---------B3
         IX 

Routers A* are in one AS, routers B* are in another AS.  A1 and B1, and A2
and B2 exchange routes via EBGP respectively. When B1 readvertises A1's
routes to its internal BGP peers it uses a site-local address of its
interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a
site-local address of its interface on the IX link to A2, say s2, as the
NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the
same site-local addresses, s1 and s2, are specified as forwarding
addresses.  Both s1 and s2 are injected into IGP with the costs of their
respective link, i.e. 1 and 5 respectively. Now costs of the IX link are
fully accounted in route selection.

In the above diagram, if the same external network is reachable via either
border router, every B* sends packets to that external network via the
B1/A1 link as a lower cost path.

>Quaizar

Dimitry

Date: Tue, 23 Sep 1997 15:55:02 -0400
From: Alan Hannan <[email-masked]>
To: Henk Smit <[email-masked]>
Cc: Paul Traina <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither!
Sender: [email-masked]

  Yes, having the ability to malleate aggregated (by peer) routes 
  somewhat independent of the internal L2/L3 topology is a good thing.

  If I've 3 peers on one router, and different levels of peering
  density within my network, I may with to make one of those three
  less preferable from the internals of the network.  Carrying the
  external next-hop in the IGP is one simple way to accomplish this.

  -alan

Thus spake Henk Smit ([email-masked])
 on or about Fri, Sep 19, 1997 at 09:40:31PM +0200:
> 
> Paul wrote:
> > In a past life, I've seen "set next-hop-self" used on ibgp peers
> > in configs by Sprint, MCI, and UUNET to specificly avoid carrying
> > the "DMZ" network's routing information in their IGP.
> 
>   Just this week I got a request from one of those for a feature
>  in our ISIS implementation, related to this. Supposedly they
>  want to be able to influence IGP metrics to the BGP nexthops.
>  This will enable them to fine-tune route selection when doing
>  shortest-exit routing. I was told that because of the growth
>  of private peerings between the large ISPs, there is more need
>  for this kind of fine-tuning.
> 
>   So it might be that carrying original eBGP next-hop info inside
>  the iBGP-mesh will be more important in the near future. Maybe
>  one of the large ISPs can comment on this ?
> 
>     Henk.

To: Dimitry Haskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Tue, 23 Sep 1997 15:13:13 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.32.19970923123217.0068b130@pobox>, Dimitry Haskin writes:
> Curtis,
> 
> >
> >The remote AS routers are on direct interfaces of your own router and
> >normally direct interfaces are included in the IGP.  The only case
> >where this gets a bit sticky is PTP links in BSD/gated style where the
> >two ends of the PTP link are not restricted to the same subnet.  This
> >is still OK if the IGP includes both ends of the PTP link to be in the
> >IGP.  It only a problem for unnumbered PTP links (which don't see much
> >use in this sort of application since other things like SNMP
> >monitoring get unhappy with no address).
> >
> 
> In IPv6 it becomes a bit sticky on all types of directs links due to the
> desire to reduce re-numbering impact of one V6 site on other V6 sites
> ("site" is a more appropriate term than "AS" here but you can mentally
> replace it with "AS" for the discussion at hand).  The IPv6 addressing
> architecture allows two sites to have own independent subnets on the same
> link. If one site (AS) injects a subnet administrated by another site in
> its IGP, it becomes dependent on that site address administration.  One
> solution would be to assign a separate DMZ address prefix that can't be
> renumbered by either site and is not globally advertised but it would
> require someone to administer such assignments. Another solution would be
> to refrain from injecting another site's address prefix into the local IGP.

Summarizing what you said, there are two cases:

  1.  two site addresses on the same media.

    BGP sender or receiver replaces next-hop.  (not recommended for
    large provider exchanges)

 2.  fixed subnet

    same as IPv4.  (strongly recommended)

I added the stuff in parens.

I don't see interprovider interconnects using dynamic assigned
addresses.  These things come up and to the extent possible they are
not supposed to go down at all or change addresses.

Curtis

From: "John G. Scudder" <[email-masked]>
Subject: Re: (IPng 4496) Re: BGP and renumbering.. was /126 or /127 --
To: [email-masked] (Dimitry Haskin)
Date: Tue, 23 Sep 1997 14:54:56 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Dimitry Haskin writes:
...
> I don't agree that it will be necessary to use the new BGP attribute in all
> IGPs -- at least no more that you'd used MED or LocPref outside of IBGP.
> This would be normally used for route selection when IBGP "hack" is on and
> external routes are not injected into IGP.
...

Exactly.  The proposed attribute would change the route selection
procedure.  Allow me to note that the IBGP route selection procedure
is probably the biggest interoperability landmine in BGP.  We've
had enough problems with it already without putting yet *another*
special case in.

If such an attribute *were* to be introduced, I would have a large
cow if it wasn't mandatory for all (IPv6) BGPs to handle it in an
interoperable way (which probably means identically).  Since there's
no way that people are going to simultaneously mass-upgrade all
their IPv4 BGPs to accomodate this new feature, that means we'd
have to have two divergent selection procedures -- one for IPv4,
one for IPv6.  This is, at best, aesthetically unappealing.

Furthermore, if the floor is open for modifying the IBGP selection
procedure, I'd like to fix this problem in the general case rather
than applying further special-case kludges.  Do we really want to
open this can of worms?

Regards,

--John

--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (313) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

Posted-Date: Tue, 23 Sep 1997 14:33:55 -0400 (EDT)
Date: Tue, 23 Sep 1997 14:30:28 -0400
To: [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4496) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 01:24 PM 9/23/97 -0400, Curtis Villamizar wrote:
>
>In message <[email-masked]>, Quaizar Vohra
writes:
>>  > 
>>  > So Far the only use of Global addresses in the NEXT_HOP attribute in
>>  > an ebgp update I have understood from all this discussion is to
>>  > be able to readvertise it to the ibgp peer so that they could
>>  > account for the cost of the IX link between the ASs thru the IGP
>>  > metric for the route to that global nexthop. Is that right ?
>>  > 
>> 
>> If this is right then why not introduce another attribute which
>> carries the link cost of the IX link/path. 
>
>Because the protocol already covers this case.  Why remove the
>functionality and put it some other place.  You would then have to
>determine the total cost by adding the IGP cost to the new BGP
>attribute.  This would be true for all IGPs and a pain to implement.
>
I don't agree that it will be necessary to use the new BGP attribute in all
IGPs -- at least no more that you'd used MED or LocPref outside of IBGP.
This would be normally used for route selection when IBGP "hack" is on and
external routes are not injected into IGP.

>> For IPv6 this will atleast remove the need for administering
>> assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6
>> addresses to the ebgp peers on their IX interfaces. 
>> 
>> Quaizar
>
>BGP is not going to be used on dynamicly assigned subnets.  Period.
>No matter how much the IPv6 research community loves the feature.
>
>Provider routers don't even run DNS so their reliability is not
>reduced by a dependency on something external to the router.
>
The point it that in many cases it would be beneficial not assign
global-scope addresses to external BGP links at all. Unlike v4, v6 has
different scope addresses that would be nice to take advantage of to reduce
administrative and renumbering burdens. In case of EBGP, link-local
addresses may be sufficient enough.

>Curtis
>
Dimitry

From: Quaizar Vohra <[email-masked]>
Date: Tue, 23 Sep 1997 11:32:08 -0700 (PDT)
To: [email-masked]
Cc: Quaizar Vohra <[email-masked]>, [email-masked], [email-masked]
Subject: (IPng 4513) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

Curtis Villamizar writes:
 > 
 > In message <[email-masked]>, Quaizar Vohra writes:
 > >  > 
 > >  > So Far the only use of Global addresses in the NEXT_HOP attribute in
 > >  > an ebgp update I have understood from all this discussion is to
 > >  > be able to readvertise it to the ibgp peer so that they could
 > >  > account for the cost of the IX link between the ASs thru the IGP
 > >  > metric for the route to that global nexthop. Is that right ?
 > >  > 
 > > 
 > > If this is right then why not introduce another attribute which

 > 
 > Because the protocol already covers this case.  Why remove the
 > functionality and put it some other place.  You would then have to
 > determine the total cost by adding the IGP cost to the new BGP
 > attribute.  This would be true for all IGPs and a pain to implement.
 > 

Well my point was to avoid passing remote peers address in the
NEXT_HOP attr, into IBGP and IGP of the local AS. Which would mean
loss of functionality, i.e. unable to account for the cost of the IX
link.  Hence I introduced this new attribute.

Dimitry's previous mails explained why we want to avoid passing
remote peer's global IPv6 address into IBGP and IGP of the local AS.

 > > For IPv6 this will atleast remove the need for administering
 > > assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6
 > > addresses to the ebgp peers on their IX interfaces. 
 > > 
 > > Quaizar
 > 
 > BGP is not going to be used on dynamicly assigned subnets.  Period.
 > No matter how much the IPv6 research community loves the feature.
 > 
 > Provider routers don't even run DNS so their reliability is not
 > reduced by a dependency on something external to the router.
 > 
 > Curtis

My point was not at all to be able to run BGP using dynamically
assigned subnets. 

>From your's and Dimitry's reason I now understand better why
it is difficult to introduce this new attribute. 

We might still avoid passing the remote peer's global address
into local AS by using Dimitry's proposal of using link-local
addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with
a AS-local IPV6 address before readvertising it in IBGP and
ensuring that the cost of the IX link could also get accounted for.
This could be done by using the AS-local IPV6 address assigned to
the border router on the IX link in the NEXT_HOP attribute.

Quaizar

To: Quaizar Vohra <[email-masked]>
cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4496) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Tue, 23 Sep 1997 13:24:32 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Quaizar Vohra writes:
>  > 
>  > So Far the only use of Global addresses in the NEXT_HOP attribute in
>  > an ebgp update I have understood from all this discussion is to
>  > be able to readvertise it to the ibgp peer so that they could
>  > account for the cost of the IX link between the ASs thru the IGP
>  > metric for the route to that global nexthop. Is that right ?
>  > 
> 
> If this is right then why not introduce another attribute which
> carries the link cost of the IX link/path. 

Because the protocol already covers this case.  Why remove the
functionality and put it some other place.  You would then have to
determine the total cost by adding the IGP cost to the new BGP
attribute.  This would be true for all IGPs and a pain to implement.

> For IPv6 this will atleast remove the need for administering
> assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6
> addresses to the ebgp peers on their IX interfaces. 
> 
> Quaizar

BGP is not going to be used on dynamicly assigned subnets.  Period.
No matter how much the IPv6 research community loves the feature.

Provider routers don't even run DNS so their reliability is not
reduced by a dependency on something external to the router.

Curtis

To: Quaizar Vohra <[email-masked]>
cc: Pedro Marques <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Tue, 23 Sep 1997 13:06:16 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Quaizar Vohra writes:
> 
> So Far the only use of Global addresses in the NEXT_HOP attribute in
> an ebgp update I have understood from all this discussion is to
> be able to readvertise it to the ibgp peer so that they could
> account for the cost of the IX link between the ASs thru the IGP
> metric for the route to that global nexthop. Is that right ?
> 
> Can't you account for the cost of IX link in the local pref before
> readvertising the route into ibgp ?
> 
> Please soneone clear up my ignorance ?
> 
> Thanks,
> Quaizar

The IGP cost would have part of your network aiming at one IX and
another aiming at another IX (ie: shortest out).  Using local-pref
would aim all the traffic at one IX.

Local-pref is generally set per prefix per AS and IGP shortest path
used to get to the nearest peering point.

Curtis

Posted-Date: Tue, 23 Sep 1997 12:36:00 -0400 (EDT)
Date: Tue, 23 Sep 1997 12:32:30 -0400
To: [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Curtis,

>
>The remote AS routers are on direct interfaces of your own router and
>normally direct interfaces are included in the IGP.  The only case
>where this gets a bit sticky is PTP links in BSD/gated style where the
>two ends of the PTP link are not restricted to the same subnet.  This
>is still OK if the IGP includes both ends of the PTP link to be in the
>IGP.  It only a problem for unnumbered PTP links (which don't see much
>use in this sort of application since other things like SNMP
>monitoring get unhappy with no address).
>

In IPv6 it becomes a bit sticky on all types of directs links due to the
desire to reduce re-numbering impact of one V6 site on other V6 sites
("site" is a more appropriate term than "AS" here but you can mentally
replace it with "AS" for the discussion at hand).  The IPv6 addressing
architecture allows two sites to have own independent subnets on the same
link. If one site (AS) injects a subnet administrated by another site in
its IGP, it becomes dependent on that site address administration.  One
solution would be to assign a separate DMZ address prefix that can't be
renumbered by either site and is not globally advertised but it would
require someone to administer such assignments. Another solution would be
to refrain from injecting another site's address prefix into the local IGP.

>Curtis
>
Dimitry

To: Paul Ferguson <[email-masked]>
cc: Pedro Marques <[email-masked]>, Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Tue, 23 Sep 1997 11:38:02 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Paul Ferguson wri
tes:
> At 05:49 PM 9/19/97 -0700, Pedro Marques wrote:
> 
> >
> >Second, you don't inject exterior routes into IGP. It doesn't scale.
> >
> 
> Bingo. Best current practice.  ;-)
> 
> - paul

It currently doesn't scale but I think this is a matter of IGP routing
implementation quality.  Flooding ASEs can be more efficient than full
mesh BGP or the approximations of flooding like route reflectors.
There is still an AS path truncation problem but that can be solved by
the long since expired LSA type-8 idea of Dennis Fergusson which would
today be done with an opaque LSA if anyone did it.  It would also help
to have better throttling on the flooding than is currently available
in OSPF (or ISIS) though OSPF LSA flooding doing sliding window and
slow start and congestion avoidance along with RTO, cwnd, ssthresh,
and all that might still be overkill.  (OSPF LSA SACK options? :)

Curtis

To: Pedro Marques <[email-masked]>
cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Tue, 23 Sep 1997 11:25:00 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Pedro Marques writes
:
>     >> 
>     Dimitry> You extended IGP to include remote AS routers. I believe
>     Dimitry> that a similar effect can be achieved if the cost of
>     Dimitry> reaching the remote AS is included into the ASE metric
>     Dimitry> when an external route is injected into IGP.
> 
> No...
> 
> First "extending the IGP to include remote AS routers" is evil... the whole
> concept of AS is exactly where the IGP boundaries are. Also i sincerely
> doubt any reasonable network operator would accept to participate in
> someone else's IGP...

It is standard practice.  I don't know of any provider who does not
include the AS boundary interface in the IGP.

> Second, you don't inject exterior routes into IGP. It doesn't scale.

Just the subnet that your own interface is sitting on which includes
the address of the peer router, not all routes announced by a peer.

> Third, if what you want is to consider the path to the ingress point of
> the external AS, why do anything else that use today's solution: don't
> change the nexthop. There is absolutely no problem with what we do
> today. If you eliminate the ability of annoucing the unmodified nexthop
> into IBGP you do indeed create a problem.

Unless I'm mistaken, you and Dimitry are in violent agreement.

Curtis

To: Dimitry Haskin <[email-masked]>
cc: Paul Traina <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Tue, 23 Sep 1997 11:19:31 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.1.32.19970919200111.006b1f60@pobox>, Dimitry Haskin writes:
> >
> >		A1 --- OC192 --- B1 --- OC192 ---
> >					         >---- B3
> >		A2 --- 9600b --- B2 --- OC192 ---
> >
> >
> >This makes a big difference if you have a high speed internal backbone
> >with two peer connections to a remote AS, one on a fast link, the other
> >on a slow link.  You really want to take into account the cost of reaching
> >the remote AS, not just the cost of reaching the edge of your AS.
> >
> You extended IGP to include remote AS routers. I believe that a similar
> effect can be achieved if the cost of reaching the remote AS is included
> into the ASE metric when an external route is injected into IGP.
> 
> Dimitry

The remote AS routers are on direct interfaces of your own router and
normally direct interfaces are included in the IGP.  The only case
where this gets a bit sticky is PTP links in BSD/gated style where the
two ends of the PTP link are not restricted to the same subnet.  This
is still OK if the IGP includes both ends of the PTP link to be in the
IGP.  It only a problem for unnumbered PTP links (which don't see much
use in this sort of application since other things like SNMP
monitoring get unhappy with no address).

Curtis

To: Dimitry Haskin <[email-masked]>
cc: Pedro Marques <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither! 
Date: Tue, 23 Sep 1997 11:02:28 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <3.0.32.19970919161831.0068fbe8@pobox>, Dimitry Haskin writes:
> >
> >3) We loose the ability to include the metric of the interconnection link
> >in the BGP best path decision.
> >
> Why is that?

Peer A is off the FDDI, peer B is a T1 hop away.  The BGP route to A
needs to have a low metric and the route to B needs a high one.  One
mtric to the box doesn't do the job.

I personally think that if you want to propogate a NEXT-HOP beyond an
AS boundary (for example: take the next-hop from across your IBGP and
paas that to EBGP and have that passed across an IBGP) for the purpose
of level 2 shorcuts, you need to do this with an attribute rather than
use the NEXT-HOP field.  Keep the NEXT-HOP local to the IGP.

Curtis

Posted-Date: Tue, 23 Sep 1997 10:11:35 -0400 (EDT)
Date: Tue, 23 Sep 1997 10:08:05 -0400
To: Quaizar Vohra <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 04:04 PM 9/22/97 -0700, Quaizar Vohra wrote:
> > 
> > So Far the only use of Global addresses in the NEXT_HOP attribute in
> > an ebgp update I have understood from all this discussion is to
> > be able to readvertise it to the ibgp peer so that they could
> > account for the cost of the IX link between the ASs thru the IGP
> > metric for the route to that global nexthop. Is that right ?
> > 
>
>If this is right then why not introduce another attribute which
>carries the link cost of the IX link/path. 
>
This might be a sound idea assuming it is generated by border routers when
routes are re-advertised to internal peers.  For this to work, the route
selection rules must provide for consistent use of this new metric by all
IBGP peers, e.g. require to sum it with the internal IGP cost to the
address provided in the NEXT_HOP attribute. If it is not done, forwarding
loops may form.

>For IPv6 this will atleast remove the need for administering
>assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6
>addresses to the ebgp peers on their IX interfaces. 
>
>Quaizar

Dimitry

Posted-Date: Mon, 22 Sep 1997 19:09:35 -0400 (EDT)
Date: Mon, 22 Sep 1997 19:06:05 -0400
To: "Matt Crawford" <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 05:20 PM 9/22/97 -0500, Matt Crawford wrote:
>The situation so far:
>
>The Bates/Chandra/Katz/Rekhter BGP4+ draft of 7/97 dictates that an
>IPv6 BGP speaker puts both a global and a link-local address in the
>Next Hop field if & only if the peer, call it "P", shares a subnet
>with the entity so identified.
>
>I've suggested that point-to-point links not be assigned a subnet
>prefix, but that the endpoints be assigned their global addresses (if
>any, I suppose) independently by their respective operators.
>
>Some network operators would have that peer P rewrite the next-hop to
>point to itself.  Others would rather keep the Next Hop unchanged,
>but there are concerns about what might have to be dragged into the
>IGP.
>
>Suppose that BGP on the IPv6 router P gives you the option of
>injecting the advertised global next-hop address as a host route as
>well as the option of rewriting it.  Does that cover all the bases?

Major BGP implementations give you option of rewriting the advertised
global next-hop when re-advertising routes to internal peers (even if it is
not endorsed by the BGP RFC, as far as I remember). But the point is that
it should be allowed for the advertising external peer not to advertise the
global next-hop at all since it may not one assigned to its endpoint. A
link-local next-hop should be sufficient if receiving peer rewrite the
next-hop to point to itself (preferably with a site-local address).

>Can IBGP carry this usefully (I suspect not, but I'm quite an
>inexpert BGP user), or does it need to go into the IGP of P's system?
>
>				Matt
>
Dimitry

From: Quaizar Vohra <[email-masked]>
Date: Mon, 22 Sep 1997 16:04:51 -0700 (PDT)
To: Quaizar Vohra <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: (IPng 4496) Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

 > 
 > So Far the only use of Global addresses in the NEXT_HOP attribute in
 > an ebgp update I have understood from all this discussion is to
 > be able to readvertise it to the ibgp peer so that they could
 > account for the cost of the IX link between the ASs thru the IGP
 > metric for the route to that global nexthop. Is that right ?
 > 

If this is right then why not introduce another attribute which
carries the link cost of the IX link/path. 

For IPv6 this will atleast remove the need for administering
assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6
addresses to the ebgp peers on their IX interfaces. 

Quaizar

To: [email-masked], [email-masked]
From: "Matt Crawford" <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Mon, 22 Sep 1997 17:20:38 -0500
Sender: [email-masked]

The situation so far:

The Bates/Chandra/Katz/Rekhter BGP4+ draft of 7/97 dictates that an
IPv6 BGP speaker puts both a global and a link-local address in the
Next Hop field if & only if the peer, call it "P", shares a subnet
with the entity so identified.

I've suggested that point-to-point links not be assigned a subnet
prefix, but that the endpoints be assigned their global addresses (if
any, I suppose) independently by their respective operators.

Some network operators would have that peer P rewrite the next-hop to
point to itself.  Others would rather keep the Next Hop unchanged,
but there are concerns about what might have to be dragged into the
IGP.

Suppose that BGP on the IPv6 router P gives you the option of
injecting the advertised global next-hop address as a host route as
well as the option of rewriting it.  Does that cover all the bases?
Can IBGP carry this usefully (I suspect not, but I'm quite an
inexpert BGP user), or does it need to go into the IGP of P's system?

				Matt

From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither!
To: [email-masked] (Quaizar Vohra)
Date: Mon, 22 Sep 1997 13:29:55 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Quaizar Vohra writes:
...
> Can't you account for the cost of IX link in the local pref before
> readvertising the route into ibgp ?
...

Not if you want to be able to share load between the high-cost and
low-cost links.  If you use localpref to express your link preference,
all traffic will be sucked to the better-cost link.  If you use
IGP cost, traffic will *tend* to be sucked to the better-cost link,
but traffic which is topologically much further from the better-cost
link than it is from the worse-cost link will go to the worse-cost
one.

Localpref is a much heavier hammer than IGP metric.

Regards,

--John

--
John G. Scudder                       email:  [email-masked]
Internet Engineering Group, LLC       phone:  (313) 213-4939 ext 14
122 S. Main, Suite 280                fax:    (313) 669-8661
Ann Arbor, MI  48104                  www:    http://www.ieng.com

To: "Sean M. Doran" <[email-masked]>
cc: Paul Ferguson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Mon, 22 Sep 1997 13:24:34 -0400
From: Erik Sherk <[email-masked]>
Sender: [email-masked]

> Paul Ferguson <[email-masked]> writes:
> 
> > But Sean, wouldn't you agree that confederations are of
> > the implementation genre that is waning? By asking this,
> > I in no way mean to imply that we should ignore it's
> > existence, but rather, I do notice that the instance
> > of confederations is one which is a path much less taken
> > these days.
> 
> Sure, but what's your point?
> 
> One of the advantages never really used much wrt
> confederations was that it provided some additional
> information upon which one could make some sort of route
> selection.
> 
> There were three reasons why I think this never got used:
> 
> 	-- people are and were still used to AS path length 
>            as a primary metric for path selection
> 
> 	-- people had objections to the extra information
> 	   being visible (aesthetic or privacy minded
>            objections principally)
> 
> 	-- without a connectivity map to explain the
> 	   relation of the confederated ASes to one
> 	   another and to the BRs, there is no way
>            to take advantage of the extra information,
> 	   and hand-drawn ASCII maps designed to assist
> 	   in manual configuration didn't seem to help much
> 
> Moreover, as a consequence of the middle point, pst coded
> up AS-excising code which eliminated the extra information
> from the AS path, and this was deployed in most places (I
> had to fight with him to have a way to turn this
> AS-excising code off). 
> 
> In parallel, an easier-to-configure but vastly more
> complicated (and initially, very buggy) approach was
> deployed elsewhere.
> 
> Since the route reflector code became stable, and the
> confederation scheme no longer made confederated ASes
> visible to the outside world, the principal diffentiator
> became ease of configuration and maintenance, and the
> reflector code wins there.
> 
> I am not sure that the use of confederations is waning.
> Since there is no way of determining whether someone is
> using AS-excising confederation code except by giving them
> a release of IOS that breaks it, or by asking them more
> politely than that, the only evidence of "waning" is
> simply that SprintLink recently has cut over to the route
> reflector scheme, probably for the reasons outlined in the
> previous paragraph.

Right. UUNET still uses Confederations in AS701. Due to pressure
from one of our vendors, we looked hard at moving to route reflection.
We decided not to transition because confederations gave us much more
topological flexibility. Route reflection imposes a fairly strict 
hierarchy on you. There have been some recent changes to the implementation
that relax this a little, however.

Erik
 
> However, returning to the reason I brought up
> confederations in the first place, remember that the
> original idea was simply not to rewrite the next-hops and
> MEDs when talking to an eBGP peer.   This can be useful in
> cases where the non-rewritten next-hops can be resolved
> through an IGP.
> 
> This would be useful in particular cases now, in fact, if
> one could share an IGP among two or more ASes under
> different administrative control.
> 
> 	Sean.
> 
> 

From: Quaizar Vohra <[email-masked]>
Date: Mon, 22 Sep 1997 10:10:59 -0700 (PDT)
To: Pedro Marques <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

So Far the only use of Global addresses in the NEXT_HOP attribute in
an ebgp update I have understood from all this discussion is to
be able to readvertise it to the ibgp peer so that they could
account for the cost of the IX link between the ASs thru the IGP
metric for the route to that global nexthop. Is that right ?

Can't you account for the cost of IX link in the local pref before
readvertising the route into ibgp ?

Please soneone clear up my ignorance ?

Thanks,
Quaizar

To: [email-masked]
Subject: Re: proposed change to MP_UNREACH_NLRI 
Date: Mon, 22 Sep 97 09:28:20 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

> It have been pointed out that the Unfeasible Routes Length field
> in the MP_UNREACH_NLRI attribute isn't necessary - the length
> of the attribute is sufficient. So, in the absence of any objections
> I'd like to propose that we'll take out the Unfeasible Routes
> Length field.

Let me also suggest that we'll take out the Network Layer Reachability
Information Length field from the MP_REACH_NLRI attribute.

Yakov.

To: [email-masked]
Subject: proposed change to MP_UNREACH_NLRI
Date: Mon, 22 Sep 97 05:04:09 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

It have been pointed out that the Unfeasible Routes Length field
in the MP_UNREACH_NLRI attribute isn't necessary - the length
of the attribute is sufficient. So, in the absence of any objections
I'd like to propose that we'll take out the Unfeasible Routes
Length field.

Comments ???

Yakov.

Date: Mon, 22 Sep 1997 00:48:02 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Dennis Ferguson <[email-masked]>
Cc: [email-masked] (Pedro Marques), Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

>>>>> "Dennis" == Dennis Ferguson <[email-masked]> writes:

    Dennis> I'm having some difficulty figuring out the `need' for two
    Dennis> next hop addresses (and the near 40 bytes of next hop gorp
    Dennis> in every single eBGP advertisement) at all.

The need for two addresses (a non-linklocal and a linklocal) on peering
connections on a directly multi-acess connected link is that IPv6 requires
link-local addresses for ICMP redirects and from exporting and importing
into IGPs.

Puting it in another way, what you should install in a IPv6 routing table
as nexthops is:
o for recursive routes: non-linklocal addresses.
o for non-recursive routes: linklocal addresses.

Having the destintion in the protocol between direct and non-direct connections
is bad enought. I think we don't want to include in also the distintion
between multiple access networks and non-multiple access networks.

And yes, i do dislike this solution. But it is the only i got than can
support all the corner cases.

    Dennis>   If you are
    Dennis> advertising the global addresses via IBGP other routers of
    Dennis> yours attached to the same wire which learn the routes
    Dennis> third party will need to install the global addresses in
    Dennis> their forwarding tables as next hops, so the global
    Dennis> addresses must be usable as next hops.
Agreed.

[snip]

    Dennis> Sending
    Dennis> two next hops all the time only seems to ensure that you
    Dennis> maximize the trouble of making address changes in all
    Dennis> cases.

The problem is that you need the linklocals when you are using the globals
on a directly connected link.

  Pedro.

To: [email-masked] (Pedro Marques)
cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Sun, 21 Sep 1997 21:48:03 -0700
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]

> Passing just *one* address in a direct ebgp peering makes you loose
> functionality compared to ipv4 bgp. You do need to pass *two* addresses:
> a link local that your peer can install in it's forwarding table and
> a non-link local that the other BGP capable routers of the foreign AS
> can route to. The non-locally scoped address can be completly ignore
> if the other AS is configured to do so, but a border router can not
> refrain from annoucing it.

I'm having some difficulty figuring out the `need' for two next hop
addresses (and the near 40 bytes of next hop gorp in every single eBGP
advertisement) at all.  If you are advertising the global addresses
via IBGP other routers of yours attached to the same wire which learn
the routes third party will need to install the global addresses in their
forwarding tables as next hops, so the global addresses must be usable
as next hops.  Furthermore, if the addresses on the wire are changed
(and limiting the damage caused by address changes is the only reason
I'm aware of for avoiding global addresses as next hops) then it is
already required that (a) the peer readvertise every route he sent
to you, listing the new global next hops, (b) if you've been readvertising
the next hops via IBGP, that you reflood each and every one of these
announcements to your internal peers after the appropriate adjustments
to your IGP advertisement, and (c) if there are other routers on the same
wire that were learning the routes third party via IBGP, that they
readjust the next hops in their forwarding table.  The additional
effort of fixing your own forwarding table as well hardly seems to add
much more pain to an already painful process, and might even be made up
for somewhat by the opportunity of avoiding the pain of having to parse
not one but two big ugly next hops out of every eBGP advertisement you
receive forever more.

It seems to me you can do everything you need with a single next hop.  If
you need to readvertise the third-party next hops into IBGP get him to
send you global-scope next hops and you'll unavoidably have some work
to do if his addresses change (almost all of which you would have had to do
in any case), otherwise get him to send you link-local next hops and you
and he won't have to do anything at all if the addresses change.  Sending
two next hops all the time only seems to ensure that you maximize the
trouble of making address changes in all cases.

Dennis Ferguson

To: Paul Ferguson <[email-masked]>
Cc: "Sean M. Doran" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither!
From: "Sean M. Doran" <[email-masked]>
Date: 	20 Sep 1997 21:33:58 -0400
Lines: 71
Sender: [email-masked]

Paul Ferguson <[email-masked]> writes:

> But Sean, wouldn't you agree that confederations are of
> the implementation genre that is waning? By asking this,
> I in no way mean to imply that we should ignore it's
> existence, but rather, I do notice that the instance
> of confederations is one which is a path much less taken
> these days.

Sure, but what's your point?

One of the advantages never really used much wrt
confederations was that it provided some additional
information upon which one could make some sort of route
selection.

There were three reasons why I think this never got used:

	-- people are and were still used to AS path length 
           as a primary metric for path selection

	-- people had objections to the extra information
	   being visible (aesthetic or privacy minded
           objections principally)

	-- without a connectivity map to explain the
	   relation of the confederated ASes to one
	   another and to the BRs, there is no way
           to take advantage of the extra information,
	   and hand-drawn ASCII maps designed to assist
	   in manual configuration didn't seem to help much

Moreover, as a consequence of the middle point, pst coded
up AS-excising code which eliminated the extra information
from the AS path, and this was deployed in most places (I
had to fight with him to have a way to turn this
AS-excising code off). 

In parallel, an easier-to-configure but vastly more
complicated (and initially, very buggy) approach was
deployed elsewhere.

Since the route reflector code became stable, and the
confederation scheme no longer made confederated ASes
visible to the outside world, the principal diffentiator
became ease of configuration and maintenance, and the
reflector code wins there.

I am not sure that the use of confederations is waning.
Since there is no way of determining whether someone is
using AS-excising confederation code except by giving them
a release of IOS that breaks it, or by asking them more
politely than that, the only evidence of "waning" is
simply that SprintLink recently has cut over to the route
reflector scheme, probably for the reasons outlined in the
previous paragraph.

However, returning to the reason I brought up
confederations in the first place, remember that the
original idea was simply not to rewrite the next-hops and
MEDs when talking to an eBGP peer.   This can be useful in
cases where the non-rewritten next-hops can be resolved
through an IGP.

This would be useful in particular cases now, in fact, if
one could share an IGP among two or more ASes under
different administrative control.

	Sean.

To: Henk Smit <[email-masked]>
Cc: [email-masked] (Paul Traina), [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither!
From: "Sean M. Doran" <[email-masked]>
Date: 	20 Sep 1997 21:01:05 -0400
Lines: 33
Sender: [email-masked]

Henk Smit <[email-masked]> writes:

>  I was told that because of the growth of private
>  peerings between the large ISPs, there is more need for
>  this kind of fine-tuning.  

The growth in the number of borders between any two ASes
exposes the poverty of BGP in many ways; this is simply
one of them.

>  So it might be that carrying original eBGP next-hop info inside
>  the iBGP-mesh will be more important in the near future. Maybe
>  one of the large ISPs can comment on this ?

Right now you get this big blob of reachable things being
advertised in eBGP, assuming MEDs aren't being exchanged.
(If you are exchanging MEDs, you get a number from which
you may be able to infer a map, since MEDs theoretically
tell you some sort of closeness of a reachable thing to
each BR).

The obvious evolutionary path is towards seeing some level
of connectivity information in one's peer so that one
can send traffic towards the best IX.

Propagating IX addresses really makes sense only when two
connections are available between one BR and the next AS,
and one of the two is a less desirable path than that
available via another BR.  This might happen when, for
example, two peers are colocated around some sort of
public infrastructure and also have a private connection.

	Sean.

Date: Sat, 20 Sep 1997 20:42:48 -0400
To: "Sean M. Doran" <[email-masked]>
From: Paul Ferguson <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither!
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 08:36 PM 9/20/97 -0400, Sean M. Doran wrote:

>
>Yes and no.  You are forgetting confederations.
>

But Sean, wouldn't you agree that confederations are of
the implementation genre that is waning? By asking this,
I in no way mean to imply that we should ignore it's
existence, but rather, I do notice that the instance
of confederations is one which is a path much less taken
these days.

- paul

To: Pedro Marques <[email-masked]>
Cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither!
From: "Sean M. Doran" <[email-masked]>
Date: 	20 Sep 1997 20:36:42 -0400
Lines: 34
Sender: [email-masked]

Pedro Marques <[email-masked]> writes:
 
> First "extending the IGP to include remote AS routers"
> is evil... the whole concept of AS is exactly where the
> IGP boundaries are.

Yes and no.  You are forgetting confederations.

> Also i sincerely doubt any reasonable network operator
> would accept to participate in someone else's IGP...

I may not be a reasonable network operator, but I would
really like to have a sabotage-resistant means of carrying
the same next-hop-addresses that another network carries
in its IGP.

If another network is doing the standard "each router gets
a prefix, each such prefix is carried in the IGP"
configuration, and metrics were both sufficiently rich and
sufficiently useful, then a not-quite-a-confederation
approach to carrying the other network's next-hops in my
IGP and not requiring the translation of the other
network's IBGP next-hops into the eBGP next-hop for some
set of prefixes would be a nice way to help kill off the
poor closest-exit vs MEDs choice for external path
selection.

One way to look at this would be something along the lines
of having an IS-IS level 3, where the L3 ISes are those at
the borders between two networks, with a confederation of
ASes layered on top.  L3 addresses, in effect, are the 
routing names describing the L2 ISes in two separate L2 areas.

	Sean.

Posted-Date: Sat, 20 Sep 1997 12:45:40 -0400 (EDT)
Date: Sat, 20 Sep 1997 12:44:05 -0400
To: Pedro Marques <[email-masked]>, Dimitry Haskin <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 07:41 PM 9/19/97 -0700, Pedro Marques wrote:
>    Dimitry> Forth, I think that I've clearly stated that I'm not
>    Dimitry> asking to eliminate the ability to advertise unmodified
>    Dimitry> NEXT_HOP into IBGP but merely asking to remove the
>    Dimitry> requirement to include global-scope address in the
>    Dimitry> NEXT_HOP attribute.
>
>Which isn't, imho, reasonable. A given AS should not need to know the
>IBGP configuration of the ASes it peers with. If the remote AS choose
>to ignore the global and replace it with it's own "non-linklocal scoped
>address valid in it's entire AS" we end up with exactly the same
>functionality that you ask. If not it has to advertise into the IGP
>a route to the foreign next-hop.
>
>Note that a border router should insert the link local and not the
>global address on it's forwarding table when directly connected to
>another AS.
>
>Passing just *one* address in a direct ebgp peering makes you loose
>functionality compared to ipv4 bgp. You do need to pass *two* addresses:
>a link local that your peer can install in it's forwarding table and
>a non-link local that the other BGP capable routers of the foreign AS
>can route to. The non-locally scoped address can be completly ignore
>if the other AS is configured to do so, but a border router can not
>refrain from annoucing it.
>
A given AS should not be forced to configure global-scope addresses to a
border router DMZ interface and supply this address to its external peer if
it does not want to. It should be completely a policy decision. BGP still
can operate without global next hop addresses as long as the receiving peer
implementation can handle it. In fact you are trying to impose some policy
and administrative decisions on an AS even if it is not absolutely required
for the BGP operation. Well, I may loose some functionality by not
supplying a global-scope next hop but it should be my choice weighted
against administrative and other gains that I may get instead.

BGP peering is a consenting relationship. If my policy is not to supply a
global next hop and you policy is to require a global next hop, so we don't
peer until we reconcile our differences. But in no way it should be imposed
by the protocol unless it is absolutely necessary for protocol operation.
You can look at the MED attribute as a precedence, receiving peer may get
some extra functionality if it gets it but it is not required to send it.

>  Pedro.

Dimitry

Date: Fri, 19 Sep 1997 19:41:50 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Dimitry Haskin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    Dimitry> Forth, I think that I've clearly stated that I'm not
    Dimitry> asking to eliminate the ability to advertise unmodified
    Dimitry> NEXT_HOP into IBGP but merely asking to remove the
    Dimitry> requirement to include global-scope address in the
    Dimitry> NEXT_HOP attribute.

Which isn't, imho, reasonable. A given AS should not need to know the
IBGP configuration of the ASes it peers with. If the remote AS choose
to ignore the global and replace it with it's own "non-linklocal scoped
address valid in it's entire AS" we end up with exactly the same
functionality that you ask. If not it has to advertise into the IGP
a route to the foreign next-hop.

Note that a border router should insert the link local and not the
global address on it's forwarding table when directly connected to
another AS.

Passing just *one* address in a direct ebgp peering makes you loose
functionality compared to ipv4 bgp. You do need to pass *two* addresses:
a link local that your peer can install in it's forwarding table and
a non-link local that the other BGP capable routers of the foreign AS
can route to. The non-locally scoped address can be completly ignore
if the other AS is configured to do so, but a border router can not
refrain from annoucing it.

  Pedro.

Posted-Date: Fri, 19 Sep 1997 22:22:10 -0400 (EDT)
Date: Fri, 19 Sep 1997 22:20:08 -0400
To: Pedro Marques <[email-masked]>, Dimitry Haskin <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 05:49 PM 9/19/97 -0700, Pedro Marques wrote:
>    >> 
>    >> A1 --- OC192 --- B1 --- OC192 --- >---- B3 A2 --- 9600b --- B2
>    >> --- OC192 ---
>    >> 
>    >> 
>    >> This makes a big difference if you have a high speed internal
>    >> backbone with two peer connections to a remote AS, one on a
>    >> fast link, the other on a slow link.  You really want to take
>    >> into account the cost of reaching the remote AS, not just the
>    >> cost of reaching the edge of your AS.
>    >> 
>    Dimitry> You extended IGP to include remote AS routers. I believe
>    Dimitry> that a similar effect can be achieved if the cost of
>    Dimitry> reaching the remote AS is included into the ASE metric
>    Dimitry> when an external route is injected into IGP.
>
>No...
>
>First "extending the IGP to include remote AS routers" is evil... the whole
>concept of AS is exactly where the IGP boundaries are. Also i sincerely
>doubt any reasonable network operator would accept to participate in
>someone else's IGP...
>
First, I was not advocating "extending the IGP to include remote AS
routers" but merely 
clarified the Paul's example. Contrarily, this is exactly what you are
advocating since using a global address of remote AS as the next hop
technically amounts to extending IGP to that AS.

>Second, you don't inject exterior routes into IGP. It doesn't scale.
>
Second, I'm well aware of different ways of distributing external routes
within AS and their merits. By far, not all ASs have to deal with 40K
routes and hopefully it shell never be the case for v6 domains.  In
addition, injecting ASE routes into IGP is often the only way to deliver
them to BGP-incapable routers.

>Third, if what you want is to consider the path to the ingress point of
>the external AS, why do anything else that use today's solution: don't
>change the nexthop. There is absolutely no problem with what we do
>today. If you eliminate the ability of annoucing the unmodified nexthop
>into IBGP you do indeed create a problem.
>
Third, as it has been pointed out, changing the next hop *is* the
prevailing today's solution at many ISP domains.

Forth, I think that I've clearly stated that I'm not asking to eliminate
the ability to advertise unmodified NEXT_HOP into IBGP but merely asking to
remove the requirement to include global-scope address in the NEXT_HOP
attribute.

>  Pedro.

Dimitry

Date: Fri, 19 Sep 1997 21:02:04 -0400
To: Pedro Marques <[email-masked]>
From: Paul Ferguson <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 05:49 PM 9/19/97 -0700, Pedro Marques wrote:

>
>Second, you don't inject exterior routes into IGP. It doesn't scale.
>

Bingo. Best current practice.  ;-)

- paul

To: Dimitry Haskin <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Date: Fri, 19 Sep 1997 17:53:04 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Dimitry Haskin <[email-masked]>
  Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
  At 02:54 PM 9/19/97 -0700, Paul Traina wrote:
  >
  >  >
  >  >3) We loose the ability to include the metric of the interconnection link
  >  >in the BGP best path decision.
  >  >
  >  Why is that?
  >
  >Please note the following terminology, I'm talking ingres/egress based
  >on routing information flow, not packet forwarding flow:
  >
  >	remote  ---------> ingress  -------------> egress
  >	AS		   router		   router
  >	router
  >
  >If you just use your IGP to determine the cost of reaching a
  >particular point, any meansurement the egress router would make
  >would be based on the metric of the path from the ingress router
  >to the egress router, instead of the metric along the path from
  >the remote router in the other AS to the egress router.
  >
  >
  >		A1 --- OC192 --- B1 --- OC192 ---
  >					         >---- B3
  >		A2 --- 9600b --- B2 --- OC192 ---
  >
  >
  >This makes a big difference if you have a high speed internal backbone
  >with two peer connections to a remote AS, one on a fast link, the other
  >on a slow link.  You really want to take into account the cost of reaching
  >the remote AS, not just the cost of reaching the edge of your AS.
  >
  You extended IGP to include remote AS routers. I believe that a similar
  effect can be achieved if the cost of reaching the remote AS is included
  into the ASE metric when an external route is injected into IGP.

Agreed again.
  
  Dimitry

To: Pedro Marques <[email-masked]>
cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither! 
Date: Fri, 19 Sep 1997 17:52:39 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Pedro Marques <[email-masked]>
  Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neithe
>>r! 
  >>>>> "Paul" == Paul Traina <[email-masked]> writes:

      >>  3) We loose the ability to include the metric of the
      >> interconnection link in the BGP best path decision.
      >> 
      Dimitry>   Why is that?
  
  	[snip]
  
      Paul> This makes a big difference if you have a high speed
      Paul> internal backbone with two peer connections to a remote AS,
      Paul> one on a fast link, the other on a slow link.  You really
      Paul> want to take into account the cost of reaching the remote
      Paul> AS, not just the cost of reaching the edge of your AS.
  
  Thanks for the explanation.
  So, i assume that you actually agree that not modifing the nexthop is
  useful in some situations and that removing bgp's ability to annouce the
  exterior peer's address as nexthop would be handicapping the protocol.
  
It would handicap the ability for a BGP implementation to influence
path selection based upon the IGP metric to a remote router.  There
are plenty of suitably clever ways to get the same information, so
I really don't have a strong stance one way or another.  I certainly
don't think it ham-strings the protocol, it makes one way of determining
this information less obvious, that's all.

In BGP3 we always did the the moral equivelant of next-hop-self,
and this change was specificly requested in BGP4 by Dennis for this
reason, among others.

Date: Fri, 19 Sep 1997 17:49:22 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Dimitry Haskin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Sender: [email-masked]

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    Dimitry> At 02:54 PM 9/19/97 -0700, Paul Traina wrote:
    >>  > >3) We loose the ability to include the metric of the
    >> interconnection link >in the BGP best path decision.  > Why is
    >> that?
    >> 
    >> Please note the following terminology, I'm talking
    >> ingres/egress based on routing information flow, not packet
    >> forwarding flow:
    >> 
    >> remote ---------> ingress -------------> egress AS router
    >> router router
    >> 
    >> If you just use your IGP to determine the cost of reaching a
    >> particular point, any meansurement the egress router would make
    >> would be based on the metric of the path from the ingress
    >> router to the egress router, instead of the metric along the
    >> path from the remote router in the other AS to the egress
    >> router.
    >> 
    >> 
    >> A1 --- OC192 --- B1 --- OC192 --- >---- B3 A2 --- 9600b --- B2
    >> --- OC192 ---
    >> 
    >> 
    >> This makes a big difference if you have a high speed internal
    >> backbone with two peer connections to a remote AS, one on a
    >> fast link, the other on a slow link.  You really want to take
    >> into account the cost of reaching the remote AS, not just the
    >> cost of reaching the edge of your AS.
    >> 
    Dimitry> You extended IGP to include remote AS routers. I believe
    Dimitry> that a similar effect can be achieved if the cost of
    Dimitry> reaching the remote AS is included into the ASE metric
    Dimitry> when an external route is injected into IGP.

No...

First "extending the IGP to include remote AS routers" is evil... the whole
concept of AS is exactly where the IGP boundaries are. Also i sincerely
doubt any reasonable network operator would accept to participate in
someone else's IGP...

Second, you don't inject exterior routes into IGP. It doesn't scale.

Third, if what you want is to consider the path to the ingress point of
the external AS, why do anything else that use today's solution: don't
change the nexthop. There is absolutely no problem with what we do
today. If you eliminate the ability of annoucing the unmodified nexthop
into IBGP you do indeed create a problem.

  Pedro.

To: Andrew Partan <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither! 
Date: Fri, 19 Sep 1997 17:47:29 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Andrew Partan <[email-masked]>
  Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neithe
  
  So I when I redistribute my connected routes into my IGP, I want
  to be able to set a metric (possibly per interface).  And I don't
  use next-hop self for routes from this AS.
  	[email-masked] (Andrew Partan)

Exactly.

Date: Fri, 19 Sep 1997 17:11:23 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Quaizar Vohra <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: (IPng 4449) BGP and renumbering.. was Re:  /126 or /127 -- neither!
Sender: [email-masked]

>>>>> "Quaizar" == Quaizar Vohra <[email-masked]> writes:

    >> you advertise into your IBGP...
    >> 
    >> As it is currently defined, IPv6's BGP can take any beating you
    >> want.  Restricting it to carry link locals in ebgp sessions
    >> would seriously handicap the protocol.
    >> 
    >> For instance you would completly loose the capability to do
    >> multihop ebgp.

    Quaizar> I think if we remove the restriction that the NEXT_HOP
    Quaizar> will either only carry link-local or global IPv6 address,
    Quaizar> i.e. allow either, then as per Dimitry's Proposal we can
    Quaizar> avoid propogating global IX addresses in the most usual
    Quaizar> case of single hop ebgp.

IPv6 BGP carries a non-linklocal scope address as nexthop plus a link local
scoped address if the two peers are directly connected.

That does not prevent a peer from rewriting the nexthop when annoucing
those routes to either ibgp or ebgp peers.

I may start to sound like a broken record by now, but the above scheme
permits all types of configuration without loosing bgp capabilities...

  Pedro.

Posted-Date: Fri, 19 Sep 1997 20:02:59 -0400 (EDT)
Date: Fri, 19 Sep 1997 20:01:11 -0400
To: Paul Traina <[email-masked]>, Dimitry Haskin <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 02:54 PM 9/19/97 -0700, Paul Traina wrote:
>
>  >
>  >3) We loose the ability to include the metric of the interconnection link
>  >in the BGP best path decision.
>  >
>  Why is that?
>
>Please note the following terminology, I'm talking ingres/egress based
>on routing information flow, not packet forwarding flow:
>
>	remote  ---------> ingress  -------------> egress
>	AS		   router		   router
>	router
>
>If you just use your IGP to determine the cost of reaching a
>particular point, any meansurement the egress router would make
>would be based on the metric of the path from the ingress router
>to the egress router, instead of the metric along the path from
>the remote router in the other AS to the egress router.
>
>
>		A1 --- OC192 --- B1 --- OC192 ---
>					         >---- B3
>		A2 --- 9600b --- B2 --- OC192 ---
>
>
>This makes a big difference if you have a high speed internal backbone
>with two peer connections to a remote AS, one on a fast link, the other
>on a slow link.  You really want to take into account the cost of reaching
>the remote AS, not just the cost of reaching the edge of your AS.
>
You extended IGP to include remote AS routers. I believe that a similar
effect can be achieved if the cost of reaching the remote AS is included
into the ASE metric when an external route is injected into IGP.

Dimitry

Date: Fri, 19 Sep 1997 17:00:11 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Paul Traina <[email-masked]>
Cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither! 
Sender: [email-masked]

>>>>> "Paul" == Paul Traina <[email-masked]> writes:

    >>  3) We loose the ability to include the metric of the
    >> interconnection link in the BGP best path decision.
    >> 
    Dimitry>   Why is that?

	[snip]

    Paul> This makes a big difference if you have a high speed
    Paul> internal backbone with two peer connections to a remote AS,
    Paul> one on a fast link, the other on a slow link.  You really
    Paul> want to take into account the cost of reaching the remote
    Paul> AS, not just the cost of reaching the edge of your AS.

Thanks for the explanation.
So, i assume that you actually agree that not modifing the nexthop is
useful in some situations and that removing bgp's ability to annouce the
exterior peer's address as nexthop would be handicapping the protocol.

  Pedro.

From: Andrew Partan <[email-masked]>
Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither!
To: [email-masked] (Paul Traina)
Date: Fri, 19 Sep 1997 18:37:26 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> This makes a big difference if you have a high speed internal backbone
> with two peer connections to a remote AS, one on a fast link, the other
> on a slow link.  You really want to take into account the cost of reaching
> the remote AS, not just the cost of reaching the edge of your AS.

So I when I redistribute my connected routes into my IGP, I want
to be able to set a metric (possibly per interface).  And I don't
use next-hop self for routes from this AS.
	[email-masked] (Andrew Partan)

To: Dimitry Haskin <[email-masked]>
cc: Pedro Marques <[email-masked]>, [email-masked], [email-masked]
Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither! 
Date: Fri, 19 Sep 1997 14:54:40 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Dimitry Haskin <[email-masked]>
  Subject: Re: (IPng 4453) BGP and renumbering.. was Re:  /126 or /127 --
	   neither!
  At 11:06 AM 9/19/97 -0700, Pedro Marques wrote:
  > ...
  >    Dimitry> 1) There is no conceptual relationship between Site and
  >    Dimitry> AS.  Therefore site and AS topologies can arbitrary
  >    Dimitry> overlap and as the result site-local addresses can not be
  >    Dimitry> generally used within AS.
  >
  >    Dimitry> 2) We loose some functionality since "third party"
  >    Dimitry> addresses can't be advertised in the NEXT_HOP and all
  >    Dimitry> traffic will be forced through the border router that
  >    Dimitry> does route re-advertisement.
  >
  >3) We loose the ability to include the metric of the interconnection link
  >in the BGP best path decision.
  >
  Why is that?

Please note the following terminology, I'm talking ingres/egress based
on routing information flow, not packet forwarding flow:

	remote  ---------> ingress  -------------> egress
	AS		   router		   router
	router

If you just use your IGP to determine the cost of reaching a
particular point, any meansurement the egress router would make
would be based on the metric of the path from the ingress router
to the egress router, instead of the metric along the path from
the remote router in the other AS to the egress router.

		A1 --- OC192 --- B1 --- OC192 ---
					         >---- B3
		A2 --- 9600b --- B2 --- OC192 ---

This makes a big difference if you have a high speed internal backbone
with two peer connections to a remote AS, one on a fast link, the other
on a slow link.  You really want to take into account the cost of reaching
the remote AS, not just the cost of reaching the edge of your AS.

Posted-Date: Fri, 19 Sep 1997 16:22:08 -0400 (EDT)
Date: Fri, 19 Sep 1997 16:18:31 -0400
To: Pedro Marques <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: (IPng 4453) BGP and renumbering.. was Re:  /126 or /127 -- neither!
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:06 AM 9/19/97 -0700, Pedro Marques wrote:
> ...
>    Dimitry> 1) There is no conceptual relationship between Site and
>    Dimitry> AS.  Therefore site and AS topologies can arbitrary
>    Dimitry> overlap and as the result site-local addresses can not be
>    Dimitry> generally used within AS.
>
>    Dimitry> 2) We loose some functionality since "third party"
>    Dimitry> addresses can't be advertised in the NEXT_HOP and all
>    Dimitry> traffic will be forced through the border router that
>    Dimitry> does route re-advertisement.
>
>3) We loose the ability to include the metric of the interconnection link
>in the BGP best path decision.
>
Why is that?

>    Dimitry> Under examination 1) does not appear to be a valid
>    Dimitry> concern.  If site-local addresses are to be used for
>    Dimitry> communications within a site (as recommended), an AS must
>    Dimitry> be completely contained within a single site.
>
>No. An AS can potentially encompass several sites...

If we define AS as an IGP cloud (I know there are exotic use of AS numbers
which is irrelevant for purpose of this discursion) I don't really see how
this can be accomplished with site-local prefixes. Example would help.
>
>    Dimitry>  Otherwise
>    Dimitry> site-local prefixes of one site can be flooded to other
>    Dimitry> sites of the same AS by a intra-AS routing protocol
>    Dimitry> (IGP).
>
>Running the same IGP instance across AS boundaries ?
>Somehow that doesn't sound a realistic solution to me.

I didn't say that, did I? I rather implied that it was not realistic to run
IGP across site boundaries.
This is why I concluded that an AS (or IGP domain if you wish) was always
contained within a single site.
>
>    Dimitry> For those sites that insist on advertising global-scope
>    Dimitry> next hop addresses across site boundaries, it may be
>    Dimitry> desirable to allocate prefixes from a single reserved
>    Dimitry> non-routable TLA which can be assigned to their DMZ links
>    Dimitry> (links connecting ASs).  Assuming that such prefixes
>    Dimitry> never need to be renumbered, it takes re-numbering
>    Dimitry> concern away but will require administration.
>
>Like i told you in Munich, let's not break the protocol. If you really
>want to you can still use site local addresses for all the addresses
>you advertise into your IBGP...
>
As far as I remember it was required to advertise a global address in the
NEXT_HOP attribute. In should be fixed not to require that. I don't think
removing such a requirement would break the protocol -- just opposite, it
will make it more flexible. The spec should also explain what to do if only
link-local address is received in the NEXT_HOP attribute from EBGP peer.

>As it is currently defined, IPv6's BGP can take any beating you want.
>Restricting it to carry link locals in ebgp sessions would seriously
>handicap the protocol.
>
I did not ask for such a restriction, did I? I said it would be a good
approach for the vast majority cases but not *all* cases.

>For instance you would completly loose the capability to do multihop ebgp.
>
>A very personal opinion: Is this dicussion really relevant ? Is this really
>the major obstacle to automatic renumbering on the fly of entire
confederations
>of ASes without any manual intervention ?
>
>  Pedro.

Dimitry

From: Henk Smit <[email-masked]>
Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither!
To: [email-masked] (Paul Traina)
Date: Fri, 19 Sep 1997 21:40:31 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Paul wrote:
> In a past life, I've seen "set next-hop-self" used on ibgp peers
> in configs by Sprint, MCI, and UUNET to specificly avoid carrying
> the "DMZ" network's routing information in their IGP.

  Just this week I got a request from one of those for a feature
 in our ISIS implementation, related to this. Supposedly they
 want to be able to influence IGP metrics to the BGP nexthops.
 This will enable them to fine-tune route selection when doing
 shortest-exit routing. I was told that because of the growth
 of private peerings between the large ISPs, there is more need
 for this kind of fine-tuning.

  So it might be that carrying original eBGP next-hop info inside
 the iBGP-mesh will be more important in the near future. Maybe
 one of the large ISPs can comment on this ?

    Henk.

From: Quaizar Vohra <[email-masked]>
Date: Fri, 19 Sep 1997 12:34:54 -0700 (PDT)
To: Pedro Marques <[email-masked]>
Cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: (IPng 4449) BGP and renumbering.. was Re:  /126 or /127 -- neither!
Sender: [email-masked]

 > you advertise into your IBGP...
 > 
 > As it is currently defined, IPv6's BGP can take any beating you want.
 > Restricting it to carry link locals in ebgp sessions would seriously
 > handicap the protocol.
 > 
 > For instance you would completly loose the capability to do multihop ebgp.

I think if we remove the restriction that the NEXT_HOP will either
only carry link-local or global IPv6 address, i.e. allow either, then
as per Dimitry's Proposal we can avoid propogating global IX addresses
in the most usual case of single hop ebgp. 

THIS will also allow us to do multihop ebgp at the added complexity of
propagating IX addresses into IGPs of the AS.

Instead of replacement of link-local address of ebgp peer by the
site-local, I would propose that the site-local address be added to
the link-local address of the ebgp peer. This will allow the us to 
retain the NBMA shortcut functionality too.

Quaizar

 >
 > A very personal opinion: Is this dicussion really relevant ? Is this really
 > the major obstacle to automatic renumbering on the fly of entire confederations
 > of ASes without any manual intervention ?
 > 
 >   Pedro.

To: Vince Fuller <[email-masked]>
cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither! 
Date: Fri, 19 Sep 1997 11:50:16 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Vince Fuller <[email-masked]>
  Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 --
	   neither!
      I have to agree with Dmitry's conclusions.  Operational experience
      on the IPv4 network shows that the vast majority of large sites
      are already reseting the next hop to an address on the border router
      itself before advertising info into their IGP mesh.
						^^^
sorry: s/IGP/IBGP/
  
  Really? Can you provide specific references to large providers? I was under
  the impression that most propagate public-peering next-hops unmolested (thoug
  this is becoming less relavent along with the public interconnects).

In a past life, I've seen "set next-hop-self" used on ibgp peers
in configs by Sprint, MCI, and UUNET to specificly avoid carrying
the "DMZ" network's routing information in their IGP.
  
  I agree, in principal, that rewriting next-hops on export to IGP can generall
  avoid having to globally propagate addresses specific to an IX, but the exact
  technique for doing that needs to be clearly indicated (and there are a few
  rare cases, i.e. a provider with multiple routers at an IX, where it may be
  problematic).

We're in 100% agreement.  There are cases where this isn't optimal, then
you need to do something else, my point was that in the general case, we
have operational experience that shows it's a win.

Date: Fri, 19 Sep 97 11:17:59 PDT
From: Vince Fuller <[email-masked]>
To: Paul Traina <[email-masked]>
Cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked]
Phone: (415) 528-7227
USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither!
Sender: [email-masked]

    I have to agree with Dmitry's conclusions.  Operational experience
    on the IPv4 network shows that the vast majority of large sites
    are already reseting the next hop to an address on the border router
    itself before advertising info into their IGP mesh.

Really? Can you provide specific references to large providers? I was under
the impression that most propagate public-peering next-hops unmolested (though
this is becoming less relavent along with the public interconnects).

I agree, in principal, that rewriting next-hops on export to IGP can generally
avoid having to globally propagate addresses specific to an IX, but the exact
technique for doing that needs to be clearly indicated (and there are a few
rare cases, i.e. a provider with multiple routers at an IX, where it may be
problematic).

	--Vince

Date: Fri, 19 Sep 1997 11:06:51 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Dimitry Haskin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: (IPng 4449) BGP and renumbering.. was Re:  /126 or /127 -- neither!
Sender: [email-masked]

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    >>  i A ----- B
    >> 
    >> if link is numbered (global scope address):
    >> 
    >> A and B will announce routes to each other using as nexthop the
    >> global addresses Ia and Ib (respectivly). Those addresses are
    >> the ones annouced in to the IBGP mesh. I's global prefix will
    >> be injected into the IGP.
    >> 
    >> if the link is unnumbered:
    >> 
    >> A and B will need to make those annoucements with Ag and
    >> Bg. That means site B needs to manually configure a route to
    >> A's prefix and inject it in it's own IGP a vice-versa.
    >> 
    >> So, taking the address out of the link only adds complexity and
    >> creates two possible reasons for manual reconfiguration: the
    >> renumbering of site A and the renumbering of site B. While you
    >> only had one with a numbered link: the renumbering of link i.
    >> 

    Dimitry> I think this requires a little bit of elaboration.

    Dimitry> At a BGP WG meeting in Munich I did a presentation that
    Dimitry> pointed to a potential affect of advertising a
    Dimitry> global-scope address in the NEXT_HOP attribute of BGP
    Dimitry> route updates. Since a route to such a global address has
    Dimitry> to be injected into IGP, it would make re-numbering
    Dimitry> somewhat more difficult.  In essence, if a global address
    Dimitry> of one site it advertised as a next hop address to
    Dimitry> another site, the addressing information of one site gets
    Dimitry> injected into IGP of another site. This is exactly what I
    Dimitry> believe we tried to avoid in order to minimize
    Dimitry> re-numbering dependencies between sites. Note that
    Dimitry> currently there is no automatic way to correct IGP tables
    Dimitry> of at least one of two bordering sites when another site
    Dimitry> renumbers.

    Dimitry> As a solution, I proposed to avoid advertising of a
    Dimitry> global-scope address as the NEXT_HOP across site
    Dimitry> boundaries. Instead a link-local address is used and,
    Dimitry> when a border router re-advertise external routes within
    Dimitry> own AS, it replaces the NEXT_HOP with a site-local
    Dimitry> address of one of the router own interfaces.

    Dimitry> During the deliberation at the meeting this approach
    Dimitry> seems to be rejected on the following grounds:

    Dimitry> 1) There is no conceptual relationship between Site and
    Dimitry> AS.  Therefore site and AS topologies can arbitrary
    Dimitry> overlap and as the result site-local addresses can not be
    Dimitry> generally used within AS.

    Dimitry> 2) We loose some functionality since "third party"
    Dimitry> addresses can't be advertised in the NEXT_HOP and all
    Dimitry> traffic will be forced through the border router that
    Dimitry> does route re-advertisement.

3) We loose the ability to include the metric of the interconnection link
in the BGP best path decision.

    Dimitry> Under examination 1) does not appear to be a valid
    Dimitry> concern.  If site-local addresses are to be used for
    Dimitry> communications within a site (as recommended), an AS must
    Dimitry> be completely contained within a single site.

No. An AS can potentially encompass several sites...

    Dimitry>  Otherwise
    Dimitry> site-local prefixes of one site can be flooded to other
    Dimitry> sites of the same AS by a intra-AS routing protocol
    Dimitry> (IGP).

Running the same IGP instance across AS boundaries ?
Somehow that doesn't sound a realistic solution to me.

    Dimitry> For those sites that insist on advertising global-scope
    Dimitry> next hop addresses across site boundaries, it may be
    Dimitry> desirable to allocate prefixes from a single reserved
    Dimitry> non-routable TLA which can be assigned to their DMZ links
    Dimitry> (links connecting ASs).  Assuming that such prefixes
    Dimitry> never need to be renumbered, it takes re-numbering
    Dimitry> concern away but will require administration.

Like i told you in Munich, let's not break the protocol. If you really
want to you can still use site local addresses for all the addresses
you advertise into your IBGP...

As it is currently defined, IPv6's BGP can take any beating you want.
Restricting it to carry link locals in ebgp sessions would seriously
handicap the protocol.

For instance you would completly loose the capability to do multihop ebgp.

A very personal opinion: Is this dicussion really relevant ? Is this really
the major obstacle to automatic renumbering on the fly of entire confederations
of ASes without any manual intervention ?

  Pedro.

To: Dimitry Haskin <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither! 
Date: Fri, 19 Sep 1997 11:02:11 -0700
From: Paul Traina <[email-masked]>
Sender: [email-masked]

I have to agree with Dmitry's conclusions.  Operational experience
on the IPv4 network shows that the vast majority of large sites
are already reseting the next hop to an address on the border router
itself before advertising info into their IGP mesh.

Posted-Date: Fri, 19 Sep 1997 12:39:30 -0400 (EDT)
Date: Fri, 19 Sep 1997 12:35:51 -0400
To: [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither!
Cc: [email-masked]
Sender: [email-masked]

At 12:02 PM 9/18/97 -0700, Pedro Marques wrote:
>
>	    i
>	A ----- B
>
>if link is numbered (global scope address):
>
>A and B will announce routes to each other using as nexthop the global
>addresses Ia and Ib (respectivly). Those addresses are the ones annouced
>in to the IBGP mesh. I's global prefix will be injected into the IGP.
>
>if the link is unnumbered:
>
>A and B will need to make those annoucements with Ag and Bg. That means
>site B needs to manually configure a route to A's prefix and inject it
>in it's own IGP a vice-versa.
>
>So, taking the address out of the link only adds complexity and creates
>two possible reasons for manual reconfiguration: the renumbering of
>site A and the renumbering of site B. While you only had one with
>a numbered link: the renumbering of link i.
>

I think this requires a little bit of elaboration.

At a BGP WG meeting in Munich I did a presentation that pointed to a
potential affect of advertising a global-scope address in the NEXT_HOP
attribute of BGP route updates. Since a route to such a global address has
to be injected into IGP, it would make re-numbering somewhat more
difficult.  In essence, if a global address of one site it advertised as a
next hop address to another site, the addressing information of one site
gets injected into IGP of another site. This is exactly what I believe we
tried to avoid in order to minimize re-numbering dependencies between
sites. Note that currently there is no automatic way to correct IGP tables
of at least one of two bordering sites when another site renumbers.

As a solution, I proposed to avoid advertising of a global-scope address as
the NEXT_HOP across site boundaries. Instead a link-local address is used
and, when a border router re-advertise external routes within own AS, it
replaces the NEXT_HOP with a site-local address of one of the router own
interfaces.

During the deliberation at the meeting this approach seems to be rejected
on the following grounds:

1) There is no conceptual relationship between Site and AS.  Therefore site
and AS topologies can arbitrary overlap and as the result site-local
addresses can not be generally used within AS.

2) We loose some functionality since "third party" addresses can't be
advertised in the NEXT_HOP and all traffic will be forced through the
border router that does route re-advertisement.

Under examination 1) does not appear to be a valid concern.  If site-local
addresses are to be used for communications within a site (as recommended),
an AS must be completely contained within a single site. Otherwise
site-local prefixes of one site can be flooded to other sites of the same
AS by a intra-AS routing protocol (IGP).

2) is partially true.  But is it really a problem for the vast majority of
sites?  I believe that generally border routers that redistribute external
routes within its AS also serve as forwarders for routes they advertise.
Note that it is still possible to advertise a site-local address of a
different border router within own AS.  The functionality that is lost is
the ability to use BGP information alone to establish NBMA shortcuts to a
BGP peer in an adjacent AS. I'm not sure if it's normally done due to the
policy concerns.

To summarize I believe that the proposed approach is applicable and
desirable in many deployments.  It can be definitely used at 6bone.

For those sites that insist on advertising global-scope next hop addresses
across site boundaries, it may be desirable to allocate prefixes from a
single reserved non-routable TLA which can be assigned to their DMZ links
(links connecting ASs).  Assuming that such prefixes never need to be
renumbered, it takes re-numbering concern away but will require
administration.

Do svidanja,

Dimitry

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-cap-neg-00.txt
Date: Wed, 10 Sep 1997 15:05:02 -0400
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		: Capabilities Negotiation with BGP-4
	Author(s)	: J. Scudder, R. Chandra
	Filename	: draft-ietf-idr-bgp4-cap-neg-00.txt
	Pages		: 4
	Date		: 1997-09-09
	
   Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an
   OPEN message with one or more unrecognized Optional Parameters, the
   speaker must terminate BGP peering. This complicates introduction of
   new capabilities in BGP.
     
   This document defines new Optional Parameter, called Capabilities,
   that is expected to facilitate introduction of new capabilities in
   BGP by providing graceful capability negotiation.
     
   The proposed parameter is backward compatible - a router that
   supports the parameter can maintain BGP peering with a router that
   doesn't support the parameter.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-cap-neg-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-cap-neg-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-00.txt".
	
NOTE:	The mail server at ds.internic.net 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-bgp4-cap-neg-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-cap-neg-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: WG last call
Date: Wed, 10 Sep 97 07:51:27 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

At the last WG meeting we agreed to move 
draft-ietf-idr-bgp4-multiprotocol-00.txt to a Proposed Standard.
This is the WG last call. The deadline for comments is 9/24.

Yakov.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-00.txt
Date: Wed, 10 Sep 1997 09:59:48 -0400
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		: Multiprotocol Extensions for BGP-4
	Author(s)	: D. Katz, Y. Rekhter,  
                          T. Bates, R. Chandra
	Filename	: draft-ietf-idr-bgp4-multiprotocol-00.txt
	Pages		: 9
	Date		: 09-Sept-97
	
   Currently BGP-4 [BGP-4] is capable of carrying routing information
   only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
   enable it to carry routing information for multiple Network Layer
   protocols (e.g., IPv6, IPX, etc...). The extensions are backward
   compatible - a router that supports the extensions can interoperate
   with a router that doesn't support the extensions.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-multiprotocol-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-00.txt".
	
NOTE:	The mail server at ds.internic.net 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-bgp4-multiprotocol-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-multiprotocol-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: [email-masked]
cc: [email-masked]
Subject: draft-ietf-idr-as-dedicated-00.txt to an Informational RFC
Date: Mon, 08 Sep 97 10:54:20 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Joel,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-as-dedicated-00.txt to an Informational RFC.

Yakov.