Subject: transport connection
From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Date: Fri, 25 Sep 1998 16:22:19 PDT

Hi,
1)
   In the BGP state machine, does transport connection open event
   refer to successful outbound(initiated) connection (establishment)       
only or refers to (successful) inbound connection also?

2) 
   Does unconfigured peer means a peer using a source ip address (for 
the connection it is initiating ) something other than what we are using 
as destination ip address in an outbound connection?
Thanks,
-Jaihari.

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

Date: Thu, 24 Sep 1998 13:31:43 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Comments on bgp4 draft -08.txt
Sender: [email-masked]

|  It doesn't appear that either of the above situations would allow an 
|  implementation to restart any ConnectRetry timer.  

Good point.  I agree.

|  How about replacing this paragraph with something along the lines of:
|  
|     If the local system allows unconfigured connections (for example,
|     by configuring the BGP Identifier of the peer while allowing its
|     remote IP address to vary), then when the local system detects
|     that a remote peer is trying to establish a BGP connction to it,
|     and the IP address of the remote peer is not a configured one, 
|     the local system creates a temporary peer entry, completes
|     initialization, sends an OPEN message to its peer, sets its Hold
|     Timer to a large value, and changes its state to OpenSent.
|  
|     If the local system does not allow unconfigured connections,
|     then connections from IP addresses which are not configured peers
|     are rejected.

I think that the text can be massaged but I agree with the intent.

Tony

From: Dave Thaler <[email-masked]>
Subject: Re: Comments on bgp4 draft -08.txt
To: [email-masked] (Tony Li)
Date: Thu, 24 Sep 1998 15:13:22 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Tony, thanks for the reply...

> |  > Active state:
[...]
> |  > If the local system detects that a remote peer is trying to
> |  > establish BGP connection to it, and the IP address of the
> |  > remote peer is not an expected one, the local system restarts
> |  > the ConnectRetry timer, rejects the attempted connection,
> |  > continues to listen for a connection that may be initiated by
> |  > the remote BGP peer, and stays in the Active state.
[...]
> The expectation is that you shouldn't be getting a TCP connection for BGP
> from someone that is not a configured peer.
[...]
> I think that this was worded this way to intentionally allow an
> implementation to be promiscuous (i.e., accept unconfigured connections).

It doesn't appear that either of the above situations would allow an 
implementation to restart any ConnectRetry timer.  If you reject
a connection because it's not a configured peer, then you have
no timer to restart.  If you accept a peer promiscuously, then
you don't reject the attempted connection.

How about replacing this paragraph with something along the lines of:

   If the local system allows unconfigured connections (for example,
   by configuring the BGP Identifier of the peer while allowing its
   remote IP address to vary), then when the local system detects
   that a remote peer is trying to establish a BGP connction to it,
   and the IP address of the remote peer is not a configured one, 
   the local system creates a temporary peer entry, completes
   initialization, sends an OPEN message to its peer, sets its Hold
   Timer to a large value, and changes its state to OpenSent.

   If the local system does not allow unconfigured connections,
   then connections from IP addresses which are not configured peers
   are rejected.

-Dave

Date: Thu, 24 Sep 1998 01:09:23 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on bgp4 draft -08.txt
Sender: [email-masked]

Dave,

|  > Active state:
|  >   In this state BGP is trying to acquire a peer by initiating a
|  >   transport protocol connection.
|  
|  If I understand things right, when the local system is in the Active
|  state, it isn't trying to connect to the remote peer, it's only
|  listening for the remote peer to connect to it.  Hence, shouldn't
|  this be "trying to acquire a peer by listening for (or accepting)
|  a transport protocol connection"?  I don't think the local system
|  is "initiating" anything is it?

Yeah, this should probably go over to Connect state.

|  > If the local system detects that a remote peer is trying to
|  > establish BGP connection to it, and the IP address of the
|  > remote peer is not an expected one, the local system restarts
|  > the ConnectRetry timer, rejects the attempted connection,
|  > continues to listen for a connection that may be initiated by
|  > the remote BGP peer, and stays in the Active state.
|  
|  I find this paragraph very confusing.  First of all, when
|  the local system is in the Active state, it has not yet received
|  an OPEN message, and hence only has available to it the IP address
|  of the new connection.  So what does it mean by "expected"?

