Subject: [Idr] draft-ietf-idr-bgp4-26.txt: active state (page 61)

From: saravana kumar <[email-masked]>
Date: Wed, 1 Jun 2005 12:52:32 -0700 (PDT)

Hi,
  The Active State on the draft reads :
"In response to a TCP connection succeeding (Event 16
or Event 17)"

  I am assuming in Active State there is no pending
outbound connection attempt.

  If this assumption is correct, then is Event 16
Tcp_CR_Acked really valid/possible in active state?

  I apologize if this question has been answered
already, i couldn't locate in the archives.

Thanks,
skumar.

__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Tulip Rasputin <[email-masked]>
Date: Thu, 2 Jun 2005 00:27:54 -0400 (EDT)

Hi,

Is the Route Origin Community defined in draft-ietf-idr-bgp-ext-communities-08.txt the same as the
Site Of Origin that is explained in a lot of online and regular BGP/MPLS VPN documentation?

If not, then I would appreciate if somebody could point me to an IETF doc that tells more about
SOO in terms of IANA values, etc.

Thanks,
Tulip

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 2 Jun 2005 10:24:10 +0200

Possible, perhaps not valid, depending on your implementation and what's
happening at the other end.

Note that Active state is the bucket into which things fall, so while the normal
way there is from Idle, you can also get there from Connect state or Open Sent
state after a failure.  If, in such transitions, you wipe all traces from your
memory of having sent a TCP SYN, then the SYN-ACK could appear out of the blue
as an invalid packet and be discarded.  But if you remember that while in
Connect state you sent a SYN and are now getting a second SYN-ACK - perhaps the
ACK and OPEN you sent got lost - then that could count as a further event 16.
So you certainly can receive a SYN-ACK in Active state but your TCP processing
might not let it get to the BGP machine.

Tom Petch

---

From: saravana kumar <[email-masked]>
Date: Thu, 2 Jun 2005 07:35:56 -0700 (PDT)

Thanks, I realized that, but Event 18 ( TCP connection
fail detection by local TCP machinery ) is what gets
us to active state. So an outbound connection success
after this point seems not likely.

Another question along the same lines :
In the connect state, if Event 16 happens (inbound
connection was successful), the draft suggests 
"sending an open or start open delay timer."

Aren't there two connections (fsms ) to track here :
one for the pending outbound connection and the
inbound connection?

Thanks,
-skumar.

		
__________________________________ 
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 2 Jun 2005 19:40:12 +0200

I don't follow you here.  Event 16 I would regard as outbound connection
complete; I sent SYN, received SYN-ACK and sent ACK (TCP three-way handshake).
Connection established, I send BGP OPEN (or start the DelayOpen timer); I don't
see a second connection.

Tom Petch

----- Original Message -----
From: "saravana kumar" <[email-masked]>
To: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 02, 2005 4:35 PM
Subject: Re: [Idr] draft-ietf-idr-bgp4-26.txt: active state (page 61)

> one for the pending outbound connection and the
<snip>

---

From: saravana kumar <[email-masked]>
Date: Thu, 2 Jun 2005 14:22:13 -0700 (PDT)

correction: Read that as Event 17.
-skumar.

---

From: "Tom Petch" <[email-masked]>
Date: Sun, 5 Jun 2005 10:20:06 +0200

Probably two connections.  Event 17 in the Connect state should have been
preceded by Event 14 TcpConnection_Valid in Connect state, most likely with
DelayOpenTimer running.

But the intention of this fsm is to model all that happens between a particular
pair of configured peers with a single fsm at each end.  (Modelling each
connection between a particular pair of peers as an fsm requires a different set
of events and states; it was discussed but would have greater changes to the
existing specification which was not considered within the remit of the WG).
The challenge then is, as discussed in 8.2.1, that the identifier of the peer is
not known until OPENs are exchanged, so each tcp connection may start as a
separate fsm and then when it becomes apparent that there is already an fsm for
this peer,  6.8 BGP connection collision detection  comes into play and you end
up with one.  But you are not required to implement it this way as long as the
appearance you present conforms with the specification.  You may choose to know
from the TCP SYN that this packet relates to an existing fsm and not create a
second.

As with any fsm, it is a matter of judgement what states there are, what events
there are.  What you see is considered the best compromise.  Read section 8.2.1
carefully; it says what there is to be said.

Tom Petch

---

From: saravana kumar <[email-masked]>
Date: Sun, 5 Jun 2005 09:12:37 -0700 (PDT)

Thanks for your response.

I am deriving :

on detecting an inbound connection attempt :
1) In the connect state,  continue to be in the
connect state; process the new connection with a new
fsm in active state. I am not sure you could 'choose'
to close the outbound connection fsm as that would
cause
both sides to potentially close the connection same
way.

2) In the active state ( no outbound connection
pending ), associate the inbound connection with the
current fsm.

Question : Suppose unconfigured peers were never
allowed by the draft (as i suppose is reality), is it
correct to say that one could've used source tcp
address comparison as a means to break the tie as soon
as it is detected? (assuming both sides use this
mechanism).

-skumar.

--- Tom Petch <[email-masked]> wrote:

> > > I don't follow you here.  Event 16 I would
> regard as
> > > outbound connection
> > > complete; I sent SYN, received SYN-ACK and sent
> ACK
> > > (TCP three-way handshake).
> > > Connection established, I send BGP OPEN (or
> start
> > > the DelayOpen timer); I don't
> > > see a second connection.
> > >
> > > Tom Petch
> > >
> > > > Aren't there two connections (fsms ) to track
> here
> > > :

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 6 Jun 2005 10:59:19 +0200

I think you should do what the I-D says if you wish to interoperate with other
implementations:-). The issue, which I think lay behind your initial question,
is that depending on how you choose to set up the fsm, some events are unlikely
to occur (I hesitate to say cannot without spending more time thinking about
it).  In particular, it is BGP identifier, usually from
the OPEN message, that you must use to identify which peer wins a collision.
s6.8
defines what a connection collision is in terms of source and destination IP
address so, at TCP SYN time, you see a collision coming but then have to track
the progress of the TCP connection until you find out what you do about it and
ensure the BGP peer has the
information to take the same decision as you ie, assuming no errors, you should
send SYN-ACK and OPEN and then NOTIFICATION on the one that is to be closed.
Quite how you do this is up to you.  One constraint is that the bgp4-mib has a
peer table indexed by remote ip address with fsm state in it which pushes you
towards having one fsm per remote ip address/peer as far as possible.

You will find the fsm discussed in the idr archives, at least from Jan2002 to
Nov2003; the issue of how many fsm to have crops up several times, eg in
January, July and September 2002.  To quote one suggestion (not quite the
wording we ended up with)

 An instance of an FSM is created by a BGP speaker for each configured
   peer. It may also be created dynamically when an incoming transport
   connection is reported, there's no matching configured peer and
   the speaker is configured to accept such connections

This, as another post says, is a temporary breach of the idea that BGP limits
you to a single connection between a pair of ip addresses and that there is one
fsm associated with it

Tom Petch

----- Original Message -----
From: "saravana kumar" <[email-masked]>
To: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Sunday, June 05, 2005 6:12 PM
Subject: Re: [Idr] draft-ietf-idr-bgp4-26.txt: active state (page 61)

> as it is detected? (assuming both sides use this
/listinfo/idr