Subject: Re: AS prepend, MED or local_pref question.
From: "John W. Stewart III" <[email-masked]>
To: Steve Francis <[email-masked]>
Cc: [email-masked]
Date: Fri, 31 Jan 1997 15:12:38 EST

my personal suggestion would be to statically set MEDs
to force the traffic the way you want it to go.  this
isn't the most scaleable way to do it, but it sounds
like (1) you're not talking about a huge number of
prefixes and (2) you've got to do prefix-based stuff
anyway, and that's kind of inherently not scaleable.
keep in mind that nothing within the protocol ensures
symmetry -- if you care about it, then you have to
manage the configs such that the static-MED-setting
results in symmetry

as for why there are multiple ways, some ways make
more sense in certain contexts.  for example, in
your situation you're gonna have to have a fair
amount of manual config on all 4 routers, so you
can do it any way.  but large service providers
might not want to put so much config in place, and
instead will take the community-based approach
because it's more scaleable for them (i.e., all of
the manual config stuff is in the customer router).
as for manipulating the AS-paths, while it is
sometimes the only tool that people have and so
therefore is sometimes legitimately used, i myself
consider it little more than a hack

/jws

 > Hi.  
 > Apologies if this is not the correct forum for this question.
 > 
 > I wish to connect two separate routers in AS1 to two separate routers in
 > AS2.  I want half the networks in AS1 to use router1 going to AS2, and half
 > the networks to router 2 to go to AS2. And I want the return traffic to
 > follow the same paths, symmetrically.
 > 
 > Now, I can think of three ways to do this:
 > - at router 1, prepend a bunch of AS numbers to the routes advertisements
 > for the networks I want to come back via router2, and at router 2 prepend
 > for teh networks that should come back via router1.
 > - assign different communities to the two sets of routes, which are
 > announced both places, and apply a local_pref at the routers in AS2, so at
 > the router 1 peer in AS2, one set of routes would have a lower local_pref
 > applied, and a higher local_pref at router 2 peer in AS2.
 > - Use the MED attribute for the two sets of routes.
 > 
 > Is there a preferred way to do this?  Any advantage/disadvantage to any
 > specific approach?
 > 
 > Is it necessary for the protocol to provide so many ways to achieve the same
 > thing?  It seems to me that MED is redundant.
 > 
 > TIA
 > Steve Francis
 > Network Analyst
 > Communications Services
 > UCSB	
 > ph (805) 893 7775	fax (805) 893 7272
 > 
- - - - - - - - - - - - - - - - -

Date: Fri, 31 Jan 1997 11:35:41 -0800 (PST)
To: [email-masked]
From: Steve Francis <[email-masked]>
Subject: AS prepend, MED or local_pref question.
Sender: [email-masked]

Hi.  
Apologies if this is not the correct forum for this question.

I wish to connect two separate routers in AS1 to two separate routers in
AS2.  I want half the networks in AS1 to use router1 going to AS2, and half
the networks to router 2 to go to AS2. And I want the return traffic to
follow the same paths, symmetrically.

Now, I can think of three ways to do this:
- at router 1, prepend a bunch of AS numbers to the routes advertisements
for the networks I want to come back via router2, and at router 2 prepend
for teh networks that should come back via router1.
- assign different communities to the two sets of routes, which are
announced both places, and apply a local_pref at the routers in AS2, so at
the router 1 peer in AS2, one set of routes would have a lower local_pref
applied, and a higher local_pref at router 2 peer in AS2.
- Use the MED attribute for the two sets of routes.

Is there a preferred way to do this?  Any advantage/disadvantage to any
specific approach?

Is it necessary for the protocol to provide so many ways to achieve the same
thing?  It seems to me that MED is redundant.

TIA
Steve Francis
Network Analyst
Communications Services
UCSB	
ph (805) 893 7775	fax (805) 893 7272

- - - - - - - - - - - - - - - - -

Date: Thu, 23 Jan 1997 12:37:10 +0500
From: [email-masked] (Joel Halpern)
To: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN
Cc: [email-masked]
Sender: [email-masked]

Just to confirm my initial reaction, I asked the IESG.
The clear agreement was that:
1) A change such as the proposed hello change would indeed prevent
   the specification from going to Full Standard.
If you want to make the change, you will need to cycle in grade.
We can probably bend things enough to allow the new feature in the draft
standard.  Then, after at least 4 months, and with at least two
implementations, we can advance to full standard.

Yours,
Joel M. Halpern				[email-masked]
- - - - - - - - - - - - - - - - -