The expectation is that you shouldn't be getting a TCP connection for BGP
from someone that is not a configured peer.

|  If this means that it has no state for any peer known to have
|  the associated IP address, then there is no peer state to be in
|  the Active state.  If, on the other hand, it does have state for 
|  a given IP address, then in what way would the IP address not be 
|  an "expected one"?
|  
|  Can someone clarify what the intended meaning of this paragraph is?

I think that this was worded this way to intentionally allow an
implementation to be promiscuous (i.e., accept unconfigured connections).

|  Finally, one question on section 6.2 (OPEN message error handling):
|  Why is it that the Version field in the OPEN message is 1-octet,
|  but the Data field of an Unsupported Version Number notification
|  is 2-octets?

That's probably a bug.  But a really tiny one.  ;-)

Tony

From: Dave Thaler <[email-masked]>
Subject: Comments on bgp4 draft -08.txt
To: [email-masked]
Date: Wed, 23 Sep 1998 18:43:43 -0400 (EDT)
Sender: [email-masked]

In trying to clean up the BGMP spec, I came up with some comments
on text that was stolen from the BGP spec.  So here they are
in the context of the BGP4 -08 draft.

Two comments on section 8, Active state:
> Active state:
>   In this state BGP is trying to acquire a peer by initiating a
>   transport protocol connection.

If I understand things right, when the local system is in the Active
state, it isn't trying to connect to the remote peer, it's only
listening for the remote peer to connect to it.  Hence, shouldn't
this be "trying to acquire a peer by listening for (or accepting)
a transport protocol connection"?  I don't think the local system
is "initiating" anything is it?

> If the local system detects that a remote peer is trying to
> establish BGP connection to it, and the IP address of the
> remote peer is not an expected one, the local system restarts
> the ConnectRetry timer, rejects the attempted connection,
> continues to listen for a connection that may be initiated by
> the remote BGP peer, and stays in the Active state.

I find this paragraph very confusing.  First of all, when
the local system is in the Active state, it has not yet received
an OPEN message, and hence only has available to it the IP address
of the new connection.  So what does it mean by "expected"?
If this means that it has no state for any peer known to have
the associated IP address, then there is no peer state to be in
the Active state.  If, on the other hand, it does have state for 
a given IP address, then in what way would the IP address not be 
an "expected one"?

Can someone clarify what the intended meaning of this paragraph is?

Finally, one question on section 6.2 (OPEN message error handling):
Why is it that the Version field in the OPEN message is 1-octet,
but the Data field of an Unsupported Version Number notification
is 2-octets?

Thanks,
-Dave

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: connection collision detection (was :-) : BGP FSM question)
Date: Sat, 12 Sep 1998 17:50:02 PDT
Sender: [email-masked]

Hi ,
  Connection collision section states : to use the BGP identifier of
  a received open message and compare it with the peers in open confirm 
state to detect a collision.
  This seems to contradict the Finite state machine transition from
  ACTIVE state (to open sent state). The transition requires to match 
the incoming connection with the peer in the ACTIVE state.
  Could you clarify this.
Thanks,
-Jaihari.

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

Date: Sat, 12 Sep 1998 14:56:39 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Route selection criteria (again)
Sender: [email-masked]

|          Is this a conformant(or acceptable) implementation :
|  
|    Select the best route 'b' according to criteria 9.1.2.1
|      
|    Update the external peers.
|  
|    If this route is an EBGP route
|        update the internal peers.

Assuming a whole lot of other stuff (e.g., updating the Local RIB, policy
filtering, ...), yes, that's fine.  In fact, I believe that's the way that
Cisco still works...  

Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Route selection criteria (again)
Date: Sat, 12 Sep 1998 03:56:12 PDT
Sender: [email-masked]

Hi,

