Subject: using the TCP MD5 protection for BGP - Proposed Standard???

From: Sandy Murphy <[email-masked]>
Date: Mon, 27 Jul 1998 13:45:16 -0400 (EDT)

I just saw an announcement that the Protection of BGP Sessions via the 
TCP MD5 Signature Option draft was being put forward as a Proposed
Standard.

I hope that I won't hear a chorus of "For God's sake - where have
you been!".  But I thought that this was going to be proposed as a
BCP, not a PS.  If the idr group is going to propose a standard for
protecting BGP, then more work needs to be done with the TCP MD5 option.
The option documents an existing practice and deservedly so.  But the
existing practice was put into practice before many of the advances
in the use of MD5 for integrity and authentication protection were
known.  It doesn't use some of the ideas that have developed in the ipsec
group like using HMAC and replay protection.

And this is somewhat my fault, because I have not revised the draft I
presented before the group last December to include more discussion of
the differences between doing IPSEC, the TCP MD5 proposal or the
proposal that was made at the same time of doing MD5 at the BGP layer.

Can someone set me straight here?

And I obviously missed the fact in the last call that it was being
advanced as Proposed Standard, also.  Which troubles me, because I
try to pay particular attention to security related standards.

--Sandy

---

From: Pedro Marques <[email-masked]>
Date: Mon, 27 Jul 1998 11:32:37 -0700 (PDT)

>>>>> "Sandy" == Sandy Murphy <[email-masked]> writes:

    Sandy> I just saw an announcement that the Protection of BGP
    Sandy> Sessions via the TCP MD5 Signature Option draft was being
    Sandy> put forward as a Proposed Standard.

    Sandy> I hope that I won't hear a chorus of "For God's sake -
    Sandy> where have you been!".

Sandy,
My personal recollection is that the IDR wg has decided that the TCP MD5
document should be advanced as Proposed Standard in the December meeting
in D. C. This after considering the alternative of publishing the document
has BCP. I believe that the group agreed that publishing this document as
PS would not preclude the group to work on another method(s) for
authentication.

regards,
  Pedro.

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 27 Jul 1998 15:22:36 -0400

> group like using HMAC and replay protection.

As far I remember, the facts you're stating are correct, Sandy ... but I
guess one would have to check the minutes to be sure here.
        --- tony

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 28 Jul 1998 11:42:12 -0400

> try to pay particular attention to security related standards.

We've been back and forth and at the last meeting it was agreed that
PS was fine since we can always obsolete it if something better comes
along (most likely IPSEC standards get implemented).

One argument in favor of PS was that to the extent that IETF has any
effect on what vendors do, a PS gives vendors more incentive to do
more than nothing while waiting for the ultimate solution.

Are there any objections to the content of the draft (holes that need
to be plugged other than weakness in MD5?).

Curtis

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Tue, 28 Jul 1998 16:14:50 +0000 (GMT)

> to be plugged other than weakness in MD5?).

Curtis,

	there are some problems with the draft "Protection of BGP
Sessions via the TCP MD5 Signature Option" aside from using MD5 as
_the_ hash function. I did not check the idr archive so maybe someone
already made these suggestions. If so, please accept my apologies for
wasting your bandwidth. Some of the suggestions listed below will only
affect the draft and others will affect the implementation. First, the
easy ones:

- I found eight instances (not counting the title) of the word
"signature" in the document. This should be changed to "Integrity
Check Value (ICV)" or "authenticator" I prefer the latter but both
terms will be appropriate in this context.

Explanation: The protocol carries a keyed-hash as a TCP option. The
keys are pre-established manually and are common (of course) to both
ends of the communication. In RSA, a signature consists of a hash
encrypted with the sender's private key. In DSA, a signature consists
of a hash that has been modified by a signature function that depends
on the sender's private key and some other public values known to both
principals. This TCP option is only hashing the TCP segment and
nothing else. No encryption or modification of the hash is performed
on the segment before it flows down the stack. Based on the argument
provided above I suggest we change the title of the I-D to TCP MD5
Integrity Check Value (ICV) Option and edit the rest of the document
accordingly.

- There are some residual vulnerabilities in the protocol that i think
should be mentioned. For example, the fact that the keys are
configured manually (since there is no automated key management
facility) implies that these keys will exist for a reasonable amount
of time, certainly longer than a single TCP connection since no-one
will be reconfiguring the keys manually after every route flap, hard
reset or TCP FIN for that matter. THis means that the opportunity
exists for an attacker to replay old traffic that could cause
interesting problems. Of particular interest, would be recorded
traffic carrying hard resets. This traffic would succesfully pass the
ICV validation. The trick is in mapping the sequence numbers, which
could be done. Although it is harder than it used to be. This changes
will affect section 4.1 and will probably require a new section too.

- One would want to specify key sizes and ranges to be used in
conjuction with MD5. This will allow one to assess the level of
security being offered by this mechanism. Security through obscurity
(intentionally or not) has proven to be the wrong approach.  Hence,
section 4.5 needs some more explanation and clarification.

Now, the hard ones:

- The use of a hash algorithm in this keyed fashion (Keyed-MD5) has
been disparaged in the literature for two years, prompting changes in
the IPsec RFCs; it seems inappropriate to promote the use of this sort
of authentication technology in a newly issued RFC.  Personally, i
think we should provide an HMAC with either with the option of using
it with either (MD5 or SHA-1). 

I think that minimum we should modify section 4.4 since it gives the
impression that the collison problem of MD5 is the only problem with
using this option and, that we add a new section comparing the
keyed-MD5 transform used in this protocol versus using an HMAC with
MD5. Vendors who choose to implement this option and customers who
choose to use it will be able to assess the level of security provided
by this feature.

Luis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 29 Jul 1998 10:05:05 -0400

> terms will be appropriate in this context.

This strikes me as a wording change but the term authenticator is more
accurate.

> will affect section 4.1 and will probably require a new section too.

You'd also need to match the port pair.  Since one end is randomized
over the better part of 64k (or at least around 10k for TCP
implementations that restrict the range of port values) and the
initial sequence number is randomized, the chance of being able to
replay is quite small.

BTW- BGP sessions do last quite long.  Generally months or more.

> section 4.5 needs some more explanation and clarification.

OK.

> choose to use it will be able to assess the level of security provided

These seem like reasonable changes.  We may need two more TCP option
numbers for HMAC with MD5 and HMAC with SHA-1 or one more option and a
algorithm type (two bytes is plenty).  The TCP option 19 is already in
widespread use so we'd need to get another number.

The security consideration section could then state that:

   This document defines a weak but currently practiced security
   mechanism for BGP using MD5 and a incremental improvement using an
   HMAC with MD5 or an HMAC with SHA-1.  It is anticipated that future
   work will provide different stronger mechanisms for dealing with
   these issues.

Perhaps the author of the draft should comment rather than me (or
someone that knows what they are talking about rather than me :).

Curtis

ps- for us near crypto illiterates could you point to some consise
references that explain HMAC with MD5 and HMAC with SHA-1.

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Tue, 4 Aug 1998 21:59:59 +0000 (GMT)

> references that explain HMAC with MD5 and HMAC with SHA-1.

try rfc2104 first. It is a concise reference for HMAC (10 pages including
sample code). It explains how HMAC operates and how it could be used
in conjunction with crypto hash functions such as MD5 and SHA-1.

Luis

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: One more question 9) UPDATE MESSAGE HANDLING ii)
Date: Mon, 31 Aug 1998 17:13:04 PDT
Sender: [email-masked]

Hi,
1)   In section 9. Update message handling :
       ii ) If the new route is an overlapping route that is included in 
an earlier route contained in the Adj-RIB-In, the BGP speaker shall run 
its Decision Process since the more specific route has implicitly made a 
portion of the less specific route unavailable for use.
    
      Here i under stand the incoming route is a more specific route.
I just want to clarify that the RFC does not mean withdrawing the 
earlier less specific route - right?

2)    iii) If the new route is more specific and has identical path
attributes no further actions are necessary.
       Is this because the more specific route does not provide any new 
"value" for routing (because we already have the earlier less specific 
route with exactly the same routing attributes) ?

Thank you,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

To: [email-masked] (Eric Horowitz)
cc: [email-masked]
Subject: Re: Fwd: Re: NEXT_HOP Question...
From: Tony Li <[email-masked]>
Date: 31 Aug 1998 14:15:49 -0700
Lines: 29
Sender: [email-masked]

[email-masked] (Eric Horowitz) writes:

> OK, but what is the meaning of... 
> 
> " This immediate next hop MUST be used when installing the selected route
> in the Loc-RIB."
> 
> I understand that NEXT_HOP is a necessary attribute of a BGP route, but is
> "immediate next hop" another attribute?

No.  Again, the immediate next hop is the result of looking up the NEXT_HOP
in the routing table.  

> How is the immediate next hop used in installing the route into the Loc_RIB?

Your implementation has multiple choices, depending on the implementation
of the Loc_RIB.  In one implementation, the lookup of the NEXT_HOP can
actually happen by recursive lookup at packet forwarding time.  In this
case, one need only install the BGP route with the NEXT_HOP.

In another implementation, the NEXT_HOP is actually resolved into an
immediate next hop and then installed in the Loc_RIB.

Very simple, actually.

Tony

Date: Mon, 31 Aug 1998 11:25:47 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Fwd: Re: Internal Update Process...
Sender: [email-masked]

|  >|  " When a BGP speaker receives a new route from an external peer, it
|  >|    MUST advertise that route to all other internal peers by means of an
|  >|    UPDATE message if this routes has been installed in its Loc-RIB
|  >|    according to the route selection rules in 9.1.2."
|  >|  
|  >|  Well, 9.1.2 has NOT happened yet. 9.1.1 indicates that this 9.2.1 is done 
|  >|  BEFORE 9.1.2.
|  >
|  >
|  >Um, ok.  Yes, 9.2.1 should not use past tense.
|  >
|  Should I read this as...
|  
|      When a BGP speaker receives a new route from an external peer, it
|      MUST advertise that route to all other internal peers by means of an
|      UPDATE message if this routes ***WILL BE*** installed in its Loc-RIB
|      according to the route selection rules in 9.1.2.
|  
|  ?

I'm not sure that that isn't more confusing.  But yes, that would be
correct.  Note that the part that I'm worried about is that an
implementation should install the route in Loc-RIB before UPDATing
everyone.

Tony

Date: Mon, 31 Aug 1998 11:23:29 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