Date: Mon, 20 Jan 1997 12:48:38 -0500 (EST)
To: [email-masked], [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr bgp [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

From: [email-masked]
Organization: Way Communications
Date: Sun, 19 Jan 1997 00:48:48 -1812
To: [email-masked]
Subject: ===>> An Interesting FREE Offer
Sender: [email-masked]

<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>FOR
MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to:                  718-227-9125  
(this is a fax # in the USA)</bigger></bigger></bigger></color>

</bold>

<bold>or send via smail (first class mail or airmail) to:    

                                         Tempting Tear-Outs

                                         Att. Free-catalogue-by-email
Dept

                                         3835 Richmond Ave.  Suite
#200

                                         Staten Island NY  10312-3828

                                         USA</bold>

<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>-->
IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue
options.</bigger></bigger></bigger></color></bold>

<bold><italic>*------------cut
here/begin-------------------------------------------*</italic>

Name:

Internet email address:

Smail home address:

City-State-Zip:

Country:

Work Tel. #:

Work Fax #:

Home Tel. #:

Home Fax #:

How did you hear about us (name of person/company who referred you or
the area of

the internet that you saw us mentioned in):  Referral by: Tempting
Tear-Outs     

011897-l

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the
mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

<italic>*------------cut
here/end--------------------------------------------*</italic>

</bold>

<bold>CATALOGUE VERSION CHOICES</bold>:

<bold>1.</bold>  This version can be read by everyone, no matter what
type of 

     computer you use, or what type of software you use.  It is a
simple

     format, with just <bold>our entire catalogue pasted into the body
of a 

    single email message, 316K in size.</bold>  If you use pine or elm
on a unix 

     system or an advanced software version such as Eudora Pro 3.0 or

     later, you will most likely receive it as a single email message. 

     However, if your software limits incoming email messages to a     

     certain size, say 32K or so, then your software will split it into

     multiple email message parts.   Whether you receive it as a single

     email message or multiple part email messages, you can easily 

     paste it into one whole text document with your word processor, in

     about 10 minutes or so.

<bold>2.</bold>  For more advanced computer users:  <bold>attached text
file ~316K</bold> - you

     must know how to download an attached text file and then be able
to

     open it with your word processor.  If in doubt, don't ask for
this

     version.  This isn't for internet *newbies.* Better to order
option 1

     and spend a few minutes pasting them into one whole text document

     with your word processor, than to waste hours trying to figure
how

     to deal with this option.   This version is great for doing word

     searches and jumping around within the catalogue with your word 

     processing software, if your normal email reading software doesn't

     allow this.

<bold>3. </bold> For more advanced <bold>Macintosh</bold> computer
users: compressed attached

     text file, created with a <bold>Stuffit(tm) self-extracting
archive (.sea),

    ~140K.</bold>  Can be decompressed by any Macintosh computer user;
no

     special expansion software or knowledge of Stuffit (tm) needed. 
You

     just double-click on the file icon and it automatically expands

     (unstuffs). This is for more advanced mac computer users only, as

     you still have to know how to deal with an attached file.  It will
cut

     your download time by 55%.   Expands out to the same ~316K file
in

     option #2.  See option #2 for more info on what you will need to
be

     able to do.

<bold>4.</bold>  For expert <bold>mac or pc computer users</bold>:
compressed attached text file, 

     created with <bold>Stuffit(tm),  ~116K</bold>.  Can be
decompressed by any 

     computer user who has expansion software to decompress (expand) 

     Stuffit(tm)<bold> (.sit)</bold> files.  This is for more advanced
computer users only

      and will cut your download time by 63%.   Expands out to the same

     ~316K file in option#2.  See option #2 for more info on what you
will 

     need to be able to do.

<bold>5.</bold>  For expert pc or mac computer users: <bold>compressed
attached text file, 

    in a .zip file format, ~143K. </bold>  Can be decompressed by any
computer

      user who has expansion software to decompress (expand) .zip
files.

      This is for more advanced computer users only and will cut your 

      download time by 54%.   Expands out to the same  ~316K file in 

      option#2.   See option #2 for more info on what you will need to
be

      able to do.

<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>VERY
IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A
REPLY:</bigger></bigger></bigger></color></bold>

1.   you must call from an "unblocked number," ie. one that is not
blocked from caller id.  We are very sorry for this requirement, but
our fax software requires this before it allows an incoming fax call to
connect.   If you have a blocked number, you must first unblock it.  In
most cases this means dialing *82 from a touch-tone phone (or 1182 from
a rotary phone) before you dial 1-718-227-9125.     NOTE:  If you are
not sure if your number is blocked, just try dialing our fax #
normally.  If you don't get a recording telling you your number is
blocked, your number has been transmitted and you may press the start
button on your fax when you hear the fax tone from our fax.

2.   no reply forms can be accepted by email....only via fax or smail. 

3.   your form must be typewritten or printed out on your computer
printer before you fax it;  ie. no handwritten forms can be accepted.

4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.

5.   forms not *completely* filled in will not be acknowledged.

6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email
address, or access to one, at least.   :-)

7.   your fax must not exceed 1 page in length.   Faxes of 2 or more
pages will be sensed, then auto-terminated and deleted.  Your fax goes
directly onto our 5.0 gigabyte hard drive and we must limit all
incoming faxes to 1 page.

8.   all faxes must begin with:

*------------cut
here/begin-------------------------------------------*

and must end with:

*------------cut here/end--------------------------------------------*

9. Any fax not conforming to this format will be sensed by our
software, then auto-terminated and deleted from the hard drive, before
any human ever gets to see it.

10.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!

<bold>WHO WE ARE:</bold>

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

<bold>MORE ABOUT THE COMPANY MAKING THE FREE OFFER:</bold>

The company making the offer is a magazine subscription agency based in
the USA.  They have over 1,500 popular USA titles available to be
shipped to *any* country, including of course, to anywhere in the USA! 
  <bold><underline>They offer a FREE 1 yr. subscription to your choice
of over 270 of the titles in their catalogue to any new customer using
them for the first time.</underline></bold>       The  dollar value of
the freebies, based on the subscription prices directly from the
publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign
postage & handling), so the freebie is 100% free!   For new customers
living overseas, the only charge on the freebie would be for the FPH
(foreign postage & handling).

Their president has been in the magazine subscription business since
1973 and they are very customer-service oriented.   They will even help
you with address changes on your magazines, even if you move from one
country to another country.   They have thousands of happy customers in
over 59 countries.

<bold>Their price guarantee is very simple:       they guarantee that
their subscription prices are the lowest available and they will BEAT
any legitimate, verifiable offer before you pay them or match it
afterwards, by refunding you the difference in price PLUS the cost of
the postage stamp you would use sending in the special offer to them,
even 6 months after you pay them, as long as it was current at the time
of your offer.    Does that sound fair?       Wouldn't it be great if
everything you bought came with that price guarantee? </bold> 

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,500 titles on their list,
they would like to think that they have also the best selection
around!

Within the USA, for their USA customers, they are cheaper than all
their competitors and even the publishers themselves.  This is their
price guarantee.         The 1 yr. freebie that you get with your first
order is completely free!   

Overseas, (even after you factor in the cost of the FPH (foreign
postage & handling) and the conversion from USA Dollars to your
currency), on the average, they are generally around one-fourth to
one-half of what the newsstands overseas charge locally for USA
magazines.  On some titles they are as little as one-tenth of what the
newsstands charge.  They are also the cheapest subscription source for
delivery overseas, including directly from the publishers themselves!  
Some publishers don't even offer subscriptions overseas.........but
overseas subscriptions are this company's specialty!  They feel that
magazines should not be a luxury overseas.   In the USA, people buy
magazines and then toss them after reading them for just a few minutes
or hours.  They are so cheap in the USA!   Well, this company would
like to make it the same way for their overseas members.  They are also
cheaper than all their competitors in the USA and overseas, including
the publishers themselves!   It is also *highly unlikely* you will find
any of their USA competitors calling you overseas, in order to offer
that personal touch, just to sell you a couple of magazines!  But that
is what this company specializes in and loves doing!     Around
one-half their business comes from overseas, so they are very patient
with new members who only speak limited English as a 2nd language.   
Subscription prices quoted for overseas consist of the subscription
price, plus the FPH.   You add the two together and that is your total
cost.   The exception is the 1 yr. freebie you get with your first
order.   On that title, you pay *only* the FPH for the 1 yr. term.

<bold><underline>Their prices are so cheap because when you deal with
them, you cut-out all the middlemen.</underline></bold>

<bold><bigger><bigger>HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED
WITH THEM:</bigger></bigger></bold>

<bold>Simply fax or smail back to us the reply form listed at the top
of this message.</bold>   We will then forward your form on to the
subscription agency.  They will then email their "big and juicy"
catalogue to you, in whichever of the four formats you chose.   The
catalogue is FREE and makes for hours of fascinating reading, on its
own. It includes the complete list of freebies, a complete list of all
the titles they sell, as well as detailed descriptions on most of the
titles, along with lists of titles by category of interest and their
terms of sale.    

They will then give you a friendly, no-pressure, no obligation,
5-minute call to go over how they work and to answer any questions that
you might have, as well as give you up-to-the minute price quotes on
any titles you might be considering.     They will call you in whatever
country you live in, taking the time difference into account.        As
they like to emphasize the personal touch they give to each new
customer, all first-time orders can only be done via phone, so they can
answer all your questions completely and personally.   Once you have
placed your first order via phone, you will be able to place future
orders and make inquiries on your account, get price quotes, etc., all
via email, if that is most convenient for you.

Within the USA, they accept payment via check over the phone,
Mastercard, Visa and American Express.      Overseas, they accept
Mastercard, Visa and American Express, even if your credit card is a
local one in local currency!

That's our introduction of our client that we represent.   We hope that
we have piqued your interest and that you will take the next step to
get their free catalogue!   Thank you for your time and interest.

<bold><color><param>0000,FFFF,0000</param>--

Tempting Tear-Outs.

For more info on advertising rates, please write us on your company
letterhead, w/business card, via smail to:   Tempting Tear-Outs, 3835
Richmond Ave. Suite #200, Staten Island NY  10312-3828, USA.
</color></bold><color><param>0000,FFFF,0000</param> </color>           

- - - - - - - - - - - - - - - - -

From: [email-masked]
Organization: Way Communications
Date: Sat, 18 Jan 1997 14:02:49 -1812
To: [email-masked]
Subject: ===>> FREE 1 yr USA Magazine Sub sent worldwide-270+ Choices!  Up to $64.00 value!
Sender: [email-masked]

<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>FOR
MORE INFO:   please "cut out" the below form on the "cut" lines shown,
and fax it, for the fastest reply to:                  718-227-9125  
(this is a fax # in the USA)</bigger></bigger></bigger></color>

</bold>

<bold>or send via smail (first class mail or airmail) to:    

                                         Tempting Tear-Outs

                                         Att. Free-catalogue-by-email
Dept

                                         3835 Richmond Ave.  Suite
#200

                                         Staten Island NY  10312-3828

                                         USA</bold>

<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>-->
IMPORTANT complete directions, to ensure that you get a reply, and more
info follow, below the reply form and the catalogue
options.</bigger></bigger></bigger></color></bold>

<bold><italic>*------------cut
here/begin-------------------------------------------*</italic>

Name:

Internet email address:

Smail home address:

City-State-Zip:

Country:

Work Tel. #:

Work Fax #:

Home Tel. #:

Home Fax #:

How did you hear about us (name of person/company who referred you or
the area of

the internet that you saw us mentioned in):  Referral by: Tempting
Tear-Outs     

011897-l

Name of USA mags you currently get on the newsstand or in the store:

Name of USA mags you currently get on a subscription basis, through the
mail:

Name of USA mags you would like price quotes on when we call you:

Catalogue version desired (list number of choice below):

<italic>*------------cut
here/end--------------------------------------------*</italic>

</bold>

<bold>CATALOGUE VERSION CHOICES</bold>:

<bold>1.</bold>  This version can be read by everyone, no matter what
type of 

     computer you use, or what type of software you use.  It is a
simple

     format, with just <bold>our entire catalogue pasted into the body
of a 

    single email message, 316K in size.</bold>  If you use pine or elm
on a unix 

     system or an advanced software version such as Eudora Pro 3.0 or

     later, you will most likely receive it as a single email message. 

     However, if your software limits incoming email messages to a     

     certain size, say 32K or so, then your software will split it into

     multiple email message parts.   Whether you receive it as a single

     email message or multiple part email messages, you can easily 

     paste it into one whole text document with your word processor, in

     about 10 minutes or so.

<bold>2.</bold>  For more advanced computer users:  <bold>attached text
file ~316K</bold> - you

     must know how to download an attached text file and then be able
to

     open it with your word processor.  If in doubt, don't ask for
this

     version.  This isn't for internet *newbies.* Better to order
option 1

     and spend a few minutes pasting them into one whole text document

     with your word processor, than to waste hours trying to figure
how

     to deal with this option.   This version is great for doing word

     searches and jumping around within the catalogue with your word 

     processing software, if your normal email reading software doesn't

     allow this.

<bold>3. </bold> For more advanced <bold>Macintosh</bold> computer
users: compressed attached

     text file, created with a <bold>Stuffit(tm) self-extracting
archive (.sea),

    ~140K.</bold>  Can be decompressed by any Macintosh computer user;
no

     special expansion software or knowledge of Stuffit (tm) needed. 
You

     just double-click on the file icon and it automatically expands

     (unstuffs). This is for more advanced mac computer users only, as

     you still have to know how to deal with an attached file.  It will
cut

     your download time by 55%.   Expands out to the same ~316K file
in

     option #2.  See option #2 for more info on what you will need to
be

     able to do.

<bold>4.</bold>  For expert <bold>mac or pc computer users</bold>:
compressed attached text file, 

     created with <bold>Stuffit(tm),  ~116K</bold>.  Can be
decompressed by any 

     computer user who has expansion software to decompress (expand) 

     Stuffit(tm)<bold> (.sit)</bold> files.  This is for more advanced
computer users only

      and will cut your download time by 63%.   Expands out to the same

     ~316K file in option#2.  See option #2 for more info on what you
will 

     need to be able to do.

<bold>5.</bold>  For expert pc or mac computer users: <bold>compressed
attached text file, 

    in a .zip file format, ~143K. </bold>  Can be decompressed by any
computer

      user who has expansion software to decompress (expand) .zip
files.

      This is for more advanced computer users only and will cut your 

      download time by 54%.   Expands out to the same  ~316K file in 

      option#2.   See option #2 for more info on what you will need to
be

      able to do.

<bold><color><param>FFFF,0000,0000</param><bigger><bigger><bigger>VERY
IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A
REPLY:</bigger></bigger></bigger></color></bold>

1.   you must call from an "unblocked number," ie. one that is not
blocked from caller id.  We are very sorry for this requirement, but
our fax software requires this before it allows an incoming fax call to
connect.   If you have a blocked number, you must first unblock it.  In
most cases this means dialing *82 from a touch-tone phone (or 1182 from
a rotary phone) before you dial 1-718-227-9125.     NOTE:  If you are
not sure if your number is blocked, just try dialing our fax #
normally.  If you don't get a recording telling you your number is
blocked, your number has been transmitted and you may press the start
button on your fax when you hear the fax tone from our fax.

2.   no reply forms can be accepted by email....only via fax or smail. 

3.   your form must be typewritten or printed out on your computer
printer before you fax it;  ie. no handwritten forms can be accepted.

4.   faxes with cover pages will be rejected.  You must send *only* the
reply form.

5.   forms not *completely* filled in will not be acknowledged.

6.   you will receive a reply within 1 business day directly from the
company making the offer via email.  Therefore you must have an email
address.  If you read this message, then you must have an email
address, or access to one, at least.   :-)

7.   your fax must not exceed 1 page in length.   Faxes of 2 or more
pages will be sensed, then auto-terminated and deleted.  Your fax goes
directly onto our 5.0 gigabyte hard drive and we must limit all
incoming faxes to 1 page.

8.   all faxes must begin with:

*------------cut
here/begin-------------------------------------------*

and must end with:

*------------cut here/end--------------------------------------------*

9. Any fax not conforming to this format will be sensed by our
software, then auto-terminated and deleted from the hard drive, before
any human ever gets to see it.

10.  If this all seems too complicated for faxing, just do it the old
fashioned way via smail!!!

<bold>WHO WE ARE:</bold>

Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.

<bold>MORE ABOUT THE COMPANY MAKING THE FREE OFFER:</bold>

The company making the offer is a magazine subscription agency based in
the USA.  They have over 1,500 popular USA titles available to be
shipped to *any* country, including of course, to anywhere in the USA! 
  <bold><underline>They offer a FREE 1 yr. subscription to your choice
of over 270 of the titles in their catalogue to any new customer using
them for the first time.</underline></bold>       The  dollar value of
the freebies, based on the subscription prices directly from the
publishers, ranges from $6.97 all the way up to $50.00!

For new customers in the USA, there is no charge for FPH (foreign
postage & handling), so the freebie is 100% free!   For new customers
living overseas, the only charge on the freebie would be for the FPH
(foreign postage & handling).

Their president has been in the magazine subscription business since
1973 and they are very customer-service oriented.   They will even help
you with address changes on your magazines, even if you move from one
country to another country.   They have thousands of happy customers in
over 59 countries.

<bold>Their price guarantee is very simple:       they guarantee that
their subscription prices are the lowest available and they will BEAT
any legitimate, verifiable offer before you pay them or match it
afterwards, by refunding you the difference in price PLUS the cost of
the postage stamp you would use sending in the special offer to them,
even 6 months after you pay them, as long as it was current at the time
of your offer.    Does that sound fair?       Wouldn't it be great if
everything you bought came with that price guarantee? </bold> 

Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around.     With 1,500 titles on their list,
they would like to think that they have also the best selection
around!

Within the USA, for their USA customers, they are cheaper than all
their competitors and even the publishers themselves.  This is their
price guarantee.         The 1 yr. freebie that you get with your first
order is completely free!   

Overseas, (even after you factor in the cost of the FPH (foreign
postage & handling) and the conversion from USA Dollars to your
currency), on the average, they are generally around one-fourth to
one-half of what the newsstands overseas charge locally for USA
magazines.  On some titles they are as little as one-tenth of what the
newsstands charge.  They are also the cheapest subscription source for
delivery overseas, including directly from the publishers themselves!  
Some publishers don't even offer subscriptions overseas.........but
overseas subscriptions are this company's specialty!  They feel that
magazines should not be a luxury overseas.   In the USA, people buy
magazines and then toss them after reading them for just a few minutes
or hours.  They are so cheap in the USA!   Well, this company would
like to make it the same way for their overseas members.  They are also
cheaper than all their competitors in the USA and overseas, including
the publishers themselves!   It is also *highly unlikely* you will find
any of their USA competitors calling you overseas, in order to offer
that personal touch, just to sell you a couple of magazines!  But that
is what this company specializes in and loves doing!     Around
one-half their business comes from overseas, so they are very patient
with new members who only speak limited English as a 2nd language.   
Subscription prices quoted for overseas consist of the subscription
price, plus the FPH.   You add the two together and that is your total
cost.   The exception is the 1 yr. freebie you get with your first
order.   On that title, you pay *only* the FPH for the 1 yr. term.

<bold><underline>Their prices are so cheap because when you deal with
them, you cut-out all the middlemen.</underline></bold>

<bold><bigger><bigger>HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED
WITH THEM:</bigger></bigger></bold>

<bold>Simply fax or smail back to us the reply form listed at the top
of this message.</bold>   We will then forward your form on to the
subscription agency.  They will then email their "big and juicy"
catalogue to you, in whichever of the four formats you chose.   The
catalogue is FREE and makes for hours of fascinating reading, on its
own. It includes the complete list of freebies, a complete list of all
the titles they sell, as well as detailed descriptions on most of the
titles, along with lists of titles by category of interest and their
terms of sale.    

They will then give you a friendly, no-pressure, no obligation,
5-minute call to go over how they work and to answer any questions that
you might have, as well as give you up-to-the minute price quotes on
any titles you might be considering.     They will call you in whatever
country you live in, taking the time difference into account.        As
they like to emphasize the personal touch they give to each new
customer, all first-time orders can only be done via phone, so they can
answer all your questions completely and personally.   Once you have
placed your first order via phone, you will be able to place future
orders and make inquiries on your account, get price quotes, etc., all
via email, if that is most convenient for you.

Within the USA, they accept payment via check over the phone,
Mastercard, Visa and American Express.      Overseas, they accept
Mastercard, Visa and American Express, even if your credit card is a
local one in local currency!

That's our introduction of our client that we represent.   We hope that
we have piqued your interest and that you will take the next step to
get their free catalogue!   Thank you for your time and interest.

<bold><color><param>0000,FFFF,0000</param>--

Tempting Tear-Outs.

For more info on advertising rates, please write us on your company
letterhead, w/business card, via smail to:   Tempting Tear-Outs, 3835
Richmond Ave. Suite #200, Staten Island NY  10312-3828, USA.
</color></bold><color><param>0000,FFFF,0000</param> </color>           

- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Date: Wed, 15 Jan 97 06:31:08 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,

> however, is it too late to add it to bgp4?  the arguments
> in favor of it are (1) it's a minor feature that adds
> flexibility to the protocol and (2) something needs to be
> done anyway to fix the contradiction about whether to die
> or ignore unknown options.  the argument against it is that
> the spec is nigh going from draft to [full] standard, so
> can we add a feature (no matter how small) or do we have to
> live with picking one of "die" or "ignore"?

Just to add another piece of information, RFC1771 (BGP-4 Draft
Standard) specifies that if an optional parameter is not recognized,
then the connection should be terminated (see previous to the last
paragraph in Section 6.2 of RFC1771).  So, the notion that an
unrecognized optional parameter may be ignored wasn't in the Draft
Standard.

I think it would help the WG to make a decision if Joel would shed more
light on whether the IESG would have any problems if we would put the
the change you proposed into BGP-4, as it moves from a Draft Standard
to a Full Standard.

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

Date: Mon, 13 Jan 97 14:17 PST
From: [email-masked] (Randy Bush)
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Sender: [email-masked]

is it possible that, given a dozen or so optional parameters, their
mandatoryosities <g> might interact?  i.e. X is mandatory only if Y
is [not] understood.

randy
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Date: Mon, 13 Jan 1997 17:07:54 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

structuring the optional parameters to allow for this
"implicit negotiation" is something i like and something
that i've talked about on this list for bgp5 in the past
few weeks.  so i like the idea

however, is it too late to add it to bgp4?  the arguments
in favor of it are (1) it's a minor feature that adds
flexibility to the protocol and (2) something needs to be
done anyway to fix the contradiction about whether to die
or ignore unknown options.  the argument against it is that
the spec is nigh going from draft to [full] standard, so
can we add a feature (no matter how small) or do we have to
live with picking one of "die" or "ignore"?

i think i'd like to see it added to bgp4, though i *know*
i'd like to see it in bgp5

/jws

 > JJ,
 > 
 > >    Picking one is certainly an option as well.
 > >    
 > >    So, to summarize it seems like we have three options:
 > >    
 > >    1. Allow to either ignore unrecognized parameters, or to
 > >       shut down BGP connection when an unrecognized parameter received.
 > >    
 > >    2. Shutdown BGP connection when an unrecognized parameter received.
 > >    
 > >    3. Ignore unrecognized parameters.
 > > 
 > > I think we have yet another option....
 > 
 > Correct.
 >   
 > > The Parameter Type could contain a bit (say, the leftmost) saying
 > > whether understanding this parameter is a life-or-death matter
 > > (requiring option 2 above), or no big deal (allowing 3), which would
 > > give us some flexibility.
 > > 
 > > I would put "Authentication Information" into the former category.  So,
 > > to be backwards compatible, a zero in the leftmost bit of the Parameter
 > > Type means "shut down the connection if you don't understand this
 > > parameter."
 > > 
 > > I've probably missed something here (let me know), but if not, does this
 > > make sense?
 > 
 > It does make sense to me. 
 > 
 > Yakov.
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Date: Mon, 13 Jan 97 12:57:29 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

JJ,

>    Picking one is certainly an option as well.
>    
>    So, to summarize it seems like we have three options:
>    
>    1. Allow to either ignore unrecognized parameters, or to
>       shut down BGP connection when an unrecognized parameter received.
>    
>    2. Shutdown BGP connection when an unrecognized parameter received.
>    
>    3. Ignore unrecognized parameters.
> 
> I think we have yet another option....

Correct.
  
> The Parameter Type could contain a bit (say, the leftmost) saying
> whether understanding this parameter is a life-or-death matter
> (requiring option 2 above), or no big deal (allowing 3), which would
> give us some flexibility.
> 
> I would put "Authentication Information" into the former category.  So,
> to be backwards compatible, a zero in the leftmost bit of the Parameter
> Type means "shut down the connection if you don't understand this
> parameter."
> 
> I've probably missed something here (let me know), but if not, does this
> make sense?

It does make sense to me. 

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

Posted-Date: Mon, 13 Jan 1997 12:16:37 -0800 (PST)
Date: Mon, 13 Jan 1997 15:16:37 -0500
From: John Krawczyk <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: "John W. Stewart III" <[email-masked]>, [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Reply-To: [email-masked]
Sender: [email-masked]

   On Mon, 13 January, Yakov Rekhter ([email-masked]) wrote:

   John,
    
   > it's unfortunate that the spec contradicts itself.  but
   > rather than react by allowing two completely different
   > behaviors, why don't we just pick one and say that it
   > is the required behavior?  
   
   Picking one is certainly an option as well.
   
   So, to summarize it seems like we have three options:
   
   1. Allow to either ignore unrecognized parameters, or to
      shut down BGP connection when an unrecognized parameter received.
   
   2. Shutdown BGP connection when an unrecognized parameter received.
   
   3. Ignore unrecognized parameters.

I think we have yet another option....

The Parameter Type could contain a bit (say, the leftmost) saying
whether understanding this parameter is a life-or-death matter
(requiring option 2 above), or no big deal (allowing 3), which would
give us some flexibility.

I would put "Authentication Information" into the former category.  So,
to be backwards compatible, a zero in the leftmost bit of the Parameter
Type means "shut down the connection if you don't understand this
parameter."

I've probably missed something here (let me know), but if not, does this
make sense?

-jj
- - - - - - - - - - - - - - - - -

Date: Mon, 13 Jan 1997 13:45:45 -0600 (CST)
From: Brandon Black <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: "John W. Stewart III" <[email-masked]>, [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Sender: [email-masked]

Would it be possible to have answer number one ina contrlled fashion?
i.e. Have "required" and "optional" parameters?  Possibly a flag in the
parameter itself being transmitted could indicate whether the parameter is
required (drop connection if you don't support it) or optional (ignore it
if unrecognized)?  Maybe the high bit of the option's identifier could be
the flag?  Just a vague idea...

Brandon

On Mon, 13 Jan 1997, Yakov Rekhter wrote:

> John,
>  
> > it's unfortunate that the spec contradicts itself.  but
> > rather than react by allowing two completely different
> > behaviors, why don't we just pick one and say that it
> > is the required behavior?  
> 
> Picking one is certainly an option as well.
> 
> So, to summarize it seems like we have three options:
> 
> 1. Allow to either ignore unrecognized parameters, or to
>    shut down BGP connection when an unrecognized parameter received.
> 
> 2. Shutdown BGP connection when an unrecognized parameter received.
> 
> 3. Ignore unrecognized parameters.
> 
> Yakov.
> 

.................................             ..............
: Brandon Lee Black  : [Office] :.............: [Personal] :....
:....................: [email-masked] : [email-masked] :.......
: "Sanity is the     : +1.281.362.6466 .......: [email-masked] :
: trademark of a     :.................:..../\: [email-masked] :
: weak mind. . ."    : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
:....................:.....................:..:.................:

- - - - - - - - - - - - - - - - -

Date: Mon, 13 Jan 97 11:13 PST
From: [email-masked] (Randy Bush)
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Sender: [email-masked]

>>> It is assumed that new optional parameters could be added after the base
>>> spec is frozen.
>> If forwards compatibility causes the old system to fall over, what is meant
>> by compatibility?
> That would suggest that unrecognized optional parameters should be ignored.

Or that part of the spec is utterly useless.

randy
- - - - - - - - - - - - - - - - -

Posted-Date: Mon, 13 Jan 1997 11:07:27 -0800 (PST)
Date: Mon, 13 Jan 1997 14:07:28 -0500
From: [email-masked] (Dimitry Haskin)
To: [email-masked], [email-masked]
Subject: Re: handling optional parameters in BGP OPEN
Cc: [email-masked]
Sender: [email-masked]

> 
> John,
>  
> > it's unfortunate that the spec contradicts itself.  but
> > rather than react by allowing two completely different
> > behaviors, why don't we just pick one and say that it
> > is the required behavior?  
> 
> Picking one is certainly an option as well.
> 
> So, to summarize it seems like we have three options:
> 
> 1. Allow to either ignore unrecognized parameters, or to
>    shut down BGP connection when an unrecognized parameter received.
>
I think this is the most rational approach with the current BGP-4 spec,
i.e. fixing the spec the way that has no impact on the already deployed
product.
 
> 2. Shutdown BGP connection when an unrecognized parameter received.
> 
> 3. Ignore unrecognized parameters.
> 
> Yakov.
> 
Dimitry
- - - - - - - - - - - - - - - - -

Date: Mon, 13 Jan 1997 13:19:53 -0500
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Re: handling optional parameters in BGP OPEN
Cc: [email-masked]
Sender: [email-masked]

At 1:10 PM -0500 1/13/97, Howard C. Berkowitz wrote:
>Folks,
>
>Few days ago I posted a message asking about how BGP implementations
>handle unrecognized optional parameters in the OPEN. So far
>I received information about 3 implementations. Out of these
>two terminate BGP session, and one ignores the parameter.
>
>I would like to suggest that we change the text to allow
>both behaviors. That is an implementation could either
>terminate a session, or could ignore an unrecognized optional
>parameter.
>
>Any comments ?
>
>Yakov.

A mostly lurker comment here, but I am bothered by allowing both behaviors.
There is an argument in favor of both.  I believe a behavior should be
specified that supports general robustness or detailed control, but not
both. I lean toward the latter case given the applications of BGP.

IMHO, it would be in the general IP tradition, stated most recently in
RFC1812, to ignore the option.  This would emphasize the robustness
principle.

But it is arguable BGP connectivity is not something every implementation
does every day, and the operational environment in which it runs is closely
monitored.  Terminating the session would tend to cause an event that would
invoke manual review and intervention, which would in turn draw attention
to an interoperability issue -- why is the optional parameter being
proposed?  Should it be?  If it should, what needs to be done between the
specific implementations.

Howard

- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Date: Mon, 13 Jan 97 10:06:39 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
> it's unfortunate that the spec contradicts itself.  but
> rather than react by allowing two completely different
> behaviors, why don't we just pick one and say that it
> is the required behavior?  

Picking one is certainly an option as well.

So, to summarize it seems like we have three options:

1. Allow to either ignore unrecognized parameters, or to
   shut down BGP connection when an unrecognized parameter received.

2. Shutdown BGP connection when an unrecognized parameter received.

3. Ignore unrecognized parameters.

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

To: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Date: Mon, 13 Jan 97 10:01:55 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

> Few days ago I posted a message asking about how BGP implementations
> handle unrecognized optional parameters in the OPEN. So far
> I received information about 3 implementations. Out of these
> two terminate BGP session, and one ignores the parameter.

I received information about one more implementation. Now we
have a tie - two implementations terminate BGP sessions and
two ignore unrecognized parameters.

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

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Date: Mon, 13 Jan 1997 12:03:38 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

it's unfortunate that the spec contradicts itself.  but
rather than react by allowing two completely different
behaviors, why don't we just pick one and say that it
is the required behavior?  how many optional parameters
are there, anyway?  (i think i know of one that is used
only by one vendor.  the point being that this ends up
mostly being a bug fix in the spec without many
implications in terms of operation)

and while i think the "ignore unknown optional
parameters" semantic is useful because it allows new
message types to be added in a backwards-compatible
fashion, either is fine with me (and in fact going the
other way means work for only one implementor [that we
know of so far])

/jws

 > Folks,
 > 
 > Few days ago I posted a message asking about how BGP implementations
 > handle unrecognized optional parameters in the OPEN. So far
 > I received information about 3 implementations. Out of these
 > two terminate BGP session, and one ignores the parameter.
 > 
 > I would like to suggest that we change the text to allow
 > both behaviors. That is an implementation could either
 > terminate a session, or could ignore an unrecognized optional
 > parameter. 
 > 
 > Any comments ?
 > 
 > Yakov.
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: Re: handling optional parameters in BGP OPEN 
Date: Mon, 13 Jan 97 08:02:12 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Few days ago I posted a message asking about how BGP implementations
handle unrecognized optional parameters in the OPEN. So far
I received information about 3 implementations. Out of these
two terminate BGP session, and one ignores the parameter.

I would like to suggest that we change the text to allow
both behaviors. That is an implementation could either
terminate a session, or could ignore an unrecognized optional
parameter. 

Any comments ?

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

To: [email-masked]
Subject: handling optional parameters in BGP OPEN
Date: Thu, 09 Jan 97 10:28:06 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

It seems that the current text is self-contradicting wrt
handling optional parameters in BGP OPEN.

Quoting from 6.2, 3rd paragraph from the bottom:

   If one of the Optional Parameters in the OPEN message is not
   recognized, then the Error Subcode is set to Unsupported Optional
   Parameters.

Quoting from 6.2, last paragraph:

   If the OPEN message carries any other Optional Parameter (other than
   Authentication Information), and the local system doesn't recognize
   the Parameter, the Parameter shall be ignored.

I would appreciate input from BGP-4 implementors wrt how their
implementations handle unrecognized optional parameters in the
OPEN message. Please send this to me directly, and I'll summarize
the results to the list.

Thanks in advance.

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

Date: Thu, 09 Jan 1997 05:05:32 -0500
To: Dave Wreski <[email-masked]>
From: Paul Ferguson <[email-masked]>
Subject: Re: Basic BGP questions
Cc: "Dorian R. Kim" <[email-masked]>, [email-masked]
Sender: [email-masked]

Try inserting 'public' in place of 'customer' in the URL's
below. Usually works.

- paul

At 09:48 PM 1/8/97 -0500, Dave Wreski wrote:

>
>> I suggest the following readings:
>> 
>> http://amazing.netaxs.com/internet/
>> http://www.cisco.com/warp/customer/459/18.html
>> http://www.cisco.com/warp/customer/103/index.shtml
>> http://www.cisco.com/warp/customer/104/index.shtml
>> http://www.nanog/org/isp.html
>
>I'm sure the cisco ones are really great, but you need a CCO (??) number
>to access them.  I found some really great information at the last URL
>(eventually led me to 3com!) and I pulled a few great RFC's refered to me
>by Howard C. Berkowitz <[email-masked]>.
>

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 21:48:23 -0500 (EST)
From: Dave Wreski <[email-masked]>
To: "Dorian R. Kim" <[email-masked]>
Cc: [email-masked]
Subject: Re: Basic BGP questions
Sender: [email-masked]

On Wed, 8 Jan 1997, Dorian R. Kim wrote:

> I suggest the following readings:
> 
> http://amazing.netaxs.com/internet/
> http://www.cisco.com/warp/customer/459/18.html
> http://www.cisco.com/warp/customer/103/index.shtml
> http://www.cisco.com/warp/customer/104/index.shtml
> http://www.nanog/org/isp.html

I'm sure the cisco ones are really great, but you need a CCO (??) number
to access them.  I found some really great information at the last URL
(eventually led me to 3com!) and I pulled a few great RFC's refered to me
by Howard C. Berkowitz <[email-masked]>.

Thanks so much guys.  I really appreciate all you have helped me with.

Dave

-----------------------------------------------------------------------
"The opinions expressed here are my own and do not represent the views
or opinions of United Parcel Service, Inc."
-----------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 21:24:38 -0500
To: Dave Wreski <[email-masked]>
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Re: Basic BGP questions
Cc: [email-masked]
Sender: [email-masked]

I'm combining my response to several of Dave's postings.

>On Wed, 8 Jan 1997, Howard C. Berkowitz wrote:
>
>
>> I don't want to be negative, but it sounds as if you need to get a better
>> idea what you are trying to do before you even can define the requirements
>> for a routing protocol.  There are some white papers in CCO on "Choosing a
>> Routing Protocol," but these are at a fairly high level.  You might want to
>> think about something like the Cisco Internetwork Design course to get into
>> more detail.
>
>Thanks for your help, and point well taken.  After my last post, this
>point is even more true.  I wish there was a basic routing list that I
>could ask my stupid questions to :)

The Cisco newsgroup, comp.dcom.sys.cisco, or possibly
comp.protocols.tcp-ip, are closer to what you are looking for.

>
>Also, I see how one little typo can really screw up a message.  I
>understood that BGP was an exterior routing protocol (I'm trying to route
>from our network to someone else's out on the Internet), but I was
>actually trying to refer to cisco's proprietary external routing protocol,
>and thought IGRP was it :(

Well, you are actually right!  IGRP, and for that matter EIGRP, do have a
limited exterior routing capability, but only to other Ciscos.  BGP is the
standard exterior routing protocol of the Internet.

>
>What is Link State?  From what I have heard, OSPF is not something that
>would be useful.

Dave.  Trust me on this.  I'm a Redskin fan.  My wife is a Dallas fan.
There are some religious wars you don't want to get into. :-)  Suffice it
to say that link state, distance vector, and diffusing update (EIGRP's
variant on classic distance vector) are all underlying algorithms for
routing table computation.  In this discussion, they are used in interior
routing. You wouldn't use OSPF _or_ EIGRP on the link to your ISP.

My advice to an enterprise connecting to an ISP is to use static and
default routing to the maximum extent possible, only using BGP if you have
to -- and the need for BGP has been confirmed by someone experienced.  Let
me put it this way...when I had a coronary bypass, I was very happy my
surgeon did several per week.  The most dangerous thing for a heart patient
is a part-time heart surgeon.  Just knowing the BGP protocol itself, as
complicated as it is, is not enough.  IMHO, to handle BGP routing
effectively, you have to stay in constant touch with Internet operational
issue and major carrier policies.

>
>I have read, and I believe I understand, what an AS is.
>

>What I still don't understand is if I have two equal-sized links to one
>point in the network (dual-homing?) from an ISP, and two equal-sized links
>to another part of the network from an ISP, wouldn't I just use BGP to
>route to the ISP from each of the links?

If these are the same ISP, you might not need BGP at all.  One basic way to
do this -- and there are many nuances to this -- is simply to have both
routers that connect to an ISP advertise the default into your interior
routing protocol.  Internal devices will simply go to the default router
that's closest to them in terms of internal metric.

>I don't think the internal
>routing information would leave our network; does that mean that we don't
>have an AS?

Exactly.  If all your Internet connectivity is via the ISP, you probably
don't need your own AS.  The rest of the world sees you as part of the
ISP's AS.  Be sure to read    http://ds.internic.net/rfc/rfc1930.txt
"Guidelines for creation, selection, and registration  of an Autonomous
System (AS)"

>I would assume our ISP would have an AS, and very well may
>have more than one, depending on how far geographically the two links from
>the ISP are to our network.
>
>If each link was routed from the ISP to a firewall, couldn't I just use
>static routing?

Quite likely.  In fact, on Ciscos and probably most other major router
implementations, you can set up load-balancing among static routes to the
ISP.
>
>How does CIDR work into this, or shouldn't I worry about that at this
>point?

You absolutely should worry about CIDR.  (Worry sounds _so_ negative
though)  CIDR is the fundamental way Internet addresses are assigned.  Your
interior routing protocol really needs to understand CIDR/VLSM.  The
addressing policies that make this necessary are in, among other things,
http://ds.internic.net/rfc/rfc2050.txt.

Hank Nussbacher runs a CIDR FAQ well worth reading, although I don't have
the URL in front of me.  I'm sure someone will chip in with it.

As long as you are thinking about your addressing -- and you should be --
be aware that IP addresses involved in exterior connectivity are apt to
change.  Be ready to renumber when appropriate.  With all due modesty, I'll
refer you to  http://ds.internic.net/rfc/rfc2071.txt and
http://ds.internic.net/rfc/rfc2072.txt

>A previous post mentioned "Routing on the Internet", and my local Barnes
>and Noble have it.. Gonna spend the fifty bucks..
>
An excellent book. There will be several new books out this summer from
CiscoPress that deal with issues here, but they aren't here yet.

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 17:11:19 -0800
From: Dave Katz <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Basic BGP questions
Sender: [email-masked]

EIGRP is still DV;  it just has a very interesting twist in dealing with
Bad News.  The routing information sent is fundamentally the same as
RIP (VLSM notwithstanding).

   Date: Wed, 8 Jan 1997 19:47:29 -0500 (EST)
   From: "Dorian R. Kim" <[email-masked]>
   Mime-Version: 1.0
   Content-Type: TEXT/PLAIN; charset=US-ASCII
   Sender: [email-masked]
   Precedence: bulk

   > On Wed, 8 Jan 1997, Gregory Mirsky wrote:
   > 
   > > IGRP like OSPF is an interior for Autonomous System routing protocol.
   > > If you're looking for a dynamic routing protocol for a group of routers
   > > controlled by one administrator then either one will serve you well.
   > > There are some differences between IGRP and OSPF (OSPF is an IETF standard
   > > and supported by most of vendors while IGRP is a proprietary), but they
   > > are both Link State and are comparable.

   Just one point. IGRP is not a link state routing protocol but rather a
   distrance vector routing protocol, and since it, doesn't understand VLSM,
   should really be considered historical, along with with RIPv1, which already
   is.

   EIGRP is a different matter.

   -dorian

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 17:05:28 -0800
From: Dave Katz <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Basic BGP questions
Sender: [email-masked]

Um, I'm not going to wade into this one other than to say that IGRP
(and EIGRP) are decidedly *not* link-state protocols.  They are both
unrepentant distance-vector protocols.

--Dave

   Date: Wed, 8 Jan 1997 18:43:30 -0500 (EST)
   From: Dave Wreski <[email-masked]>
   X-Sender: tel1dvw@butthead
   Mime-Version: 1.0
   Content-Type: TEXT/PLAIN; charset=US-ASCII
   Sender: [email-masked]
   Precedence: bulk

   On Wed, 8 Jan 1997, Gregory Mirsky wrote:

   > > I basically don't understand how they can do load balancing, and work in
   > > conjunction with round-robin-type solutions.

   Thanks much for the explanation.  That sure is alot to think about.  

   > 
   > Hi Dave,
   > IGRP like OSPF is an interior for Autonomous System routing protocol.
   > If you're looking for a dynamic routing protocol for a group of routers
   > controlled by one administrator then either one will serve you well.
   > There are some differences between IGRP and OSPF (OSPF is an IETF standard
   > and supported by most of vendors while IGRP is a proprietary), but they
   > are both Link State and are comparable.

   What is Link State?  From what I have heard, OSPF is not something that
   would be useful.  I have read, and I believe I understand, what an AS is. 
   What I still don't understand is if I have two equal-sized links to one
   point in the network (dual-homing?) from an ISP, and two equal-sized links
   to another part of the network from an ISP, wouldn't I just use BGP to
   route to the ISP from each of the links?  I don't think the internal
   routing information would leave our network; does that mean that we don't
   have an AS?  I would assume our ISP would have an AS, and very well may
   have more than one, depending on how far geographically the two links from
   the ISP are to our network.

   If each link was routed from the ISP to a firewall, couldn't I just use
   static routing?

   How does CIDR work into this, or shouldn't I worry about that at this
   point?

   > BGP is mostly used as an exterior routing protocol when you need to exchange
   > routing information among numerous Autonomous Systems controlled by different
   > organizations.
   > Though there is iBGP portion of BGP for interdomain routing I'd suggest to
   > use OSPF or IGRP if you don't need to exchange routing information with
   > another AS.

   > For load balancing you can probably use multipath options and IP Policies.
   > Latter affects propagation of routing information whithin and outside of AS.

   Is channel-bonding something that people often do?

   > 
   > Don't hesitate to ask questions.

   Thanks, I really appreciate that.  Low-level networking is really what I'm
   interested in, I one day hope my information can be useful to someone.

   I hope I don't seem completely clueless; I figured asking basic questions
   rather than guessing would be better.

   > 
   > 	Greg Mirsky
   > 

   -----------------------------------------------------------------------
   "The opinions expressed here are my own and do not represent the views
   or opinions of United Parcel Service, Inc."
   -----------------------------------------------------------------------
   echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 19:58:31 -0500 (EST)
From: "Dorian R. Kim" <[email-masked]>
Reply-To: "Dorian R. Kim" <[email-masked]>
To: Dave Wreski <[email-masked]>
Cc: [email-masked]
Subject: Re: Basic BGP questions
Sender: [email-masked]

I suggest the following readings:

http://amazing.netaxs.com/internet/
http://www.cisco.com/warp/customer/459/18.html
http://www.cisco.com/warp/customer/103/index.shtml
http://www.cisco.com/warp/customer/104/index.shtml
http://www.nanog/org/isp.html

While they may not answer all your questions, I think they'll give you a
decent start.

There are several mailing lists that are more suitable for answer your
questions, ans [email-masked] is for protocol development of the BGP routing
protocol. Hope his helps,

-dorian

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 19:47:29 -0500 (EST)
From: "Dorian R. Kim" <[email-masked]>
To: Dave Wreski <[email-masked]>
Cc: [email-masked]
Subject: Re: Basic BGP questions
Sender: [email-masked]

> On Wed, 8 Jan 1997, Gregory Mirsky wrote:
> 
> > IGRP like OSPF is an interior for Autonomous System routing protocol.
> > If you're looking for a dynamic routing protocol for a group of routers
> > controlled by one administrator then either one will serve you well.
> > There are some differences between IGRP and OSPF (OSPF is an IETF standard
> > and supported by most of vendors while IGRP is a proprietary), but they
> > are both Link State and are comparable.

Just one point. IGRP is not a link state routing protocol but rather a
distrance vector routing protocol, and since it, doesn't understand VLSM,
should really be considered historical, along with with RIPv1, which already
is.

EIGRP is a different matter.

-dorian

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 19:02:02 -0500 (EST)
From: Dave Wreski <[email-masked]>
To: [email-masked]
Subject: Re: Basic BGP questions
Sender: [email-masked]

On Wed, 8 Jan 1997, Howard C. Berkowitz wrote:

> I don't want to be negative, but it sounds as if you need to get a better
> idea what you are trying to do before you even can define the requirements
> for a routing protocol.  There are some white papers in CCO on "Choosing a
> Routing Protocol," but these are at a fairly high level.  You might want to
> think about something like the Cisco Internetwork Design course to get into
> more detail.

Thanks for your help, and point well taken.  After my last post, this
point is even more true.  I wish there was a basic routing list that I
could ask my stupid questions to :)

Also, I see how one little typo can really screw up a message.  I
understood that BGP was an exterior routing protocol (I'm trying to route
from our network to someone else's out on the Internet), but I was
actually trying to refer to cisco's proprietary external routing protocol,
and thought IGRP was it :(

A previous post mentioned "Routing on the Internet", and my local Barnes
and Noble have it.. Gonna spend the fifty bucks..

Thanks again,
Dave Wreski

> 
> Howard Berkowitz
> PSC International

-----------------------------------------------------------------------
"The opinions expressed here are my own and do not represent the views
or opinions of United Parcel Service, Inc."
-----------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 18:43:30 -0500 (EST)
From: Dave Wreski <[email-masked]>
To: [email-masked]
Subject: Re: Basic BGP questions
Sender: [email-masked]

On Wed, 8 Jan 1997, Gregory Mirsky wrote:

> > I basically don't understand how they can do load balancing, and work in
> > conjunction with round-robin-type solutions.

Thanks much for the explanation.  That sure is alot to think about.  

> 
> Hi Dave,
> IGRP like OSPF is an interior for Autonomous System routing protocol.
> If you're looking for a dynamic routing protocol for a group of routers
> controlled by one administrator then either one will serve you well.
> There are some differences between IGRP and OSPF (OSPF is an IETF standard
> and supported by most of vendors while IGRP is a proprietary), but they
> are both Link State and are comparable.

What is Link State?  From what I have heard, OSPF is not something that
would be useful.  I have read, and I believe I understand, what an AS is. 
What I still don't understand is if I have two equal-sized links to one
point in the network (dual-homing?) from an ISP, and two equal-sized links
to another part of the network from an ISP, wouldn't I just use BGP to
route to the ISP from each of the links?  I don't think the internal
routing information would leave our network; does that mean that we don't
have an AS?  I would assume our ISP would have an AS, and very well may
have more than one, depending on how far geographically the two links from
the ISP are to our network.

If each link was routed from the ISP to a firewall, couldn't I just use
static routing?

How does CIDR work into this, or shouldn't I worry about that at this
point?

> BGP is mostly used as an exterior routing protocol when you need to exchange
> routing information among numerous Autonomous Systems controlled by different
> organizations.
> Though there is iBGP portion of BGP for interdomain routing I'd suggest to
> use OSPF or IGRP if you don't need to exchange routing information with
> another AS.

> For load balancing you can probably use multipath options and IP Policies.
> Latter affects propagation of routing information whithin and outside of AS.

Is channel-bonding something that people often do?

> 
> Don't hesitate to ask questions.

Thanks, I really appreciate that.  Low-level networking is really what I'm
interested in, I one day hope my information can be useful to someone.

I hope I don't seem completely clueless; I figured asking basic questions
rather than guessing would be better.

> 
> 	Greg Mirsky
> 

-----------------------------------------------------------------------
"The opinions expressed here are my own and do not represent the views
or opinions of United Parcel Service, Inc."
-----------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 18:20:17 -0500
To: Dave Wreski <[email-masked]>
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Re: Basic BGP questions
Cc: [email-masked]
Sender: [email-masked]

At 3:30 PM -0500 1/8/97, Dave Wreski wrote:
>Hi all.  I'm basically just learning BGP, to see if it meets our needs.
>Could someone either explain to me, or point me in the direction of, a
>document that explains the differences between BGP and IGRP?  Maybe a link
>at cisco that explains what IGRP actually is?
>

For all practical purposes, BGP and IGRP are completely different protocols
intended to do different things.

Simpifying incredibly, BGP is intended to run between organizations that
have different policies on what addresses are reachable through them --
these addresses can be contained inside the organization (e.g., in an
enterprise) or reachable via the organization (e.g., the organization is an
internet service provider that interconnects enterprises).  In general, the
question is whether you need BGP at all, or simpler mechanisms are quite
adequate.

There's a saying in the Old Army:  "When do you need a pistol?  Only when
you need it very, very much."  BGP is like that.  Most of its applications
involve global Internet routing, or equivalent multi-organization utilities
such as secure military networks.  It is rare, but not unheard of, to use
BGP to interconnect major parts of very large enterprises (e.g., Chrysler).

IGRP, OSPF, EIGRP, and IS-IS are intended for use inside an enterprise.
They are concerned with the most efficient way to reach an address.  They
have a general assumption that if a path to a resource exists, it is
usable; if there is more than one path, the most effective one is taken.
BGP, on the other hand, is more concerned with first determining if a path
is permissible.

While IGRP and EIGRP have been used for exterior routing, that's really not
what they are designed for.  In any case, IGRP is obsolescent at best;
EIGRP has replaced it as Cisco's proprietary interior routing protocol.
IMHO, the practical choice of an interior routing protocol for an
enterprise is between OSPF and EIGRP.

>I basically don't understand how they can do load balancing, and work in
>conjunction with round-robin-type solutions.
>
Simple answer:  BGP doesn't attempt to load balance.  The policy issues
with which it has to deal are so complex that attempting to load balance
would be an unneeded complication.  Indeed, BGP may not have the
information to make accurate load balanced decision in a multiprovider
Internet.

There are actually many definitions of load balancing, and it can generally
be said that modern interior routing protocol implementations (e.g., OSPF
and EIGRP) have an assortment of mechanisms for doing so.

I don't want to be negative, but it sounds as if you need to get a better
idea what you are trying to do before you even can define the requirements
for a routing protocol.  There are some white papers in CCO on "Choosing a
Routing Protocol," but these are at a fairly high level.  You might want to
think about something like the Cisco Internetwork Design course to get into
more detail.

Howard Berkowitz
PSC International

- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 15:30:38 -0500 (EST)
From: Dave Wreski <[email-masked]>
To: [email-masked]
Subject: Basic BGP questions
Sender: [email-masked]

Hi all.  I'm basically just learning BGP, to see if it meets our needs.
Could someone either explain to me, or point me in the direction of, a
document that explains the differences between BGP and IGRP?  Maybe a link
at cisco that explains what IGRP actually is?

I basically don't understand how they can do load balancing, and work in
conjunction with round-robin-type solutions.

Thanks much,
Dave Wreski

-----------------------------------------------------------------------
"The opinions expressed here are my own and do not represent the views
or opinions of United Parcel Service, Inc."
-----------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

- - - - - - - - - - - - - - - - -

Posted-Date: Wed, 8 Jan 1997 09:27:04 -0800 (PST)
Date: Wed, 8 Jan 1997 12:27:05 -0500
From: [email-masked] (Dimitry Haskin)
To: [email-masked]
Subject: Re: a different proposal for ipv6 in bgp
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Tony,

> 
>  Dimitry Haskin <[email-masked]> writes:
>   * At 04:53 PM 1/6/97 -0800, Dave Katz wrote:
>   * >It remains unclear to me why it is desirable to couple multiprotocol
>   * >support and the AS number space increase.  The two functions are
>   * >completely orthogonal and as far as I can tell there is no benefit for
>   * >*mandating* that the two changes be made at the same time.
>   * >
>   * >Clearly the multiprotocol stuff could be deployed and become useful
>   * >more quickly than the AS number extension, due to the fact that it
>   * >can be done in a backward compatible, pairwise fashion.
>   * >
>   * I don't believe that this assessment is accurate.  The BGP5 proposal
>   * is as backward compatible (if not more) with BGP4 as the proposed multiprot
>   * ocol 
>   * extension to BGP4.  I.e., v4 routing information exchanged between BGP5
>   * peers can be fully re-advertised via BGP4 and vise versa.  As you might not
>   * ice
>   * we even didn't require to immediately extend AS number space for v4
>   * to keep the v4 related changes to a bare minimum.  To support v6, bgp data
>   * structures need to change any way and v6 has no backward compatibility
>   * issue at this point. Thus it only makes sense to get a larger AS space for
>   * v6 now
>   * to avoid another transition later.
>   * 
> 
> Let's perhaps look at this a little differently. Since widespread
> deployment of BGP4 and the hassle of transition from BGP3 (for those
> of us who went through this, it was certainly not something to do more
> than say a couple of times in your lifetime and in that case we were
> driven by an immediate need) we have actually been able to add several
> new attributes (communities, reflection, etc) to keep enhancing
> inter-domain routing capabilities (all in use today) with very little
> pain.

We definitely not proposing a transition of the grand-scale of moving
from the classfull to classless routing paradigm.  I can assure you that
what we're proposing is of a much smaller scale, practically no scale at all.
And our intention was to make it even more extensible than BGP4.

>The reason we've been able to do this is becuase we essentially
> haven't messed with the underpinnings of the protocol itself.

Neither did we.

> The operational factors in doing this are much greater than perhaps many
> folks realize (ISPs tell me different if you think I'm
> overstating). In your proposal, before I can get benefit of the pain I
> need to move I have the entrie Internet moved over to BGP5.

This is definitely an overstatement.

> I understand I can use it for multiprotocol on a pairwise basis
> providing I dont touch the AS space but this doesn't seem like too
> much of a win when I can add attributes to the exisiting BGP4 protocol
> and start using BGP for multi-protocol interdomain support in an
> understood and well-practiced operational way.

This is a win because we don't have to drag 2-byte ASN into IPv6.
There is enough discomfort with the 2-byte ASN to make me belive that
dragging 2-byte ASN into v6 as a bad idea. And the most important it
is _not_ necessary.  Is it v6 that all this multiprotocol support
is really about?

And, if you want, you can use the option of gradually extending ASN for
v4 too.  For some, probably long,  period simple mapping of zero-extended
4-byte ASN into 2-byte ASN used by BGP4 will ensure backward compatibility
with BGP4.

> 
>   * >The deployment considerations for multiprotocol support are far less
>   * >onerous than the AS number stuff.
>   * >
>   * Care elaborate (in light of the BGP5 proposal)? 
>   *  
> See above.

See above.

> 
> If you buy into my ease of deployment point above [and of course you
> might not] let's look at where we are in terms of AS space as this is
> other factor driving the current discussuion.  Since I've started the
> CIDR report I produce I've also been tracking the activity of ASes in the
> global routing system as seen in BGP by a well connected router. The
> interesting trend you see is the growth of ASes in the global routing
> system is essentially linear. Whilst my data source is quite small (see
> http://www.remplyees.org/~tbates/cidr.as.plot.html) this seems to be
> growing at an average rate of 3 ASes per day. The linear growth if
> further backed in "An analysis of Internet Inter-Domain Topology and
> Route Stability" by Ramesh Govindan and Anoop Reddy from USC/ISI.
> 
> If we use this growth rate and look at a couple of scenarios:
> 
> Best Case 
> ---------
> Assuming we have 65000 (not including Private ASes) ASes and
> accounting for the 1937 ASes already in the system (this also assumes
> we could re-use ones pre-allocated and not currently being used which
> is probably over optimistic) we have 63063 ASes to play with resulting
> in :
> 
>         63063/3 = 21021 Days
>         21021/365 = 57 Years before we run out.
> 
> Worst Case
> ----------
> 
> If we assume 15535 ASes will in fact be wasted (private space,
> early/bad allocations before RFC1930, some ISPs getting as AS 
> for the wrong reason) we still end up with.
> 
>         (50000-1937)/3/365 = 43.8 years
> 
> Now you could argue that this doesn't take into account the increasing
> trend towards mutlihoming (not currently shown in the AS growth either
> but anyway ;-)). However, there are a number of things to help with
> this approach. 
> 
> 1. Improving use of private AS space. ISP router should be able to
>    override customer's AS with a preconfigured number. ISP router
>    shouldn't propagate a route to a customer router if the route includes
>    AS of the customer (this AS is preconfigured on the ISP router).
> 
> 2. Use RIPv2 (instead of BGP) - doesn't require AS number at all.
> 
> 3. Use single globally unique AS number (draft-stewart-bgp-without-as-00.txt)
>

None of that will be necessary for v6 if we use a larger ASN space there.
 
> So with this in mind do we really want to tackle the AS number issue
> right now at the risk of the operational impact ?

You still didn't convince me that there is a significant operational impact
with the BGP5 proposal.  If you afraid to extend ASN for v4, we don't force
you to do so. But we want a larger ASN space for v6.  Would you agree that
there is a zero operational impact for v6 at this point? If it not for v6 we,
most probable, would be looking in extending BGP-4, don't we?

> If the answer is yes
> (which I must abmit seems hard to see from my viewpoint) then we
> better make sure we look at all aspects before spinning the protocol
> again wouldn't you agree ?
>
Sure.
> 		--Tony
Dimitry
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-5 proposal.. 
Date: Wed, 08 Jan 1997 12:15:47 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

 > > if you change the OPEN message, then wouldn't you need to
 > > change the version number?  
 > 
 > I think that was assumed - Ravi was talking about BGP-5.

ok

 > > and if you change the version
 > > number, then isn't it kind of a hack to put IPv4 NLRI in
 > > the NLRI field but non-IPv4 NLRI in an attribute?
 > 
 > Read carefully item (1):
 > 
 > >  > 1. Replace how NLRI, next hop, and withdrawn routes are presently
 > >  >    carried with MP_NLRI_REACH and MP_NLRI_UNREACH attributes.
 > 
 > Which means *all* NLRI information (IPv4, IPv6, etc...) will be
 > carried in MP_NLRI_REACH and MP_NLRI_UNREACH attributes. 

ok

so the UPDATE message would have a "path attributes" field
but no [explicit] NLRI field?  it seems like an odd syntactic
change, but it would satisfy my concerns about giving bgp a
longer lifetime

one of the strengths of the bgp5 draft, thanks to dimitry, is
the presence of the bgp4 compatible update along with the new
multi-protocol one.  with the latter you get bigger ASs, but
with the bgp4-compatible one you get more certainty about
being able to advertise ipv4-with-2-byte-ASs routing info
heard via bgp5 to a bgp4 speaker.  there are some specifics
like this that are probably good things to have, but i'm sure
we can come to an aggreement on them

 > > your message is a good lead-in to something that i've
 > > been thinking about.  in trying to come up with a
 > > backwards-compatible multi-protocol bgp4, my first idea
 > > was to add an optional parameter to the OPEN message
 > > saying "i support MULTI-PROTOCOL-UPDATE messages."  but
 > > after 5 seconds of thinking i realized that this is not
 > > backwards compatible because a vanilla bgp4
 > > implementation would die right away with an "unsupported
 > > optional parameter" error.  so the question is, should
 > > there be two different sets of parameters:  one which the
 > > receiver *must* understand in order for the bgp session
 > > to reach "established" state, and one which the receiver
 > > can silently ignore if unrecognized?  this could be done
 > > by adding hierarchy to the parameter space similar to the
 > > "Attribute Flags" part of the "Attribute Type" field.  if
 > > bgp4 had this, then a MULTI-PROTOCOL-UPDATE message type
 > > could have been added in a backwards-compatible way
 > 
 > I guess you are talking about adding "capabilities" to the
 > OPEN message. And you would have "well-known" and "optional"
 > capabilities. If two peers support the same set of "well-known"
 > capabilities, then the two could go into an established state,
 > even if the set of "optional" capabilities provided by each
 > of the peers may not be the same.  Correct ?

exactly

 > > i don't think bgp4 could get this feature without starting
 > > over in the standards-track, but is it useful enough to
 > > consider adding it to a bgp5?
 > 
 > I think it is, but I don't have a strong opinion on this topic.

anyone else?

/jws
- - - - - - - - - - - - - - - - -

Posted-Date: Wed, 8 Jan 1997 08:19:24 -0800 (PST)
Date: Wed, 8 Jan 1997 11:19:25 -0500
X-UIDL: 852772146.004
From: [email-masked] (Dimitry Haskin)
To: [email-masked], [email-masked]
Subject: Re: BGP-5 proposal..
Sender: [email-masked]
Content-Length: 3444

Ravi,

> 
> well, if we want to both (a) introduce multiprotocol capabilities in
> BGP, and (b) expand AS space, then how doing the following..
> 
> 1. Replace how NLRI, next hop, and withdrawn routes are presently
>    carried with MP_NLRI_REACH and MP_NLRI_UNREACH attributes.
>
If it something that can bring us to a mutually acceptable specification,
I can live with that but more on that below..

> 2. Resize "My Automous System" in OPEN to 4 octets.
It is a variable size field in the current BGP5 draft which imo makes
it a little bit more flexible.  Do you have problem with that?

>    Resize "BGP Identifier" in OPEN to 16 octets.
>
This is actually what John had in the very initial (unpublished)
BGP5 draft and I made him to change it to a 4-octet field.
My concern was that 16 bytes BGP Identifier/RouterID might not be
compatible with the v4 and v6 OSPF drafts which both use
4-byte RouterID. The OSPF-BGP interaction RFC for v4 requires
that OSPF and BGP RouterIDs are the same for routers that inject
BGP information into OSPF.  I'm not sure if the same requirement
holds for v6 due to the opaque LSA type support in OSPFv6.  In
the current BGP5 draft the RouterID definition was taken from
the OSPFv6 draft.

> 3. Resize AS space in AS_PATH and AGGREGATOR to 4 octets.
>    Make the address component of the aggregator variable, and include
>    (as part of this information) address family.
> 
> Note that with this proposal adding multiprotocol capabilities doesn't
> require different types of UPDATE messages. In fact, a single UPDATE
> message could carry NLRI associated with multiple protocols.
>
As I said it may be an acceptable change but before we do it let me ask
the following question.  Beyond a theoretical exercise,  will it be
usefull in practical terms to cary routes from multiple protocols
in a single UPDATE.  Are you planning to use it in your implementation?
I for one don't see how I'd use it due to complete separation of network
layer stacks.  Besides, supporting multible types of UPDATEs is not
such a bad idea, IMHO.  It makes protocol more flexible and
extensible IMO.  There are enough network protocol differences to expect
different sets of attributes for different protocols, e.g. v6 already needs
an attribute to carry link-local next hop addresses which has no use
in v4.  Are you proposing to tack any new protocol family specific
attribute in MP_REACH_NLRI (wouldn't it be like an update withing an update)?  
If not, you will not be able to take advantage of multiprotocol capabilities
of MP_REACH_NLRI.

> The multiprotocol extensions defined this way are not confined to IPv4
> and IPv6. 
>
Neither the support of multiple updates types.  The only requirement is
that before a new network-layer protocol support is added (by defining
a new UPDATE type for this purpose) someone has to write up the BGP5
specifics for that protocol.  The same is true with MP_REACH_NLRI except
it will be more difficult to do.  You don't get a free lunch here.  Think
if you'll be able to automatically support OSI (just an example) with your
approach.

> Also note that replacing encoding of NLRI and withdrawn routes with two
> attributes (MP_REACH_NLRI, MP_UNREACH_NLRI) makes the overall protocol 
> design more consistent.
>
I don't feel that way.

My final note: if we can agree that BGP5 is needed (at least for v6)
I think we can work out the optimization details.

> --ravi
> 
Regards,
 Dimitry

----- End Included Message -----

- - - - - - - - - - - - - - - - -

Posted-Date: Wed, 8 Jan 1997 08:19:24 -0800 (PST)
Date: Wed, 8 Jan 1997 11:19:25 -0500
From: [email-masked] (Dimitry Haskin)
To: [email-masked], [email-masked]
Subject: Re: BGP-5 proposal..
Sender: [email-masked]

Ravi,

> 
> well, if we want to both (a) introduce multiprotocol capabilities in
> BGP, and (b) expand AS space, then how doing the following..
> 
> 1. Replace how NLRI, next hop, and withdrawn routes are presently
>    carried with MP_NLRI_REACH and MP_NLRI_UNREACH attributes.
>
If it something that can bring us to a mutually acceptable specification,
I can live with that but more on that below..

> 2. Resize "My Automous System" in OPEN to 4 octets.
It is a variable size field in the current BGP5 draft which imo makes
it a little bit more flexible.  Do you have problem with that?

>    Resize "BGP Identifier" in OPEN to 16 octets.
>
This is actually what John had in the very initial (unpublished)
BGP5 draft and I made him to change it to a 4-octet field.
My concern was that 16 bytes BGP Identifier/RouterID might not be
compatible with the v4 and v6 OSPF drafts which both use
4-byte RouterID. The OSPF-BGP interaction RFC for v4 requires
that OSPF and BGP RouterIDs are the same for routers that inject
BGP information into OSPF.  I'm not sure if the same requirement
holds for v6 due to the opaque LSA type support in OSPFv6.  In
the current BGP5 draft the RouterID definition was taken from
the OSPFv6 draft.

> 3. Resize AS space in AS_PATH and AGGREGATOR to 4 octets.
>    Make the address component of the aggregator variable, and include
>    (as part of this information) address family.
> 
> Note that with this proposal adding multiprotocol capabilities doesn't
> require different types of UPDATE messages. In fact, a single UPDATE
> message could carry NLRI associated with multiple protocols.
>
As I said it may be an acceptable change but before we do it let me ask
the following question.  Beyond a theoretical exercise,  will it be
usefull in practical terms to cary routes from multiple protocols
in a single UPDATE.  Are you planning to use it in your implementation?
I for one don't see how I'd use it due to complete separation of network
layer stacks.  Besides, supporting multible types of UPDATEs is not
such a bad idea, IMHO.  It makes protocol more flexible and
extensible IMO.  There are enough network protocol differences to expect
different sets of attributes for different protocols, e.g. v6 already needs
an attribute to carry link-local next hop addresses which has no use
in v4.  Are you proposing to tack any new protocol family specific
attribute in MP_REACH_NLRI (wouldn't it be like an update withing an update)?  
If not, you will not be able to take advantage of multiprotocol capabilities
of MP_REACH_NLRI.

> The multiprotocol extensions defined this way are not confined to IPv4
> and IPv6. 
>
Neither the support of multiple updates types.  The only requirement is
that before a new network-layer protocol support is added (by defining
a new UPDATE type for this purpose) someone has to write up the BGP5
specifics for that protocol.  The same is true with MP_REACH_NLRI except
it will be more difficult to do.  You don't get a free lunch here.  Think
if you'll be able to automatically support OSI (just an example) with your
approach.

> Also note that replacing encoding of NLRI and withdrawn routes with two
> attributes (MP_REACH_NLRI, MP_UNREACH_NLRI) makes the overall protocol 
> design more consistent.
>
I don't feel that way.

My final note: if we can agree that BGP5 is needed (at least for v6)
I think we can work out the optimization details.

> --ravi
> 
Regards,
 Dimitry
- - - - - - - - - - - - - - - - -

Date: Wed, 8 Jan 1997 01:41:58 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2723) Re: MOs' 8+8
Sender: [email-masked]

Please, please, please.... Remove [email-masked] and [email-masked] from this
conversation.  We do NOT need self-spam within the IETF.

Thanks,
Tony
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: Masataka Ohta <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2723) Re: MOs' 8+8 
Date: Tue, 07 Jan 97 22:40:19 -0500
Sender: [email-masked]

Steve did not conclude anything but suggested where we may be headed.
Read the IPng minutes.

You simply don't know what your talking about.  You are also not
defending your claims or giving any technical input or details to
discuss.  Or even architectural or model premises.  Even if you would
take your conclusions and then state the premises maybe I could follow
you via inductive logic.  

Get a grip and fix your attitude buddy.  I think you need an attitude
adjustment. Note you never agree with anyone, you never say when your
wrong, and that sounds like you have a serious ego-centric behavior
problem.  Go fix it and help us work on technology standards, you appear
to be a bright person but its all clouded in your attitude with email.
This is not how you act in person at the IETF meetings.  Is the terminal
like a drug to you that causes you to act this way.

I am not listening to you anymore or reading your mail for awhile.

/jim

- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2723) Re: MOs' 8+8
To: [email-masked]
Date: Wed, 8 Jan 97 10:29:06 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> >But, I think it necessary to modify the locator of the destination
> >address.
> 
> I don't think it should be modified in transit.  It must be maintained
> end to end.

As I explained already, maintaining it is simply impossible.

Simply repeating unfounded opinion is boring.

> >It means that you rely routers to dcdd:. So, you can rely routers
> >to dcdd: won't harmfully rewrite destination locator.
> 
> I do not want the Routing Goop rewritten once it leaves the end node.

Simply repeating unfounded opinion is boring.

> >That is, rewriting of destination locator is harmless.
> 
> I consider it dangerous.  For reasons stated previously.

Your reason taht "I do not want the Routing Goop rewritten" is too weak.

> >> and renumbering in the routing
> >> system using ND and autoconfiguration can take place with minimum of
> >> effort as opposed to the effort of securing the environment from
> >> altering the goop on the fly.
> 
> >You are wrong here. We don't need any reconfiguration at all.
> 
> Wrong where?  If a sites prefix changes then the site must be
> renumbered.

With locator ID separation, site renumbering does not need new
autoconfiguration, unless you call locator announcement
autoconfiguration.

> >Nor do I. But, it's not 8+2+6. It's 6+2+8 now.
> 
> I hope we get Mike's updated draft soon.

You don't have to. 6+2+8 is the WG conclusion stated by Steve at
San Jose.

> >Because you are insisting that you need so much time in face-to-face
> >meeting ignoring the mailing list discussion.
> 
> I am not doing that.

No. You have even ignored a conclusion of face-to-face meetings.

							Masataka Ohta
- - - - - - - - - - - - - - - - -

Date: Tue, 07 Jan 1997 20:15:06 -0500
To: Tony Bates <[email-masked]>
From: Paul Ferguson <[email-masked]>
Subject: Re: a different proposal for ipv6 in bgp 
Cc: Dimitry Haskin <[email-masked]>, Dave Katz <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 04:59 PM 1/7/97 -0800, Tony Bates wrote:
>
>If you buy into my ease of deployment point above [and of course you
>might not] let's look at where we are in terms of AS space as this is
>other factor driving the current discussuion.  Since I've started the
>CIDR report I produce I've also been tracking the activity of ASes in the
>global routing system as seen in BGP by a well connected router. The
>interesting trend you see is the growth of ASes in the global routing
>system is essentially linear. Whilst my data source is quite small (see
>http://www.remplyees.org/~tbates/cidr.as.plot.html) this seems to be

Make that:

 http://www.employees.org:80/~tbates/cidr.as.plot.html

:-)

- paul

>growing at an average rate of 3 ASes per day. The linear growth if
>further backed in "An analysis of Internet Inter-Domain Topology and
>Route Stability" by Ramesh Govindan and Anoop Reddy from USC/ISI.
>

- - - - - - - - - - - - - - - - -

To: Dimitry Haskin <[email-masked]>
Cc: Dave Katz <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: a different proposal for ipv6 in bgp 
From: Tony Bates <[email-masked]>
Date: Tue, 07 Jan 1997 16:59:05 -0800
Sender: [email-masked]

 Dimitry Haskin <[email-masked]> writes:
  * At 04:53 PM 1/6/97 -0800, Dave Katz wrote:
  * >It remains unclear to me why it is desirable to couple multiprotocol
  * >support and the AS number space increase.  The two functions are
  * >completely orthogonal and as far as I can tell there is no benefit for
  * >*mandating* that the two changes be made at the same time.
  * >
  * >Clearly the multiprotocol stuff could be deployed and become useful
  * >more quickly than the AS number extension, due to the fact that it
  * >can be done in a backward compatible, pairwise fashion.
  * >
  * I don't believe that this assessment is accurate.  The BGP5 proposal
  * is as backward compatible (if not more) with BGP4 as the proposed multiprot
  * ocol 
  * extension to BGP4.  I.e., v4 routing information exchanged between BGP5
  * peers can be fully re-advertised via BGP4 and vise versa.  As you might not
  * ice
  * we even didn't require to immediately extend AS number space for v4
  * to keep the v4 related changes to a bare minimum.  To support v6, bgp data
  * structures need to change any way and v6 has no backward compatibility
  * issue at this point. Thus it only makes sense to get a larger AS space for
  * v6 now
  * to avoid another transition later.
  * 

Let's perhaps look at this a little differently. Since widespread
deployment of BGP4 and the hassle of transition from BGP3 (for those
of us who went through this, it was certainly not something to do more
than say a couple of times in your lifetime and in that case we were
driven by an immediate need) we have actually been able to add several
new attributes (communities, reflection, etc) to keep enhancing
inter-domain routing capabilities (all in use today) with very little
pain. The reason we've been able to do this is becuase we essentially
haven't messed with the underpinnings of the protocol itself. The
operational factors in doing this are much greater than perhaps many
folks realize (ISPs tell me different if you think I'm
overstating). In your proposal, before I can get benefit of the pain I
need to move I have the entrie Internet moved over to BGP5. I
understand I can use it for multiprotocol on a pairwise basis
providing I dont touch the AS space but this doesn't seem like too
much of a win when I can add attributes to the exisiting BGP4 protocol
and start using BGP for multi-protocol interdomain support in an
understood and well-practiced operational way.

  * >The deployment considerations for multiprotocol support are far less
  * >onerous than the AS number stuff.
  * >
  * Care elaborate (in light of the BGP5 proposal)? 
  *  
See above.

  * >Operators who are concerned about deploying new software twice could
  * >always wait until BGP5 deployment and turn on both features at the
  * >same time.  However, I think that the deployment timing for each
  * >feature is difficult to predict in advance (will IPv6 take off?  Are
  * >we really under pressure for AS numbers?) so keeping them decoupled
  * >keeps things more flexible.
  * >
  * >So, what is it that makes it preferable to entwine the changes?
  * >
  * Once again, the way the BGP5 proposal written I don't believe this larger A
  * S
  * space for v6 introduces more implementation and/or deployment burdens than
  * yours multiprotocol
  * stuff does...  unless I miss some vital points. My point is that there is n
  * o
  * additional penalty for the introducing a larger AS number space for v6 now
  * and,  to boot,  BGP5
  * provides an optional mechanism to gradually introduce a larger AS number
  * space for v4
  * too.  So why not?
  *

If you buy into my ease of deployment point above [and of course you
might not] let's look at where we are in terms of AS space as this is
other factor driving the current discussuion.  Since I've started the
CIDR report I produce I've also been tracking the activity of ASes in the
global routing system as seen in BGP by a well connected router. The
interesting trend you see is the growth of ASes in the global routing
system is essentially linear. Whilst my data source is quite small (see
http://www.remplyees.org/~tbates/cidr.as.plot.html) this seems to be
growing at an average rate of 3 ASes per day. The linear growth if
further backed in "An analysis of Internet Inter-Domain Topology and
Route Stability" by Ramesh Govindan and Anoop Reddy from USC/ISI.

If we use this growth rate and look at a couple of scenarios:

Best Case 
---------
Assuming we have 65000 (not including Private ASes) ASes and
accounting for the 1937 ASes already in the system (this also assumes
we could re-use ones pre-allocated and not currently being used which
is probably over optimistic) we have 63063 ASes to play with resulting
in :

        63063/3 = 21021 Days
        21021/365 = 57 Years before we run out.

Worst Case
----------

If we assume 15535 ASes will in fact be wasted (private space,
early/bad allocations before RFC1930, some ISPs getting as AS 
for the wrong reason) we still end up with.

        (50000-1937)/3/365 = 43.8 years

Now you could argue that this doesn't take into account the increasing
trend towards mutlihoming (not currently shown in the AS growth either
but anyway ;-)). However, there are a number of things to help with
this approach. 

1. Improving use of private AS space. ISP router should be able to
   override customer's AS with a preconfigured number. ISP router
   shouldn't propagate a route to a customer router if the route includes
   AS of the customer (this AS is preconfigured on the ISP router).

2. Use RIPv2 (instead of BGP) - doesn't require AS number at all.

3. Use single globally unique AS number (draft-stewart-bgp-without-as-00.txt)

So with this in mind do we really want to tackle the AS number issue
right now at the risk of the operational impact ? If the answer is yes
(which I must abmit seems hard to see from my viewpoint) then we
better make sure we look at all aspects before spinning the protocol
again wouldn't you agree ?

		--Tony

  * >--Dave
  * 
  * Dimitry
  * >
  * >   X-Phone: +1 703 812 3704
  * >   Date: Mon, 30 Dec 1996 14:05:41 EST
  * >   From: "John W. Stewart III" <[email-masked]>
  * >   Sender: [email-masked]
  * >   Precedence: bulk
  * >
  * >
  * >   attached below is a proposal for a multi-protocol (including
  * >   ipv6) bgp
  * >
  * >   while there are a number of differences between this one and
  * >   the bates/chandra/katz/rekhter one, one of the main motivating
  * >   factors for this one is to support longer-than-two-byte ASs.
  * >   it is our view that making bgp multi-protocol significantly
  * >   extends its life.  so, although in a narrow sense the length
  * >   of the AS is orthogonal to being multi-protocol, the logistics
  * >   of transitions and the need to adequeately engineer the
  * >   protocol up-front, to us, suggests the need for longer-than-
  * >   two-byte ASs
  * >
  * >   /jws
  * >
  * >
  * 
- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-5 proposal.. 
Date: Tue, 07 Jan 97 16:31:16 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
> if you change the OPEN message, then wouldn't you need to
> change the version number?  

I think that was assumed - Ravi was talking about BGP-5.

> and if you change the version
> number, then isn't it kind of a hack to put IPv4 NLRI in
> the NLRI field but non-IPv4 NLRI in an attribute?

Read carefully item (1):

>  > 1. Replace how NLRI, next hop, and withdrawn routes are presently
>  >    carried with MP_NLRI_REACH and MP_NLRI_UNREACH attributes.

Which means *all* NLRI information (IPv4, IPv6, etc...) will be
carried in MP_NLRI_REACH and MP_NLRI_UNREACH attributes. 

> your message is a good lead-in to something that i've
> been thinking about.  in trying to come up with a
> backwards-compatible multi-protocol bgp4, my first idea
> was to add an optional parameter to the OPEN message
> saying "i support MULTI-PROTOCOL-UPDATE messages."  but
> after 5 seconds of thinking i realized that this is not
> backwards compatible because a vanilla bgp4
> implementation would die right away with an "unsupported
> optional parameter" error.  so the question is, should
> there be two different sets of parameters:  one which the
> receiver *must* understand in order for the bgp session
> to reach "established" state, and one which the receiver
> can silently ignore if unrecognized?  this could be done
> by adding hierarchy to the parameter space similar to the
> "Attribute Flags" part of the "Attribute Type" field.  if
> bgp4 had this, then a MULTI-PROTOCOL-UPDATE message type
> could have been added in a backwards-compatible way

I guess you are talking about adding "capabilities" to the
OPEN message. And you would have "well-known" and "optional"
capabilities. If two peers support the same set of "well-known"
capabilities, then the two could go into an established state,
even if the set of "optional" capabilities provided by each
of the peers may not be the same.  Correct ?

> i don't think bgp4 could get this feature without starting
> over in the standards-track, but is it useful enough to
> consider adding it to a bgp5?

I think it is, but I don't have a strong opinion on this topic.

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

To: Ravi Chandra <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-5 proposal.. 
Date: Tue, 07 Jan 1997 18:48:24 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

if you change the OPEN message, then wouldn't you need to
change the version number?  and if you change the version
number, then isn't it kind of a hack to put IPv4 NLRI in
the NLRI field but non-IPv4 NLRI in an attribute?

your message is a good lead-in to something that i've
been thinking about.  in trying to come up with a
backwards-compatible multi-protocol bgp4, my first idea
was to add an optional parameter to the OPEN message
saying "i support MULTI-PROTOCOL-UPDATE messages."  but
after 5 seconds of thinking i realized that this is not
backwards compatible because a vanilla bgp4
implementation would die right away with an "unsupported
optional parameter" error.  so the question is, should
there be two different sets of parameters:  one which the
receiver *must* understand in order for the bgp session
to reach "established" state, and one which the receiver
can silently ignore if unrecognized?  this could be done
by adding hierarchy to the parameter space similar to the
"Attribute Flags" part of the "Attribute Type" field.  if
bgp4 had this, then a MULTI-PROTOCOL-UPDATE message type
could have been added in a backwards-compatible way

i don't think bgp4 could get this feature without starting
over in the standards-track, but is it useful enough to
consider adding it to a bgp5?

/jws

 > 
 > well, if we want to both (a) introduce multiprotocol capabilities in
 > BGP, and (b) expand AS space, then how doing the following..
 > 
 > 1. Replace how NLRI, next hop, and withdrawn routes are presently
 >    carried with MP_NLRI_REACH and MP_NLRI_UNREACH attributes.
 > 
 > 2. Resize "My Automous System" in OPEN to 4 octets.
 >    Resize "BGP Identifier" in OPEN to 16 octets.
 > 
 > 3. Resize AS space in AS_PATH and AGGREGATOR to 4 octets.
 >    Make the address component of the aggregator variable, and include
 >    (as part of this information) address family.
 > 
 > Note that with this proposal adding multiprotocol capabilities doesn't
 > require different types of UPDATE messages. In fact, a single UPDATE
 > message could carry NLRI associated with multiple protocols.
 > 
 > The multiprotocol extensions defined this way are not confined to IPv4
 > and IPv6. 
 > 
 > Also note that replacing encoding of NLRI and withdrawn routes with two
 > attributes (MP_REACH_NLRI, MP_UNREACH_NLRI) makes the overall protocol 
 > design more consistent.
 > 
 > --ravi
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: BGP-5 proposal..
Date: Tue, 07 Jan 1997 13:57:25 -0800
From: Ravi Chandra <[email-masked]>
Sender: [email-masked]

well, if we want to both (a) introduce multiprotocol capabilities in
BGP, and (b) expand AS space, then how doing the following..

1. Replace how NLRI, next hop, and withdrawn routes are presently
   carried with MP_NLRI_REACH and MP_NLRI_UNREACH attributes.

2. Resize "My Automous System" in OPEN to 4 octets.
   Resize "BGP Identifier" in OPEN to 16 octets.

3. Resize AS space in AS_PATH and AGGREGATOR to 4 octets.
   Make the address component of the aggregator variable, and include
   (as part of this information) address family.

Note that with this proposal adding multiprotocol capabilities doesn't
require different types of UPDATE messages. In fact, a single UPDATE
message could carry NLRI associated with multiple protocols.

The multiprotocol extensions defined this way are not confined to IPv4
and IPv6. 

Also note that replacing encoding of NLRI and withdrawn routes with two
attributes (MP_REACH_NLRI, MP_UNREACH_NLRI) makes the overall protocol 
design more consistent.

--ravi
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: "Brian Carpenter CERN-CN" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: (IPng 2724) Re: MOs' 8+8 
Date: Tue, 07 Jan 97 15:36:51 -0500
Sender: [email-masked]

Brian,

I think the risk is very high if one application breaks.

But thats not the main issue.  I think many things will break if
altering the RG is permitted in transit.

Also I think there were other reasons for Mike's proposal in addition to
renumbering.  The ISPs do not think the Provider Based Addressing will
work.  They are a customer of IPv6.  Mikes LSID + more RG + ESD I think
is a more flexible model than the Provider Based addressing.

The proposal as I understand it appeases many of the providers and all
the ones I have spoken with 1x1.  So its a bit more than renumbering.

But I believe we will get the benefits of renumbering without the
alteration of IPv6 packets in transit from one end node to the other.

/jim
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: Masataka Ohta <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2723) Re: MOs' 8+8 
Date: Tue, 07 Jan 97 15:29:48 -0500
Sender: [email-masked]

>OK. You actually are worrying about the modification of the locator
>of source address.

>But, I think it necessary to modify the locator of the destination
>address.

I don't think it should be modified in transit.  It must be maintained
end to end.

>> I also believe if I sent a packet to dcdd::11:edcdba I want to find that
>> address in by application dns lookup and it will be received only by
>> dcdd::11:edcdba.

>It means that you rely routers to dcdd:. So, you can rely routers
>to dcdd: won't harmfully rewrite destination locator.

I do not want the Routing Goop rewritten once it leaves the end node.

>That is, rewriting of destination locator is harmless.

I consider it dangerous.  For reasons stated previously.

>> When a site gets a new prefix the goop can be changed quite easily by
>> advertising the new goop to the site

>The problem is that it's a lot easier than you think.

I think its even easier with Bob Hinden's RR proposal.  RR + what I can
do with Addr conf (stateless and dhcpv6) is very robust.   

>> and renumbering in the routing
>> system using ND and autoconfiguration can take place with minimum of
>> effort as opposed to the effort of securing the environment from
>> altering the goop on the fly.

>You are wrong here. We don't need any reconfiguration at all.

Wrong where?  If a sites prefix changes then the site must be
renumbered.

> >> It has a lot to do with how 8+8 is done for
> >> DNS and the root servers.
> 
> >Maybe for DNS but no for the root servers.
> 
> >To make everything too much complex, the root servers should
> >have constant locator.
> 
> Please explain why as you asked me?

Understand the existing anwer below.

>Nor do I. But, it's not 8+2+6. It's 6+2+8 now.

I hope we get Mike's updated draft soon.

>> Whats this have to do with anything?  WHy do you make this statement?
>
>Because you are insisting that you need so much time in face-to-face
>meeting ignoring the mailing list discussion.

I am not doing that.  In fact I sent mail stating we should have much
discussion on the mail list before the interim meeting.  So I don't know
what your talking about.

/jim
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: Masataka Ohta <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2720) Re: MOs' 8+8 
Date: Tue, 07 Jan 97 13:05:39 -0500
Sender: [email-masked]

Masataka,

>> >One of the agreement at San Jose meeting was that lower 8 byte
>> >should be globally unique.
>> 
>> It can't be done and no one has given an algorithm to do it.
>
>As discussed in San Jose, it can be and is being algorithmically done
>with IPv4 through in-addr.arpa.

I was there and this discussion did not take place except maybe in your
mind as to it being resolved.  And we did not agree to anything as consensus. 
Your wrong.  Read the IPng minutes.

>> ALso if
>> you would read mail more carefully you would note I said based on the
>> "premises" for IPv6 in ND and Addrconf the low order 6bytes cannot in
>> fact be unique which is why we do Duplicate Address Detection if this
>> should happen.

>We don't have Duplicate Address Detection to encourage duplication.

Is this like the question does a bear shit in the woods?  

>> Mike in his spec states he does not want to

>You apparently missed discussion in San Jose and later.

Ah more Masatakagrams... You delete the end to suit your own mind to
respond.  Re-Read the mail and it meant we are not doing 8+8 to the
point where it breaks IPv6 existing specs dramatically.  Its a boundary
we all want to keep.  

/jim

- - - - - - - - - - - - - - - - -

Date: Tue, 7 Jan 1997 08:31:16 -0500
To: "Brian Carpenter   CERN-CN" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: (IPng 2718) Re: MOs' 8+8
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 2:15 PM +0100 1/7/97, Brian Carpenter   CERN-CN wrote:
>P.S. the bgp list is still getting all this. Necessary?

No.

--John

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

- - - - - - - - - - - - - - - - -

Subject: Re: (IPng 2718) Re: MOs' 8+8
To: [email-masked], [email-masked]
Date: Tue, 7 Jan 1997 14:15:07 +0100 (MET)
From: "Brian Carpenter   CERN-CN" <[email-masked]>
Sender: [email-masked]

Jim and Masataka,

> > 
> > I don't agree.  I don't think the Protocol Control Blocks can deal
> > globally with just the ESD they are simply not "unique" on the
> > "Internet" but can only be 100% guranteed in a site.  
> 
> One of the agreement at San Jose meeting was that lower 8 byte
> should be globally unique.
> 

"Should be" is not equal to "will be". The real-world issue
is whether ESDs would be unique enough to satisfy reasonable
requirements, or perhaps: would ESDs be significantly *less*
unique than (RG+ESD)s would be?

Note on the bizarre concept of "unique enough": what I mean is
that in analysing security risks (or the risk of TCP checksum
collisions), an ESD is unique enough if the probability of
an ESD collision is below some acceptable level.

  Brian Carpenter

P.S. the bgp list is still getting all this. Necessary?
- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2709) Re: MOs' 8+8
To: [email-masked]
Date: Tue, 7 Jan 97 19:10:13 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jim;

> >> I agree.  I also think 8+8 (or where it will end up) will add additional
> >> benefits to the CIDR paradigm and solves the Multihoming problem too for
> >> large organizations.  The only part I don't like and will battle is that
> >> when a packet leaves a host I do not think anyone should step on any
> >> parts of the 128bit address space at site border routers or from ISP to
> >> ISP.
> 
> >Why?

> The other reason is that from a business perspective I don't want to
> deal with the security ramifications of a packet being altered from my
> site to an ISP and brings up an entire discussion of permitting and
> external entity to my site or home changing my packets in transit which
> I may not trust.  

OK. You actually are worrying about the modification of the locator
of source address.

But, I think it necessary to modify the locator of the destination
address.

The opinions are compatible.

> I also believe if I sent a packet to dcdd::11:edcdba I want to find that
> address in by application dns lookup and it will be received only by
> dcdd::11:edcdba.

It means that you rely routers to dcdd:. So, you can rely routers
to dcdd: won't harmfully rewrite destination locator.

That is, rewriting of destination locator is harmless.

> >With DNS lookup, rewriting won't make weak security weaker.
> 
> Now as you asked me?  Please explain in detail what you mean? I don't
> know where your coming from on this?

Dig ML log last December.

> When a site gets a new prefix the goop can be changed quite easily by
> advertising the new goop to the site

The problem is that it's a lot easier than you think.

> and renumbering in the routing
> system using ND and autoconfiguration can take place with minimum of
> effort as opposed to the effort of securing the environment from
> altering the goop on the fly.

You are wrong here. We don't need any reconfiguration at all.

> >> It has a lot to do with how 8+8 is done for
> >> DNS and the root servers.
> 
> >Maybe for DNS but no for the root servers.
> 
> >To make everything too much complex, the root servers should
> >have constant locator.
> 
> Please explain why as you asked me?

Understand the existing anwer below.

> >The root servers DOES worth additional 9 toplevel routing
> >table entries.

> I can't parse your english statement here at all?

Try "nslookup -q=ns ." and count the number of root servers.

> I do not believe 0::11:ddcabb (2+6 without the goop --> ESD) will be
> gloablly unique

Nor do I. But, it's not 8+2+6. It's 6+2+8 now.

> >And the uniqueness of the locators of the SECOND level servers
> >depends on how many are the second level servers.
> 
> Why?

Because I can count the number of routing table entries.

> >The idea has been around more than a year.
> 
> Whats this have to do with anything?  WHy do you make this statement?

Because you are insisting that you need so much time in face-to-face
meeting ignoring the mailing list discussion.

						Masataka Ohta
- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2672) Re: larger AS/RD space for v6?
To: [email-masked] (Brandon Black)
Date: Tue, 7 Jan 97 18:31:46 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Brandon;