>>This is incorrect.  An implementation MAY advertise an EBGP route that 
>it
>>is not using to internal peers.  
>
>   Yes I got it in an earlier mail. But my question is :
>       Since we cannot select ONE EBGP route for advertising to 
external 
>peers (we did not select a IBGP route) and a DIFFERENT EBGP route for 
>advertising to internal peers (according to earlier mail), is this a 
>correct interpretation :
>       The set of EBGP routes as ordered by 9.1.2.1 are IN THE SAME 
>RELATIVE ORDER when ordered by 9.2.1.1 ?
>
>Thank you,
>-Jaihari.

  Rephrasing : 

        Is this a conformant(or acceptable) implementation :

  Select the best route 'b' according to criteria 9.1.2.1
    
  Update the external peers.

  If this route is an EBGP route
      update the internal peers.

Thanks, 
-Jaihari

     

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

From: "jaihari loganathan" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Route selection criteria (again)
Date: Fri, 11 Sep 1998 16:10:51 PDT
Sender: [email-masked]

Hi,

>This is incorrect.  An implementation MAY advertise an EBGP route that 
it
>is not using to internal peers.  

   Yes I got it in an earlier mail. But my question is :
       Since we cannot select ONE EBGP route for advertising to external 
peers (we did not select a IBGP route) and a DIFFERENT EBGP route for 
advertising to internal peers (according to earlier mail), is this a 
correct interpretation :
       The set of EBGP routes as ordered by 9.1.2.1 are IN THE SAME 
RELATIVE ORDER when ordered by 9.2.1.1 ?

Thank you,
-Jaihari.

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

MBOX-Line: From [email-masked] Fri Sep 11 21:24:17 1998
MBOX-Line: From [email-masked] Fri Sep 11 21:04:01 1998
Date: Fri, 11 Sep 1998 13:44:07 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Route selection criteria (again)
Sender: [email-masked]

Pedro,

|      jaihari> If we have selected an internal path (IBGP route) for
|      jaihari> external update, we can ,out of the EBGP routes select
|      jaihari> one for internal update.
|  
|  No. You can't tell your external peers one thing and your internal
|  peers something completly different. The goal here is for traffic not
|  to loop. If you annouce your peers a route they will probably forward
|  traffic though you. You really don't want to create a situation where
|  everybody around you things your their nexthop to the destination.

This is incorrect.  An implementation MAY advertise an EBGP route that it
is not using to internal peers.  The constraint is that the domain MUST
select the same internal route or same consistent set of internal routes
and that the suboptimal EBGP route that is advertised is clearly inferior
to those already in use.  Thus, no systems will select this suboptimal EBGP
path.  This avoids the forwarding loop.

Note that not all implementations support this and that it's not clear that
this flexibility is required, but it was added because there was the
prospect that this would help reduce the amount of route churn seen in
large domains, at the expense of additional state space.

Tony

MBOX-Line: From [email-masked] Fri Sep 11 21:04:01 1998
Date: Fri, 11 Sep 1998 13:44:07 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Route selection criteria (again)
Sender: [email-masked]

Pedro,

|      jaihari> If we have selected an internal path (IBGP route) for
|      jaihari> external update, we can ,out of the EBGP routes select
|      jaihari> one for internal update.
|  
|  No. You can't tell your external peers one thing and your internal
|  peers something completly different. The goal here is for traffic not
|  to loop. If you annouce your peers a route they will probably forward
|  traffic though you. You really don't want to create a situation where
|  everybody around you things your their nexthop to the destination.

This is incorrect.  An implementation MAY advertise an EBGP route that it
is not using to internal peers.  The constraint is that the domain MUST
select the same internal route or same consistent set of internal routes
and that the suboptimal EBGP route that is advertised is clearly inferior
to those already in use.  Thus, no systems will select this suboptimal EBGP
path.  This avoids the forwarding loop.

Note that not all implementations support this and that it's not clear that
this flexibility is required, but it was added because there was the
prospect that this would help reduce the amount of route churn seen in
large domains, at the expense of additional state space.

Tony

