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

["Luis A. Sanchez" <[e-mail]>]

> ps- for us near crypto illiterates could you point to some consise
> 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




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA25436 for <[e-mail]>; Mon, 31 Aug 1998 20:18:00 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA24541 for idr-outgoing; Mon, 31 Aug 1998 20:13:42 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA24533 for <[e-mail]>; Mon, 31 Aug 1998 20:13:36 -0400 (EDT)
Received: from hotmail.com (f190.hotmail.com [207.82.251.79]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id UAA06051 for <[e-mail]>; Mon, 31 Aug 1998 20:13:35 -0400 (EDT)
Received: (qmail 7321 invoked by uid 65534); 1 Sep 1998 00:13:04 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Mon, 31 Aug 1998 17:13:04 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: One more question 9) UPDATE MESSAGE HANDLING ii)
Content-Type: text/plain
Date: Mon, 31 Aug 1998 17:13:04 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id RAA23892 for <[e-mail]>; Mon, 31 Aug 1998 17:20:26 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA22175 for idr-outgoing; Mon, 31 Aug 1998 17:17:10 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA22160 for <[e-mail]>; Mon, 31 Aug 1998 17:16:46 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id OAA04056; Mon, 31 Aug 1998 14:16:15 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id OAA14632; Mon, 31 Aug 1998 14:15:50 -0700 (PDT)
To: [e-mail] (Eric Horowitz)
cc: [e-mail]
Subject: Re: Fwd: Re: NEXT_HOP Question...
References: <[e-mail]>
From: Tony Li <[e-mail]>
Date: 31 Aug 1998 14:15:49 -0700
In-Reply-To: [e-mail]'s message of 31 Aug 98 13:14:16 GMT
Message-ID: <[e-mail]>
Lines: 29
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: [e-mail]
Precedence: bulk

[e-mail] (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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA22127 for <[e-mail]>; Mon, 31 Aug 1998 14:28:02 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA18718 for idr-outgoing; Mon, 31 Aug 1998 14:26:49 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA18711 for <[e-mail]>; Mon, 31 Aug 1998 14:26:43 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id LAA19999; Mon, 31 Aug 1998 11:26:11 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id LAA14077; Mon, 31 Aug 1998 11:25:47 -0700 (PDT)
Date: Mon, 31 Aug 1998 11:25:47 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Eric Horowitz on Mon, 31 Aug 1998 09:03:20 -0400)
Subject: Re: Fwd: Re: Internal Update Process...
Sender: [e-mail]
Precedence: bulk

|  >|  " 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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA22089 for <[e-mail]>; Mon, 31 Aug 1998 14:26:37 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA18681 for idr-outgoing; Mon, 31 Aug 1998 14:24:32 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA18677 for <[e-mail]>; Mon, 31 Aug 1998 14:24:26 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id LAA19755; Mon, 31 Aug 1998 11:23:54 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id LAA14067; Mon, 31 Aug 1998 11:23:29 -0700 (PDT)
Date: Mon, 31 Aug 1998 11:23:29 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

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.  ;-)


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA19070 for <[e-mail]>; Mon, 31 Aug 1998 09:22:11 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA12742 for idr-outgoing; Mon, 31 Aug 1998 09:16:30 -0400 (EDT)
Received: from camel7.mindspring.com (camel7.mindspring.com [207.69.200.57]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA12737 for <[e-mail]>; Mon, 31 Aug 1998 09:16:24 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lcjrs.dialup.mindspring.com [209.86.79.124]) by camel7.mindspring.com (8.8.5/8.8.5) with SMTP id JAA32233 for <[e-mail]>; Mon, 31 Aug 1998 09:16:23 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 31 Aug 1998 09:14:16 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: Fwd: Re: NEXT_HOP Question...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>|  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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA18941 for <[e-mail]>; Mon, 31 Aug 1998 09:13:18 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA12569 for idr-outgoing; Mon, 31 Aug 1998 09:05:30 -0400 (EDT)
Received: from camel7.mindspring.com (camel7.mindspring.com [207.69.200.57]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA12565 for <[e-mail]>; Mon, 31 Aug 1998 09:05:24 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lcjrs.dialup.mindspring.com [209.86.79.124]) by camel7.mindspring.com (8.8.5/8.8.5) with SMTP id JAA04616 for <[e-mail]>; Mon, 31 Aug 1998 09:05:22 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 31 Aug 1998 09:03:20 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: Fwd: Re: Internal Update Process...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA14431 for <[e-mail]>; Mon, 31 Aug 1998 00:50:02 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA09118 for idr-outgoing; Mon, 31 Aug 1998 00:48:10 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA09114 for <[e-mail]>; Mon, 31 Aug 1998 00:48:05 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA14225; Sun, 30 Aug 1998 21:47:34 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id VAA12748; Sun, 30 Aug 1998 21:47:10 -0700 (PDT)
Date: Sun, 30 Aug 1998 21:47:10 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Eric Horowitz on Wed, 26 Aug 1998 08:14:49 -0400)
Subject: Re: Internal Update Process...
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA14279 for <[e-mail]>; Mon, 31 Aug 1998 00:40:06 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA09065 for idr-outgoing; Mon, 31 Aug 1998 00:38:26 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA09061 for <[e-mail]>; Mon, 31 Aug 1998 00:38:20 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA13950; Sun, 30 Aug 1998 21:37:50 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id VAA12731; Sun, 30 Aug 1998 21:37:26 -0700 (PDT)
Date: Sun, 30 Aug 1998 21:37:26 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Eric Horowitz on Wed, 26 Aug 1998 08:29:05 -0400)
Subject: Re: withdrawn routes
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA14236 for <[e-mail]>; Mon, 31 Aug 1998 00:37:59 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA09056 for idr-outgoing; Mon, 31 Aug 1998 00:35:39 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA09052 for <[e-mail]>; Mon, 31 Aug 1998 00:35:33 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA13864; Sun, 30 Aug 1998 21:35:02 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id VAA12715; Sun, 30 Aug 1998 21:34:39 -0700 (PDT)
Date: Sun, 30 Aug 1998 21:34:39 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Eric Horowitz on Wed, 26 Aug 1998 09:04:44 -0400)
Subject: Re: NEXT_HOP Question...
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA14186 for <[e-mail]>; Mon, 31 Aug 1998 00:35:26 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA09032 for idr-outgoing; Mon, 31 Aug 1998 00:31:01 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA09028 for <[e-mail]>; Mon, 31 Aug 1998 00:30:56 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA13703; Sun, 30 Aug 1998 21:30:25 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id VAA12705; Sun, 30 Aug 1998 21:30:01 -0700 (PDT)
Date: Sun, 30 Aug 1998 21:30:01 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Eric Horowitz on Thu, 27 Aug 1998 08:55:14 -0400)
Subject: Re: NEXT_HOP
Sender: [e-mail]
Precedence: bulk