> But I don't think Tony was referring really to the routing system knowing
> (were you?)... it seems to me he was referring to the address itself
> carrying inherent information... i.e. if someone just read off an IP to
> me, I shouldn't be able to automatically know from that number the AS it
> belongs to, its netmask, etc....

Then, perhaps, Tony now think renumbering mistake or, at
least, hard.

The problem is that dynamic mapping between AS and aggregated
address prefix is also hard.

It's no good to introduce another level of indirection only to
delay facing the problem.

Let's face the issue and make renumbering easy.

							Masataka Ohta
- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2720) Re: MOs' 8+8
To: [email-masked]
Date: Tue, 7 Jan 97 16:33:23 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jim;

> >One of the agreement at San Jose meeting was that lower 8 byte
> >should be globally unique.
> 
> It can't be done and no one has given an algorithm to do it.

As discussed in San Jose, it can be and is being algorithmically done
with IPv4 through in-addr.arpa.

> ALso if
> you would read mail more carefully you would note I said based on the
> "premises" for IPv6 in ND and Addrconf the low order 6bytes cannot in
> fact be unique which is why we do Duplicate Address Detection if this
> should happen.

We don't have Duplicate Address Detection to encourage duplication.

> Mike in his spec states he does not want to

You apparently missed discussion in San Jose and later.