Date: Fri, 11 Sep 1998 13:44:07 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Route selection criteria (again)
Sender: [email-masked]

Pedro,

|      jaihari> If we have selected an internal path (IBGP route) for
|      jaihari> external update, we can ,out of the EBGP routes select
|      jaihari> one for internal update.
|  
|  No. You can't tell your external peers one thing and your internal
|  peers something completly different. The goal here is for traffic not
|  to loop. If you annouce your peers a route they will probably forward
|  traffic though you. You really don't want to create a situation where
|  everybody around you things your their nexthop to the destination.

This is incorrect.  An implementation MAY advertise an EBGP route that it
is not using to internal peers.  The constraint is that the domain MUST
select the same internal route or same consistent set of internal routes
and that the suboptimal EBGP route that is advertised is clearly inferior
to those already in use.  Thus, no systems will select this suboptimal EBGP
path.  This avoids the forwarding loop.

Note that not all implementations support this and that it's not clear that
this flexibility is required, but it was added because there was the
prospect that this would help reduce the amount of route churn seen in
large domains, at the expense of additional state space.

Tony

MBOX-Line: From [email-masked] Fri Sep 11 17:30:29 1998
MBOX-Line: From [email-masked] Fri Sep 11 17:11:40 1998
Date: Fri, 11 Sep 1998 09:54:34 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Route selection criteria (again)
Sender: [email-masked]

>>>>> "jaihari" == jaihari loganathan <[email-masked]> writes:

    jaihari> Hi, Sorry for repeating the question again.  I understand
    jaihari> from the earlier mails that one cannot select a different
    jaihari> EBGP route for internal update and external update.

Yes, you cannot. The reason being you have to select one route from the
set of routes you have availiable for a destination and install it on
your forwarding table and you cannot annouce a route that you are not using.

If you would annouce a different route through ibgp than the one you
are using you would create the possibility of loops when your ibgp peers
annouce those routes out of your AS.

    jaihari> If we have selected an internal path (IBGP route) for
    jaihari> external update, we can ,out of the EBGP routes select
    jaihari> one for internal update.

No. You can't tell your external peers one thing and your internal
peers something completly different. The goal here is for traffic not
to loop. If you annouce your peers a route they will probably forward
traffic though you. You really don't want to create a situation where
everybody around you things your their nexthop to the destination.

    jaihari>   Suppose say, we keep a list of
    jaihari> routes (I)BGP and (E)BGP I1,E1,E2,I2,E3 sorted according
    jaihari> to criteria of 9.1.2.1(external update tie breaker) if
    jaihari> E1,E2,E3 appear in the order mentioned they would have to
    jaihari> appear in the same (relative) order according to 9.2.1.1
    jaihari> (internal update selection criteria) also - right?

    jaihari>      Suppose I1 goes away, E1 is the best route for
    jaihari> external update, E2 or E3 cannot be the best route for
    jaihari> internal update -right?

Right.

  Pedro.

MBOX-Line: From [email-masked] Fri Sep 11 17:11:40 1998
Date: Fri, 11 Sep 1998 09:54:34 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Route selection criteria (again)
Sender: [email-masked]

>>>>> "jaihari" == jaihari loganathan <[email-masked]> writes:

    jaihari> Hi, Sorry for repeating the question again.  I understand
    jaihari> from the earlier mails that one cannot select a different
    jaihari> EBGP route for internal update and external update.

Yes, you cannot. The reason being you have to select one route from the
set of routes you have availiable for a destination and install it on
your forwarding table and you cannot annouce a route that you are not using.

If you would annouce a different route through ibgp than the one you
are using you would create the possibility of loops when your ibgp peers
annouce those routes out of your AS.

    jaihari> If we have selected an internal path (IBGP route) for
    jaihari> external update, we can ,out of the EBGP routes select
    jaihari> one for internal update.