Someone privately responded:

|  > Even more concrete example: take three IBGP speakers, A, B and C.
|  > Suppose that B advertises an external route to A and C.  A selects B's path
|  > and installs it in its rib.  Now, A also selects one of its external paths
|  > and advertises that to B and C.
|  
|  Are you saying that this external path is the best route among all the routes
|  received from external peers but it is not the best bgp route to be installed
|  in the local rib? 

Exactly.

|  i.e. the best route for internal update is the external path
|  selected by A and the best BGP route is the one obtained from B.

Correct.

|  > C now has paths via A and B.  C can either use an external path or select
|  > B.  It must NOT select A.
|  
|  What if the local preference of the route sent by A is more than that sent by
|  B? I understand that C must NOT select A because A itself is using B but this
|  can be ensured only if the policies are configured consistently. How do the
|  protocol take care of misconfiguration of policies?

Then A would have selected its external route in preference to B's internal
route.

The protocol does NOT take care of misconfiguration of policies.  Several
folks have struggled with that and even detecting such misconfiguration is
extremely challenging.  It's (IMHO) basically an AI problem.

Tony

p.s. I prefer questions to the list as that means that we don't have to
repeat answers for each new BGP programmer.  ;-)

Date: Mon, 31 Aug 1998 09:14:16 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: Fwd: Re: NEXT_HOP Question...
Sender: [email-masked]

>|  REFERENCING draft-ietf-idr-bgp4-08.txt
>|  
>|  Sec 9.1.2 P41 states...
>|  
>|  
>|            The local speaker MUST determine the immediate
>|            next hop to the address depicted by the NEXT_HOP attribute of
the
>|            selected route by performing a lookup in the IGP and selecting
>|  one of
>|            the possible paths in the IGP.  This immediate next hop MUST
be used
>|            when installing the selected route in the Loc-RIB.  If the
route to
>|            the address depicted by the NEXT_HOP attribute changes such
that the
>|            immediate next hop changes, route selection should be
>|  recalculated as
>|            specified above.
>|  
>
>No you're misreading 9.1.2 here.  The point is that the local speaker gets
>a NEXT_HOP address that it is not adjacent to.  Then, it does an IGP lookup
>and (hopefully) finds an IGP route to the BGP NEXT_HOP.  This IGP route
>will have an IGP (i.e., immediate) next hop associated with it.  This does
>NOT imply any change to the BGP NEXT_HOP.
>
>Tony
>

OK, but what is the meaning of... 

" This immediate next hop MUST be used when installing the selected route
in the Loc-RIB."

I understand that NEXT_HOP is a necessary attribute of a BGP route, but is
"immediate next hop" another attribute?
How is the immediate next hop used in installing the route into the Loc_RIB?

Thanks - Eric...

===========================
Eric Horowitz
[email-masked]
===========================

Date: Mon, 31 Aug 1998 09:03:20 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: Fwd: Re: Internal Update Process...
Sender: [email-masked]

Thank you for the previous answers. They are a tremendous help.

>|  REFERENCING draft-ietf-idr-bgp4-08.txt
>|  
>|  QUESTION...
>|  
>|     Section 9.1.1 states...
>|  
>|  " The local speaker shall then run the internal update process
>|     of 9.2.1 to select and advertise the most preferable route."
>|  
>|     Section 9.2.1 states...
>|  
>|  " When a BGP speaker receives a new route from an external peer, it
>|    MUST advertise that route to all other internal peers by means of an
>|    UPDATE message if this routes has been installed in its Loc-RIB
>|    according to the route selection rules in 9.1.2."
>|  
>|  Well, 9.1.2 has NOT happened yet. 9.1.1 indicates that this 9.2.1 is done 
>|  BEFORE 9.1.2.
>
>
>Um, ok.  Yes, 9.2.1 should not use past tense.
>
Should I read this as...

    When a BGP speaker receives a new route from an external peer, it
    MUST advertise that route to all other internal peers by means of an
    UPDATE message if this routes ***WILL BE*** installed in its Loc-RIB
    according to the route selection rules in 9.1.2.

?

===========================
Eric Horowitz
[email-masked]
===========================

Date: Sun, 30 Aug 1998 21:47:10 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Internal Update Process...
Sender: [email-masked]

|  REFERENCING draft-ietf-idr-bgp4-08.txt
|  
|  QUESTION...
|  
|     Section 9.1.1 states...
|  
|  " The local speaker shall then run the internal update process
|     of 9.2.1 to select and advertise the most preferable route."
|  
|     Section 9.2.1 states...
|  
|  " When a BGP speaker receives a new route from an external peer, it
|    MUST advertise that route to all other internal peers by means of an
|    UPDATE message if this routes has been installed in its Loc-RIB
|    according to the route selection rules in 9.1.2."
|  
|  Well, 9.1.2 has NOT happened yet. 9.1.1 indicates that this 9.2.1 is done 
|  BEFORE 9.1.2.

Um, ok.  Yes, 9.2.1 should not use past tense.

|  =================================================
|  
|  Document suggestions
|  
|     The following minor wording changes would help me understand the
|  document. I submit them to this list because maybe the document is correct
|  and I don't understand it...
|  
|  1) 9.1.1: First paragraph....
|  
|  The Phase 1 decision function shall be ..., or a withdrawn route.
|  
|  "a withdrawn route" should be "withdrawn routes" (there may be several)

Actually, by the prior mail, it should be "... or withdrawn prefixes".

|  2) 9.1.1 is invoked for each new route. Thus the "For each" in paragraph 4
|  is redundant. I suggest changing it to "For the"

Ok.  Other folks?

|  3) 9.1.1 - last sentence - "The local speaker shall then run the internal
|  update process
|      of 9.2.1 to select and advertise the most preferable route."
|  
|      This sentence should indicate that it is only done for routes learned
|  from external peers. Thus it should be...
|  
|       "For a route learned from an external peer, the local speaker shall
|  then run the internal update process
|       of 9.2.1 to select and advertise the most preferable route."

Yup.  Other folks?

Tony

Date: Sun, 30 Aug 1998 21:37:26 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: withdrawn routes
Sender: [email-masked]

|  I am having trouble understanding how withdrawn routes relate to installed
|  routes. 
|  
|  As I understand it, a single installed route contains an NLRI which is a
|  list of <length, prefix> pairs. We'll use <l,p> for this discussion. 
|  
|  An update message can contain several withdrawn routes, each identified by
|  a SINGLE <l, p> pair. 

There's wording confusion here about the exact semantics of 'route'.  One
part of the document is being sloppy.  You withdraw prefixes.

|  How does this work? From the spec, I assumed that each <l,p> in the
|  withdrawn routes field of an UPDATE message corresponds to one route in the
|  receiving Adj-RIB-In but this can not be, since a route is identified by a
|  list of <l,p>'s.  
|  
|  Must I try to group the <l,p>'s in the withdrawn field into sets that
|  correspond to <l,p>'s in a route in the Adj-RIB-In?

No, the withdrawn <l,p>'s only withdraw the particular prefix, not the
entire set of prefixes advertised in a single UPDATE.

Tony

Date: Sun, 30 Aug 1998 21:34:39 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: NEXT_HOP Question...
Sender: [email-masked]

|  REFERENCING draft-ietf-idr-bgp4-08.txt
|  
|  Sec 9.1.2 P41 states...
|  
|  
|            The local speaker MUST determine the immediate
|            next hop to the address depicted by the NEXT_HOP attribute of the
|            selected route by performing a lookup in the IGP and selecting
|  one of
|            the possible paths in the IGP.  This immediate next hop MUST be used
|            when installing the selected route in the Loc-RIB.  If the route to
|            the address depicted by the NEXT_HOP attribute changes such that the
|            immediate next hop changes, route selection should be
|  recalculated as
|            specified above.
|  
|  But... 
|  
|  Sec 5.1.3 p.24 states...
|  
|            When a BGP speaker advertises the route to an internal peer, the
|            advertising speaker should not modify the NEXT_HOP attribute
|            associated with the route.  
|  
|  Now if we change the NEXT_HOP when entering a new route into the Loc_RIB as
|  part of Phase 2 (9.1.2), then the original next hop will be lost. 

No you're misreading 9.1.2 here.  The point is that the local speaker gets
a NEXT_HOP address that it is not adjacent to.  Then, it does an IGP lookup
and (hopefully) finds an IGP route to the BGP NEXT_HOP.  This IGP route
will have an IGP (i.e., immediate) next hop associated with it.  This does
NOT imply any change to the BGP NEXT_HOP.

Also note that this only applies to IBGP learned routes.  If it's via EBGP,
it should be an adjacent address.  And because you never pass an IBGP
learned route to an IBGP peer (modulo route reflectors), this language
shouldn't be ambiguous.

Tony

Date: Sun, 30 Aug 1998 21:30:01 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: NEXT_HOP
Sender: [email-masked]

|  REFERENCING draft-ietf-idr-bgp4-08.txt
|  
|  Section 5.1.3 P.24
|  
|  I am trying to interpret the following statement. I added the numbers in
|  parentheses.
|  
|            A BGP speaker (1) can advertise any external peer router (2) in
|            the NEXT_HOP attribute provided that the IP address of this border
|            router (2) was learned from an external peer (3) and the external
|  peer (4) to
|            which the route is being advertised shares a common subnet with the
|            NEXT_HOP address.  This is a second form of "third party" NEXT_HOP
|            attribute.
|  
|  Is this paragraph speaking of 4 different speakers?

Yes, that's correct.

|  (1) The advertising BGP speaker.
|  (2) The NEXT_HOP router.
|  (3) The router from which (1) learned of (2)
|  (4) The recipient of the advertisement.

Exactly.

|  Why must (2) be an peer? To whom is it a peer? 

Ok, that's a bug.  (2) need not be a peer.  

Proposed text:

A BGP speaker can advertise any adjacent router in the NEXT_HOP attribute
provided that the IP address of this router was learned from an external
peer and the external peer to which the route is being advertised shares a
common subnet with the NEXT_HOP address.

Tony

Date: Sat, 29 Aug 1998 13:34:09 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|  Let me interject the service provider's perspective. EBGP multi hop
|  is used extensively, especially in cases where you have two parallel
|  links between two routers in different ASs and you want to attempt
|  some load sharing.

Ah yes, this is a well-known kludge that we should never have let out of
the lab...

Tony