> >As discussed last year and I stated in my mail yesterday, rewriting
> >does not break the weak security.
> 
> I read your mail yesterday.  I did have a site outage though I hear from
> colleagues on other mail lists, so humor me and resend it.

No.

Unless you want to be the rude, don't bother us all the members of
IPNG and BGP MLs only because of your site local mail failure.

Dig ML archive (starting from last December) by yourself.

							Masatkaa Ohta
- - - - - - - - - - - - - - - - -

Date: Mon, 6 Jan 1997 23:25:25 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked] (Dave Katz)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: a different proposal for ipv6 in bgp
Sender: [email-masked]

   So, what is it that makes it preferable to entwine the changes?

The changes are not tightly coupled.  However, if we're going to give BGP
Yet Another Lease on Life (die, bastard child from hell, die!!! ;-) ) it
follows that we need to give the heart transplant as well as the new
liver.  One without the other is pointless.

I, for one, greatly prefer the tabula rasa so that we can (hopefully)
retract many of the mistakes that have been made.  I'm also painfully aware
of the pragmatics of the situation.

So it goes,
Tony
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: Masataka Ohta <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2715) Re: MOs' 8+8 
Date: Tue, 07 Jan 97 00:13:13 -0500
Sender: [email-masked]

Masataka,

>One of the agreement at San Jose meeting was that lower 8 byte
>should be globally unique.