No. You can't tell your external peers one thing and your internal
peers something completly different. The goal here is for traffic not
to loop. If you annouce your peers a route they will probably forward
traffic though you. You really don't want to create a situation where
everybody around you things your their nexthop to the destination.

    jaihari>   Suppose say, we keep a list of
    jaihari> routes (I)BGP and (E)BGP I1,E1,E2,I2,E3 sorted according
    jaihari> to criteria of 9.1.2.1(external update tie breaker) if
    jaihari> E1,E2,E3 appear in the order mentioned they would have to
    jaihari> appear in the same (relative) order according to 9.2.1.1
    jaihari> (internal update selection criteria) also - right?

    jaihari>      Suppose I1 goes away, E1 is the best route for
    jaihari> external update, E2 or E3 cannot be the best route for
    jaihari> internal update -right?

Right.

  Pedro.

Date: Fri, 11 Sep 1998 09:54:34 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: "jaihari loganathan" <[email-masked]>
Cc: [email-masked]
Subject: Route selection criteria (again)
Sender: [email-masked]

>>>>> "jaihari" == jaihari loganathan <[email-masked]> writes:

    jaihari> Hi, Sorry for repeating the question again.  I understand
    jaihari> from the earlier mails that one cannot select a different
    jaihari> EBGP route for internal update and external update.

Yes, you cannot. The reason being you have to select one route from the
set of routes you have availiable for a destination and install it on
your forwarding table and you cannot annouce a route that you are not using.

If you would annouce a different route through ibgp than the one you
are using you would create the possibility of loops when your ibgp peers
annouce those routes out of your AS.

    jaihari> If we have selected an internal path (IBGP route) for
    jaihari> external update, we can ,out of the EBGP routes select
    jaihari> one for internal update.

No. You can't tell your external peers one thing and your internal
peers something completly different. The goal here is for traffic not
to loop. If you annouce your peers a route they will probably forward
traffic though you. You really don't want to create a situation where
everybody around you things your their nexthop to the destination.

    jaihari>   Suppose say, we keep a list of
    jaihari> routes (I)BGP and (E)BGP I1,E1,E2,I2,E3 sorted according
    jaihari> to criteria of 9.1.2.1(external update tie breaker) if
    jaihari> E1,E2,E3 appear in the order mentioned they would have to
    jaihari> appear in the same (relative) order according to 9.2.1.1
    jaihari> (internal update selection criteria) also - right?

    jaihari>      Suppose I1 goes away, E1 is the best route for
    jaihari> external update, E2 or E3 cannot be the best route for
    jaihari> internal update -right?

Right.

  Pedro.

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: Route selection criteria (again)
Date: Fri, 11 Sep 1998 03:28:15 PDT
Sender: [email-masked]

Hi,
   Sorry for repeating the question again.
   I understand from the earlier mails that one cannot select 
   a different EBGP route for internal update and external update.
   If we have selected an internal path (IBGP route) for external 
update, we can ,out of the EBGP routes select one for internal update.
   Suppose say, we keep a list of routes (I)BGP and (E)BGP
    I1,E1,E2,I2,E3
    sorted according to criteria of 9.1.2.1(external update tie breaker)
      if E1,E2,E3 appear in the order mentioned 
     they would have to appear in the same (relative) order 
     according to 9.2.1.1 (internal update selection criteria) 
     also - right?

     Suppose I1 goes away, E1 is the best route for external update,
     E2 or E3 cannot be the best route for internal update -right?
    
     It appears to me then 9.2.1.1 is a subset of 9.1.2.1 applied to
     EBGP routes ONLY.
     ( AND if we sort the routes according to the criteria of
        9.1.2.1, we can select the first EBGP route appearing in
        the list for internal update)
 
     Is this interpretation correct?

Thank you,
-Jaihari.

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

Date: Fri, 4 Sep 1998 15:27:28 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: BGP alternate routes
Sender: [email-masked]

|  Also, don't not store routes that are administratively rejected.  A
|  reconfiguration then requires reseting the BGP peering since you don't
|  know if policy changes that accept new prefixes that you don't have in
|  Adj-RIB-In are due to having previously thrown them away.

Whether or not this is good idea depends very much on your hardware and on
where you plan to fit this box in the network.  This is a functional
decision and there are certainly reasons why one would do it in ways that
Curtis would disagree with.