Date: Sat, 29 Aug 1998 02:01:38 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|  11. Non RFC1771 question: Does EBGP multihop means we are talking 
|     EBGP to a peer that is not on the same subnet as ourselves. I 
|     thought the RFC explicitly prohibited this. But i see many commercial 
|  implementations to this. 
|      (in such cases what guarantees the reachability to this EBGP peer ? 
|  - is the path hand configured or an IGP is used ?)

In particular, implementors do this so that they can test without actually
getting on a plane.  A good commercial implementation will discourage users
from using this. 

Nothing guarantees the path, and if the path ends up with another AS or two
in it, wierd things (and bad things) can happen.

Just say no.

Tony

Date: Sat, 29 Aug 1998 01:58:38 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|  8. What is the average length of the AS-PATHS to expect in the UPDATE 
|  message (not considering the case where AS'S are duplicated to increase 
|  the path length) - mean AS diameter of the current internet?

How long is a piece of string?

;-)

Tony

Date: Sat, 29 Aug 1998 01:57:49 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|  7. Am i correct in understanding that there are two wait states to 
|  consider for the routes.
|     a) For IBGP routes, wait for the NEXT_HOP to be reachable via IGP,
|        and the IBGP prefix itself reachable via IGP.

Yes, tho the latter is frequently disabled by manual configuration.

|     b) For EBGP routes wait for the route advertisement interval, ( for a 
|  peer)

Yes.

|     c) For locally generated routes wait for the origin adv. interval ( 
|  for a peer )

Yes.

Note that a) is a correctness issue (Don't advertise black holes), while b)
& c) are simply limiting flappage.

Tony

Date: Sat, 29 Aug 1998 01:56:05 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|  > Also ( unrelated ), are you saying we could potentially for a prefix 'p'
|  > learnt from EBGP peers PEER-A,PEER-B choose route from PEER-A for
|  > updating the IBGP peers and use route from PEER-B for updating the other
|  > EBGP peers.?
|  
|  Yes it is possible to send different best route to IBGP peers ( after
|  selecting the best route among all routes received from neighboring ASs) and
|  a different best route to EBGP peers ( after selecting the best route
|  received from all BGP peers ). But if the policies are consistent in all the
|  peers in an autonomous system, all the peers finally will have the same
|  route.

I'm not certain, but I think the answer doesn't quite match the question
here (btw, the answer is correct for the question not asked ;-).

I think that the original question has three speakers, A, B and C.  C
learns paths for 'p' from A and B.  Can C select A to send internally and B
to send externally?

The answer to this question is no.  If path B is installed in the RIB and
an IBGP speaker believes path A, then you have a possible forwarding loop.
If path A is installed, then you're lying to EBGP peers.

Tony

Date: Sat, 29 Aug 1998 01:43:31 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|  6. 9.2.1.1 says "If the local system can ascertain the cost of a path to 
|  the entity depicted by the NEXT-HOP". What is the context here?
|  (same goes to the one in the route selection criteria)

~= Use your IGP cost to the next hop as a tiebreaker.  Closest exit
wins. =~

Tony

Date: Sat, 29 Aug 1998 01:40:50 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|  >> 3. I understand internal update process considers the ADJ-RIBs-in 
|  from
|  >> external peers and takes a decision to IBGP advertise. If the route 
|  so
|  >> selected is not installed in LOC-RIB (by 9.1.2 ) we must not 
|  advertise
|  >> this - right? (according to 9.2.1)
|  >
|  >We must not advertise it to external BGP peers.
|  
|     What is the decision regarding the internal peers (this is 
|     internal update process)
|     (9.2.1 says "When a BGP speaker receives a new route from an external 
|  peer, it MUST advertise that route to all other internal peers by means 
|  of an UPDATE message if this routes has been installed in its LOC-RIB 
|  according to the route selection rules in 9.1.2".
|     I am interpreting this as saying " ONLY if the route has been 
|  installed in its LOC-RIB"?)

Let me summarize informally and let's see if that clarifies things.  In
general a BGP speaker simply selects a path, installs it in it's RIB and
then advertises it.  This is BGP Principle #1.  ;-)

However, there is one possible exception.  If a BGP speaker (named A) has
selected a path from an internal peer, AND it also has alternate paths from
external peers, that BGP speaker can advertise the external path to its
internal peers.

Other IBGP speakers can do one of two things: either they can select and
use the same internal path that A is using, or they can select and use some
external path.  In either case, they should ignore the internal path that A
is advertising.

A's advertisement is beneficial in that it reduces churn if the primary
path is lost, because all IBGP speakers already have the information for
'the next best path'.  

Even more concrete example: take three IBGP speakers, A, B and C.  
Suppose that B advertises an external route to A and C.  A selects B's path
and installs it in its rib.  Now, A also selects one of its external paths
and advertises that to B and C.

C now has paths via A and B.  C can either use an external path or select
B.  It must NOT select A.

Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Date: Fri, 28 Aug 1998 09:21:56 PDT
Sender: [email-masked]

Hi,
  
>
>In RFC1771, I can not see the above statement in 9.2.1
>
>
  I am refering to : 
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-08.txt

-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Fri, 28 Aug 1998 11:55:39 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: jaihari loganathan <[email-masked]>
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

jaihari loganathan wrote:

> Hi,
>
> >> 3. I understand internal update process considers the ADJ-RIBs-in
> from
> >> external peers and takes a decision to IBGP advertise. If the route
> so
> >> selected is not installed in LOC-RIB (by 9.1.2 ) we must not
> advertise
> >> this - right? (according to 9.2.1)
> >
> >We must not advertise it to external BGP peers.
>
>    What is the decision regarding the internal peers (this is
>    internal update process)
>    (9.2.1 says "When a BGP speaker receives a new route from an external
> peer, it MUST advertise that route to all other internal peers by means
> of an UPDATE message if this routes has been installed in its LOC-RIB
> according to the route selection rules in 9.1.2".
>    I am interpreting this as saying " ONLY if the route has been
> installed in its LOC-RIB"?)

In RFC1771, I can not see the above statement in 9.2.1

> >> 7. Am i correct in understanding that there are two wait states to
> >> consider for the routes.
> >>    a) For IBGP routes, wait for the NEXT_HOP to be reachable via IGP,
> >>       and the IBGP prefix itself reachable via IGP.
> >
> >You do not have to wait for NEXT_HOP. It will be there in your IGP.
> >
>
>     I am seeing in a public domain version of gated where there is an
>     attempt to sync up with the NEXT_HOP received in an IBGP route.
>     Are you saying that by the time we receive the NEXTHOP attribute
>     of the IBGP route we learnt, our IGP would've already learnt the
>     route to the NEXTHOP.
>     Consider two peers talking IBGP PEER-3 and PEER-1 (meaning TCP
>     connection is established and they are exchaning updates )
>     Consider for the PEER-1, a external-AS-interface comes up ( IP
> subnet is P2 , and is being propagated by IGP inside the AS and let's
> say it takes a time 't') and  a neighbouring AS PEER-2 establishes a
> connection. At this point consider N1 as the host address of the PEER-2
> which it is using  to advertise a EBGP route to prefix 'p' to the PEER-1
> in the initial blast of routes.
>      Suppose the PEER-3 receives this IBGP route to prefix 'p'
>      with NEXTHOP N1 , at this point IGP route to N1 has not caught up
> in PEER-3, does this not represent a unsynchronized condition?
>

No this is not unsynchronized condition because if the route to the next hop
is not there in PEER-3's IGP, this route will not be considered in the route
selection procedure ( though it will be there in Adj-RIB_IN) and hence will
not be installed in the IP forwarding table.

> Also ( unrelated ), are you saying we could potentially for a prefix 'p'
> learnt from EBGP peers PEER-A,PEER-B choose route from PEER-A for
> updating the IBGP peers and use route from PEER-B for updating the other
> EBGP peers.?

Yes it is possible to send different best route to IBGP peers ( after
selecting the best route among all routes received from neighboring ASs) and
a different best route to EBGP peers ( after selecting the best route
received from all BGP peers ). But if the policies are consistent in all the
peers in an autonomous system, all the peers finally will have the same
route.

>
>
> >Hope it helps.
>
>   A lot. Thank you for your time.
> -Jaihari.
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

-Rajesh

--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

From: "jaihari loganathan" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Date: Fri, 28 Aug 1998 08:25:03 PDT
Sender: [email-masked]

Hi,

>> 3. I understand internal update process considers the ADJ-RIBs-in 
from
>> external peers and takes a decision to IBGP advertise. If the route 
so
>> selected is not installed in LOC-RIB (by 9.1.2 ) we must not 
advertise
>> this - right? (according to 9.2.1)
>
>We must not advertise it to external BGP peers.

   What is the decision regarding the internal peers (this is 
   internal update process)
   (9.2.1 says "When a BGP speaker receives a new route from an external 
peer, it MUST advertise that route to all other internal peers by means 
of an UPDATE message if this routes has been installed in its LOC-RIB 
according to the route selection rules in 9.1.2".
   I am interpreting this as saying " ONLY if the route has been 
installed in its LOC-RIB"?)

>> 7. Am i correct in understanding that there are two wait states to
>> consider for the routes.
>>    a) For IBGP routes, wait for the NEXT_HOP to be reachable via IGP,
>>       and the IBGP prefix itself reachable via IGP.
>
>You do not have to wait for NEXT_HOP. It will be there in your IGP.
>
    
    I am seeing in a public domain version of gated where there is an
    attempt to sync up with the NEXT_HOP received in an IBGP route.
    Are you saying that by the time we receive the NEXTHOP attribute
    of the IBGP route we learnt, our IGP would've already learnt the
    route to the NEXTHOP.
    Consider two peers talking IBGP PEER-3 and PEER-1 (meaning TCP
    connection is established and they are exchaning updates )
    Consider for the PEER-1, a external-AS-interface comes up ( IP 
subnet is P2 , and is being propagated by IGP inside the AS and let's 
say it takes a time 't') and  a neighbouring AS PEER-2 establishes a 
connection. At this point consider N1 as the host address of the PEER-2 
which it is using  to advertise a EBGP route to prefix 'p' to the PEER-1 
in the initial blast of routes. 
     Suppose the PEER-3 receives this IBGP route to prefix 'p'
     with NEXTHOP N1 , at this point IGP route to N1 has not caught up 
in PEER-3, does this not represent a unsynchronized condition?

Also ( unrelated ), are you saying we could potentially for a prefix 'p' 
learnt from EBGP peers PEER-A,PEER-B choose route from PEER-A for 
updating the IBGP peers and use route from PEER-B for updating the other 
EBGP peers.? 

>Hope it helps.

  A lot. Thank you for your time.
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Fri, 28 Aug 1998 10:40:48 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: jaihari loganathan <[email-masked]>
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

jaihari loganathan wrote:

> Hi,
>    Here is a list of putting-the-pieces-together questions. Thanks for
> your time ( and patience).
>
> 1. As i understand from earlier e-mails (from Tony,Rajesh) Calculation
> of degree of preference is done for both EBGP and IBGP learnt routes.
> Phase 1 (9.1.1) calls for internal update process (9.2.1) to advertise
> ONLY  EBGP learnt routes. Is this the correct interpretation?

Yes

>
>
> 2. By 9.2.1.1 considering different EBGP routes and selecting one to
> advertise to an IBGP peer, is it possible to choose a EBGP route for
> IBGP advertisement that is different from the one chosen to install in
> the LOC-RIB (according to the 9.1.2)?

Yes

>
>
> 3. I understand internal update process considers the ADJ-RIBs-in from
> external peers and takes a decision to IBGP advertise. If the route so
> selected is not installed in LOC-RIB (by 9.1.2 ) we must not advertise
> this - right? (according to 9.2.1)

We must not advertise it to external BGP peers.

>     This is confusing :
>       If a route's IBGP advertisement is always going to be determined
> by the fact that whether it is installed in LOC-RIB, why do we have a
> separate advertisement selection criteria. a) If the route selected
> according to 9.2.1.1 is not selected to be installed in LOC-RIB (in
> accordance with 9.1.2), we are prohibited from IBGP advertisement. b) If
> the route is selected according to 9.2.1.1 for IBGP advertisement is
> ALSO selected to be installed in LOC-RIB ONLY then we are allowed to do
> IBGP advertisement. Why not then use just the route selected by LOC-RIB
> to IBGP advertise ( if the route so selected did not come from another
> IBGP peer?)
>
> 4. 9.2.1 Internal Update tie-breaker : What if the MEDs are coming from
> different AS? (I understand the route selection criteria 9.1.2 addresses
> this, but here it is not stated explicitly )