|  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



Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id QAA26558 for <[e-mail]>; Sat, 29 Aug 1998 16:44:07 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA27734 for idr-outgoing; Sat, 29 Aug 1998 16:35:09 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA27727 for <[e-mail]>; Sat, 29 Aug 1998 16:35:02 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id QAA16648 for <[e-mail]>; Sat, 29 Aug 1998 16:35:01 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id NAA10077; Sat, 29 Aug 1998 13:34:30 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id NAA08535; Sat, 29 Aug 1998 13:34:09 -0700 (PDT)
Date: Sat, 29 Aug 1998 13:34:09 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Erik Sherk on Sat, 29 Aug 1998 14:13:31 -0400)
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id FAA21254 for <[e-mail]>; Sat, 29 Aug 1998 05:08:15 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA24039 for idr-outgoing; Sat, 29 Aug 1998 05:02:35 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA24035 for <[e-mail]>; Sat, 29 Aug 1998 05:02:30 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id FAA24105 for <[e-mail]>; Sat, 29 Aug 1998 05:02:29 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id CAA13463; Sat, 29 Aug 1998 02:01:59 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id CAA06316; Sat, 29 Aug 1998 02:01:38 -0700 (PDT)
Date: Sat, 29 Aug 1998 02:01:38 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id FAA21185 for <[e-mail]>; Sat, 29 Aug 1998 05:05:15 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA24020 for idr-outgoing; Sat, 29 Aug 1998 04:59:36 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA24016 for <[e-mail]>; Sat, 29 Aug 1998 04:59:30 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id EAA23900 for <[e-mail]>; Sat, 29 Aug 1998 04:59:29 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id BAA13128; Sat, 29 Aug 1998 01:58:58 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id BAA06228; Sat, 29 Aug 1998 01:58:38 -0700 (PDT)
Date: Sat, 29 Aug 1998 01:58:38 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id FAA21173 for <[e-mail]>; Sat, 29 Aug 1998 05:04:24 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA24012 for idr-outgoing; Sat, 29 Aug 1998 04:58:47 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA24008 for <[e-mail]>; Sat, 29 Aug 1998 04:58:42 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id EAA23881 for <[e-mail]>; Sat, 29 Aug 1998 04:58:41 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id BAA13114; Sat, 29 Aug 1998 01:58:10 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id BAA06225; Sat, 29 Aug 1998 01:57:49 -0700 (PDT)
Date: Sat, 29 Aug 1998 01:57:49 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id FAA21140 for <[e-mail]>; Sat, 29 Aug 1998 05:02:51 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA23999 for idr-outgoing; Sat, 29 Aug 1998 04:57:05 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA23995 for <[e-mail]>; Sat, 29 Aug 1998 04:56:59 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id EAA23864 for <[e-mail]>; Sat, 29 Aug 1998 04:56:58 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id BAA13066; Sat, 29 Aug 1998 01:56:26 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id BAA06216; Sat, 29 Aug 1998 01:56:05 -0700 (PDT)
Date: Sat, 29 Aug 1998 01:56:05 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Rajesh Saluja on Fri, 28 Aug 1998 11:55:39 -0400)
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|  > 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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id EAA20975 for <[e-mail]>; Sat, 29 Aug 1998 04:50:08 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA23951 for idr-outgoing; Sat, 29 Aug 1998 04:44:29 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA23945 for <[e-mail]>; Sat, 29 Aug 1998 04:44:24 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id EAA23551 for <[e-mail]>; Sat, 29 Aug 1998 04:44:23 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id BAA12696; Sat, 29 Aug 1998 01:43:52 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id BAA06194; Sat, 29 Aug 1998 01:43:31 -0700 (PDT)
Date: Sat, 29 Aug 1998 01:43:31 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id EAA20949 for <[e-mail]>; Sat, 29 Aug 1998 04:48:48 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA23923 for idr-outgoing; Sat, 29 Aug 1998 04:41:50 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA23919 for <[e-mail]>; Sat, 29 Aug 1998 04:41:44 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id EAA23474 for <[e-mail]>; Sat, 29 Aug 1998 04:41:43 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id BAA12607; Sat, 29 Aug 1998 01:41:11 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id BAA06176; Sat, 29 Aug 1998 01:40:50 -0700 (PDT)
Date: Sat, 29 Aug 1998 01:40:50 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|  >> 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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA12817 for <[e-mail]>; Fri, 28 Aug 1998 12:27:58 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA13188 for idr-outgoing; Fri, 28 Aug 1998 12:22:47 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA13184 for <[e-mail]>; Fri, 28 Aug 1998 12:22:33 -0400 (EDT)
Received: from hotmail.com (f187.hotmail.com [207.82.251.76]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id MAA13911 for <[e-mail]>; Fri, 28 Aug 1998 12:22:28 -0400 (EDT)
Received: (qmail 10794 invoked by uid 0); 28 Aug 1998 16:21:56 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Fri, 28 Aug 1998 09:21:56 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Content-Type: text/plain
Date: Fri, 28 Aug 1998 09:21:56 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA12512 for <[e-mail]>; Fri, 28 Aug 1998 11:55:33 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA12608 for idr-outgoing; Fri, 28 Aug 1998 11:50:39 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA12599 for <[e-mail]>; Fri, 28 Aug 1998 11:50:32 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id LAA10438 for <[e-mail]>; Fri, 28 Aug 1998 11:50:31 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167); 28 Aug 1998 11:53:50 -0400
Message-ID: <[e-mail]>
Date: Fri, 28 Aug 1998 11:55:39 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: jaihari loganathan <[e-mail]>
CC: [e-mail]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA12296 for <[e-mail]>; Fri, 28 Aug 1998 11:31:05 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA11858 for idr-outgoing; Fri, 28 Aug 1998 11:25:54 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA11818 for <[e-mail]>; Fri, 28 Aug 1998 11:25:37 -0400 (EDT)
Received: from hotmail.com (f217.hotmail.com [207.82.251.108]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id LAA08743 for <[e-mail]>; Fri, 28 Aug 1998 11:25:35 -0400 (EDT)
Received: (qmail 2013 invoked by uid 0); 28 Aug 1998 15:25:04 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Fri, 28 Aug 1998 08:25:03 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Content-Type: text/plain
Date: Fri, 28 Aug 1998 08:25:03 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA11814 for <[e-mail]>; Fri, 28 Aug 1998 10:41:21 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA10187 for idr-outgoing; Fri, 28 Aug 1998 10:35:53 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA10179 for <[e-mail]>; Fri, 28 Aug 1998 10:35:43 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id KAA05634 for <[e-mail]>; Fri, 28 Aug 1998 10:35:42 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167); 28 Aug 1998 10:38:59 -0400
Message-ID: <[e-mail]>
Date: Fri, 28 Aug 1998 10:40:48 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: jaihari loganathan <[e-mail]>
CC: [e-mail]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA11108 for <[e-mail]>; Fri, 28 Aug 1998 09:14:28 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA08152 for idr-outgoing; Fri, 28 Aug 1998 09:05:20 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA08147 for <[e-mail]>; Fri, 28 Aug 1998 09:05:14 -0400 (EDT)
Received: from hotmail.com (f91.hotmail.com [207.82.250.197]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id JAA00363 for <[e-mail]>; Fri, 28 Aug 1998 09:05:13 -0400 (EDT)
Received: (qmail 15825 invoked by uid 0); 28 Aug 1998 13:04:41 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Fri, 28 Aug 1998 06:04:41 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Content-Type: text/plain
Date: Fri, 28 Aug 1998 06:04:41 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA28181 for <[e-mail]>; Thu, 27 Aug 1998 09:03:34 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA11210 for idr-outgoing; Thu, 27 Aug 1998 08:53:34 -0400 (EDT)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA11205 for <[e-mail]>; Thu, 27 Aug 1998 08:53:28 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-37kbm58.dialup.mindspring.com [207.69.216.168]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id IAA30415 for <[e-mail]>; Thu, 27 Aug 1998 08:53:27 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 27 Aug 1998 08:55:14 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: NEXT_HOP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA17553 for <[e-mail]>; Wed, 26 Aug 1998 12:40:18 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA08163 for idr-outgoing; Wed, 26 Aug 1998 12:38:50 -0400 (EDT)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA08158 for <[e-mail]>; Wed, 26 Aug 1998 12:38:44 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lc448.dialup.mindspring.com [209.86.16.136]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id MAA02046 for <[e-mail]>; Wed, 26 Aug 1998 12:38:42 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 26 Aug 1998 09:04:44 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: NEXT_HOP Question...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA16891 for <[e-mail]>; Wed, 26 Aug 1998 11:30:50 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA04807 for idr-outgoing; Wed, 26 Aug 1998 11:26:49 -0400 (EDT)
Received: from idrp.merit.edu ([e-mail] [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA04802 for <[e-mail]>; Wed, 26 Aug 1998 11:26:38 -0400 (EDT)
From: [e-mail]
Date: Wed, 26 Aug 1998 11:26:37 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: August 26th IDR notes
Sender: [e-mail]
Precedence: bulk

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 


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA15908 for <[e-mail]>; Wed, 26 Aug 1998 09:54:28 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA00414 for idr-outgoing; Wed, 26 Aug 1998 09:51:41 -0400 (EDT)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA00410 for <[e-mail]>; Wed, 26 Aug 1998 09:51:34 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lc439.dialup.mindspring.com [209.86.16.105]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id JAA02047 for <[e-mail]>; Wed, 26 Aug 1998 09:51:33 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 26 Aug 1998 08:29:05 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: withdrawn routes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id IAA15043 for <[e-mail]>; Wed, 26 Aug 1998 08:18:43 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA27138 for idr-outgoing; Wed, 26 Aug 1998 08:13:10 -0400 (EDT)
Received: from camel14.mindspring.com (camel14.mindspring.com [207.69.200.64]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA27131 for <[e-mail]>; Wed, 26 Aug 1998 08:13:04 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lcju6.dialup.mindspring.com [209.86.79.198]) by camel14.mindspring.com (8.8.5/8.8.5) with SMTP id IAA05320 for <[e-mail]>; Wed, 26 Aug 1998 08:13:02 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 26 Aug 1998 08:14:49 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: Internal Update Process...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id SAA08240 for <[e-mail]>; Tue, 25 Aug 1998 18:37:32 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA06388 for idr-outgoing; Tue, 25 Aug 1998 18:35:50 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA06382 for <[e-mail]>; Tue, 25 Aug 1998 18:35:40 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id SAA11289 for <[e-mail]>; Tue, 25 Aug 1998 18:35:38 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA15411; Tue, 25 Aug 1998 15:35:08 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id PAA17685; Tue, 25 Aug 1998 15:34:47 -0700 (PDT)
Date: Tue, 25 Aug 1998 15:34:47 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
Sender: [e-mail]
Precedence: bulk

|       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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id SAA08179 for <[e-mail]>; Tue, 25 Aug 1998 18:31:01 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA06202 for idr-outgoing; Tue, 25 Aug 1998 18:30:43 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA06193 for <[e-mail]>; Tue, 25 Aug 1998 18:30:29 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA14521; Tue, 25 Aug 1998 15:29:57 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id PAA17659; Tue, 25 Aug 1998 15:29:40 -0700 (PDT)
Date: Tue, 25 Aug 1998 15:29:40 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from SS Pillai on Tue, 25 Aug 1998 16:13:25 +0530)
Subject: Re: UPDATE Message Handling
Sender: [e-mail]
Precedence: bulk

|  	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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id SAA08145 for <[e-mail]>; Tue, 25 Aug 1998 18:28:43 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA06051 for idr-outgoing; Tue, 25 Aug 1998 18:27:16 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA06024 for <[e-mail]>; Tue, 25 Aug 1998 18:26:52 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id SAA10885 for <[e-mail]>; Tue, 25 Aug 1998 18:26:49 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167); 25 Aug 1998 18:30:28 -0400
Message-ID: <[e-mail]>
Date: Tue, 25 Aug 1998 18:31:51 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: jaihari loganathan <[e-mail]>
CC: [e-mail]
Subject: Re: Clarification needed 9.1.2.1 and 9.2.1.1
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id RAA07772 for <[e-mail]>; Tue, 25 Aug 1998 17:55:54 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA04678 for idr-outgoing; Tue, 25 Aug 1998 17:53:03 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA04657 for <[e-mail]>; Tue, 25 Aug 1998 17:52:36 -0400 (EDT)
Received: from hotmail.com (f115.hotmail.com [207.82.250.165]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id RAA09160 for <[e-mail]>; Tue, 25 Aug 1998 17:52:32 -0400 (EDT)
Received: (qmail 6312 invoked by uid 0); 25 Aug 1998 21:51:59 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Tue, 25 Aug 1998 14:51:59 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: Section 6.2 Open message error handling
Content-Type: text/plain
Date: Tue, 25 Aug 1998 14:51:59 PDT
Sender: [e-mail]
Precedence: bulk

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


>From [e-mail] 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: <[e-mail]>
>To: Tony Li <[e-mail]>
>cc: [e-mail], [e-mail]
>Subject: Re: Section 6.2 Open message error handling
>In-reply-to: Your message of "Tue, 25 Aug 1998 09:20:12 PDT."
>             <[e-mail]>
>Date: Tue, 25 Aug 1998 09:50:22 -0700
>From: Paul Traina <[e-mail]>
>
>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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA04600 for <[e-mail]>; Tue, 25 Aug 1998 12:25:19 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA21664 for idr-outgoing; Tue, 25 Aug 1998 12:21:26 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA21637 for <[e-mail]>; Tue, 25 Aug 1998 12:21:00 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id MAA16447 for <[e-mail]>; Tue, 25 Aug 1998 12:20:58 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id JAA14368; Tue, 25 Aug 1998 09:20:27 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id JAA15904; Tue, 25 Aug 1998 09:20:12 -0700 (PDT)
Date: Tue, 25 Aug 1998 09:20:12 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: Section 6.2 Open message error handling
Sender: [e-mail]
Precedence: bulk

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
|  


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id DAA29464 for <[e-mail]>; Tue, 25 Aug 1998 03:46:30 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA04618 for idr-outgoing; Tue, 25 Aug 1998 03:45:43 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA04613 for <[e-mail]>; Tue, 25 Aug 1998 03:45:38 -0400 (EDT)
Received: from hotmail.com (f96.hotmail.com [207.82.250.215]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id DAA21142 for <[e-mail]>; Tue, 25 Aug 1998 03:45:37 -0400 (EDT)
Received: (qmail 5258 invoked by uid 0); 25 Aug 1998 07:45:06 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Tue, 25 Aug 1998 00:45:05 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: Section 6.2 Open message error handling
Content-Type: text/plain
Date: Tue, 25 Aug 1998 00:45:05 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id BAA28396 for <[e-mail]>; Tue, 25 Aug 1998 01:16:29 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA00867 for idr-outgoing; Tue, 25 Aug 1998 01:13:47 -0400 (EDT)
Received: from teil.soft.net ([164.164.10.2]) by merit.edu (8.8.7/8.8.5) with SMTP id BAA00863 for <[e-mail]>; Tue, 25 Aug 1998 01:13:32 -0400 (EDT)
Received: from sspillai.teil.soft.net by teil.soft.net via SMTP (940816.SGI.8.6.9/940406.SGI) id KAA03319; Tue, 25 Aug 1998 10:43:48 -0530
Message-ID: <[e-mail]>
Date: Tue, 25 Aug 1998 16:13:25 +0530
From: SS Pillai <[e-mail]>
X-Mailer: Mozilla 3.0Gold (X11; U; BSD/OS 3.0 i386)
MIME-Version: 1.0
To: Tony Li <[e-mail]>
CC: [e-mail]
Subject: Re: UPDATE Message Handling
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA28213 for <[e-mail]>; Tue, 25 Aug 1998 00:57:50 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA29382 for idr-outgoing; Tue, 25 Aug 1998 00:26:35 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA29371 for <[e-mail]>; Tue, 25 Aug 1998 00:26:04 -0400 (EDT)
Received: from hotmail.com (f124.hotmail.com [207.82.251.3]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id AAA14605 for <[e-mail]>; Tue, 25 Aug 1998 00:25:53 -0400 (EDT)
Received: (qmail 22852 invoked by uid 0); 25 Aug 1998 04:25:21 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Mon, 24 Aug 1998 21:25:21 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: Clarification needed 9.1.2.1 and 9.2.1.1
Content-Type: text/plain
Date: Mon, 24 Aug 1998 21:25:21 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA20973 for <[e-mail]>; Mon, 24 Aug 1998 11:43:05 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA01662 for idr-outgoing; Mon, 24 Aug 1998 11:41:06 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA01654 for <[e-mail]>; Mon, 24 Aug 1998 11:40:59 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id IAA17710; Mon, 24 Aug 1998 08:40:29 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id IAA09631; Mon, 24 Aug 1998 08:40:15 -0700 (PDT)
Date: Mon, 24 Aug 1998 08:40:15 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Eric Horowitz on Mon, 24 Aug 1998 08:47:50 -0400)
Subject: Re: UPDATE Message Handling
Sender: [e-mail]
Precedence: bulk

|            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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA20894 for <[e-mail]>; Mon, 24 Aug 1998 11:39:34 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA01451 for idr-outgoing; Mon, 24 Aug 1998 11:36:58 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA01430 for <[e-mail]>; Mon, 24 Aug 1998 11:36:48 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id IAA17270; Mon, 24 Aug 1998 08:35:50 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id IAA09601; Mon, 24 Aug 1998 08:35:37 -0700 (PDT)
Date: Mon, 24 Aug 1998 08:35:37 -0700 (PDT)
Message-Id: <[e-mail]>
From: Tony Li <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Eric Horowitz on Mon, 24 Aug 1998 08:47:50 -0400)
Subject: Re: UPDATE Message Handling
Sender: [e-mail]
Precedence: bulk

|  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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA20425 for <[e-mail]>; Mon, 24 Aug 1998 10:54:41 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA28784 for idr-outgoing; Mon, 24 Aug 1998 10:50:56 -0400 (EDT)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA28778 for <[e-mail]>; Mon, 24 Aug 1998 10:50:46 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lcmgp.dialup.mindspring.com [209.86.90.25]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id KAA05637 for <[e-mail]>; Mon, 24 Aug 1998 10:50:44 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 24 Aug 1998 08:47:50 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: UPDATE Message Handling
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA15471 for <[e-mail]>; Mon, 24 Aug 1998 00:47:45 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA13804 for idr-outgoing; Mon, 24 Aug 1998 00:46:01 -0400 (EDT)
Received: from hotmail.com (f113.hotmail.com [207.82.251.43]) by merit.edu (8.8.7/8.8.5) with SMTP id AAA13800 for <[e-mail]>; Mon, 24 Aug 1998 00:45:55 -0400 (EDT)
Received: (qmail 19929 invoked by uid 0); 24 Aug 1998 04:45:24 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Sun, 23 Aug 1998 21:45:24 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Appropriate Adj_RIB_In
Content-Type: text/plain
Date: Sun, 23 Aug 1998 21:45:24 PDT
Sender: [e-mail]
Precedence: bulk

>
>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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA09690 for <[e-mail]>; Sun, 23 Aug 1998 12:40:56 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA28261 for idr-outgoing; Sun, 23 Aug 1998 12:34:50 -0400 (EDT)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA28256 for <[e-mail]>; Sun, 23 Aug 1998 12:34:44 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lciu1.dialup.mindspring.com [209.86.75.193]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id MAA27259 for <[e-mail]>; Sun, 23 Aug 1998 12:34:38 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Sun, 23 Aug 1998 12:24:53 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: Appropriate Adj_RIB_In
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id XAA03029 for <[e-mail]>; Sat, 22 Aug 1998 23:33:31 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA21356 for idr-outgoing; Sat, 22 Aug 1998 23:28:42 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id XAA21348 for <[e-mail]>; Sat, 22 Aug 1998 23:24:54 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id UAA26044; Sat, 22 Aug 1998 20:24:19 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id UAA01483; Sat, 22 Aug 1998 20:24:08 -0700 (PDT)
To: [e-mail] (jaihari loganathan)
cc: [e-mail]
Subject: Re: MinRouteAdvertisementInterval
References: <[e-mail]>
From: Tony Li <[e-mail]>
Date: 22 Aug 1998 20:24:08 -0700
In-Reply-To: [e-mail]'s message of 22 Aug 98 07:15:50 GMT
Message-ID: <[e-mail]>
Lines: 26
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: [e-mail]
Precedence: bulk

[e-mail] (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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id EAA25827 for <[e-mail]>; Sat, 22 Aug 1998 04:34:48 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA04956 for idr-outgoing; Sat, 22 Aug 1998 04:33:31 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA04950 for <[e-mail]>; Sat, 22 Aug 1998 04:33:20 -0400 (EDT)
Received: from hotmail.com (f188.hotmail.com [207.82.251.77]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id EAA01870 for <[e-mail]>; Sat, 22 Aug 1998 04:33:19 -0400 (EDT)
Received: (qmail 13985 invoked by uid 0); 22 Aug 1998 08:32:48 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Sat, 22 Aug 1998 01:32:48 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: RFC1772 (suggestion)
Content-Type: text/plain
Date: Sat, 22 Aug 1998 01:32:48 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id DAA25540 for <[e-mail]>; Sat, 22 Aug 1998 03:19:14 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA03931 for idr-outgoing; Sat, 22 Aug 1998 03:16:30 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA03927 for <[e-mail]>; Sat, 22 Aug 1998 03:16:22 -0400 (EDT)
Received: from hotmail.com (f155.hotmail.com [207.82.251.34]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id DAA28458 for <[e-mail]>; Sat, 22 Aug 1998 03:16:21 -0400 (EDT)
Received: (qmail 14396 invoked by uid 0); 22 Aug 1998 07:15:50 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Sat, 22 Aug 1998 00:15:50 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: MinRouteAdvertisementInterval
Content-Type: text/plain
Date: Sat, 22 Aug 1998 00:15:50 PDT
Sender: [e-mail]
Precedence: bulk

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


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA18073 for <[e-mail]>; Fri, 21 Aug 1998 12:17:32 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA15791 for idr-outgoing; Fri, 21 Aug 1998 12:16:17 -0400 (EDT)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA15784 for <[e-mail]>; Fri, 21 Aug 1998 12:16:11 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lcmgf.dialup.mindspring.com [209.86.90.15]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id MAA04481 for <[e-mail]>; Fri, 21 Aug 1998 12:16:05 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 21 Aug 1998 08:58:12 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: feasible
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA16588 for <[e-mail]>; Fri, 21 Aug 1998 09:06:50 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA11765 for idr-outgoing; Fri, 21 Aug 1998 09:02:28 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA11761; Fri, 21 Aug 1998 09:02:22 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167); 21 Aug 1998 09:05:09 -0400
Message-ID: <[e-mail]>
Date: Fri, 21 Aug 1998 09:07:16 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Susan Hares <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: RFC1771 page 2 (hop-by-hop paradigm) clarification please
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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" <[e-mail]>
> To: [e-mail]
> 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:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id WAA11694 for <[e-mail]>; Thu, 20 Aug 1998 22:18:54 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA05663 for idr-outgoing; Thu, 20 Aug 1998 22:17:26 -0400 (EDT)
Received: from merit.edu ([e-mail] [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA05658; Thu, 20 Aug 1998 22:17:20 -0400 (EDT)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
cc: [e-mail]
Subject: RFC1771 page 2 (hop-by-hop paradigm) clarification please
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Aug 1998 22:17:19 -0400
From: Susan Hares <[e-mail]>
Sender: [e-mail]
Precedence: bulk

------- Forwarded Message

From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
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





Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id SAA10015 for <[e-mail]>; Thu, 20 Aug 1998 18:17:51 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA02852 for idr-outgoing; Thu, 20 Aug 1998 18:17:07 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA02847 for <[e-mail]>; Thu, 20 Aug 1998 18:16:53 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167); 20 Aug 1998 18:19:16 -0400
Message-ID: <[e-mail]>
Date: Thu, 20 Aug 1998 18:21:19 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Eric Horowitz <[e-mail]>
CC: [e-mail]
Subject: Re: phases
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
> [e-mail]
> ===========================



--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id RAA09527 for <[e-mail]>; Thu, 20 Aug 1998 17:26:33 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA01823 for idr-outgoing; Thu, 20 Aug 1998 17:25:27 -0400 (EDT)
Received: from camel7.mindspring.com (camel7.mindspring.com [207.69.200.57]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA01819 for <[e-mail]>; Thu, 20 Aug 1998 17:25:22 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lc478.dialup.mindspring.com [209.86.16.232]) by camel7.mindspring.com (8.8.5/8.8.5) with SMTP id RAA09962 for <[e-mail]>; Thu, 20 Aug 1998 17:25:20 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 20 Aug 1998 13:16:41 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: phases
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA08033 for <[e-mail]>; Thu, 20 Aug 1998 14:44:15 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA27654 for idr-outgoing; Thu, 20 Aug 1998 14:39:33 -0400 (EDT)
Received: from camel7.mindspring.com (camel7.mindspring.com [207.69.200.57]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA27649 for <[e-mail]>; Thu, 20 Aug 1998 14:39:18 -0400 (EDT)
Received: from ehorowi1.sed.csc.com (user-38lc478.dialup.mindspring.com [209.86.16.232]) by camel7.mindspring.com (8.8.5/8.8.5) with SMTP id OAA31811 for <[e-mail]>; Thu, 20 Aug 1998 14:39:16 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 20 Aug 1998 10:40:08 -0400
To: [e-mail]
From: Eric Horowitz <[e-mail]>
Subject: Test
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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


===========================
Eric Horowitz
[e-mail]
===========================


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA08546 for <[e-mail]>; Thu, 13 Aug 1998 12:35:24 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA21664 for idr-outgoing; Thu, 13 Aug 1998 12:29:52 -0400 (EDT)
Received: from merit.edu ([e-mail] [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA21660; Thu, 13 Aug 1998 12:29:47 -0400 (EDT)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
cc: [e-mail]
Subject: Internet drafts
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 13 Aug 1998 12:29:47 -0400
From: Susan Hares <[e-mail]>
Sender: [e-mail]
Precedence: bulk

------- Forwarded Message

>From idr-owner  Wed Aug 12 14:36:41 1998
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by merit.edu (8.8.7/8.8.5) with ESMTP id OAA22802
	for <[e-mail]>; Wed, 12 Aug 1998 14:36:40 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01654;
	Wed, 12 Aug 1998 14:36:02 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-cap-neg-02.txt
Date: Wed, 12 Aug 1998 14:36:01 -0400
Sender: [e-mail]

- --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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message





Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id PAA04052 for <[e-mail]>; Mon, 10 Aug 1998 15:55:57 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA07830 for idr-outgoing; Mon, 10 Aug 1998 15:50:00 -0400 (EDT)
Received: from trix.cisco.com (trix-hme0.cisco.com [171.69.63.45]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA07826 for <[e-mail]>; Mon, 10 Aug 1998 15:49:55 -0400 (EDT)
Received: from cisco.com (localhost [127.0.0.1]) by trix.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA13434; Mon, 10 Aug 1998 12:49:22 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: draft-ietf-idr-aggregation-framework-03.txt
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 10 Aug 1998 12:49:22 -0700
From: Enke Chen <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-aggregation-framework-03.txt
Date: Mon, 10 Aug 1998 11:22:32 -0400
Sender: [e-mail]
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.



Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id QAA02312 for <[e-mail]>; Fri, 7 Aug 1998 16:57:21 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA06633 for idr-outgoing; Fri, 7 Aug 1998 16:51:03 -0400 (EDT)
Received: from merit.edu ([e-mail] [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA06629; Fri, 7 Aug 1998 16:50:59 -0400 (EDT)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
cc: [e-mail]
Subject: DRaft submission
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 07 Aug 1998 16:50:58 -0400
From: Susan Hares <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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

----

Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by merit.edu (8.8.7/8.8.5) with ESMTP id JAA29041
	for <[e-mail]>; Fri, 7 Aug 1998 09:31:35 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA12125;
	Fri, 7 Aug 1998 09:30:59 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-08.txt
Date: Fri, 07 Aug 1998 09:30:58 -0400
Sender: [e-mail]

- --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:	[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message





Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id PAA19123 for <[e-mail]>; Thu, 6 Aug 1998 15:37:12 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA16588 for idr-outgoing; Thu, 6 Aug 1998 15:31:01 -0400 (EDT)
Received: from idrp.merit.net ([e-mail] [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA16582; Thu, 6 Aug 1998 15:30:50 -0400 (EDT)
From: [e-mail]
Date: Thu, 6 Aug 1998 15:30:49 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: BGP MIB revision
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

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 





Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id WAA10974 for <[e-mail]>; Tue, 4 Aug 1998 22:06:11 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA11147 for idr-outgoing; Tue, 4 Aug 1998 22:03:24 -0400 (EDT)
Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA11143 for <[e-mail]>; Tue, 4 Aug 1998 22:03:19 -0400 (EDT)
Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.7/8.8.7) id VAA00485; Tue, 4 Aug 1998 21:59:59 GMT (envelope-from lsanchez)
From: "Luis A. Sanchez" <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
In-Reply-To: <[e-mail]> from Curtis Villamizar at "Jul 29, 98 10:05:05 am"
To: [e-mail]
Date: Tue, 4 Aug 1998 21:59:59 +0000 (GMT)
Cc: [e-mail]
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> ps- for us near crypto illiterates could you point to some consise
> 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




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id CAA02037 for <[e-mail]>; Tue, 4 Aug 1998 02:43:13 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA25235 for idr-outgoing; Tue, 4 Aug 1998 02:37:06 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA25230 for <[e-mail]>; Tue, 4 Aug 1998 02:37:00 -0400 (EDT)
From: [e-mail]
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id CAA21616 for <[e-mail]>; Tue, 4 Aug 1998 02:36:59 -0400 (EDT)
Received: from local by relay7.UU.NET with SMTP  (peer crosschecked as: 1Cust126.tnt3.nyc3.da.uu.net [153.37.110.126]) id QQfayc12170; Tue, 4 Aug 1998 02:36:35 -0400 (EDT)
Date: Tue, 4 Aug 1998 02:36:35 -0400 (EDT)
Message-Id: <[e-mail]>
Subject: Amazing World Record Sex!!!
Sender: [e-mail]
Precedence: bulk

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:

[e-mail]

[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