|  You CAN shoot yourself in the foot.  You SHOULD try to avoid it.

Of course, while you're trying to avoid it, you should not shoot yourself
in the other foot.

Tony

To: Wayne Mesard <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP alternate routes 
Date: Fri, 04 Sep 1998 17:37:56 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Flash backs...

I don't think this was adequately answered.

In message <[email-masked]>, Wayne Mesard writes:
> [email-masked] (Tony Li) writes:
> > >      The question is : IS IT MANDATORY THEN TO STORE ALL ALTERNATE
> > >      ROUTES TO A DESTINATION?
> 
> > The protocol specification
> > says NOTHING about what you have to store.  If you decided to not store the
> > route, that's fine.  It would be exactly as if you rejected the route for
> > administrative purposes.
> 
> Really?  RFC-1771, sec 9, par 5 sez:
> 
>    If the UPDATE message contains a feasible route, it shall be placed
>    in the appropriate Adj-RIB-In...                    ^^^^^
>                                                        |||||
> 
> And sec 3.2, par 5 sez:
> 
>    In summary, the Adj-RIBs-In contain unprocessed routing information
>                                        ^^^^^^^^^^^
>    that has been advertised to the local BGP speaker by its peers;
> 
> Wayne();

Having been involved with BGP coding, let me just say that you'd be a
complete idiot not to store the information in the Adj-RIB-In and keep
it until withdrawn regardless of the exact wording of RFC1771 and
whether it mandates storing it or just suggests that it would be a
Real Good Idea.

Tony was trying to point out that "real bad things happen" if you
don't in his prior message.  (If a withdraw occurs and you didn't save
unused advertisements you'd have no route).

Also, don't not store routes that are administratively rejected.  A
reconfiguration then requires reseting the BGP peering since you don't
know if policy changes that accept new prefixes that you don't have in
Adj-RIB-In are due to having previously thrown them away.

You CAN shoot yourself in the foot.  You SHOULD try to avoid it.

Curtis

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: One More nexthop question
Date: Thu, 03 Sep 1998 18:40:21 PDT
Sender: [email-masked]