You compare MEDs if routes are coming from the same AS.

>
>
> 5. Iam not understanding what Phase 3 does. The spec says Phase 3
> processes all routes in the LOC-RIB into the corresponding entry in the
> associated Adj-RIBS-out.
>     Are we talking about ONLY Adj-RIBs-out of external peers here?

Yes

>     (meaning what happens to the one chosen from ADJ-RIBs-In according
> to 9.2.1.1, By definition Adj-RIBs-out MUST contain the routes
> advertised -right ?)

They have already been taken care in internal update.

>
>
> 6. 9.2.1.1 says "If the local system can ascertain the cost of a path to
> the entity depicted by the NEXT-HOP". What is the context here?
> (same goes to the one in the route selection criteria)
>
> 7. Am i correct in understanding that there are two wait states to
> consider for the routes.
>    a) For IBGP routes, wait for the NEXT_HOP to be reachable via IGP,
>       and the IBGP prefix itself reachable via IGP.

You do not have to wait for NEXT_HOP. It will be there in your IGP.

>    b) For EBGP routes wait for the route advertisement interval, ( for a
> peer)
>    c) For locally generated routes wait for the origin adv. interval (
> for a peer )
>
> 8. What is the average length of the AS-PATHS to expect in the UPDATE
> message (not considering the case where AS'S are duplicated to increase
> the path length) - mean AS diameter of the current internet?

I would also like to hear from somebody :-))

>
>
> 9. In ASPATH aggregation under 9.2.4.1 : "-determine the longest leading
> sequence of tuples" . Here the term 'sequence' has nothing to
> do with AS_SEQUENCE - right? (meaning as long as the leading stream of
> tuples are same ? )

Yes

>
>
> 10. In 9.1.2 while resolving the NEXT_HOP attribute and using the IGP
> gateway, are we talking about both IBGP and EBGP routes here ( EBGP
> routes i understand are required to be reachable without the use of an
> IGP - on the same subnet as the peer?)

Yes

>
>
> 11. Non RFC1771 question: Does EBGP multihop means we are talking
>    EBGP to a peer that is not on the same subnet as ourselves. I
>    thought the RFC explicitly prohibited this. But i see many commercial
> implementations to this.
>     (in such cases what guarantees the reachability to this EBGP peer ?
> - is the path hand configured or an IGP is used ?)

It is a manual configuration.

>
>
> Thanks for your time and hopefully i am done with all my questions.
>
> -Jaihari.
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

Hope it helps.
-Rajesh
--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

From: "jaihari loganathan" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Date: Fri, 28 Aug 1998 06:04:41 PDT
Sender: [email-masked]

Hi,
   Here is a list of putting-the-pieces-together questions. Thanks for 
your time ( and patience).

1. As i understand from earlier e-mails (from Tony,Rajesh) Calculation 
of degree of preference is done for both EBGP and IBGP learnt routes.
Phase 1 (9.1.1) calls for internal update process (9.2.1) to advertise 
ONLY  EBGP learnt routes. Is this the correct interpretation?

2. By 9.2.1.1 considering different EBGP routes and selecting one to 
advertise to an IBGP peer, is it possible to choose a EBGP route for 
IBGP advertisement that is different from the one chosen to install in 
the LOC-RIB (according to the 9.1.2)?

3. I understand internal update process considers the ADJ-RIBs-in from 
external peers and takes a decision to IBGP advertise. If the route so
selected is not installed in LOC-RIB (by 9.1.2 ) we must not advertise 
this - right? (according to 9.2.1)
    This is confusing :
      If a route's IBGP advertisement is always going to be determined 
by the fact that whether it is installed in LOC-RIB, why do we have a 
separate advertisement selection criteria. a) If the route selected 
according to 9.2.1.1 is not selected to be installed in LOC-RIB (in 
accordance with 9.1.2), we are prohibited from IBGP advertisement. b) If 
the route is selected according to 9.2.1.1 for IBGP advertisement is 
ALSO selected to be installed in LOC-RIB ONLY then we are allowed to do 
IBGP advertisement. Why not then use just the route selected by LOC-RIB 
to IBGP advertise ( if the route so selected did not come from another 
IBGP peer?)

4. 9.2.1 Internal Update tie-breaker : What if the MEDs are coming from 
different AS? (I understand the route selection criteria 9.1.2 addresses 
this, but here it is not stated explicitly )

5. Iam not understanding what Phase 3 does. The spec says Phase 3 
processes all routes in the LOC-RIB into the corresponding entry in the 
associated Adj-RIBS-out.
    Are we talking about ONLY Adj-RIBs-out of external peers here?
    (meaning what happens to the one chosen from ADJ-RIBs-In according 
to 9.2.1.1, By definition Adj-RIBs-out MUST contain the routes 
advertised -right ?)

6. 9.2.1.1 says "If the local system can ascertain the cost of a path to 
the entity depicted by the NEXT-HOP". What is the context here?
(same goes to the one in the route selection criteria)

7. Am i correct in understanding that there are two wait states to 
consider for the routes.
   a) For IBGP routes, wait for the NEXT_HOP to be reachable via IGP,
      and the IBGP prefix itself reachable via IGP.
   b) For EBGP routes wait for the route advertisement interval, ( for a 
peer)
   c) For locally generated routes wait for the origin adv. interval ( 
for a peer )

8. What is the average length of the AS-PATHS to expect in the UPDATE 
message (not considering the case where AS'S are duplicated to increase 
the path length) - mean AS diameter of the current internet?

9. In ASPATH aggregation under 9.2.4.1 : "-determine the longest leading 
sequence of tuples" . Here the term 'sequence' has nothing to
do with AS_SEQUENCE - right? (meaning as long as the leading stream of 
tuples are same ? )

10. In 9.1.2 while resolving the NEXT_HOP attribute and using the IGP 
gateway, are we talking about both IBGP and EBGP routes here ( EBGP 
routes i understand are required to be reachable without the use of an 
IGP - on the same subnet as the peer?)

11. Non RFC1771 question: Does EBGP multihop means we are talking 
   EBGP to a peer that is not on the same subnet as ourselves. I 
   thought the RFC explicitly prohibited this. But i see many commercial 
implementations to this. 
    (in such cases what guarantees the reachability to this EBGP peer ? 
- is the path hand configured or an IGP is used ?)

Thanks for your time and hopefully i am done with all my questions.

-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Thu, 27 Aug 1998 08:55:14 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: NEXT_HOP
Sender: [email-masked]

REFERENCING draft-ietf-idr-bgp4-08.txt

Section 5.1.3 P.24

I am trying to interpret the following statement. I added the numbers in
parentheses.

          A BGP speaker (1) can advertise any external peer router (2) in
          the NEXT_HOP attribute provided that the IP address of this border
          router (2) was learned from an external peer (3) and the external
peer (4) to
          which the route is being advertised shares a common subnet with the
          NEXT_HOP address.  This is a second form of "third party" NEXT_HOP
          attribute.

Is this paragraph speaking of 4 different speakers?

(1) The advertising BGP speaker.
(2) The NEXT_HOP router.
(3) The router from which (1) learned of (2)
(4) The recipient of the advertisement.

Why must (2) be an peer? To whom is it a peer? 

Thanks - Eric...

===========================
Eric Horowitz
[email-masked]
===========================

Date: Wed, 26 Aug 1998 09:04:44 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: NEXT_HOP Question...
Sender: [email-masked]

REFERENCING draft-ietf-idr-bgp4-08.txt

Sec 9.1.2 P41 states...

          The local speaker MUST determine the immediate
          next hop to the address depicted by the NEXT_HOP attribute of the
          selected route by performing a lookup in the IGP and selecting
one of
          the possible paths in the IGP.  This immediate next hop MUST be used
          when installing the selected route in the Loc-RIB.  If the route to
          the address depicted by the NEXT_HOP attribute changes such that the
          immediate next hop changes, route selection should be
recalculated as
          specified above.

But... 

Sec 5.1.3 p.24 states...

          When a BGP speaker advertises the route to an internal peer, the
          advertising speaker should not modify the NEXT_HOP attribute
          associated with the route.  

Now if we change the NEXT_HOP when entering a new route into the Loc_RIB as
part of Phase 2 (9.1.2), then the original next hop will be lost. As I
understand it, there is (implementation decisions withstanding) one
Adj_RIB_In per peer and one Adj_RIB_Out per peer but only one Loc_RIB per
speaker. So this route, installed with a new NEXT_HOP into the Loc_RIB will
be used for all internal and external peers. Do we need to track another
field, immediate-next-hop which we use for external peers but not internal
ones?