It can't be done and no one has given an algorithm to do it.  ALso if
you would read mail more carefully you would note I said based on the
"premises" for IPv6 in ND and Addrconf the low order 6bytes cannot in
fact be unique which is why we do Duplicate Address Detection if this
should happen.  With the 2 extra bytes it can be unique within a site
even if the low order 6 bytes are duplicated on two different links
(which is permitted in IPv6).  But I claim it cannot be unique outside
of the site on the Internet. It may be your in a discussion for IPv6
that your are not qualified to be in or you would not have made the
above statement so lightly.  Mike in his spec states he does not want to
break the machinery for existing IPv6 in the specs but develop an
addressing architecture that can exist within it.  I think that can be
done as long as the 128bits are used.

>> Also I believe doing this will break lots of vital thinks like
>> end-to-end connectivity and open an entirely new set of security
>> problems, when we still have not solved the ones we have now
>> "completely".

>You are completely out of date.

Your being rude and you obviously don't have the integrity to defend 
your own statements.  Your the one who is just talking and taking up
much valuable Internet-waves with your one line sentences that are
meaningless technically.  I had other text to my sentence above to draw
my conclusion which are called premises.  You just keep giving me
conclusions.  Didn't you take any deductive logic course in your life.

>As discussed last year and I stated in my mail yesterday, rewriting
>does not break the weak security.