>|  
>|       for a prefix 'p' about to be advertised to the EBGP peer 
>|       (peering on a shared interface let's call our ip address for 
the
>|        shared interface as ip1(along with subnet mask info), the 
>|  ipaddress for the peer's interface as ip2 )
>|        with the NEXTHOP attribute as N1
>|        If configured to send nexthop as self
>|           use ip1 as the NEXTHOP attribute
>|        else
>|          lookup N1 in the IGP and obtain the directly connected 
>|          IGP nexthop N2.
>
>
>Why did you need to do this step?

     I thought this was a cisco option to set the NEXT HOP to self
     for multiaccess networks where the only path to the route
     is through ourselves.
-Jaihari.

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

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: BGP FSM question
Date: Thu, 03 Sep 1998 06:35:29 PDT
Sender: [email-masked]

Hi,
  I have a basic confusion in the FSM.
  The BGP FSM says if the connect initiate times out,
  transition to ACTIVE STATE and wait for the peer to establish
  the connection. In the ACTIVE state if the transport connection
  succeeds send OPEN and transition to OPEN_SENT state.

  My question is : upon receiving an incoming connection, how do we
  associate this connection to the PEER waiting in ACTIVE state? 
  As i understand we need to receive an open message to get the
  peer's bgpId and associate with a peer in OPENCONFIRM state and
  close one of the connections by connection collision resolution.
  So for the incoming connection we cannot associate the above PEER
  waiting in an ACTIVE_STATE -right?
  Rephrasing : "what is the FSM START STATE for a incoming connection
  ?" or "how can a peer in an ACTIVE_STATE transition out by an
  incoming connection?"

  (or could a peer be associated with this inbound connection, forcing
   the state as ACTIVE and send an OPEN and transition to OPEN_SENT
   state?)
Thanks,
-Jaihari.

    

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

Date: Wed, 2 Sep 1998 23:22:40 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: One More nexthop question
Sender: [email-masked]

|     Suppose we learn a IBGP prefix 'p' with nexthop N1, and we lookup in 
|  our IGP to obtain the directly connected IGP nexthop to 'p' as N2
|  And if N2 is not on the same subnet as our shared peering interface,
|  what should be the NEXTHOP attribute for the prefix 'p' advertised to 
|  the  peer (EBGP). Do we use our shared interface address in this case?

Yes.  That is, you advertise yourself as the next hop (or you don't
advertise anything) as that's the only path that your neighbor can
legitimately use.

|     Can we (then) summarize the NEXTHOP processing behaviour like this :
|  
|       for a prefix 'p' about to be advertised to the EBGP peer 
|       (peering on a shared interface let's call our ip address for the
|        shared interface as ip1(along with subnet mask info), the 
|  ipaddress for the peer's interface as ip2 )
|        with the NEXTHOP attribute as N1
|        If configured to send nexthop as self
|           use ip1 as the NEXTHOP attribute
|        else
|          lookup N1 in the IGP and obtain the directly connected 
|          IGP nexthop N2.

Why did you need to do this step?

|          if N2 and ip1 are on the same subnet ( this incidentally 
|          ensures that ip2 is on the same subnet also - because we
|          require it so )
|                use N2 as the NEXTHOP attribute
|           else
|                 use ip1 as the NEXTHOP attribute

Otherwise, that looks about right.  [Fun starts when you allow multiple
subnets per interface.  ;-) ]

|       For a prefix 'p' (an EBGP prefix with NEXTHOP attribute N1) 
|       to be advertised to an IBGP peer USE N1 as the NEXT HOP attribute.

Yup.  

Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: One More nexthop question
Date: Wed, 02 Sep 1998 17:07:50 PDT
Sender: [email-masked]

Hi,
   From the RFC, the first party/third party (1& 2 form) nexthop is 
required to be on the same subnet as our peering interface. 

   Suppose we learn a IBGP prefix 'p' with nexthop N1, and we lookup in 
our IGP to obtain the directly connected IGP nexthop to 'p' as N2
And if N2 is not on the same subnet as our shared peering interface,
what should be the NEXTHOP attribute for the prefix 'p' advertised to 
the  peer (EBGP). Do we use our shared interface address in this case?

   Can we (then) summarize the NEXTHOP processing behaviour like this :

     for a prefix 'p' about to be advertised to the EBGP peer 
     (peering on a shared interface let's call our ip address for the
      shared interface as ip1(along with subnet mask info), the 
ipaddress for the peer's interface as ip2 )
      with the NEXTHOP attribute as N1
      If configured to send nexthop as self
         use ip1 as the NEXTHOP attribute
      else
        lookup N1 in the IGP and obtain the directly connected 
        IGP nexthop N2.
        if N2 and ip1 are on the same subnet ( this incidentally 
        ensures that ip2 is on the same subnet also - because we
        require it so )
              use N2 as the NEXTHOP attribute
         else
               use ip1 as the NEXTHOP attribute

     For a prefix 'p' (an EBGP prefix with NEXTHOP attribute N1) 
     to be advertised to an IBGP peer USE N1 as the NEXT HOP attribute.
      
     Thank you,
     -Jaihari.

 

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

Date: Wed, 2 Sep 1998 13:53:50 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: NEXT_HOP
Sender: [email-masked]

|  I think I understand that when a speaker advertizes a route to an eBGP
|  peer, it must advertize a NEXT_HOP that is adjacent to the eBGP peer. 
|  
|  I think I also understand that when a speaker advertizes a route to an iBGP
|  peer, it advertizes the NEXT_HOP that came with the route when it got it,
|  even though that NEXT_HOP may not be adjacent to the iBGP peer.

Exactly.

|  QUESTION:
|  
|     A speaker may get a route from one peer and then advertizes it to other
|  peers. The speaker may have to advertize different NEXT_HOPs with this
|  route to each eBGP peer.

Yes.

|  Internally, the speaker has (conceptually)
|  multiple copies of this route - one in the Adj_RIB_In from the receiving
|  peer, another in the Loc_RIB and others in the Adj_RIBs_Out of the other
|  peers. It seems that these copies are not identical. In paritcular, the
|  NEXT_HOP attribute could be different. 

Not exactly how I would conceptualize it (or implement it), but that view
is not inconsistent.

|     Would I be correct to say that the NEXT_HOP attribute is modified when
|  it is placed in the Adj_RIB_Out? The Loc_RIB copy must support all of the
|  peers and thus could not be tailored to have a NEXT_HOP adjecent to any one
|  peer. 

The Loc_RIB must have in it the immediate next hop.  This can be tailored
for external peers, and can be used verbatim for internal peers [assuming
that we ignore reflectors].

|     I know that this may be implementation specific, but the spec defines
|  these 3 RIBs. We should be able to agree on one conceptual model and let
|  developers decide individually if their implementation meets the intent.

Agreed, however, 'modification' is an implementation thought....  To stay
at a conceptual level, the BGP speaker merely 'computes' what the
advertised next hop should be.

Tony

From: "Luis A. Sanchez" <[email-masked]>
Subject: Re: August 26th IDR notes
To: [email-masked]
Date: Wed, 2 Sep 1998 09:34:00 +0000 (GMT)
Sender: [email-masked]

You can find the slides (html) and the source document (ppt) for the
Secure-BGP presentation in

http://www.net-tech.bbn.com/sbgp/sbp-briefing/index.htm

Luis

Date: Wed, 02 Sep 1998 09:06:15 -0400
To: [email-masked]
From: Eric Horowitz <[email-masked]>
Subject: NEXT_HOP
Sender: [email-masked]

I think I understand that when a speaker advertizes a route to an eBGP
peer, it must advertize a NEXT_HOP that is adjacent to the eBGP peer. 

I think I also understand that when a speaker advertizes a route to an iBGP
peer, it advertizes the NEXT_HOP that came with the route when it got it,
even though that NEXT_HOP may not be adjacent to the iBGP peer.

QUESTION:

   A speaker may get a route from one peer and then advertizes it to other
peers. The speaker may have to advertize different NEXT_HOPs with this
route to each eBGP peer. Internally, the speaker has (conceptually)
multiple copies of this route - one in the Adj_RIB_In from the receiving
peer, another in the Loc_RIB and others in the Adj_RIBs_Out of the other
peers. It seems that these copies are not identical. In paritcular, the
NEXT_HOP attribute could be different. 

   Would I be correct to say that the NEXT_HOP attribute is modified when
it is placed in the Adj_RIB_Out? The Loc_RIB copy must support all of the
peers and thus could not be tailored to have a NEXT_HOP adjecent to any one
peer. 

   I know that this may be implementation specific, but the spec defines
these 3 RIBs. We should be able to agree on one conceptual model and let
developers decide individually if their implementation meets the intent.

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

Date: Tue, 1 Sep 1998 01:54:16 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: BGP (For new implementors) Algorithmic issues
Sender: [email-masked]

|     Here is an excellent BGP informational article discussing the 
|     pitfalls of inefficient BGP implementation.
|  
|  http://engr.ans.net/nsf-scaling/scaling.html

Before this is taken as gospel, it should be noted that this paper reflects
certain opinions, and not everything that is an opinion is obviously an
opinion. 

Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: BGP (For new implementors) Algorithmic issues
Date: Tue, 01 Sep 1998 01:11:09 PDT
Sender: [email-masked]

Hi Folks,
   FYI.
   Here is an excellent BGP informational article discussing the 
   pitfalls of inefficient BGP implementation.

http://engr.ans.net/nsf-scaling/scaling.html

-Jaihari.

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

Date: Tue, 1 Sep 1998 00:13:04 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: One more question 9) UPDATE MESSAGE HANDLING ii)
Sender: [email-masked]

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

Correct.  In particular, the address space covered by the less specific and
NOT covered by the more specific is still in effect.

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

Exactly.

Tony