===========================
Eric Horowitz
[email-masked]
===========================

From: [email-masked]
Date: Wed, 26 Aug 1998 11:26:37 -0400 (EDT)
To: [email-masked]
Subject: August 26th IDR notes
Sender: [email-masked]

Agenda:

 bgp-4 mib
 Secure-bgp (S-BGP) Luis Sanchez (BBN)

1) bgp-4 MIB

  BGP-4+ MIB is being revised to match current NM format.
  We will be sending out another revision in 2 weeks.

2) Secure-BGP 
 
   Presentation location will be posted to the mail list.   

   Discussion:
	a) AS path must be intact.  AS routes are intact 
		except for Route Servers and Confederations.
		Route server may be configured to either add the
		Route Server AS or to not add the Route Server AS.
		Confederations 
   
	b) Authentication per NLRI or per block
	   if per block, then you must carry the whole Updates

   Luis will post the write-up of this presentation to the mail group.
         
Susan Hares 

Date: Wed, 26 Aug 1998 08:29:05 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: withdrawn routes
Sender: [email-masked]

I am having trouble understanding how withdrawn routes relate to installed
routes. 

As I understand it, a single installed route contains an NLRI which is a
list of <length, prefix> pairs. We'll use <l,p> for this discussion. 

An update message can contain several withdrawn routes, each identified by
a SINGLE <l, p> pair. 

How does this work? From the spec, I assumed that each <l,p> in the
withdrawn routes field of an UPDATE message corresponds to one route in the
receiving Adj-RIB-In but this can not be, since a route is identified by a
list of <l,p>'s.  

Must I try to group the <l,p>'s in the withdrawn field into sets that
correspond to <l,p>'s in a route in the Adj-RIB-In?

Thanks - Eric...

===========================
Eric Horowitz
[email-masked]
===========================

Date: Wed, 26 Aug 1998 08:14:49 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: Internal Update Process...
Sender: [email-masked]

REFERENCING draft-ietf-idr-bgp4-08.txt

QUESTION...

   Section 9.1.1 states...

" The local speaker shall then run the internal update process
   of 9.2.1 to select and advertise the most preferable route."

   Section 9.2.1 states...

" When a BGP speaker receives a new route from an external peer, it
  MUST advertise that route to all other internal peers by means of an
  UPDATE message if this routes has been installed in its Loc-RIB
  according to the route selection rules in 9.1.2."

Well, 9.1.2 has NOT happened yet. 9.1.1 indicates that this 9.2.1 is done 
BEFORE 9.1.2.

=================================================

Document suggestions

   The following minor wording changes would help me understand the
document. I submit them to this list because maybe the document is correct
and I don't understand it...

1) 9.1.1: First paragraph....

The Phase 1 decision function shall be ..., or a withdrawn route.

"a withdrawn route" should be "withdrawn routes" (there may be several)

2) 9.1.1 is invoked for each new route. Thus the "For each" in paragraph 4
is redundant. I suggest changing it to "For the"

3) 9.1.1 - last sentence - "The local speaker shall then run the internal
update process
    of 9.2.1 to select and advertise the most preferable route."

    This sentence should indicate that it is only done for routes learned
from external peers. Thus it should be...

     "For a route learned from an external peer, the local speaker shall
then run the internal update process
     of 9.2.1 to select and advertise the most preferable route."

===========================
Eric Horowitz
[email-masked]
===========================

Date: Tue, 25 Aug 1998 15:34:47 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

|       I understand among all different paths available to a prefix
|       one route is chosen as the best route according to the route
|       selection criteria of 9.1.2.1
|       Why is there another route selection criteria in 9.2.1.1
|       I understand this says it is for internal updates.
|       But the section 9.2.1 (Internal updates) also says this procedure
|       advertises to internal peers if the route has been installed 
|  according to 9.1.2.
|        I am confused as to why there are two route selection criteria
|        specified? Or are they the same given in different context.

9.1.2.1 is for selecting which routes to inject into your FIB.

9.2.1.1 is for selecting which routes to advertise.

Not at all the same...

Tony

Date: Tue, 25 Aug 1998 15:29:40 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: UPDATE Message Handling
Sender: [email-masked]

|  	Once a BGP connection is extablished between two BGP Speacker, 
|  	A ROUTE WILL BE ADVERTISED ONLY ONCE FROM ONE SPEACKER TO
|  	ANOTHER SPEAKER, since they have reliable connection. (Assume there
|  	is no change for that route after)
|  
|  	A better implementaion MUST receive all the routes advertiesd by
|  	its peer and KEEP it in RIB-IN. 

Let's be very careful here.  An implementation MAY choose to keep routes or
it MAY choose to discard them.  There are non-trivial tradeoffs involved
when considering the memory requirements of storing an arbitrary amount of
information, and those requirements vary widely depending on the intended
use of the implementation.  "Best" is a value judgement.

|  	Dynamic reconfiguration can cause the recevied route to ACTIVE.
|  	See, if you don't keep all the routes advertied by peers, in RIB-In,
|  	you will MISS THE ROUTE. Because  your peer won't know about all
|  	the dynamic reconfiguration and obviously he won't advertise once
|  again.
|  	So you will loss.

Unless you restart the connection upon reconfiguration, in which case you
simply need to understand when you want to restart the connection.

Tony

Date: Tue, 25 Aug 1998 18:31:51 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: jaihari loganathan <[email-masked]>
CC: [email-masked]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [email-masked]

Jaihari,
For internal updates, you consider only those routes which have been
obtained from neighboring ASs while for best BGP route selection, you
consider all the routes received from internal as well as external peers.
This is the difference in these two criteria.

Thanks,
Rajesh

jaihari loganathan wrote:

> Folks,
>      I understand among all different paths available to a prefix
>      one route is chosen as the best route according to the route
>      selection criteria of 9.1.2.1
>      Why is there another route selection criteria in 9.2.1.1
>      I understand this says it is for internal updates.
>      But the section 9.2.1 (Internal updates) also says this procedure
>      advertises to internal peers if the route has been installed
> according to 9.1.2.
>       I am confused as to why there are two route selection criteria
>       specified? Or are they the same given in different context.
> Thanks for your response,
> -Jaihari.
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

From: "jaihari loganathan" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Section 6.2 Open message error handling
Date: Tue, 25 Aug 1998 14:51:59 PDT
Sender: [email-masked]

I never said i am not going to support BGP3 :-)
My statement specifically said "For e.g". (honest :-) ).
-Jaihari.

>From [email-masked] Tue Aug 25 09:50:25 1998
>Received: from red.juniper.net (localhost.juniper.net [127.0.0.1])
>	by red.juniper.net (8.8.5/8.8.5) with ESMTP id JAA17130;
>	Tue, 25 Aug 1998 09:50:22 -0700 (PDT)
>Message-Id: <[email-masked]>
>To: Tony Li <[email-masked]>
>cc: [email-masked], [email-masked]
>Subject: Re: Section 6.2 Open message error handling
>In-reply-to: Your message of "Tue, 25 Aug 1998 09:20:12 PDT."
>             <[email-masked]>
>Date: Tue, 25 Aug 1998 09:50:22 -0700
>From: Paul Traina <[email-masked]>
>
>Oh my... Jaihari's not going to support BGP3?
>Ouch, there goes backwards compatability with the butterfly's out the 
door. :-(

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Tue, 25 Aug 1998 09:20:12 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Section 6.2 Open message error handling
Sender: [email-masked]

Seems like you need to send a 4 then, yes?

Tony

|    The section 6.2 (draft-ietf-idr-bgp4-08.txt,page 27) reads :
|    "If the version number contained in the Version field of the received 
|  OPEN message is not supported, then ......
|  ......... 
|     The Data field is a 2-octet unsigned integer, which indicates the 
|  LARGEST LOCALLY SUPPORTED VERSION NUMBER LESS THAN THE VERSION THE
|  REMOTE PEER BID)"
|  
|    What happens if you don't have any version less (than what the peer
|    bid) to support? What should the data field contain?
|    (For e.g : if the local implementation supports only version 4?)
|  Thank You,
|  -Jaihari.
|  
|  
|  ______________________________________________________
|  Get Your Private, Free Email at http://www.hotmail.com
|  

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: Section 6.2 Open message error handling
Date: Tue, 25 Aug 1998 00:45:05 PDT
Sender: [email-masked]

Hi,
  The section 6.2 (draft-ietf-idr-bgp4-08.txt,page 27) reads :
  "If the version number contained in the Version field of the received 
OPEN message is not supported, then ......
......... 
   The Data field is a 2-octet unsigned integer, which indicates the 
LARGEST LOCALLY SUPPORTED VERSION NUMBER LESS THAN THE VERSION THE
REMOTE PEER BID)"

  What happens if you don't have any version less (than what the peer
  bid) to support? What should the data field contain?
  (For e.g : if the local implementation supports only version 4?)
Thank You,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Tue, 25 Aug 1998 16:13:25 +0530
From: SS Pillai <[email-masked]>
To: Tony Li <[email-masked]>
CC: [email-masked]
Subject: Re: UPDATE Message Handling
Sender: [email-masked]