I read your mail yesterday.  I did have a site outage though I hear from
colleagues on other mail lists, so humor me and resend it.

/jim

- - - - - - - - - - - - - - - - -

Posted-Date: Mon, 6 Jan 1997 19:28:05 -0800 (PST)
Date: Mon, 06 Jan 1997 22:26:08 -0500
To: Dave Katz <[email-masked]>, [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: a different proposal for ipv6 in bgp
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 04:53 PM 1/6/97 -0800, Dave Katz wrote:
>It remains unclear to me why it is desirable to couple multiprotocol
>support and the AS number space increase.  The two functions are
>completely orthogonal and as far as I can tell there is no benefit for
>*mandating* that the two changes be made at the same time.
>
>Clearly the multiprotocol stuff could be deployed and become useful
>more quickly than the AS number extension, due to the fact that it
>can be done in a backward compatible, pairwise fashion.
>
I don't believe that this assessment is accurate.  The BGP5 proposal
is as backward compatible (if not more) with BGP4 as the proposed multiprotocol 
extension to BGP4.  I.e., v4 routing information exchanged between BGP5
peers can be fully re-advertised via BGP4 and vise versa.  As you might notice
we even didn't require to immediately extend AS number space for v4
to keep the v4 related changes to a bare minimum.  To support v6, bgp data
structures need to change any way and v6 has no backward compatibility
issue at this point. Thus it only makes sense to get a larger AS space for
v6 now
to avoid another transition later.

>The deployment considerations for multiprotocol support are far less
>onerous than the AS number stuff.
>
Care elaborate (in light of the BGP5 proposal)? 
 
>Operators who are concerned about deploying new software twice could
>always wait until BGP5 deployment and turn on both features at the
>same time.  However, I think that the deployment timing for each
>feature is difficult to predict in advance (will IPv6 take off?  Are
>we really under pressure for AS numbers?) so keeping them decoupled
>keeps things more flexible.
>
>So, what is it that makes it preferable to entwine the changes?
>
Once again, the way the BGP5 proposal written I don't believe this larger AS
space for v6 introduces more implementation and/or deployment burdens than
yours multiprotocol
stuff does...  unless I miss some vital points. My point is that there is no
additional penalty for the introducing a larger AS number space for v6 now
and,  to boot,  BGP5
provides an optional mechanism to gradually introduce a larger AS number
space for v4
too.  So why not?

>--Dave

Dimitry
>
>   X-Phone: +1 703 812 3704
>   Date: Mon, 30 Dec 1996 14:05:41 EST
>   From: "John W. Stewart III" <[email-masked]>
>   Sender: [email-masked]
>   Precedence: bulk
>
>
>   attached below is a proposal for a multi-protocol (including
>   ipv6) bgp
>
>   while there are a number of differences between this one and
>   the bates/chandra/katz/rekhter one, one of the main motivating
>   factors for this one is to support longer-than-two-byte ASs.
>   it is our view that making bgp multi-protocol significantly
>   extends its life.  so, although in a narrow sense the length
>   of the AS is orthogonal to being multi-protocol, the logistics
>   of transitions and the need to adequeately engineer the
>   protocol up-front, to us, suggests the need for longer-than-
>   two-byte ASs
>
>   /jws
>
>

- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2715) Re: MOs' 8+8
To: [email-masked]
Date: Tue, 7 Jan 97 10:50:36 JST
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jim;