Tony Li wrote:
> 
> |            If the UPDATE message contains a feasible route, it shall be placed
> |            in the appropriate Adj-RIB-In, and the following additional actions
> |            shall be taken:
> |
> |            i) ...
> |
> |            ii) ...
> |
> |            iii) If ...,  no further actions are necessary.
> |
> |            iv) If ..., then the new route shall be placed in the Adj-RIB-In.
> |
> |            v) If the new route is an overlapping route that is less specific
> |            (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
> |            BGP speaker shall run its Decision Process on the set of
> |  destinations
> |            described only by the less specific route.
> |
> |  What is confusing me is that the first paragraph clearly states that the
> |  route shall be placed in the Adj-RIB-In but the additional actions seem to
> |  indicate that this is not always the case. Is it true that in cases (i) and
> |  (ii) the new route replaces an older route, in case (iii) and (iv) the new
> |  route is NOT placed in the Adj-RIB-In and in case (iv) it is placed in the
> |  Adj-RIB-In?
> 
> The distinction between putting an unuseable prefix in Adj-RIB-In and not
> putting it into Adj-RIB-In at all is pretty much an implementation
> decision.
> 
> I know one implementation that always ejected discarded routes.  I know
> another that never did so.  The question is, how will the implementation
> deal with policy changes.
> 
> Tony

Hi,
	Once a BGP connection is extablished between two BGP Speacker, 
	A ROUTE WILL BE ADVERTISED ONLY ONCE FROM ONE SPEACKER TO
	ANOTHER SPEAKER, since they have reliable connection. (Assume there
	is no change for that route after)

	A better implementaion MUST receive all the routes advertiesd by
	its peer and KEEP it in RIB-IN. 

	Dynamic reconfiguration can cause the recevied route to ACTIVE.
	See, if you don't keep all the routes advertied by peers, in RIB-In,
	you will MISS THE ROUTE. Because  your peer won't know about all
	the dynamic reconfiguration and obviously he won't advertise once
again.
	So you will loss.
		
        If I am wrong correct me
Thnaks
Pillai

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: Clarification needed 9.1.2.1 and 9.2.1.1
Date: Mon, 24 Aug 1998 21:25:21 PDT
Sender: [email-masked]

Folks,
     I understand among all different paths available to a prefix
     one route is chosen as the best route according to the route
     selection criteria of 9.1.2.1
     Why is there another route selection criteria in 9.2.1.1
     I understand this says it is for internal updates.
     But the section 9.2.1 (Internal updates) also says this procedure
     advertises to internal peers if the route has been installed 
according to 9.1.2.
      I am confused as to why there are two route selection criteria
      specified? Or are they the same given in different context.
Thanks for your response,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Mon, 24 Aug 1998 08:40:15 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: UPDATE Message Handling
Sender: [email-masked]

|            If the UPDATE message contains a feasible route, it shall be placed
|            in the appropriate Adj-RIB-In, and the following additional actions
|            shall be taken:
|  
|            i) ...
|  
|            ii) ...
|  
|            iii) If ...,  no further actions are necessary.
|  
|            iv) If ..., then the new route shall be placed in the Adj-RIB-In. 
|  
|            v) If the new route is an overlapping route that is less specific
|            (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
|            BGP speaker shall run its Decision Process on the set of
|  destinations
|            described only by the less specific route.
|  
|  What is confusing me is that the first paragraph clearly states that the
|  route shall be placed in the Adj-RIB-In but the additional actions seem to
|  indicate that this is not always the case. Is it true that in cases (i) and
|  (ii) the new route replaces an older route, in case (iii) and (iv) the new
|  route is NOT placed in the Adj-RIB-In and in case (iv) it is placed in the
|  Adj-RIB-In?

The distinction between putting an unuseable prefix in Adj-RIB-In and not
putting it into Adj-RIB-In at all is pretty much an implementation
decision.

I know one implementation that always ejected discarded routes.  I know
another that never did so.  The question is, how will the implementation
deal with policy changes.

Tony

Date: Mon, 24 Aug 1998 08:35:37 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: UPDATE Message Handling
Sender: [email-masked]

|  In reading RFC1771 I find various instances where a minor modification to
|  the text would provide me with a much clearer understanding of the intent.
|  Is there a mechanism whereby I could suggest such changes?

First, you should be looking at the current draft, not 1771.  ;-)

If it is an editorial change, sending a change to the editors would be
appropriate.  

If it's actually a content change, sending it to this mailing list would be
appropriate.

Tony

Date: Mon, 24 Aug 1998 08:47:50 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: UPDATE Message Handling
Sender: [email-masked]

RFC 1771 (and draft-ietf-idr-bgp4-08.txt) state in section 9...

          If the UPDATE message contains a feasible route, it shall be placed
          in the appropriate Adj-RIB-In, and the following additional actions
          shall be taken:

          i) ...

          ii) ...

          iii) If ...,  no further actions are necessary.

          iv) If ..., then the new route shall be placed in the Adj-RIB-In. 

          v) If the new route is an overlapping route that is less specific
          (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
          BGP speaker shall run its Decision Process on the set of
destinations
          described only by the less specific route.

What is confusing me is that the first paragraph clearly states that the
route shall be placed in the Adj-RIB-In but the additional actions seem to
indicate that this is not always the case. Is it true that in cases (i) and
(ii) the new route replaces an older route, in case (iii) and (iv) the new
route is NOT placed in the Adj-RIB-In and in case (iv) it is placed in the
Adj-RIB-In?

In reading RFC1771 I find various instances where a minor modification to
the text would provide me with a much clearer understanding of the intent.
Is there a mechanism whereby I could suggest such changes?

Thanks - Eric...

===========================
Eric Horowitz
[email-masked]
===========================

From: "jaihari loganathan" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Appropriate Adj_RIB_In
Date: Sun, 23 Aug 1998 21:45:24 PDT
Sender: [email-masked]

>
>RFC1771 - Section 9. - P34 - 5th para...
>
>     "If the UPDATE message contains a feasible route, it shall be 
placed
>in the appropriate Adj-RIB-In, ..."
>
>Is there more than one Adj-RIB-In per speaker? Is there one per peer? 
If

    There is one Adj-RIB-In and one Adj-RIB-Out per peer. 

   ( Note that the separate view of Adj-RIB-In/Out Loc-Rib is ONLY AN
     ABSTRACTION. And it would be inefficient to maintain three copies
     of a route - i think the RFC clearly says it does NOT require
     an implementation to maintain three separate copies of a route).

>so, then I guess the appropriate one would be that which corresponds to 
the
>peer from which it was received. If not, then what does "appropriate" 
mean?
  
    I interpreted appropriate as "corresponding"
>
>Likewise, section 3.2 seems to indicate that there are multiple 
Adj-RIBs-IN
>and Adj-RIBs-Out but only one Loc-RIB. I guess that each Adj-RIB-Out
>corresponds to a given peer as well - right?
>
   Yes.

-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Sun, 23 Aug 1998 12:24:53 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: Appropriate Adj_RIB_In
Sender: [email-masked]

RFC1771 - Section 9. - P34 - 5th para...

     "If the UPDATE message contains a feasible route, it shall be placed
in the appropriate Adj-RIB-In, ..."

Is there more than one Adj-RIB-In per speaker? Is there one per peer? If
so, then I guess the appropriate one would be that which corresponds to the
peer from which it was received. If not, then what does "appropriate" mean?

Likewise, section 3.2 seems to indicate that there are multiple Adj-RIBs-IN
and Adj-RIBs-Out but only one Loc-RIB. I guess that each Adj-RIB-Out
corresponds to a given peer as well - right?

I think I am a good test case to see how intelligable RFC 1771 is to some
one who has not a clue as to what is going on! }:>)

Thanks again - Eric....

===========================
Eric Horowitz
[email-masked]
===========================

To: [email-masked] (jaihari loganathan)
cc: [email-masked]
Subject: Re: MinRouteAdvertisementInterval
From: Tony Li <[email-masked]>
Date: 22 Aug 1998 20:24:08 -0700
Lines: 26
Sender: [email-masked]

[email-masked] (jaihari loganathan) writes:

>      Is a single timer (per peer) scan of the routes, combined with
>      route dampening form a suffcient condition for 
>      MinRouteAdvertisementInterval specified in the RFC 1771.
>      (A single timer per peer can ensure the minimum time lapse between 
>      any route advertisement to the peer)

More to the point, that would seem to be an acceptable implementation.
I'll point out that it's perhaps not an optimal implementation,
however....  I cannot throw stones in that regard.  ;-)

>      One additional question, what is the state information about a
> route advertised to a peer (other than the fact that it has been 
> advertised) need to be preserved according to the RFC? (instead of
> a Adjout-RIB)

That depends on your particular implementation and how fast and footloose
you wish to be with UPDATE messages.  One particular implementation used to
send a new update to all neighbors anytime anything changed about the
route.  This, of course, was correct, however, was again suboptimal.

Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC1772 (suggestion)
Date: Sat, 22 Aug 1998 01:32:48 PDT
Sender: [email-masked]

Folks,
   Going through the past mail archives discussing the route selection
   procedure, it seems to be a good idea to provide diagrammatic
   illustration (taking input from all those discussions in the archive 
) of looping scenarios that could arise due to
    1) wrong route calculations
    2) misconfiguration 
    3) IGP/BGP wrong interaction due to 2
   in RFC 1772 as an addendum.

    This would serve as a guideline to
     1) new implementors (me ;-) )
     2) ISP administrators
Any thoughts on this?
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: MinRouteAdvertisementInterval
Date: Sat, 22 Aug 1998 00:15:50 PDT
Sender: [email-masked]

Folks,
     Is a single timer (per peer) scan of the routes, combined with
     route dampening form a suffcient condition for 
MinRouteAdvertisementInterval specified in the RFC 1771.
     (A single timer per peer can ensure the minimum time lapse between 
any route advertisement to the peer)
     One additional question, what is the state information about a
route advertised to a peer (other than the fact that it has been 
advertised) need to be preserved according to the RFC? (instead of
a Adjout-RIB)

Thanks,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Fri, 21 Aug 1998 08:58:12 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: feasible
Sender: [email-masked]

The term feasible appears frequently in RFC1771 in relation to PATHS. I can
not find a definition. Is the following correct?

A path is feasible if the BGP speaker considering it can get to the NEXT
HOP of the path, i.e., if the BGP speaker has a route in its local routing
table to the NEXT HOP of the path. 

The RFC indicates that when this speaker sends this path to an external
peer, it replaces the NEXT HOP with the next hop to the NEXT HOP that it
finds in its local routing table. Is this correct? 

It seems possible that one speaker may advertise a feasible route which its
peer may find unfeasible (RFC1771) or infeasible (RFC1772).
Is this correct?

Thanks - Eric Horowitz....

===========================
Eric Horowitz
[email-masked]
===========================

Date: Fri, 21 Aug 1998 09:07:16 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: Susan Hares <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RFC1771 page 2 (hop-by-hop paradigm) clarification please
Sender: [email-masked]

As the RFC says " a BGP speaker must advertise to its peers in neighboring
ASs only those routes that it itself uses", in this scenario if the router
is not using the routes learnt from BGP, it MUST NOT advertise the routes to
other BGP peers. Note that BGP is a policy oriented protocol. Any router A
accepts the routes advertised by B based on many policies ( particularly AS
path ) assuming that the route will be followed as advertised by B. If B
does not use the route that it advertises, A will be misled and the packtes
coming from A via B will not follow the routes as A thinks. This may not
only cause unwanted routing, it may also cause looping.