> >It's different in one vital way: since the RG is *not* used in
> >pseudo-headers, stamping on it doesn't break anything vital.
> 
> I don't agree.  I don't think the Protocol Control Blocks can deal
> globally with just the ESD they are simply not "unique" on the
> "Internet" but can only be 100% guranteed in a site.  

One of the agreement at San Jose meeting was that lower 8 byte
should be globally unique.

> Also I believe doing this will break lots of vital thinks like
> end-to-end connectivity and open an entirely new set of security
> problems, when we still have not solved the ones we have now
> "completely".

You are completely out of date.

As discussed last year and I stated in my mail yesterday, rewriting
does not break the weak security.

							Masataka Ohta
- - - - - - - - - - - - - - - - -

Date: Mon, 6 Jan 1997 16:53:05 -0800
From: Dave Katz <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: a different proposal for ipv6 in bgp
Sender: [email-masked]

It remains unclear to me why it is desirable to couple multiprotocol
support and the AS number space increase.  The two functions are
completely orthogonal and as far as I can tell there is no benefit for
*mandating* that the two changes be made at the same time.

Clearly the multiprotocol stuff could be deployed and become useful
more quickly than the AS number extension, due to the fact that it
can be done in a backward compatible, pairwise fashion.

The deployment considerations for multiprotocol support are far less
onerous than the AS number stuff.

Operators who are concerned about deploying new software twice could
always wait until BGP5 deployment and turn on both features at the
same time.  However, I think that the deployment timing for each
feature is difficult to predict in advance (will IPv6 take off?  Are
we really under pressure for AS numbers?) so keeping them decoupled
keeps things more flexible.

So, what is it that makes it preferable to entwine the changes?

--Dave

   X-Phone: +1 703 812 3704
   Date: Mon, 30 Dec 1996 14:05:41 EST
   From: "John W. Stewart III" <[email-masked]>
   Sender: [email-masked]
   Precedence: bulk

   attached below is a proposal for a multi-protocol (including
   ipv6) bgp

   while there are a number of differences between this one and
   the bates/chandra/katz/rekhter one, one of the main motivating
   factors for this one is to support longer-than-two-byte ASs.
   it is our view that making bgp multi-protocol significantly
   extends its life.  so, although in a narrow sense the length
   of the AS is orthogonal to being multi-protocol, the logistics
   of transitions and the need to adequeately engineer the
   protocol up-front, to us, suggests the need for longer-than-
   two-byte ASs

   /jws
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: "Brian Carpenter CERN-CN" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: (IPng 2706) Re: MOs' 8+8 
Date: Mon, 06 Jan 97 17:07:48 -0500
Sender: [email-masked]

Brian,

>> 
>> Another site could choose to permit their ISP's routers to rewrite
>> the RG portion of source addresses as they exit the site, thus
>> relieving their hosts of what source address to choose...they would
>> just use the (as yet undefined) Exportable-Site-Local-Prefix for
>> any communications with globally addressed destinations.  As stated
>> by Mike in his draft, this is not terribly different from the way
>> NAT boxes work today.
>> 

>It's different in one vital way: since the RG is *not* used in
>pseudo-headers, stamping on it doesn't break anything vital.

I don't agree.  I don't think the Protocol Control Blocks can deal
globally with just the ESD they are simply not "unique" on the
"Internet" but can only be 100% guranteed in a site.  

Also I believe doing this will break lots of vital thinks like
end-to-end connectivity and open an entirely new set of security
problems, when we still have not solved the ones we have now
"completely".

/jim

- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: 05.txt
Date: Mon, 06 Jan 97 12:33:07 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The revised version also includes fair amount of changes
that had been discussed on the mailing list, and for
which Tony posted diffs.

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

From: "Harrington, Dan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: (IPng 2697) MOs' 8+8
Date: Mon, 6 Jan 1997 12:11:51 -0500
Sender: [email-masked]

[email-masked] wrote:
> I would think rewriting network adresses in transit would certainly affect
> the heart of any routing system's integrity, if it were not a defined and
> controlled part of a standard.

You'll get no argument from me...

> I don't like the idea of the host having to know so much about network
> adresses or topology, which it would have to do to intelligently make that
> decision.  Hosts should only care about one thing:  Sending their traffic
> to an opaque destination IP address through the appropriate (and probably
> default and only) gateway.  The translation of addresses, tunneling,
> routing decisions, etc. are the jobs of routers, which are more incline to
> be aware of the factors involved and the current network topology.

It's swell that you have such a clear vision of what hosts should
be and what they should be capable of.  But I don't think your
view is necessarily universal, and some folks might disagree with
your position.  In any event, I'm merely trying to point out that
both views can be accomodated (I think), while preserving the primary
benefits of the 8+8 plan (or whatever it's called today).

> There are some great network managers out there, but probably a good half
> or more of them don't really understand IPv4 right now, much less are they
> likely to understand the nuances of v6...  You've got to assume they are
> all stupid when designing the protocol and the software... don't put the
> integrity of the protocol in a network admin's hands... or least leave it
> open to interpretation in the protocol standard, but encourage the vendors
> to implement a standard easy method in their software.

I'm all for robust network and protocol design, though I would not
necessarily base it upon the alleged shortcomings of any class of
persons.  That doesn't strike me as particularly polite (at least).
I do think flexibility is a worthwhile goal, and that's all I'm
trying to encourage.

Dan
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: Masataka Ohta <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: MOs' 8+8 
Date: Mon, 06 Jan 97 11:34:54 -0500
Sender: [email-masked]

Masataka,

[ Dan/Joe : I take this to respond to your mails and Dan I have no issue
if folks want to permit such a policy but I think there are some
security and business practice issues for users that are unneccessary].

>> I agree.  I also think 8+8 (or where it will end up) will add additional
>> benefits to the CIDR paradigm and solves the Multihoming problem too for
>> large organizations.  The only part I don't like and will battle is that
>> when a packet leaves a host I do not think anyone should step on any
>> parts of the 128bit address space at site border routers or from ISP to
>> ISP.

>Why?

>IETF is the place for technical and engineering discussion, not a
>place to express one's opinion without any valid reasoning.

Well I was testing the waters and you did exactly what your accusing me
of below )--->....  

I do not believe for security reasons that the application should rely
only on the ESD.  It must use the entire 128bits as one reason.  It
permits a node to speak to an application and impersonate the routing
goop just securing the ESD at the application layer is simply not
enough.

The other reason is that from a business perspective I don't want to
deal with the security ramifications of a packet being altered from my
site to an ISP and brings up an entire discussion of permitting and
external entity to my site or home changing my packets in transit which
I may not trust.  

I also believe if I sent a packet to dcdd::11:edcdba I want to find that
address in by application dns lookup and it will be received only by
dcdd::11:edcdba.  This gets to the DNS issue I will discuss further
below.  

Finally I believe it is not necessary to achieve the goals of 8+8 in
this manner.  The benefits outlined in that spec can be done by simply
using it without changing the goop.  

When a site gets a new prefix the goop can be changed quite easily by
advertising the new goop to the site and renumbering in the routing
system using ND and autoconfiguration can take place with minimum of
effort as opposed to the effort of securing the environment from
altering the goop on the fly.

>With DNS lookup, rewriting won't make weak security weaker.

Now as you asked me?  Please explain in detail what you mean? I don't
know where your coming from on this?

>Moreover, mobility needs SOMETHING equivalent to distination
>rewriting, anyway.

This is another thread.  I would like to see the resolution on Charlies
care-of-address discussion resolved first persoanlly before we enter
this discussion.  I think that may make this a moot point?????

>> It has a lot to do with how 8+8 is done for
>> DNS and the root servers.

>Maybe for DNS but no for the root servers.

>To make everything too much complex, the root servers should
>have constant locator.

Please explain why as you asked me?

>The root servers DOES worth additional 9 toplevel routing
>table entries.

I can't parse your english statement here at all?

>> I also do not believe we can assume any ESD can be globally unique by
>> itself at any root Internet server (e.g. .com, edu, .arpa).
>
>Stop using wrong terminologies.
>
>The root is ".", not ".com".

Fine.  I am more concerned about the next level though and the PRT
records.

I do not believe 0::11:ddcabb (2+6 without the goop --> ESD) will be
gloablly unique at the root servers or next level domains.  It must
contain the entire 128bits.

>And the uniqueness of the locators of the SECOND level servers
>depends on how many are the second level servers.

Why?

>> I think for our IPng Interim meeting Feb 27 and 28 we need to devote the
>> entire two days to 8+8 and not even try to do other stuff.

>You could have saved and still can save a lot of time by doing
>discussion in the mailing list.

We are but we will round it up at the meeting.

>The idea has been around more than a year.

Whats this have to do with anything?  WHy do you make this statement?

/jim

>Discuss!

We are....

/jim

- - - - - - - - - - - - - - - - -

Date: Mon, 6 Jan 1997 10:43:34 -0600 (CST)
From: Brandon Black <[email-masked]>
To: "Harrington, Dan" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: (IPng 2697) MOs' 8+8
Sender: [email-masked]

On Mon, 6 Jan 1997, Harrington, Dan wrote:

> > 
> > Why?
> 
> I've been wondering about the "router rewriting" portion of
> the 8+8 proposal, which clearly has the potential to polarize
> opinions.  But is this aspect of the proposed architecture
> fundamental?  Couldn't it be just another policy decision?
> 

I would think rewriting network adresses in transit would certainly affect
the heart of any routing system's integrity, if it were not a defined and
controlled part of a standard.

> It seems to me that one site could take their RG prefixes and
> leak them into their site (via whatever mechanism as yet undefined),
> so that hosts learn them from their immediately adjacent default
> routers.  This site would incur the overhead of distributing and
> maintaining this information amongst their systems, but as benefit
> the individual hosts would know exactly what their global addresses
> were, and could select an appropriate source on their own.
> 

I don't like the idea of the host having to know so much about network
adresses or topology, which it would have to do to intelligently make that
decision.  Hosts should only care about one thing:  Sending their traffic
to an opaque destination IP address through the appropriate (and probably
default and only) gateway.  The translation of addresses, tunneling,
routing decisions, etc. are the jobs of routers, which are more incline to
be aware of the factors involved and the current network topology.

> Another site could choose to permit their ISP's routers to rewrite
> the RG portion of source addresses as they exit the site, thus
> relieving their hosts of what source address to choose...they would
> just use the (as yet undefined) Exportable-Site-Local-Prefix for
> any communications with globally addressed destinations.  As stated
> by Mike in his draft, this is not terribly different from the way
> NAT boxes work today.
>
> So long as implementations at both sites are using the same rules
> for checksums and security associations (and whatever else is
> identified), it wouldn't seem to matter to the network which 
> mechanism is used by individual sites.  This would seem to be
> the key decision we need to make as a working group.
> 
> So is this really a question of all or nothing?  Or can we leave
> the ultimate decision in the hands of the network managers?  Or
> have I completely misunderstood the situation (yet again)?
>

There are some great network managers out there, but probably a good half
or more of them don't really understand IPv4 right now, much less are they
likely to understand the nuances of v6...  You've got to assume they are
all stupid when designing the protocol and the software... don't put the
integrity of the protocol in a network admin's hands... or least leave it
open to interpretation in the protocol standard, but encourage the vendors
to implement a standard easy method in their software.

> Dan
> 

Devil's Advocate
.................................             ..............
: Brandon Lee Black  : [Office] :.............: [Personal] :....
:....................: [email-masked] : [email-masked] :.......
: "Sanity is the     : +1.281.362.6466 .......: [email-masked] :
: trademark of a     :.................:..../\: [email-masked] :
: weak mind. . ."    : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
:....................:.....................:..:.................:

- - - - - - - - - - - - - - - - -

From: "Harrington, Dan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: (IPng 2706) Re: MOs' 8+8
Date: Mon, 6 Jan 1997 11:49:04 -0500
Sender: [email-masked]

Hi Brian,
  
> It's different in one vital way: since the RG is *not* used in
> pseudo-headers, stamping on it doesn't break anything vital.

Correct...I was perhaps too sweeping in my statement.  But the point
remains that all sides agree to the rules, the mechanism in place
at an individual site doesn't matter.

Dan 

- - - - - - - - - - - - - - - - -

Subject: Re: (IPng 2703) RE:  MOs' 8+8
To: [email-masked], [email-masked]
Date: Mon, 6 Jan 1997 17:16:59 +0100 (MET)
From: "Brian Carpenter   CERN-CN" <[email-masked]>
Sender: [email-masked]

Dan,
> 
> Another site could choose to permit their ISP's routers to rewrite
> the RG portion of source addresses as they exit the site, thus
> relieving their hosts of what source address to choose...they would
> just use the (as yet undefined) Exportable-Site-Local-Prefix for
> any communications with globally addressed destinations.  As stated
> by Mike in his draft, this is not terribly different from the way
> NAT boxes work today.
> 

It's different in one vital way: since the RG is *not* used in
pseudo-headers, stamping on it doesn't break anything vital.

  Brian Carpenter
- - - - - - - - - - - - - - - - -

Date: Mon, 6 Jan 1997 10:32:58 -0500 (EST)
From: Joseph Malcolm <[email-masked]>
To: "Harrington, Dan" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: (IPng 2697) MOs' 8+8
Sender: [email-masked]

Dan Harrington writes:
>I've been wondering about the "router rewriting" portion of
>the 8+8 proposal, which clearly has the potential to polarize
>opinions.  But is this aspect of the proposed architecture
>fundamental?  Couldn't it be just another policy decision?
>
>It seems to me that one site could take their RG prefixes and
>leak them into their site (via whatever mechanism as yet undefined),
>so that hosts learn them from their immediately adjacent default
>routers.  This site would incur the overhead of distributing and
>maintaining this information amongst their systems, but as benefit
>the individual hosts would know exactly what their global addresses
>were, and could select an appropriate source on their own.

I think your analysis is pretty much correct, but remember that in the
current 8+8 design, as I understand it, when the connecting outside
topology changes only the border routers need to know. If sites were
to elect your proposed alternative, this information needs to be
propagated to all hosts, which seems to me likely to involve
substantial protocol machinery.

So I think there is a significant cost to allowing the alternative. I
don't see any problem with allowing the border routers to rewrite the
addresses personally, but I'd be interested in hearing reasons from
those who don't agree as to why this is a bad idea.
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: multiprotocol extensions to BGP-4
Date: Mon, 06 Jan 97 07:14:23 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

fyi

P.S. The Internet Draft incorporats the comments we received from Dennis.
------- Forwarded Message

To: IETF-Announce:;
Sender: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-bates-bgp4-multiprotocol-00.txt
Date: Mon, 06 Jan 1997 09:37:38 -0500

- --NextPart

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

       Title     : Multiprotocol Extensions for BGP-4                      
       Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter
       Filename  : draft-bates-bgp4-multiprotocol-00.txt
       Pages     : 8
       Date      : 01/03/1997

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 with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-bates-bgp4-multiprotocol-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bates-bgp4-multiprotocol-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  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-bates-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-bates-bgp4-multiprotocol-00.txt

- --OtherAccess
Content-Type:   Message/External-body;
        name="draft-bates-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--

------- End of Forwarded Message

- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: 05.txt
Date: Mon, 06 Jan 97 07:12:45 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The revised BGP-4 Internet Draft (draft-ietf-idr-bgp4-05.txt)
contains editorial changes that clarify the meaning of
"mandatory attribute". The changes reflect the discussion
we had at the last WG meeting in San Jose.

Tony & Yakov.
- - - - - - - - - - - - - - - - -

To: IETF-Announce:;
cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-05.txt
Date: Mon, 06 Jan 1997 09:37:42 -0500
Sender: [email-masked]

--NextPart

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

       Title     : A Border Gateway Protocol 4 (BGP-4)                     
       Author(s) : Y. Rekhter, T. Li
       Filename  : draft-ietf-idr-bgp4-05.txt
       Pages     : 43
       Date      : 01/03/1997

The Border Gateway Protocol (BGP) is an inter-Autonomous System routing 
protocol.  It is built on experience gained with EGP as defined in RFC 904 
[1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and 
RFC 1093 [3].                                                              

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-idr-bgp4-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-05.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  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-05.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-05.txt

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

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

--OtherAccess--

--NextPart--

- - - - - - - - - - - - - - - - -

From: "Harrington, Dan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: (IPng 2697) MOs' 8+8
Date: Mon, 6 Jan 1997 09:58:58 -0500
Sender: [email-masked]

Masataka wrote:
> Jim;
> 
> > I agree.  I also think 8+8 (or where it will end up) will add additional
> > benefits to the CIDR paradigm and solves the Multihoming problem too for
> > large organizations.  The only part I don't like and will battle is that
> > when a packet leaves a host I do not think anyone should step on any
> > parts of the 128bit address space at site border routers or from ISP to
> > ISP.
> 
> Why?

I've been wondering about the "router rewriting" portion of
the 8+8 proposal, which clearly has the potential to polarize
opinions.  But is this aspect of the proposed architecture
fundamental?  Couldn't it be just another policy decision?

It seems to me that one site could take their RG prefixes and
leak them into their site (via whatever mechanism as yet undefined),
so that hosts learn them from their immediately adjacent default
routers.  This site would incur the overhead of distributing and
maintaining this information amongst their systems, but as benefit
the individual hosts would know exactly what their global addresses
were, and could select an appropriate source on their own.

Another site could choose to permit their ISP's routers to rewrite
the RG portion of source addresses as they exit the site, thus
relieving their hosts of what source address to choose...they would
just use the (as yet undefined) Exportable-Site-Local-Prefix for
any communications with globally addressed destinations.  As stated
by Mike in his draft, this is not terribly different from the way
NAT boxes work today.

So long as implementations at both sites are using the same rules
for checksums and security associations (and whatever else is
identified), it wouldn't seem to matter to the network which 
mechanism is used by individual sites.  This would seem to be
the key decision we need to make as a working group.

So is this really a question of all or nothing?  Or can we leave
the ultimate decision in the hands of the network managers?  Or
have I completely misunderstood the situation (yet again)?

Dan
- - - - - - - - - - - - - - - - -

Subject: Re: (IPng 2629) BGP/IDRP/IPv6
To: [email-masked] (Dave Katz)
Date: Mon, 6 Jan 1997 14:02:22 +0100 (MET)
From: "Brian Carpenter   CERN-CN" <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>--------- Text sent by Dave Katz follows:
> 
...
> 
> IMHO, the right course of action is to do the multiprotocol extension
> to BGP4 quickly so that interdomain routing would not stand in the way
> of IPv6 deployment.  This can be done independently of any other work.
> 
...
> 
> I'd like to hear what the ISPs (who will be the ones to deploy this
> stuff) have to say about the subject.  It seems to me as though IPv6
> will be easier to deploy as an incremental add-on to the existing BGP4
> then if it were bundled in an incompatible (if perhaps almost-compatible)
> protocol, but I'll let the ISPs speak for themselves.
> 
They haven't, at least on lists that I watch, but what you say
makes a lot of sense to me. The key issue is to have a BGP4 extension
that doesn't break the deployed BGP4 system - that is IMHO the only
reasonable way forward in the short term.

  Brian Carpenter
- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: MOs' 8+8
To: [email-masked]
Date: Mon, 6 Jan 97 10:40:01 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jim;

> I agree.  I also think 8+8 (or where it will end up) will add additional
> benefits to the CIDR paradigm and solves the Multihoming problem too for
> large organizations.  The only part I don't like and will battle is that
> when a packet leaves a host I do not think anyone should step on any
> parts of the 128bit address space at site border routers or from ISP to
> ISP.

Why?

IETF is the place for technical and engineering discussion, not a
place to express one's opinion without any valid reasoning.

With DNS lookup, rewriting won't make weak security weaker.

Moreover, mobility needs SOMETHING equivalent to distination
rewriting, anyway.

> It has a lot to do with how 8+8 is done for
> DNS and the root servers.

Maybe for DNS but no for the root servers.

To make everything too much complex, the root servers should
have constant locator.

The root servers DOES worth additional 9 toplevel routing
table entries.

> I also do not believe we can assume any ESD can be globally unique by
> itself at any root Internet server (e.g. .com, edu, .arpa).

Stop using wrong terminologies.

The root is ".", not ".com".

And the uniqueness of the locators of the SECOND level servers
depends on how many are the second level servers.

> I think for our IPng Interim meeting Feb 27 and 28 we need to devote the
> entire two days to 8+8 and not even try to do other stuff.

You could have saved and still can save a lot of time by doing
discussion in the mailing list.

The idea has been around more than a year.

Discuss!

							Masataka Ohta
- - - - - - - - - - - - - - - - -

From: [email-masked]
To: Brandon Black <[email-masked]>
Cc: Masataka Ohta    <[email-masked]>, Tony Li <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2672) Re: larger AS/RD space for v6? 
Date: Sat, 04 Jan 97 11:05:39 -0500
Sender: [email-masked]

Brandon,

I agree.  I also think 8+8 (or where it will end up) will add additional
benefits to the CIDR paradigm and solves the Multihoming problem too for
large organizations.  The only part I don't like and will battle is that
when a packet leaves a host I do not think anyone should step on any
parts of the 128bit address space at site border routers or from ISP to
ISP.  I have given Mike this input at San Jose privately and also a
means that this part of 8+8 is unnecessary and still can support the
objectives of his proposal.  It has a lot to do with how 8+8 is done for
DNS and the root servers.

I also do not believe we can assume any ESD can be globally unique by
itself at any root Internet server (e.g. .com, edu, .arpa).  I say this
given the technology premises we have defined in IPv6 Neighbor Discovery
and Autoconfiguration (Stateless and DHCPv6).  But this does not mean
8+8 does not support dynamic renumbering by replacing the routing goop.
It is all in the interpretation of 8+8 and what part the host transport
mechanisms use (ESD) and what part the application layer uses (128bits).

I think for our IPng Interim meeting Feb 27 and 28 we need to devote the
entire two days to 8+8 and not even try to do other stuff.

/jim
- - - - - - - - - - - - - - - - -

Date: Sat, 4 Jan 1997 09:25:06 -0600 (CST)
From: Brandon Black <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: Tony Li <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2672) Re: larger AS/RD space for v6?
Sender: [email-masked]

On Sat, 4 Jan 1997, Masataka Ohta wrote:

> Tony;
> 
> > I'd like to point out that ANYTHING that "knows" about the internal
> > structure of the address is probably a mistake.  It constrains the future
> > flexibility of the system, thereby eliminating future adaptability.  Basic
> > engineering demands that create the absolute minimum in internal
> > interdependencies.  Thus, the address should be wholly opaque outside of
> > the routing system.
> 
> Any policy routing system MUST "know" about the internal structure
> of the address to the extent necessary for (fine or coarse) policy
> control.
> 
> For example, IPv4 routing systems know about lasses A, B and C.
> 
> Or, do you think classfull addressing mistake?
> 
> Then, with CIDRized class A, routing systems (even global ones) must
> know about the subnet masks.
> 
> No, this is not a proper example, because CIDR is a mistake. :-)
> 
> 							Masataka Ohta
> 

CIDR is not a mistake IMHO.  I think the original classes were a mistake,
althought probably an unforseeable one.  Every network address should
carry a mask, and how large or small that mask is should be up to
individual network needs.  Limiting network address sizes to being 16M
nodes, 64k nodes, or 255 nodes means that most people would waste a lot of
space, or have to use a bunch of C's as seperate networks when they may
have wanted a single continous network. 

The concept of classes, and their ability to make it unnecessary to
transmit masks (with a classful address space, the mask of any netework is
obvious), is a good one at first.... but to be effective, there would have
to be many more than 3 classes, and probably nobody can predict ahead of
time when designing a protocol how much space should go to each class.
Given that dilemma, the only reasonable classy solution would to be to
give a huge chunk of space to every class, which would result in being
wasteful of space.

As far as the backbone having to know too much, That's not really true in
many cases.  i.e. If I'm a backbone bgp speaker, and I'm advertising
130.130.0.0/16, then that is all the backbone needs to know and does
know... even if in reality that single route represents a routing
heirarchy of hundreds of subnets within my AS.

But I don't think Tony was referring really to the routing system knowing
(were you?)... it seems to me he was referring to the address itself
carrying inherent information... i.e. if someone just read off an IP to
me, I shouldn't be able to automatically know from that number the AS it
belongs to, its netmask, etc.... the adress should just be an address to
the user or host, and the routers should be the ones implementing a
routing policy on those addresses, which is flexible and not constrained
to a certain view of address structure.

.................................             ..............
: Brandon Lee Black  : [Office] :.............: [Personal] :....
:....................: [email-masked] : [email-masked] :.......
: "Sanity is the     : +1.281.362.6466 .......: [email-masked] :
: trademark of a     :.................:..../\: [email-masked] :
: weak mind. . ."    : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
:....................:.....................:..:.................:

- - - - - - - - - - - - - - - - -

From: [email-masked]
To: Masataka Ohta <[email-masked]>
Cc: [email-masked] (Tony Li), [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2672) Re: larger AS/RD space for v6? 
Date: Sat, 04 Jan 97 09:54:28 -0500
Sender: [email-masked]

Tony,

I understood what you mean't...

thanks
/jim
- - - - - - - - - - - - - - - - -

To: [email-masked] (David R. Conrad)
Cc: [email-masked]
Subject: Re: BGP-4+
From: Paul Traina <[email-masked]>
Date: 03 Jan 1997 16:54:29 -0800
Lines: 7
Sender: [email-masked]

Which is exactly why the protocol should be rev'ed to support >16 bit
"AS" numbers (RDs),  however we can refrain from using them at the start
so that we would be backwards compatible with BGP3^H4.

This is not rocket science.  Be liberal in what you accept, conservative in
what you send.

- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2672) Re: larger AS/RD space for v6?
To: [email-masked] (Tony Li)
Date: Sat, 4 Jan 97 9:43:59 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Tony;

> I'd like to point out that ANYTHING that "knows" about the internal
> structure of the address is probably a mistake.  It constrains the future
> flexibility of the system, thereby eliminating future adaptability.  Basic
> engineering demands that create the absolute minimum in internal
> interdependencies.  Thus, the address should be wholly opaque outside of
> the routing system.

Any policy routing system MUST "know" about the internal structure
of the address to the extent necessary for (fine or coarse) policy
control.

For example, IPv4 routing systems know about lasses A, B and C.

Or, do you think classfull addressing mistake?

Then, with CIDRized class A, routing systems (even global ones) must
know about the subnet masks.

No, this is not a proper example, because CIDR is a mistake. :-)

							Masataka Ohta
- - - - - - - - - - - - - - - - -

To: Dave Wreski <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: General info 
Date: Thu, 02 Jan 97 10:59:22 -0500
From: "Acee Lindem" <[email-masked]>
Sender: [email-masked]

Dave Wreski <[email-masked]>  writes:

> 
> Hi all.  I am interested in general info, other than the RFC's on BGP.  Is
> there a general BGP faq?  (ie, is it supported in gated, will my router
> handle it, etc).

BGP-3 and BGP-4 are supported by GateD. All the routers in your network 
support BGP-4 but the older ones (i.e., 6611s) will require a software
upgrade - the release you are currently running only supports BGP-3. Feel
free to contact me offline if you have any questions. 

Acee
- - - - - - - - - - - - - - - - -