Thanks,
Rajesh

Susan Hares wrote:

> ------- Forwarded Message
>
> From: "jaihari loganathan" <[email-masked]>
> To: [email-masked]
> Subject: RFC1771 page 2 (hop-by-hop paradigm) clarification please
> Content-Type: text/plain
> Date: Thu, 20 Aug 1998 16:11:48 PDT
>
> Can someone clarify the statement "a BGP speaker (must) advertise to its
> peers in neighboring ASs only those routes that it itself uses". under
> the following scenario :
>
> BGP learns from an EBGP peer that a prefix 'p' is reachable through a
> next hop 'N' via certain path attributes (as list etc)
> the BGP route for the prefix 'p' is installed in the table with nexthop
> 'N' .
>
> A user configures a static route to the prefix 'p' with next hop N1 and
> static route is not redistributed into BGP.
> Suppose static route is given more weightage than BGP external route and
> STATIC route for prefix 'p' is being
> used and packets are routed to nextHOP 'N1',
>    can BGP still advertise prefix 'p' to other peers with next hop
> attribute 'N'.
>
> (i think cisco has some backdoor config mechanism similar to this)
>
> Thank you for your response,
> - -Jaihari.
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
> ------- End of Forwarded Message

--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

To: [email-masked]
cc: [email-masked]
Subject: RFC1771 page 2 (hop-by-hop paradigm) clarification please
Date: Thu, 20 Aug 1998 22:17:19 -0400
From: Susan Hares <[email-masked]>
Sender: [email-masked]

------- Forwarded Message

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC1771 page 2 (hop-by-hop paradigm) clarification please
Content-Type: text/plain
Date: Thu, 20 Aug 1998 16:11:48 PDT

Can someone clarify the statement "a BGP speaker (must) advertise to its 
peers in neighboring ASs only those routes that it itself uses". under 
the following scenario :

BGP learns from an EBGP peer that a prefix 'p' is reachable through a 
next hop 'N' via certain path attributes (as list etc)
the BGP route for the prefix 'p' is installed in the table with nexthop 
'N' .

A user configures a static route to the prefix 'p' with next hop N1 and 
static route is not redistributed into BGP.
Suppose static route is given more weightage than BGP external route and 
STATIC route for prefix 'p' is being
used and packets are routed to nextHOP 'N1',
   can BGP still advertise prefix 'p' to other peers with next hop 
attribute 'N'.

(i think cisco has some backdoor config mechanism similar to this)

Thank you for your response,
- -Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------- End of Forwarded Message

Date: Thu, 20 Aug 1998 18:21:19 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: Eric Horowitz <[email-masked]>
CC: [email-masked]
Subject: Re: phases
Sender: [email-masked]

Eric,
If I am interpreting correctly, you ( the router ) want to send the routes
originated by your autonomous system to the other autonomous systems through
BGP. Where do you keep these routes in BGP is implementation dependent. You can
directly put these routes in the Local RIB of BGP and then send out or you can
internally assume yourself also as a peer and  consider the selforiginated
routes as coming from this peer ( self ) , put the routes in the RIBIN of this
peer and then use the normal BGP processing.
I hope this helps.

Thanks,
Rajesh

Eric Horowitz wrote:

> I am constructing an OPNET model of BGP. OPNET is a communications modeling
> tool.
> I need to code practically the entire BGP spec in this modeling tool. I
> have several questions related to interpreting RFC1771. I hope the
> community can e of help. Several individuals have already been of service
> (thanks).
>
> My implementation has BGP running on routers, each of which has an IP
> routing table. To start, I am importing the IP routig table into BGP. I am
> a bit confused as to how I should do this,  which "phases" of section 9 are
> applicable and which RIBs should be populated with what.
>
> At this point all of the RIBs are empty. At a high level, what would be the
> course of events to use the local routing table to populate the RIBs and
> produce UPDATE messages?
>
> Thanks - Eric....
>
> ===========================
> Eric Horowitz
> [email-masked]
> ===========================

--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

Date: Thu, 20 Aug 1998 13:16:41 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: phases
Sender: [email-masked]

I am constructing an OPNET model of BGP. OPNET is a communications modeling
tool. 
I need to code practically the entire BGP spec in this modeling tool. I
have several questions related to interpreting RFC1771. I hope the
community can e of help. Several individuals have already been of service
(thanks).

My implementation has BGP running on routers, each of which has an IP
routing table. To start, I am importing the IP routig table into BGP. I am
a bit confused as to how I should do this,  which "phases" of section 9 are
applicable and which RIBs should be populated with what.

At this point all of the RIBs are empty. At a high level, what would be the
course of events to use the local routing table to populate the RIBs and
produce UPDATE messages?

Thanks - Eric....

===========================
Eric Horowitz
[email-masked]
===========================

Date: Thu, 20 Aug 1998 10:40:08 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: Test
Sender: [email-masked]

I am trying to get onto this news group. This is just a test

===========================
Eric Horowitz
[email-masked]
===========================

To: [email-masked]
cc: [email-masked]
Subject: Internet drafts
Date: Thu, 13 Aug 1998 12:29:47 -0400
From: Susan Hares <[email-masked]>
Sender: [email-masked]

------- Forwarded Message

>From idr-owner  Wed Aug 12 14:36:41 1998
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-cap-neg-02.txt
Date: Wed, 12 Aug 1998 14:36:01 -0400
Sender: [email-masked]

- --NextPart

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

	Title		: Capabilities Negotiation with BGP-4
	Author(s)	: J. Scudder, R. Chandra
	Filename	: draft-ietf-idr-bgp4-cap-neg-02.txt
	Pages		: 4
	Date		: 11-Aug-98
	
   Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an
   OPEN message with one or more unrecognized Optional Parameters, the
   speaker must terminate BGP peering. This complicates introduction of
   new capabilities in BGP.
 
   This document defines new Optional Parameter, called Capabilities,
   that is expected to facilitate introduction of new capabilities in
   BGP by providing graceful capability negotiation without requiring
   that BGP peering be terminated.

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-cap-neg-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-cap-neg-02.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-02.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-aggregation-framework-03.txt
Date: Mon, 10 Aug 1998 12:49:22 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
This new version includes the following revisions/clarifications
(excl. line/page number changes):

*** draft-ietf-idr-aggregation-framework-02.txt	Fri Jul 24 18:26:42 1998
--- draft-ietf-idr-aggregation-framework-03.txt	Mon Aug  3 19:12:05 1998
***************
  
  1. Introduction
***************
*** 95,101 ****
  Because of the current size of the routing system and its dynamic
  nature, the first step towards this goal is to establish a clearly-
  defined framework in which scaleable inter-domain route aggregation can
! be realized.  The framework described in this document emphasizes the
  philosophy of aggregation by the source, both within routing domains as
  well as towards upstream providers.  The framework also strongly encour-
  ages the use of the "no-export" BGP community to balance the provider-
--- 95,102 ----
  Because of the current size of the routing system and its dynamic
  nature, the first step towards this goal is to establish a clearly-
  defined framework in which scaleable inter-domain route aggregation can
! be realized.  The framework described in this document is based on the
! predominant and current experience in the Internet. It emphasizes the
  philosophy of aggregation by the source, both within routing domains as
  well as towards upstream providers.  The framework also strongly encour-
  ages the use of the "no-export" BGP community to balance the provider-
***************
*** 103,112 ****
  net's need for scalable inter-domain routing.  The advantages of this
  framework include the following:
  
! -    Route aggregation is done in a distributed fashion.  The Internet
!      is too large and too distributed for aggregation to be performed
!      successfully by anyone other than the party injecting the aggregat-
!      able routing information into the global mesh.

--- 104,112 ----
  net's need for scalable inter-domain routing.  The advantages of this
  framework include the following:
  
! -    Route aggregation is done in a distributed fashion, with emphasis
!      on aggregation by the party or parties injecting the aggregatable
!      routing information into the global mesh.

***************
*** 151,164 ****
       routes statically configured and injected into BGP fall into this
       category.)
  
!      In general no "proxy aggregation" (i.e., aggregation of a route by
!      an AS other than the originating AS) shall be performed.  This pre-
!      serves the capability of a multi-homed site to control the granu-
!      larity of routing information injected into the global routing sys-
!      tem.  Proxy aggregation may be appropriate on a small scale where
!      the necessary coordination is tractable.  However, on a large
!      scale, experience has shown that proxy aggregation is problematic
!      because the coordination is intractable.
  
       An AS shall always originate via a stable mechanism (e.g., static
       route configuration) the BGP routes for the large aggregates from
--- 151,164 ----
       routes statically configured and injected into BGP fall into this
       category.)
  
!      This framework does not depend on "proxy aggregation" which refers
!      to route aggregation done by an AS other than the originating AS.
!      This preserves the capability of a multi-homed site to control the
!      granularity of routing information injected into the global routing
!      system. Since proxy aggregation involves coordination among multiple
!      organizations, the complexity of doing proxy aggregation increases
!      with the number of parties involved in the coordination. The 
!      complexity, in turn, impacts the practicality of proxy aggregation.
  
       An AS shall always originate via a stable mechanism (e.g., static
       route configuration) the BGP routes for the large aggregates from
***************
***************
*** 326,346 ****
       in order to balance traffic over the multiple links to the upstream
       provider.
  
! One approach to suppress such routes is to aggregate them even though
! they are originated by other ASs (termed "proxy aggregation").  However,
! due to the legitimate need for injecting more-specifics for multi-hom-
! ing, proxy aggregation needs to be done with special coordination and
! care.  The coordination work involved is non-trivial in a large environ-
! ment, and as a result, little aggregation savings have been achieved
! with proxy aggregation to date.
! 
! Instead of "proxy aggregation," our approach for dealing with these
! cases is to give control to the ASs that originate the more-specifics
! (as seen by its upstream providers) and let them tag the BGP community
! "no-export" to the appropriate routes.
  
  The BGP community "no-export" is a well known BGP community [6, 7].  A
  route with this attribute is not propagated beyond an AS boundary. So,

--- 326,346 ----
       in order to balance traffic over the multiple links to the upstream
       provider.
  
! Our approach to suppress such routes is to give control to the ASs that
! originate the more-specifics (as seen by its upstream providers) and let
! them tag the BGP community "no-export" to the appropriate routes.
  
***************
*** 560,568 ****
  
  [9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
  
! [10] Stewart, J., and Chen, E., "Using BGP Without Consuming a Unique
! ASN", Internet-Draft, January 1997 (expires July 1997), <draft-stewart-
! bgp-multiprotocol-00.txt>.
  
  [11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour
  Today", Internet-Draft, October 1996 (expires April 1997), <draft-iab-
--- 533,541 ----
  
  [9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
  
! [10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a
! Dedicated AS for Sites Homed to a Single Provider", RFC2270, January,
! 1998.
  
  [11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour
  Today", Internet-Draft, October 1996 (expires April 1997), <draft-iab-
***************

Please let us know if you have any commands or suggestions. Thanks.

 -- Enke and John

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-aggregation-framework-03.txt
Date: Mon, 10 Aug 1998 11:22:32 -0400
Sender: [email-masked]
Content-Length: 2942

--NextPart

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

	Title		: A Framework for Inter-Domain Route Aggregation
	Author(s)	: J. Stewart, E. Chen
	Filename	: draft-ietf-idr-aggregation-framework-03.txt
	Pages		: 12
	Date		: 07-Aug-98
	
   This document presents a framework for inter-domain route aggregation
   and shows an example router configuration which 'implement' this
   framework.  This framework is flexible and scales well as it
   emphasizes the philosophy of aggregation by the source, both within
   routing domains as well as towards upstream providers, and it also
   strongly encourages the use of the 'no-export' BGP community to
   balance the provider-subscriber need for more granular routing
   information with the Internet's need for scalable inter-domain
   routing.

To: [email-masked]
cc: [email-masked]
Subject: DRaft submission
Date: Fri, 07 Aug 1998 16:50:58 -0400
From: Susan Hares <[email-masked]>
Sender: [email-masked]

Please note that to cut the "Internet Ads", the idr mail list
requires you to be a submitter.  If this turns out to be a problem,
I'll change it.  I'm forwarding this draft announcements.

Sue

----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-08.txt
Date: Fri, 07 Aug 1998 09:30:58 -0400
Sender: [email-masked]

- --NextPart

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

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: T. Li, Y. Rekhter
	Filename	: draft-ietf-idr-bgp4-08.txt
	Pages		: 62
	Date		: 06-Aug-98
	
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-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	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-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-08.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

From: [email-masked]
Date: Thu, 6 Aug 1998 15:30:49 -0400 (EDT)
To: [email-masked]
Subject: BGP MIB revision
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

IDR fans:

The next message is a new Internet-Draft (draft-ietf-idr-bgp4-mib-03.txt)
correcting earlier problems iwth bgp4-mib (draft-ietf-idr-bgp4-mib-02.txt).

Here's the changes:

 I have:
 
 1) changed draft-ietf-idr-bgp4-mib-02.txt to draft-ietf-bgp4-mib-03.txt

 2) changed the editors and kept the authors (John Chu and Jeff Johnson
    were removed.)

 3) Added the copyright statement

 4) Add the MIB section boilerplate
 
 5)  Followed Bert Wijen's  suggestion to in order to be able to comply
     with current MIB standards and stools
 
        rename bgpRcvdPathAttrTable to bgpPathAttrTable
 
 6) Added the SNMP references per boiler plate  
 
 7) Added the security section 8.
 
 8) Updated the authors section

The MIB changes and the boiler plate are editorial changes.
The only real change is the security section.

The security section represents my understanding of the 
danger of the 4 read/write parameters in the MIB:

 bgpPeerHoldTimeConfigured,
 bgpPeerKeepAliveConfigured,
 bgpPeerMinASOriginationInterval,
 bgpPeerMinRouteAdvertisementInterval

Are ISPs, NSPs or implementors concerned this read/write portions of the
BGP MIB?   Would you be concern if SNMP had better security?

In addition, I included this text:

   There are a number of managed objects in this MIB that  may  be  con-
   sidered  to  contain sensitive information in the operation of a net-
   work.  For example, a BGP peer's local and remote  addresses  may  be
   sensitive  for  ISPs  who want to keep interface addresses on routers
   confidential to prevent router addresses used for a denial of service
   attack or spoofing.

But I'm only the editor repeating what I think ISPs/NSPs want.
So.. please let me know if I am wrong.   If you don't care, silence
is always a blessing.

Sue Hares 

From: "Luis A. Sanchez" <[email-masked]>
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
To: [email-masked]
Date: Tue, 4 Aug 1998 21:59:59 +0000 (GMT)
Cc: [email-masked]
Sender: [email-masked]

> references that explain HMAC with MD5 and HMAC with SHA-1.

try rfc2104 first. It is a concise reference for HMAC (10 pages including
sample code). It explains how HMAC operates and how it could be used
in conjunction with crypto hash functions such as MD5 and SHA-1.

Luis

From: [email-masked]
Date: Tue, 4 Aug 1998 02:36:35 -0400 (EDT)
Subject: Amazing World Record Sex!!!
Sender: [email-masked]

Attention!
Warning! Adults Only!                    Warning! Adults                                          Only!

If you are under 21 years of age, or not interested in sexually explicit material...
please hit your keyboard delete button now
and please excuse the intrusion. To REMOVE your name from our
email list send us email with REMOVE in the subject line.
You need not read any further!

Available NOW for only $9.95!  Next 10 Days Only!

WORLD RECORD SEX!

Be There!  See It Now On Video!  Unbelievable ...But True!

You Won't Believe Your Eyes!!!  [As Seen on the Howard Stern Show]

"The World's Biggest Gang Bang"

See sexy  Annabel Chong as she sets the world Gang Bang Record
in this fantastic video documentary that chronicles her 24 hour
sexathon with 251 men engaging in sexual intercourse and oral
sex with her!  Don't worry, you won't have to stay up 24 hours
to watch it all.  We've selected only the most exciting and red
hot scenes for you...all in breathtaking living color with plenty of
extreme close-ups!  This video is guaranteed to knock your socks
off and leave you breathless!  You've never seen anything like it!
Annabel takes on five men at a time!  90 minutes! Order Today!
Only $9.95 plus $3 shipping and handling [Total $12.95].

"GANG BANG II"
The Record Breaker!!!  Starring Jasmin St. Claire!

See Beautiful and Voluptious Jasmin St. Claire shatter Annabel's
gang bang record by taking on 300 men in one 24 hour sex session!
You won't believe your eyes at all the hot firey action that you will
see as the new world record is established before your eyes as
Jasmin  takes on five men at a time for sexual intercourse and
oral sex!  Your friends will break down your door to see this video!
You'll be the most popular guy in town!  The action is truly unreal 
and you will see the best of it in living life-like color!  Order Today
and see Jasmin break the record!  90 minutes.  Only $9.95 plus
$3 shipping and handling [total $12.95].

Also Available...

The Uncensored Authentic Underground...
Pamela Anderson Lee & Tommy Lee
Sex Video Tape!

Everyone is talking about this exciting video!  See Pam and 
Tommy engaging in sexual intercourse and oral sex in the car,
on the boat and much, much more!  A  real collectors video! 30 minutes.
Only $9.95 plus $3 shipping and Handling [total $12.95]

"Tonya Harding Wedding Night Sex Video"
Now see the beautiful Ice Skating Shame of the Olympics
Tonya Harding engaging in sexual intercourse and oral 
sex on her wedding night with husband Jeff Gillooly!
This "Bad Girl" is Hot!  Don't miss this video! 30 minutes.
Only $9.95 plus $3 shipping and handling [total $12.95]

"Traci...I Love You"  Starring Traci Lords
Now see the most beautiful and popular porn star in her last
adult video before she hit the big time!  It's the blockbuster of
the year...sensual...fiery and exposive!  Traci Lords in her most
erotic and controversial film ever!  Don't Miss It!  90 minutes.
Only $9.95 plus $3 shipping and handling [total $12.95]

EMAIL SPECIAL!

ORDER ANY FOUR VIDEOS AND GET THE FIFTH ONE FREE!!!

Your order will be shipped via First Class Mail. All Shipments in plain unmarked wrapper.
For Priority Mail - Add $5
For Overnight Express - add $15

You can order by Phone, Fax, Mail or Email.

We accept all Major Credit Cards and checks by phone or fax.
Visa - MasterCard - American Express - Discover

10 Day Money Back Guarantee!  We know that you will be pleased with these Videos!

To Email your order - DO NOT HIT REPLY ON YOUR KEYBOARD

Send email to our special email address below:

[email-masked]

[Note: If you order by email and do not receive an email acknowledgement within 24 hours, please phone our office at
718-287-3800]

Phone our office 9am to 10 pm [eastern time]

[718] 287-3800 to Order By Phone for FASTEST SERVICE!

 We can accept your credit card or check by phone

Fax Your Order 24 hours per day  to  [718] 462-5920
You can fax your credit card information or your check

Order by mail by sending $12.95 per video,  cash, check, money order or major credit card [Visa, MasterCard, American Express or Discover] to

TCPS, INC.
4718  18th Ave.  Suite 135
Brooklyn, NY 11204

Make Checks & Money Orders Payable to TCPS, Inc.
New York State Residents Please Add 85 cents for Sales Tax per Video!

You must be over 21 years of age to order and give us your date of birth with your order!

The Following Order Form is for Your Convenience!

.............................................................................................................

Please ship me the following video tape[s]!

Qty___________Annabel Chong "World's Biggest Gang Bang"

Qty__________"Gang Bang II" Jasmin St. Claire

Qty___________"Pamela & Tommy Lee Sex Video Tape"

Qty_________   "Tonya Harding Wedding Night Sex Video Tape"

Qty__________"Traci I Love You" Traci Lords

at $9.95 each plus $3.00 for shipping and handling per tape
[$12.95 per video or "SPECIAL $51.80 for ALL FIVE"!

Credit Card #______________________________Exp Date___

I hereby represent that I am over 21 years of age.  
My date of birth is_________________________________

Signature______________________________________________

Ship to:  Name_______________________________________

Address____________________________________________

City________________________State___________Zip________

Area Code and Home Phone  [    ]___________________________

Fax # [     ]______________________________________________

Email Address___________________________________________

To remove your name from our mailing list, send us an email with 
remove in the subject line.  This is a one time offer and you should not hear from us again!

FOREIGN ORDERS -Add $15us if you desire Air Parcel Post Shipment.  We ship all over the world.

By deleting your unwanted E-Mail you waste one keystroke, yet
by throwing away paper mail you waste our planet!  SAVE THE
TREES and support internet E-Mail instead of paper mail!

[C] Copyright TCPS 1998