Subject: Re: questions about draft-ietf-idr-as4bytes-04
From: Alex Zinin <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: "Rijsman, Bruno" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Thu, 31 Jan 2002 16:02:06 -0800

Enke,

 Do you think it would be a good idea to include a couple
 of paras, one specifying the temporary (if it is indeed
 temporary) value for AS_TRANS and another explicitly saying
 that dynamic renegotiation is not an option?

 Also, I think Jeff and you agreed that in the para below
 you would need some text saying that the attribute should
 not be propagated further. "discard" may not be descriptive
 enough, I think.

>    The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
>    carried in the UPDATE messages between NEW BGP peers. A NEW BGP
>    speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path
>    attributes in an UPDATE message from a NEW BGP speaker should discard
>    these path attributes and continue processing the UPDATE message.

 Thanks,

-- 
Alex Zinin

Thursday, January 31, 2002, 9:55:06 AM, Enke Chen wrote:

...
>> 1. What's the value of AS_TRANS?  (I could not find it on the IANA web site)

>  It is 23456.

...
>> 
>> 3. As currently specified the AS-PATH attribute can either contain 2-octet
>> or 4-octet AS-numbers, depending on whether or not both sides are NEW BGP
>> speakers.  The UPDATE itself does not contain enough information to
>> determine whether or not both sides are NEW or OLD BGP speakers: you have
>> to look back at the history of capability negotiations for that session.
>> In the case of dynamic capability negotiation you need the whole history
>> of the session since the OPEN.  This is not a problem for BGP
>> implementations, but I imagine this makes life difficult when decoding
>> a trace of captured packets. Would it be worthwhile to intoduce new
>> segment types NEW-AS-SEQ, NEW-AS-SET, NEW-CONFED-SEQ, and NEW-CONFED-SET
>> specifically for 4-octet AS numbers?

> See the following text in Sect 6, <draft-ietf-idr-dynamic-cap-01.txt>:

>    It is noted that the dynamic capability update may not be feasible
>    and should be disallowed for some capabilities.  One example is the
>    four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update
>    could introduce ambiguity in parsing the UPDATE messages.

> -- Enke

To: "Rijsman, Bruno" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: questions about draft-ietf-idr-as4bytes-04 
Date: Thu, 31 Jan 2002 11:09:06 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Rijsman:

> Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AD@UNIWEST1>
> From: "Rijsman, Bruno" <[email-masked]>
> To: 'Enke Chen' <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>
> Subject: RE: questions about draft-ietf-idr-as4bytes-04 
> Date: Thu, 31 Jan 2002 13:13:58 -0500
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Hi Enke,
> 
> Thanks for the quick answers.
> 
> On question 2, I was actually talking about a different situation:
> 
> 1 NEW (AS 111111)
> |
> |
> 2 NEW (AS 200)
> |
> |
> 3 OLD (AS 300)
> |
> |
> 4 NEW (AS 400)
> 
> 
> In this situation router 4 *should* receive an UPDATE from router 3
> containing the following attributes:
> 
> AS-PATH = 300 200 23456
> 
> NEW-AS-PATH = 200 111111
> 
> Note that router 3 passed the NEW-AS-PATH on as an unrecognized transitive
> attribute.
> 
> 
> But, let's say router 4 actually received the following attributes (due to a
> bug in router 2):
> 
> AS-PATH = 300 200 23456
> 
> NEW-AS-PATH = 200 100
> 

If you follow the procedures described in Sect. 4.2.3, Router-4 would
re-construct the AS-PATH as: 300 200 100.

That seems to be the most you can derive from the incomplete AS-PATH
info due to the bug on Router-2. BTW, incomplete/truncated AS-PATH info
occurs not-so-rarely in the pure 2byte-AS world.

-- Enke

> 
> Router 4 knows something is wrong, because the AS-PATH and the NEW-AS-PATH
> are inconsistent (the originating AS 23456 in the AS-PATH cannot possibly
> correspond to the originating AS 100 in the NEW-AS-PATH: one or the other
> must be wrong).
> 
> 
> What should router 4 do?
> 
> 
> -- Bruno

From: "Rijsman, Bruno" <[email-masked]>
To: "'Enke Chen'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: questions about draft-ietf-idr-as4bytes-04 
Date: Thu, 31 Jan 2002 13:13:58 -0500
Sender: [email-masked]

Hi Enke,

Thanks for the quick answers.

On question 2, I was actually talking about a different situation:

1 NEW (AS 111111)
|
|
2 NEW (AS 200)
|
|
3 OLD (AS 300)
|
|
4 NEW (AS 400)

In this situation router 4 *should* receive an UPDATE from router 3
containing the following attributes:

AS-PATH = 300 200 23456

NEW-AS-PATH = 200 111111

Note that router 3 passed the NEW-AS-PATH on as an unrecognized transitive
attribute.

But, let's say router 4 actually received the following attributes (due to a
bug in router 2):

AS-PATH = 300 200 23456

NEW-AS-PATH = 200 100

Router 4 knows something is wrong, because the AS-PATH and the NEW-AS-PATH
are inconsistent (the originating AS 23456 in the AS-PATH cannot possibly
correspond to the originating AS 100 in the NEW-AS-PATH: one or the other
must be wrong).

What should router 4 do?

-- Bruno

To: "Rijsman, Bruno" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: questions about draft-ietf-idr-as4bytes-04 
Date: Thu, 31 Jan 2002 09:55:06 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Rijsman:

> Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AA@UNIWEST1>
> From: "Rijsman, Bruno" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Subject: questions about draft-ietf-idr-as4bytes-04
> Date: Thu, 31 Jan 2002 11:52:07 -0500
> MIME-Version: 1.0
> 
> I have some questions about draft-ietf-idr-as4bytes-04:
> 
> 1. What's the value of AS_TRANS?  (I could not find it on the IANA web site)

 It is 23456.

> 
> 2. What should a BGP speaker do when it receives an AS-PATH and a
> NEW-AS-PATH which are inconsistent (or an AGGREGATOR and NEW-AGGREGATOR
> which are inconsistent)?  Send a NOTIFICATION?  If so, what error code?

See the following text in Sec. 4.1:

   The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
   carried in the UPDATE messages between NEW BGP peers. A NEW BGP
   speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path
   attributes in an UPDATE message from a NEW BGP speaker should discard
   these path attributes and continue processing the UPDATE message.

> 
> 3. As currently specified the AS-PATH attribute can either contain 2-octet
> or 4-octet AS-numbers, depending on whether or not both sides are NEW BGP
> speakers.  The UPDATE itself does not contain enough information to
> determine whether or not both sides are NEW or OLD BGP speakers: you have
> to look back at the history of capability negotiations for that session.
> In the case of dynamic capability negotiation you need the whole history
> of the session since the OPEN.  This is not a problem for BGP
> implementations, but I imagine this makes life difficult when decoding
> a trace of captured packets. Would it be worthwhile to intoduce new
> segment types NEW-AS-SEQ, NEW-AS-SET, NEW-CONFED-SEQ, and NEW-CONFED-SET
> specifically for 4-octet AS numbers?

See the following text in Sect 6, <draft-ietf-idr-dynamic-cap-01.txt>:

   It is noted that the dynamic capability update may not be feasible
   and should be disallowed for some capabilities.  One example is the
   four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update
   could introduce ambiguity in parsing the UPDATE messages.

-- Enke

From: "Rijsman, Bruno" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: questions about draft-ietf-idr-as4bytes-04
Date: Thu, 31 Jan 2002 11:52:07 -0500
Sender: [email-masked]

I have some questions about draft-ietf-idr-as4bytes-04:

1. What's the value of AS_TRANS?  (I could not find it on the IANA web site)

2. What should a BGP speaker do when it receives an AS-PATH and a
NEW-AS-PATH
   which are inconsistent (or an AGGREGATOR and NEW-AGGREGATOR which are 
   inconsistent)?  Send a NOTIFICATION?  If so, what error code?

3. As currently specified the AS-PATH attribute can either contain 2-octet
or
   4-octet AS-numbers, depending on whether or not both sides are NEW BGP
   speakers.  The UPDATE itself does not contain enough information to
determine
   whether or not both sides are NEW or OLD BGP speakers: you have to look
   back at the history of capability negotiations for that session. In the
case
   of dynamic capability negotiation you need the whole history of the
session
   since the OPEN.  This is not a problem for BGP implementations, but I
imagine 
   this makes life difficult when decoding a trace of captured packets.  
   Would it be worthwhile to intoduce new segment types NEW-AS-SEQ,
NEW-AS-SET,
   NEW-CONFED-SEQ, and NEW-CONFED-SET specifically for 4-octet AS numbers?

From: Sathya Perla <[email-masked]>
To: [email-masked]
Subject: RE: Collision detect [Re-Posting]
Date: Tue, 29 Jan 2002 23:04:20 -0500
Sender: [email-masked]

Talking to unconfigured peers is orthogonal to the collision detection
problem. 

When a router (that doesn't talk to unconfigured peers) sees that a
connection has been initiated by a peer it doesn't recognize, it closes the
connection right there.

Note that a router that listens on the BGP_PORT can receive a connection
from any peer and then check to see if the peer is known. It may receive and
accept a connection from a configured peer just at the time it succeeds in
initiating a connection to the same peer -- causing a double connection.

So, I feel it'll help to have some text about resolving a collision both
with the one/two FSM schemes. The catch is that the spec. assumes the usage
of 2 FSMs as it requires a "FSM Cease" to close a transport connection. So,
the 1-FSM scheme will have to remain a "hack" in a way, as it ignores the
"FSM Cease"....

-Sathya

-----Original Message-----
From: Eric Leisheng Ji [mailto:[email-masked]]

On Tue, 29 Jan 2002, Jeffrey Haas wrote:

> On Tue, Jan 29, 2002 at 12:41:16PM -0800, Alex Zinin wrote:
> > BTW, when you receive an incoming transport connection
> > from an unconfigured peer first time, I guess the peer
> > lookup will fail, which means you don't have an outstanding
> > transport connection, and hence no risk for collision,
> > correct?
> 
> Right.  But if you initiate a connection and then the unconfigured peer
> drops its transport session and quickly re-establishes it, you could.
> 

That may happen if the unconfigured peer just drop the connection
and wait for the initial peer to tcp-timeout. Can we deal it this 
way, whenever one incoming connection comes, the bgp instance 
will check the configured peer list. If no one match, bgp instance
will EXPLICITLY close that connection. That way no collision is
created, under the precondition that the multithread schedule 
doesnt interrupt and deal with new connection in this accept-close 
time interval. 
Though in real implementation, I think it's very rare for this
to happen.

Thanks,
> > Alex.
> 
> -- 
> Jeff Haas 

Date: Tue, 29 Jan 2002 20:58:31 -0600
From: Eric Leisheng Ji <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

On Tue, 29 Jan 2002, Jeffrey Haas wrote:

> On Tue, Jan 29, 2002 at 12:41:16PM -0800, Alex Zinin wrote:
> > BTW, when you receive an incoming transport connection
> > from an unconfigured peer first time, I guess the peer
> > lookup will fail, which means you don't have an outstanding
> > transport connection, and hence no risk for collision,
> > correct?
> 
> Right.  But if you initiate a connection and then the unconfigured peer
> drops its transport session and quickly re-establishes it, you could.
> 

That may happen if the unconfigured peer just drop the connection
and wait for the initial peer to tcp-timeout. Can we deal it this 
way, whenever one incoming connection comes, the bgp instance 
will check the configured peer list. If no one match, bgp instance
will EXPLICITLY close that connection. That way no collision is
created, under the precondition that the multithread schedule 
doesnt interrupt and deal with new connection in this accept-close 
time interval. 
Though in real implementation, I think it's very rare for this
to happen.

Thanks,
> > Alex.
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 

Date: Tue, 29 Jan 2002 12:59:12 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

>> BTW, when you receive an incoming transport connection
>> from an unconfigured peer first time, I guess the peer
>> lookup will fail, which means you don't have an outstanding
>> transport connection, and hence no risk for collision,
>> correct?

> Right.  But if you initiate a connection and then the unconfigured peer
> drops its transport session and quickly re-establishes it, you could.

I guess when you receive that second connection, you either have
a peer structure for this guy already and hence deal with it
as you would do with a configured peer, or you do not have the
peer structure and hence there's no outstanding connection...
What am I missing?

Alex.

Date: Tue, 29 Jan 2002 15:46:07 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

On Tue, Jan 29, 2002 at 12:41:16PM -0800, Alex Zinin wrote:
> BTW, when you receive an incoming transport connection
> from an unconfigured peer first time, I guess the peer
> lookup will fail, which means you don't have an outstanding
> transport connection, and hence no risk for collision,
> correct?

Right.  But if you initiate a connection and then the unconfigured peer
drops its transport session and quickly re-establishes it, you could.

> Alex.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 29 Jan 2002 12:41:16 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

Jeff:

> Do they support unconfigured peers?

Those that I've worked with do not.

BTW, when you receive an incoming transport connection
from an unconfigured peer first time, I guess the peer
lookup will fail, which means you don't have an outstanding
transport connection, and hence no risk for collision,
correct?

> The FSM text, even in its more current form, seems to not deal with
> unconfigured peers very well.

Agreed. That's why I thought it was a good idea to have
a section on processing incoming transport connections
and introduced it in my version of FSM.

Alex.

Date: Tue, 29 Jan 2002 15:02:40 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

On Mon, Jan 28, 2002 at 06:19:52PM -0800, Alex Zinin wrote:
> I thought we wanted the spec to be as close to reality
> as possible and there seemed to be sufficient number
> of people on the list saying they don't use the two-fsm
> method...

Do they support unconfigured peers?

The FSM text, even in its more current form, seems to not deal with
unconfigured peers very well.

> Alex.

-- 
Jeff Haas 
NextHop Technologies

Date: 29 Jan 2002 10:00:07 -0000
From: "Raghavendran  Gururajan" <[email-masked]>
Reply-To: "Raghavendran  Gururajan" <[email-masked]>
To: [email-masked]
Subject: Reg. Extended Communities Attribute
Sender: [email-masked]

Hi,

The BGP communities rfc (1997) talks clearly about what is to be done for communities during aggregation.
"If a range of routes is to be aggregated and the resultant aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a COMMUNITIES path attribute
which contains all communities from all of the aggregated routes."

But the Extended communities draft (draft-ietf-idr-bgp-ext-communities-02.txt) doesnot talk about aggregation.

Should the Extended communities also be aggregated or should they be dropped during aggregation as they are transitive optional attribute ? 
Can anyone clarify.

Thanks,
Raghavendran. 

Date: Mon, 28 Jan 2002 18:19:52 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

Jeff:

> Although it doesn't necessarily require it, IMO, the two-fsm
> model seems to more cleanly fit the current text.

I thought we wanted the spec to be as close to reality
as possible and there seemed to be sufficient number
of people on the list saying they don't use the two-fsm
method...

Alex.

Date: Mon, 28 Jan 2002 11:42:23 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

Gentles,

Please trim your headers when replying.

On Sun, Jan 27, 2002 at 02:30:34PM -0600, Eric Leisheng Ji wrote:
> Yes, if the new spec can list both of them for
> applicable considerations, that's more clear.
> 
> Both schemes should work fine, but the two FSM
> scheme may need more coding work than one FSM
> scheme. It's not a big deal if only one can get
> clear picture from rfc.

In both the one and two-fsm model, you have to have access to the
state of the fsm's running across all of your bgp instances
that share common resources.  This is mostly to know what
state the "other" fsm (other connection) is in.

Although it doesn't necessarily require it, IMO, the two-fsm
model seems to more cleanly fit the current text.

> --Eric Ji

-- 
Jeff Haas 
NextHop Technologies

Date: Sun, 27 Jan 2002 22:10:24 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Russ White <[email-masked]>
Cc: Russ White <[email-masked]>, Sathya Perla <[email-masked]>, "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>, <[email-masked]>
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

> I would agree with this approcach. Do we need text?

Yeah, let's wait to see what people say about this
to make sure we have a consensus on the approach
and then we would need the actual text...

Alex.

Date: Sun, 27 Jan 2002 20:47:47 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Sathya Perla <[email-masked]>, "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>, [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

I would agree with this approcach. Do we need text?

:-)

Russ

On Sat, 26 Jan 2002, Alex Zinin wrote:

> I had a similar idea as well, 'cause the new spec should
> cover deployed implementations with collision detection
> implemented both ways (unless the two-FSM way is completely
> broken, which is not the case, I believe).
> 
> However, I think we should provide sufficient information
> in the spec for guys implementing it from scratch to figure
> out what really should be done. Since both ways seem to
> work fine together (anyone correct me if I'm wrong here),
> it might work if we document both the algorithm from
> the spec and the one-FSM algorithm (seems to be that we
> already have at least three of four of its implementations)
> as *possible* approaches. What do you think?
> 
> -- 
> Alex Zinin
> 
> Saturday, January 26, 2002, 5:02:16 AM, Russ White wrote:
> 
> 
> > It actually (probably) doesn't matter what the majority is--the
> > spec should (probably) be written in such a way to make it
> > obvious that you are trying to prevent two connections, and leave
> > out anything that implies whether this means you use two fsm's or
> > one.
> 
> > Cisco uses one fsm.
> 
> > :-)
> 
> > Russ
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Sun, 27 Jan 2002 14:30:34 -0600
From: Eric Leisheng Ji <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Russ White <[email-masked]>, Russ White <[email-masked]>, Sathya Perla <[email-masked]>, "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>, [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

Yes, if the new spec can list both of them for
applicable considerations, that's more clear.

Both schemes should work fine, but the two FSM
scheme may need more coding work than one FSM
scheme. It's not a big deal if only one can get
clear picture from rfc.

--Eric Ji

On Sat, 26 Jan 2002, Alex Zinin wrote:

> I had a similar idea as well, 'cause the new spec should
> cover deployed implementations with collision detection
> implemented both ways (unless the two-FSM way is completely
> broken, which is not the case, I believe).
> 
> However, I think we should provide sufficient information
> in the spec for guys implementing it from scratch to figure
> out what really should be done. Since both ways seem to
> work fine together (anyone correct me if I'm wrong here),
> it might work if we document both the algorithm from
> the spec and the one-FSM algorithm (seems to be that we
> already have at least three of four of its implementations)
> as *possible* approaches. What do you think?
> 
> -- 
> Alex Zinin
> 
> Saturday, January 26, 2002, 5:02:16 AM, Russ White wrote:
> 
> 
> > It actually (probably) doesn't matter what the majority is--the
> > spec should (probably) be written in such a way to make it
> > obvious that you are trying to prevent two connections, and leave
> > out anything that implies whether this means you use two fsm's or
> > one.
> 
> > Cisco uses one fsm.
> 
> > :-)
> 
> > Russ
> 
> 

Date: Sat, 26 Jan 2002 18:51:29 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Russ White <[email-masked]>
Cc: Russ White <[email-masked]>, Sathya Perla <[email-masked]>, "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>, <[email-masked]>
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

I had a similar idea as well, 'cause the new spec should
cover deployed implementations with collision detection
implemented both ways (unless the two-FSM way is completely
broken, which is not the case, I believe).

However, I think we should provide sufficient information
in the spec for guys implementing it from scratch to figure
out what really should be done. Since both ways seem to
work fine together (anyone correct me if I'm wrong here),
it might work if we document both the algorithm from
the spec and the one-FSM algorithm (seems to be that we
already have at least three of four of its implementations)
as *possible* approaches. What do you think?

-- 
Alex Zinin

Saturday, January 26, 2002, 5:02:16 AM, Russ White wrote:

> It actually (probably) doesn't matter what the majority is--the
> spec should (probably) be written in such a way to make it
> obvious that you are trying to prevent two connections, and leave
> out anything that implies whether this means you use two fsm's or
> one.

> Cisco uses one fsm.

> :-)

> Russ

Date: Sat, 26 Jan 2002 08:02:16 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Sathya Perla <[email-masked]>, "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>, [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

It actually (probably) doesn't matter what the majority is--the
spec should (probably) be written in such a way to make it
obvious that you are trying to prevent two connections, and leave
out anything that implies whether this means you use two fsm's or
one.

Cisco uses one fsm.

:-)

Russ

On Fri, 25 Jan 2002, Alex Zinin wrote:

> 
> Sathya,
> 
>   In fact, that was one of my concerns about the spec.
> 
>   Regardless of whether we stay with the two-FSMs based scheme
>   or move to two transport connections under one, I think
>   we should have a section on processing of incoming transport
>   connection (I actually have it in my version of the FSM I sent
>   to the list a while ago).
> 
>   From my knowledge, at least some major implementations do not
>   treat competing connections as different FSMs. Whether they
>   make the majority or not is something that we should probably
>   ask the WG chairs to check.
> 
> -- 
> Alex Zinin
> 
> Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote:
> 
> 
> > I think the fundamental problem with Collision Detection is that the spec
> > assumes (without stating it explicitly) that there are two FSMs to deal with
> > the possible two transport connections between a pair of peers. This is
> > evident from the usage of "FSM Cease" to close a transport connection. 
> 
> > One could manage both the transport connections using the same FSM and after
> > the collision detect algorithm is run the "unwanted" transport connection
> > can be closed without requiring a "FSM Cease".
> 
> > If this is not OK, the draft should explicitly state that a separate FSM has
> > to be used for a second connection with the same peer.
> 
> > -Sathya
> 
> 
> > -----Original Message-----
> > From: Kunihiro Ishiguro [mailto:[email-masked]]
> > Sent: Wednesday, January 23, 2002 7:36 AM
> > To: Mathew Richardson
> > Cc: [email-masked]
> > Subject: Re: Collision detect
> 
> 
> >>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
> >>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
> >>t1: BoxA accepts incoming connection from BoxB
> >>t1: BoxB accepts incoming connection from BoxA
> >>t2: BoxA sends an Open message on connection 1
> >>t2: BoxB sends an Open message on connection 2
> 
> > When BoxA accept incoming connection 2 from BoxB, BoxA lookup
> > corresponding status and it is Connect for connection 1.  Here we have
> > a problem.  If BoxA decides which connection should be closed at this
> > moment, BoxB will do the same thing.  Then both connection will be
> > closed.  OK, to avoid this situation collision detect should be done
> > by Open message then take one of them based upon router-id.  (In my
> > very private opinion, if jitter is there this will not happen
> > frequently).  Until that time the both connections should be
> > maintained.
> 
> > BTW, here is my question, when BoxA sends an Open message to BoxB
> > (t2).  BoxA has two connections.  Connection 1 is OpenSent status.
> > Connection 2 will be Connect status.  But where connection 2 status
> > comes from?  Is that generated based upon Connection 1 status?  It is
> > very ambiguous in RFC and draft description.  Initially the peer has
> > only one status.  Some moment the peer has two connections and two
> > independent status.  Finally collision detect close one connection.
> > The status related the connection also goes away.
> 
> > When I implemented BGP this was the biggest obstacle to understand FSM
> > and collision detect.  Still description is not clear.  Should we fix
> > this also?
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Fri, 25 Jan 2002 19:24:50 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: randy Bush <[email-masked]>, [email-masked], [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Sue,

 Agreed, thanks!

-- 
Alex Zinin

Friday, January 25, 2002, 2:48:02 PM, Susan Hares wrote:

> Alex:

> Thanks for the comments on the draft.  I think
> I've got the fix for this in my current version.
> I'm sending it off the list so we can talk.

> Sue

Date: Fri, 25 Jan 2002 17:13:15 -0600
From: Eric Leisheng Ji <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Sathya Perla <[email-masked]>, "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>, [email-masked]
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

I think Sathya's idea is applicable. In our implementation of
BGP in company, we try to follow the RFC, but get a little 
lost there about the FSMs, for we use only one FSM and two
connections.  
So we still follow the RFC, but under the situation of
collision detection, the received Notification Packet are
just ignored. So it's equal to no sending this.
I didnt' get the previous emails on this question, but it
seems to me a problem how do we indicate the peer state 
under the picture of one FSM and two connections? we should
make sure the two connections dont race to set the FSM
peer state.

--Eric Ji

On Fri, 25 Jan 2002, Alex Zinin wrote:

> 
> Sathya,
> 
>   In fact, that was one of my concerns about the spec.
> 
>   Regardless of whether we stay with the two-FSMs based scheme
>   or move to two transport connections under one, I think
>   we should have a section on processing of incoming transport
>   connection (I actually have it in my version of the FSM I sent
>   to the list a while ago).
> 
>   From my knowledge, at least some major implementations do not
>   treat competing connections as different FSMs. Whether they
>   make the majority or not is something that we should probably
>   ask the WG chairs to check.
> 
> -- 
> Alex Zinin
> 
> Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote:
> 
> 
> > I think the fundamental problem with Collision Detection is that the spec
> > assumes (without stating it explicitly) that there are two FSMs to deal with
> > the possible two transport connections between a pair of peers. This is
> > evident from the usage of "FSM Cease" to close a transport connection. 
> 
> > One could manage both the transport connections using the same FSM and after
> > the collision detect algorithm is run the "unwanted" transport connection
> > can be closed without requiring a "FSM Cease".
> 
> > If this is not OK, the draft should explicitly state that a separate FSM has
> > to be used for a second connection with the same peer.
> 
> > -Sathya
> 
> 
> > -----Original Message-----
> > From: Kunihiro Ishiguro [mailto:[email-masked]]
> > Sent: Wednesday, January 23, 2002 7:36 AM
> > To: Mathew Richardson
> > Cc: [email-masked]
> > Subject: Re: Collision detect
> 
> 
> >>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
> >>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
> >>t1: BoxA accepts incoming connection from BoxB
> >>t1: BoxB accepts incoming connection from BoxA
> >>t2: BoxA sends an Open message on connection 1
> >>t2: BoxB sends an Open message on connection 2
> 
> > When BoxA accept incoming connection 2 from BoxB, BoxA lookup
> > corresponding status and it is Connect for connection 1.  Here we have
> > a problem.  If BoxA decides which connection should be closed at this
> > moment, BoxB will do the same thing.  Then both connection will be
> > closed.  OK, to avoid this situation collision detect should be done
> > by Open message then take one of them based upon router-id.  (In my
> > very private opinion, if jitter is there this will not happen
> > frequently).  Until that time the both connections should be
> > maintained.
> 
> > BTW, here is my question, when BoxA sends an Open message to BoxB
> > (t2).  BoxA has two connections.  Connection 1 is OpenSent status.
> > Connection 2 will be Connect status.  But where connection 2 status
> > comes from?  Is that generated based upon Connection 1 status?  It is
> > very ambiguous in RFC and draft description.  Initially the peer has
> > only one status.  Some moment the peer has two connections and two
> > independent status.  Finally collision detect close one connection.
> > The status related the connection also goes away.
> 
> > When I implemented BGP this was the biggest obstacle to understand FSM
> > and collision detect.  Still description is not clear.  Should we fix
> > this also?
> 
> 

Date: Fri, 25 Jan 2002 17:48:02 -0500
To: Alex Zinin <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: Susan Hares <[email-masked]>, randy Bush <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Alex:

Thanks for the comments on the draft.  I think
I've got the fix for this in my current version.
I'm sending it off the list so we can talk.

Sue

At 11:34 AM 1/17/2002 -0800, Alex Zinin wrote:

>Sue,
>
> > 1) Thanks for your note.
>
> >    Glad you think the bgp exponential back off is good.
>
> >    We should get operator input to answer questions in #3.
> >    I want to go with whatever the operator community has
> >    deployed for this draft.
>
>OK.
>
> > 2) State machine text clean up was more than
> >     the Idle Hold state
>
> >   Just to let you know the FSM text was tighted up based on the
> >   word document with the diagram I sent out.  There were other
> >   inconsistencies in the FSM that I fixed based on the states
> >   not being consistent with this diagram.
>
>I understand, I meant the text about exp. back-off specifically
>should be all right.
>
> >   I will generate the state machine table without
> >   the idle hold state to indicate those differences first.
> >   [Warning - this plus the 2 other state machines you
> >   sent me to review will take me a while.  Warning -- day turnaround
> >   most likely]
>
>All right, thanks. I think I'll send my version out to the list
>today to get the feeling of what people think.
>
> > 3)bgp exponential back-off
>
>[stuff for SPs ;) ]
>
> > 4) comparing all your input --- still processing
>
> > I am plugging through the 2 versions of state
> > machine you sent.   Did you send me a review
> > of the diagram (word document) I'm attaching again.
>
> > I didn't find that even though you mentioned
> > you had done it.   Did I miss it?  That would
> > speed up this process since a 5 page form is quicker to
> > review and glance over.
>
>Sue, I've briefly gone through several states in
>the table and had some questions and bugs:
>
>Event 3 (IdleHold expired, value under ceiling): I think this
>         event should be ignored in Idle and higher
>
>Idle x 3: "FSM Error" is not an action, is it?
>
>Event 4: This event should be ignored in Idle and higher as well
>
>Connect x 7: There's no associated transport session yet,
>         the event should be ignored
>
>OpenSent x 8: Ignore here?
>
>Event 9: Should be Rcv TCP Connect & peer accepted
>
>Connect x 9: Why incoming connection resets the FSM here?
>
>OpenSent x 9: Ignore here?
>
>Event 10: Should be Rcv TCP Connect & peer rejected
>
>Connect x 10: Why incoming connection resets the FSM here?
>
>OpenSent x 10: Ignore here?
>
>Connect x 11: Hold timer is not running here, ignore?
>
>Idle x 12: Idle here?
>
>Connect x 12: Events from here down should be ignored?
>
>IdleHold x 22: Should it be ignored and stay in IdleHold?
>
>Idle x 23: Idle/Ignore here?
>
>And probably the major one: there's no event that causes
>OpenSent->OpenConfirmed transition... Here I stopped.
>You should probably take another look and see if the
>table is generated correctly.
>
>Thanks.
>
>Alex.

Date: Fri, 25 Jan 2002 16:50:38 -0500
To: Alain Durand <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IPv6 Router ID draft
Cc: Francis Dupont <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Sender: [email-masked]

Did this get used in any KAME or other IP v6 trials?

Sue

At 10:47 AM 1/25/2002 -0800, Alain Durand wrote:
>Francis Dupont wrote:
>
> >  In your previous mail you wrote:
> >
> >    For a BCP, doesn't it have to be well-deployed first?
> >
> > => this is a chicken and egg problem: if it is not published,
> > then it is not yet known, then it can't be well-deployed.
> > I have a proof of the first consequence by a mail in the zebra list:
> > "I am IPv6 only, what may I put in the config for the router-ID?"
>
>I just checked what RFC2026 says  on BCP:
>
>5.  BEST CURRENT PRACTICE (BCP) RFCs
>
>    The BCP subseries of the RFC series is designed to be a way to
>    standardize practices and the results of community deliberations.  A
>    BCP document is subject to the same basic set of procedures as
>    standards track documents and thus is a vehicle by which the IETF
>    community can define and ratify the community's best current thinking
>
>    on a statement of principle or on what is believed to be the best way
>
>    to perform some operations or IETF process function.
>
>==> The key sentece here is "ratify the community's best current
>thinking"
>          This indicates to me that BCP is the right approach.
>
>     - Alain.

Date: Fri, 25 Jan 2002 12:25:42 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Sathya Perla <[email-masked]>
Cc: "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>, <[email-masked]>
Subject: Re: Collision detect [Re-Posting]
Sender: [email-masked]

Sathya,

  In fact, that was one of my concerns about the spec.

  Regardless of whether we stay with the two-FSMs based scheme
  or move to two transport connections under one, I think
  we should have a section on processing of incoming transport
  connection (I actually have it in my version of the FSM I sent
  to the list a while ago).

  From my knowledge, at least some major implementations do not
  treat competing connections as different FSMs. Whether they
  make the majority or not is something that we should probably
  ask the WG chairs to check.

-- 
Alex Zinin

Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote:

> I think the fundamental problem with Collision Detection is that the spec
> assumes (without stating it explicitly) that there are two FSMs to deal with
> the possible two transport connections between a pair of peers. This is
> evident from the usage of "FSM Cease" to close a transport connection. 

> One could manage both the transport connections using the same FSM and after
> the collision detect algorithm is run the "unwanted" transport connection
> can be closed without requiring a "FSM Cease".

> If this is not OK, the draft should explicitly state that a separate FSM has
> to be used for a second connection with the same peer.

> -Sathya

> -----Original Message-----
> From: Kunihiro Ishiguro [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2002 7:36 AM
> To: Mathew Richardson
> Cc: [email-masked]
> Subject: Re: Collision detect

>>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
>>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
>>t1: BoxA accepts incoming connection from BoxB
>>t1: BoxB accepts incoming connection from BoxA
>>t2: BoxA sends an Open message on connection 1
>>t2: BoxB sends an Open message on connection 2

> When BoxA accept incoming connection 2 from BoxB, BoxA lookup
> corresponding status and it is Connect for connection 1.  Here we have
> a problem.  If BoxA decides which connection should be closed at this
> moment, BoxB will do the same thing.  Then both connection will be
> closed.  OK, to avoid this situation collision detect should be done
> by Open message then take one of them based upon router-id.  (In my
> very private opinion, if jitter is there this will not happen
> frequently).  Until that time the both connections should be
> maintained.

> BTW, here is my question, when BoxA sends an Open message to BoxB
> (t2).  BoxA has two connections.  Connection 1 is OpenSent status.
> Connection 2 will be Connect status.  But where connection 2 status
> comes from?  Is that generated based upon Connection 1 status?  It is
> very ambiguous in RFC and draft description.  Initially the peer has
> only one status.  Some moment the peer has two connections and two
> independent status.  Finally collision detect close one connection.
> The status related the connection also goes away.

> When I implemented BGP this was the biggest obstacle to understand FSM
> and collision detect.  Still description is not clear.  Should we fix
> this also?

From: Tony Li <[email-masked]>
Date: Fri, 25 Jan 2002 11:23:42 -0800
To: Alain Durand <[email-masked]>
Cc: Francis Dupont <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: IPv6 Router ID draft
Sender: [email-masked]

It seems to me that it needs to be a 'practice' before it can reasonably be
the 'best current' practice.

Tony

Date: Fri, 25 Jan 2002 10:47:35 -0800
From: Alain Durand <[email-masked]>
To: Francis Dupont <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: IPv6 Router ID draft
Sender: [email-masked]

Francis Dupont wrote:

>  In your previous mail you wrote:
>
>    For a BCP, doesn't it have to be well-deployed first?
>
> => this is a chicken and egg problem: if it is not published,
> then it is not yet known, then it can't be well-deployed.
> I have a proof of the first consequence by a mail in the zebra list:
> "I am IPv6 only, what may I put in the config for the router-ID?"

I just checked what RFC2026 says  on BCP:

5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking

   on a statement of principle or on what is believed to be the best way

   to perform some operations or IETF process function.

==> The key sentece here is "ratify the community's best current
thinking"
         This indicates to me that BCP is the right approach.

    - Alain.

Date: Fri, 25 Jan 2002 10:56:32 -0500
From: Jeffrey Haas <[email-masked]>
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked]
Subject: Re: Route Reflectors
Sender: [email-masked]

>From RFC 2796:
: When a RR reflects a route, it must prepend the local CLUSTER_ID to
: the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it must create a new
: one. Using this attribute an RR can identify if the routing
: information is looped back to the same cluster due to mis-
: configuration. If the local CLUSTER_ID is found in the cluster-list,
: the advertisement received should be ignored.

In other words, it must always prepend the cluster_id when it reflects
a route.

On Thu, Jan 24, 2002 at 09:15:02PM -0800, Mareline Sheldon wrote:
> Hi,
> Whenever a RR reflects a route from its clients to a
> non client, it must create a new cluster list adding
> its own cluster ID if it is already not present.
> 
> My doubt is that will RR add its cluster ID when it
> receives a route from its EBGP peer and is now
> advertising this route to its other non
> clients/clients?
> 
> Regards,
> mareline s.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 25 Jan 2002 10:53:04 -0500
From: Jeffrey Haas <[email-masked]>
To: Alain Durand <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: IPv6 Router ID draft
Sender: [email-masked]

For a BCP, doesn't it have to be well-deployed first?

On Wed, Jan 16, 2002 at 11:18:48AM -0800, Alain Durand wrote:
> I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> and I would like to request this working group to consider it as
> a wg item candidate for BCP.
> 
>     - Alain.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 24 Jan 2002 21:15:02 -0800 (PST)
From: Mareline Sheldon <[email-masked]>
Subject: Route Reflectors
To: [email-masked]
Sender: [email-masked]

Hi,
Whenever a RR reflects a route from its clients to a
non client, it must create a new cluster list adding
its own cluster ID if it is already not present.

My doubt is that will RR add its cluster ID when it
receives a route from its EBGP peer and is now
advertising this route to its other non
clients/clients?

Regards,
mareline s.

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

From: Sathya Perla <[email-masked]>
To: "'Kunihiro Ishiguro'" <[email-masked]>, Mathew Richardson <[email-masked]>
Cc: [email-masked]
Subject: RE: Collision detect [Re-Posting]
Date: Wed, 23 Jan 2002 22:18:21 -0500
Sender: [email-masked]

I think the fundamental problem with Collision Detection is that the spec
assumes (without stating it explicitly) that there are two FSMs to deal with
the possible two transport connections between a pair of peers. This is
evident from the usage of "FSM Cease" to close a transport connection. 

One could manage both the transport connections using the same FSM and after
the collision detect algorithm is run the "unwanted" transport connection
can be closed without requiring a "FSM Cease".

If this is not OK, the draft should explicitly state that a separate FSM has
to be used for a second connection with the same peer.

-Sathya

-----Original Message-----
From: Kunihiro Ishiguro [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 7:36 AM
To: Mathew Richardson
Cc: [email-masked]
Subject: Re: Collision detect

>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
>t1: BoxA accepts incoming connection from BoxB
>t1: BoxB accepts incoming connection from BoxA
>t2: BoxA sends an Open message on connection 1
>t2: BoxB sends an Open message on connection 2

When BoxA accept incoming connection 2 from BoxB, BoxA lookup
corresponding status and it is Connect for connection 1.  Here we have
a problem.  If BoxA decides which connection should be closed at this
moment, BoxB will do the same thing.  Then both connection will be
closed.  OK, to avoid this situation collision detect should be done
by Open message then take one of them based upon router-id.  (In my
very private opinion, if jitter is there this will not happen
frequently).  Until that time the both connections should be
maintained.

BTW, here is my question, when BoxA sends an Open message to BoxB
(t2).  BoxA has two connections.  Connection 1 is OpenSent status.
Connection 2 will be Connect status.  But where connection 2 status
comes from?  Is that generated based upon Connection 1 status?  It is
very ambiguous in RFC and draft description.  Initially the peer has
only one status.  Some moment the peer has two connections and two
independent status.  Finally collision detect close one connection.
The status related the connection also goes away.

When I implemented BGP this was the biggest obstacle to understand FSM
and collision detect.  Still description is not clear.  Should we fix
this also?
-- 
Kunihiro Ishiguro

Date: Tue, 22 Jan 2002 18:06:29 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Mathew Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: Collision detect
Sender: [email-masked]

>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
>t1: BoxA accepts incoming connection from BoxB
>t1: BoxB accepts incoming connection from BoxA
>t2: BoxA sends an Open message on connection 1
>t2: BoxB sends an Open message on connection 2

When BoxA accept incoming connection 2 from BoxB, BoxA lookup
corresponding status and it is Connect for connection 1.  Here we have
a problem.  If BoxA decides which connection should be closed at this
moment, BoxB will do the same thing.  Then both connection will be
closed.  OK, to avoid this situation collision detect should be done
by Open message then take one of them based upon router-id.  (In my
very private opinion, if jitter is there this will not happen
frequently).  Until that time the both connections should be
maintained.

BTW, here is my question, when BoxA sends an Open message to BoxB
(t2).  BoxA has two connections.  Connection 1 is OpenSent status.
Connection 2 will be Connect status.  But where connection 2 status
comes from?  Is that generated based upon Connection 1 status?  It is
very ambiguous in RFC and draft description.  Initially the peer has
only one status.  Some moment the peer has two connections and two
independent status.  Finally collision detect close one connection.
The status related the connection also goes away.

When I implemented BGP this was the biggest obstacle to understand FSM
and collision detect.  Still description is not clear.  Should we fix
this also?
-- 
Kunihiro Ishiguro

Date: Tue, 22 Jan 2002 20:19:14 -0500
From: Mathew Richardson <[email-masked]>
To: [email-masked]
Subject: Re: Collision detect
Sender: [email-masked]

> Kunihiro Ishiguro <[email-masked]> [Tue, Jan 22, 2002 at 04:18:14PM -0800]:
>I have another point of question for BGP4 specification.  When the
>local system does not allow unconfigured peer to accept.  I think the
>local system does not need collision detect.
>
>I'm not sure when the local system connect operation is not atomic.
>Any comments are welcome.

<snip>

t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
t1: BoxA accepts incoming connection from BoxB
t1: BoxB accepts incoming connection from BoxA
t2: BoxA sends an Open message on connection 1
t2: BoxB sends an Open message on connection 2

... etc ...

mrr

Date: Tue, 22 Jan 2002 16:18:14 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Subject: Collision detect
Sender: [email-masked]

I have another point of question for BGP4 specification.  When the
local system does not allow unconfigured peer to accept.  I think the
local system does not need collision detect.

I'm not sure when the local system connect operation is not atomic.
Any comments are welcome.
-- 
Kunihiro Ishiguro

Date: Tue, 22 Jan 2002 18:24:47 -0500
To: Kunihiro Ishiguro <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Comments on FSM
Cc: Alex Zinin <[email-masked]>, [email-masked], Susan Hares <[email-masked]>
Sender: [email-masked]

Kunihiro:

Thanks for the input.

Sue

At 04:54 PM 1/16/2002 -0800, Kunihiro Ishiguro wrote:
>Thanks Alex.  I've check bgp4-17 FSM.  Below new items are added.
>
>Status  : IdleHold
>Timer   : IdleHold timer
>Variable: IdleHoldtimer
>           IdleHoldtimer ceiling mentioned as "local limit"
>           ConnectRetryCnt
>Event   : Manual start
>           Auto start
>Flag    : Keep Idle
>
>Instead of IdleHold timer we should explicitly mention about Start
>timer.  It is already implicitly used in RFC1771.  It is almost same
>as IdleHold timer but hopefully does not have impact on current
>implementation.
>
>We don't need Keep Idle flag.  Instead of that just stop Start timer.
>This mechanism can be used not only exponential backoff but also
>administratively shutdown or maximum prefix overflow.  So let's keep
>it simple.

>In IdleHold state there is a description for local limit of
>IdleHoldTimer.
>
> >         Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
> >         the local limit the "Keep Idle" flag is set.
>
>This should be clearly defined.  For example StartTimer Ceiling.
>
>Difference between manual start and auto start is small.  I'm not sure
>separating Start event into Manual start event and Auto start event is
>good idea or not.  So my proposal is liek this.
>
>Status  : No new status
>Timer   : Start timer
>Variable: StartTimer
>           StartTimer Ceiling
>           Connect Retry Count
>
>(Possible addition
>Event   : Manual start
>           Auto start)
>
>IMHO, this topic needs more discussion and clarification.
>
> >Maybe the exponential backoff parts could be published as a separate draft
> >instead of including it in the base specification?
>
>I agrree with Greg.  A separate draft for exponential back off make
>sense.  I think even we have a separate draft for exponential back
>off, previous draft bgp4-16 FSM description still work fine with that.
>--
>Kunihiro Ishiguro

Date: Tue, 22 Jan 2002 15:01:21 -0800 (PST)
From: Santosh B <[email-masked]>
To: Alex Zinin <[email-masked]>, [email-masked]
Subject: Re: More thoughts on FSM
Reply-To: [email-masked]
Sender: [email-masked]

This looks good. Here are some of my suggestions:

1. State events listed in tabular format will also give
   detailed view of the FSM. So there should be a FSM diagram
   and a table.
2. I'm not sure if the naming convention used ( ev and st prefexis )  
   are required.
3. I also would like to add some interaction diagrams:

    for example:

    Speaker1                     Speaker2
    |                             |
    |     KEEPALIVE               |
    +---------------------------->+
    |                             |

4. I'm not sure if this is the right place but still want to put
   forward my suggestion. We do not have FSMs in Dampening RFC.
   We should add FSM in dampening draft as well ( and their 
   relation to BGP states if any )

Thanks

Santosh

--- Alex Zinin <[email-masked]> wrote:
>Folks,
>
> I mentioned multiple times that I'd like the FSM to
> be represented in a more formal way. Below is what
> I have in mind. It is just a scratch, by no means
> complete. I'd like to know what people think about
> the idea. If there's a common feeling that this
> would be useful, I would invest more time in it...
> 
>--
>Alex.
>
>1. Session attributes
>
>   The following attributes required for FSM operation are associated
>   with each BGP session:
>
>   State: 
>     Indicates the current state of the BGP session FSM.
>     Possible FSM states are described in Section 3.
>
>   Start timer:
>     A timer used for automatic generation of the evStart
>     event.
>   
>   ConnectRetry timer:
>     A timer used for periodic initialization of an outgoing
>     transport session when FSM is in stConnected and stActive
>     states. Expiration of this timer triggers generation of
>     the evConnectRetryExp FSM event.
>
>     NOTE: The exact value of the ConnectRetry timer is a 
>           local matter, but it should be sufficiently large 
>           to allow TCP initialization.
>
>   HoldTime:
>     Period of time negotiated between BGP peers and used to
>     detect unreachable speakers. If no UPDATE or KEEPALIVE
>     message has been received through a BGP session during
>     the HoldTime period, the remote peer is declared unreachable
>     and the session is reset.
>
>   Hold timer:
>     A one shot timer initialized with HoldTime value and
>     indicating that no valid messages have been received
>     through the BGP session. Expiration of this timer
>     triggers generation of the evHoldTimerExp FSM event.
>
>     NOTE: If the negotiated HoldTime value is zero, 
>           the Hold timer is not started.
>
>   KeepAlive timer:
>     A periodic timer used to send a KEEPALIVE message to
>     the remote BGP peer if no UPDATE message have been
>     sent to it within a period of time (the timer is reset
>     every time an UPDATE message is sent out).
>
>     NOTE: If the negotiated HoldTime value is zero, the
>           KeepAlive timer is not started.
>
>2. Events:
>
> Timer-based events:
>
>   evKeepAliveTimerExp:
>     A periodic event generated due to expiration of 
>     the KeepAlive timer. This event is processed in
>     FSM states stOpenConfirmed and stEstablished and
>     triggers transmition of a KEEPALIVE message.
>   
>   evConnectRetryExp:
>     An event triggered by expiration of the ConnectRetry
>     timer. Processed in states stConnect and stActive,
>     this event leads to initiation of an outbound transport
>     session.
>   
>   evHoldTimerExp:
>     An event generated when the session's HoldTimer expires.
>     Processed in states stOpenConfirmed and higher, this
>     event indicates that no UPDATE or KEEPALIVE messages
>     have been received from the peer and the FSM needs to
>     be reset.
>   
>
> Message-processing related events:
>
>
>   evTransSucc:
>     An event indicating that the oubound transport session
>     initiated previously has been successfully established.
>  
>   evTransFail:
>     An event indicating that the oubound transport session
>     initiated previously could not be established.     
>  
>   evTransDisc:
>     An event indicating that the transport session associated
>     with the FSM instance has been disconnected.
>  
>   evOpenMsgRcvd:
>     An event indicating that a valid OPEN message has been
>     received and no connection collision has been detected.
>   
>   evOpenMsgErr:
>     An event indicating that received OPEN messages is not
>     correct.
>  
>   evCollision:
>     An event generated when a connection collision has been
>     detected while processing an incoming OPEN message.
>     See section XXX for more information on collision detection.
>  
>   evNotifMsg:
>     An event triggered by reception of a NOTIFICATION message.
>  
>   evNotifMsgVerErr:
>     An event generated when a NOTIFICATION message with "Version
>     Error" code is received.
>  
>   evKeepAliveMsg:
>     An event generated when a KEEPALIVE message is received.
>  
>   evUpdateMsg:
>     An event indicating that an UPDATE message has been received
>  
>   evUpdateMsgErr:
>     An event indicating that received UPDATE message is not correct.
>
>  
> Administrative events:
>      
>   evStart:
>      An event initiated by an operator or the system in response
>      to Start timer expiration to initiate the BGP session 
>      establishment procedure. This event affects only sessions 
>      in the stIdle state and is ignored in others.
>
>      If this event is generated automatically, then persistent BGP 
>      errors may result in persistent flapping of a BGP session.
>      To avoid such a condition it is recommended that evStart events
>      are not generated immediately for a session that was previously
>      transitioned to stIdle due to an error. For a session that was
>      previously transitioned to stIdle due to an error, the time
>      between consecutive generation of evStart events, if such events
>      are generated automatically, should exponentially increase. The
>      value of the initial timer should be 60 seconds. The time should
>      be doubled for each consecutive retry.
>  
>   evStopManual:
>      An event initiated by an operator and indicating that the
>      BGP session should be administratively torn down.
>  
>   evStopAuto:
>      An event generated by the system to bring a BGP session down.
>      An example when this event can be generated is exceeding 
>      the maximum number of prefixes allowed for a given peer.
>  
>      XXX: we could combine evStopManual and evStopAuto in one.
>
>
>3. States 
>
> A BGP speaker creates an instance of a BGP session FSM 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. FSMs created
> for configured peers are initially put in the Idle state. See section
> XXX for more information on incoming transport connection processing.
>
> Each state is described below, including the list of processed
> and ignored events. Also, a list of actions performed when
> the FSM transitions to a specific state is provided (In-Actions).
> For some states, a list of actions performed when transitioning
> from the state is included (Out-Actions).
>
> stIdle: 
> 
>   This is the initial state of the FSM. This state is also
>   used to keep BGP sessions in the inactive state when
>   necessary. An evStart event (manual or automatic) is necessary
>   to get the FSM out of the Idle state.
>                                                            
>    Valid events   : evStart
>    Ignored events : all others
>    Ivalid events  : None
>                                              
>    In-Actions:
>
>      1. If transitioning from a higher state:
>
>           o If the associated transport connection is open, 
>             close it.
>
>           o Stop all timers except for the Start timer
>
>           o Release resources allocated for the session,
>             including invalidation of all routes possibly 
>             received from the peer
>
>      2. Start the Start timer. See Section XXX for more info.
>
> stConnect:
>  In this state, BGP has initiated an outbound transport
>  connection and is waiting for it to be completed.
>
>    Valid events   : evConnectRetryExp,  evTransSucc,
>                     evTransFail,        evStopManual,
>                     evStopAuto
>
>    Ignored events : evStart
>    Invalid events : all others
>
>    In-Actions:
>
>      1. If necessary (e.g., previous state is Idle),
>         initialize resources for the BGP session
>
>      2. Start (or restart if already running) 
>         the ConnectRetry timer.
>
>      3. Initiate a transport connection to the peer.
>
>      4. Listen (or continue listening) for a connection 
>         that may be initiated by the peer
>
> stActive:
>  In this state BGP is not actively initiating an outbound
>  transport connection, but is trying to acquire a peer 
>  by listening for and accepting an incoming one.
>
>    Valid events   : evConnectRetryExp,  evTransSucc
>                     evStopManual,       evStopAuto
>
>    Ignored events : evStart
>
>    Invalid events : all others
>
>    In-Actions:
>
>      1. If necessary, close the transport connection
>
>      2. Restart the ConnectRetry timer
>
>      3. Continue to listen for a connection that may be
>         initiated by the remote BGP peer
>
> stOpenSent:
>    In this state, the local system has sent out an OPEN
>    messages and awaits an OPEN message from the peer.
>
>      Valid events   : evOpenMsgRcvd,     evNotifMsg,
>                       evStopManual,      evStopAuto 
>                       evHoldTimerExp
>
>      Ignored events : evStart
>
>      Invalid events : all others
>
>      In-Actions:
>
>        1. Stop the ConnectRetry timer
>
>        2. Complete session initialization (don't know
>           what this really means spec-wise)
>
>        3. Send an OPEN message to the peer
>
>        4. Set Hold timer to a large value (see note below)
>
>        5. Stop listening for an incoming transort connection
>
>        NOTE: A hold timer value of 4 minutes is suggested.
>
>
> stOpenConfirm:
>    In this state, the local system has received an OPEN message
>    from the peer, confirmed its reception by sending out
>    a KEEPALIVE message, and awaits an incoming KEEPALIVE message
>    confirming that the remote peer received the OPEN message
>    sent before, or an icoming NOTIFICATION message reporting
>    a problem.
>    
>      Valid events   : evKeepAliveTimerExp, evKeepAliveMsg
>                       evCollision,         evNotifMsg,
>                       evStopManual,        evStopAuto,
>                       evHoldTimerExp
>
>      Ignored events : evStart
>
>      Invalid events : all others
>
>      In-Actions:
>
>        1. Send a KEEPALIVE message
>        2. Set the KeepAlive timer (see note below)
>        3. Set the Hold timer according to the negotiated
>           value (see section 4.2 and note below)
>
>        NOTE: If the negotiated Hold time value is zero, then the Hold
>        and KeepAlive timers are not started.   If the value of 
>        the Autonomous System field is the same as the local Autonomous
>        System number, then the connection is an "internal" connection;
>        otherwise, it is an "external" connection.   (This will impact
>        UPDATE processing as described below.)
>
> stEstablished:
>    This is the most advanced state of the FSM.
>    In the Established state, BGP can exchange UPDATE, NOTFICATION,
>    and KEEPALIVE messages with its peer.
>
>      Valid events   : evKeepAliveTimerExp, evNotifMsg,
>                       evKeepAliveMsg,      evUpdateMsg,
>                       evUpdateMsgErr,      evStopManual,
>                       evStopAuto,          evHoldTimerExp
>
>      Ignored events : evStart
>
>      In-Actions: No standard actions
>
>
>4. Incoming transport connection processing
>
>   When an incoming connection is detected, the system
>   performs the following steps:
>
>     o Look up an existing instance of the session FSM,
>       using the remote IP addresses as the key.
>
>     o If the BGP session is not found:
>
>         - If the system is configured to not allow BGP 
>           connections with unconfigured peers, reject
>           the connection.
>           
>         - Otherwise, create a new instance of FSM,
>           set the FSM state to stActive (without performing
>           In-Actions for stActive) and generate evTransSucc
>           event.
>
>     o Otherwise (the session is found), processing depends
>       on the state of the existing FSM:
>
>         - If state is stIdle, reject the incoming connection
>           (No incoming connections are allowed in the stIdle
>           state.)
>
>         - If state is stConnected, accept the incoming connection,
>           create a new instance of FSM, set the FSM state to 
>           stActive (without performing In-Actions for stActive)
>           and generate evTransSucc event.
>
>           /* I don't believe in this, but the spec treats
>            * competing connections as seperate BGP sessions
>            */ 
>         
>         - If state is stActive, accept the incoming connection,
>           associate it with the existing session and generate
>           the evTransSucc FSM event.
>
>         - Otherwise (the FSM state is none of the above),
>           reject the incoming connection.
>           
>           /* We could also generate an event here, but that
>            * would cause an FSM restart
>            */
>
>   While in stConnected, a BGP speaker can initiate an outbound
>   connection and accept an incoming one (this specification
>   treats these connections as separate BGP sessions). 
>   See section XXX for more information on how the situation
>   of connection collision is handled.
>
>5. Event processing and state transitions
>
>   FSM operation is described below as follows. All state transitions
>   are grouped by the initial FSM state. For each state, event 
>   processing rules with associated actions are described. 
>
>
>State: stIdle
>-------------
>    
>     Event     : evStart
>     New State : stConnect 
>     Actions   : Standard stConnect In-Actions
>
>     All other events are ignored.
>
>    
>State: stConnect
>----------------
>           
>     Event     : evTransSucc
>     New State : stOpenSent
>     Actions   : Standard stOpenSent In-Actions
>           
>    
>     Event     : evTransFail
>     New State : stActive
>     Actions   : Standard stActive In-Actions
>    
>    
>     Event     : evConnectRetryExp
>     New State : stConnect
>     Actions   : Standard stConnect In-Actions
>           
>    
>     Event     : invalid events
>     New State : stIdle
>     Actions   : Standard stIdle In-Actions.
>
>
>     All other events are ignored.
> 
>
>State: stActive
>---------------
>    
>     Event     : evTransSucc
>     New State : stOpenSent
>     Actions   : Standard stOpenSent In-Actions
>    
>     Event     : evConnectRetryExp
>     New State : stConnect
>     Actions   : Standard stConnect In-Actions
>               
>     Event     : invalid events
>     New State : stIdle
>     Actions   : Standard stIdle In-Actions
>    
>     All other events are ignored.
> 
>State: stOpenSent
>-----------------       
>    
>     Event     : evOpenMsgErr, evCollision
>     New State : stIdle
>     Actions   : Standard stIdle In-Actions
>           
>    
>     Event     : evOpenMsgRcvd
>     New State : stOpenConfirm
>     Actions   : Standard stOpenConfirm In-Actions
>           
>    
>     Event     : evTransDisc
>     New State : stActive
>     Actions   : Standard stActive In-Actions
>           
>    
>     Event     : evHoldTimerExp
>     New State : stIdle
>     Actions   :
>                 1. Send a NOTIFICATION message with error code 
>                    "Hold Timer Expired"
>                 2. Standard stIdle In-Actions
>    
>     Event     : evNotifMsgVerErr
>     New State : stIdle
>     Actions   : Standard stIdle In-Actions
>           
>     
>     Event     : evNotifMsg, and others
>     New State : stIdle
>     Actions   : Standard stIdle In-Actions
>           
>     All other events are ignored.
> 
>
>
>State: stOpenConfirmed
>----------------------
>
>     Event     : evKeepAliveMsg
>     New State : stEstablished
>     Actions   : none
>    
>     Event     : evHoldTimerExp
>     New State : stIdle
>     Actions   :
>                 1. Send a NOTIFICATION message with the error 
>                    code "Hold Timer Expired"
>                 2. Standard stIdle In-Actions
>    
>     Event     : evNotifMsg, evTransDisc
>     New State : stIdle
>     Actions   : Standard stIdle In-Actions
>    
>    
>     Event     : evStopAuto
>     New State : stIdle
>     Actions   :
>                 1. Send a NOTIFICATION message with the error 
>                    code "Cease"
>                 2. Standard stIdle In-Actions
>    
>    
>     Event     : evStopManual
>     New State : stIdle
>     Actions   :
>                 1. Send a NOTIFICATION message with the error 
>                    code "Cease"
>                 2. Standard stIdle In-Actions
>
>                 
>     Event     : invalid events
>     New State : stIdle
>     Actions   :
>                 1. Send a NOTIFICATION message with the error 
>                    code "FSM Error"
>                 2. Standard stIdle In-Actions
>               
>     All other events are ignored.
> 
>State: stEstablished
>--------------------
>
>     Event     : evKeepAliveMsg, evUpdateMsg
>     New State : stEstablished
>     Actions   : 
>                 Restart the Hold timer, if the negotiated Hold Time 
>                 value is non-zero.
>    
>     Event     : evNotifMsg, evTransDisc
>     New State : stIdle
>     Actions   : Standard stIdle In-Actions
>    
>    
>     Event     : evUpdateMsgErr
>     New State : stIdle
>     Actions   : 
>                 1. Send a NOTIFICATION message with the error 
>                    code "Update Error"
>                 2. Standard stIdle In-Actions
>    
>    
>     Event     : evUpdateMsgErr
>     New State : stIdle
>     Actions   : 
>                1. Send a NOTIFICATION message with the error 
>                   code "Hold Timer Expired"
>                2. Standard stIdle In-Actions
>    
>    
>     Event     : evKeepAliveTimerExp
>     New State : stEstablished
>     Actions   : 
>                1. Send a KEEPALIVE message
>                2. Restart the KeepAlive timer, unless the negotiated 
>                   Hold Time value is zero.
>    
>    
>     Event     : evStopAuto
>     New State : stIdle
>     Actions   : 
>                1. Send a NOTIFICATION message with the error 
>                   code "Cease"
>                2. Standard stIdle In-Actions
>                3. Deletes all routes (in stIdle In-Actions already)
>    
>    
>     Event     : evStopManual
>     New State : stIdle
>     Actions   : 
>                1. Send a NOTIFICATION message with the error
>                   code "Cease" ??? (it was not in Sue's FSM)
>                2. Standard stIdle In-Actions
>    
>    
>     Event     : invalid events
>     New State : stIdle
>     Actions   :
>                1. Send a NOTIFICATION message with the error 
>                   code "FSM Error"
>                2. Standard stIdle In-Actions
>                3. Deletes all routes (in stIdle In-Actions already)
>    
>     All other events are ignored.
> 
>
>*Incomplete* state transition diagram below.
>Only main state transitions are shown.
>
>
>                               +---------+
>                  evStart      |         |
>                      +--------|  Idle   |
>                      |        |         |
>                      |        +---------+
>                      |
>                      | 
>                      v        
>                +---------+    evTransFail     +---------+
>             +->|         |------------------->|         |
>evConnRtrExp |  | Connect |                    | Active  |
>             +--|         |<-------------------|         | 
>                +---------+  evConnectRetryExp +---------+
>                     |                            |  ^
>                     |                evTransSucc |  |
>          evTransSucc|                            |  | evTransDisc
>                     |       +-------------+      |  |
>                     |       |             |<-----+  |
>                     +------>|  OpenSent   |         |
>                             |             |---------+
>                             +-------------+
>                                    |
>                                    | evOpenMsgRcvd
>                                    v
>                             +-------------+
>                          +->|             |
>      evKeepAliveTimerExp |  | OpenConfirm |
>                          +--|             |
>                             +-------------+
>                                    |
>                                    | evKeepAliveMsgRcvd
>                                    v
>                             +-------------+
>          evKeepAliveMsg  +->|             |
>             evUpdateMsg  |  | Established |
>     evKeepAliveTimerExp  +--|             |
>                             +-------------+

_____________________________________________________________
Get your spam-free, Linux email now --> http://www.LinuxWaves.com
Join Linux discussions --> http://Community.LinuxWaves.com

Date: Sat, 19 Jan 2002 11:45:52 -0500
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: Russ White <[email-masked]>, "Reddy, Sudhakar" <[email-masked]>, "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Sender: [email-masked]

On Fri, Jan 18, 2002 at 01:37:45PM -0800, Pedro Roque Marques wrote:
> If you consider that both link 1 and 2 have the same probability of
> failure then there is 50% change that it is link 2 that flaps case in
> which the first path selection change due to the tie break is helpful.

Once and exactly once.
You keep the most stable path.

> If they have different probabilities of failure then bgp needs to be
> informed of that through one of the several metric parameters...

If both are failing, there is nothing we can do other than to negatively
bias all routes at this ingress.

> I still believe that having a deterministic path selection algorithm
> (i.e. independent of temporal order of arrival) is a very significant
> advantage in terms of being able to debug network/equipment.

I don't think people who run redunant SONET loops would agree with you.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

Date: Sat, 19 Jan 2002 14:59:51 +0100
From: Vincent Gillet <[email-masked]>
To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

[email-masked] disait :

> >> I guess we are going to find this out as part of the implementation
> >> report. And if it is not in (at least two) current implementations,
> >> we'll take it out of the text.
> >
> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
> >I checked that new subcode does not put other BGP stack in trouble
> >(checked Cisco and Juniper).
> 
> First of all, sorry for talking about specific implementation.  In
> Zebra implementation we've implemented Cease subcode.  The code is in
> CVS repository.  I'll prepare a release version for that.

Good. I guess your implementation is much better than my hack ;-)
It was the very first time i looked at zebra source code !!

> Exponential backoff is a good feature.  I can't understand why it
> require change to FSM.

No feeling about FSM, but concerned to monitor this "good feature" !

Vincent

Date: Sat, 19 Jan 2002 14:55:09 +0100
From: Vincent Gillet <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

[email-masked] disait :

> > 3)bgp exponential back-off
> 
> One operator's view:

My operator view (France Telecom) matches Andrew needs.

Backoff mechanism would be really helpfull for ops team.
I think that every body agree on that.

Big questions are : 

. new FSM state or NOT
. CAN / SHOULD / RECOMMEND / MUST word should we use ...

> As for the FSM, were we to have this feature we would demand a command from 
> the vendor that would indicate what the status of the backoff is.  So when
> we did a "sh ip bgp summ" we could see either that it was transitioned to
> idle for x reason and it had y seconds/minutes/hours remaining.  The 

Timers are not used to be shown in a "summary/terse" view but are welcome
for dedicated peer view. I trust vendors to make timers it available via CLI.

> proposal to call that state "IdleHold" is a sound one.  Although if
> it were called ("Idle - Hold Flag Set" or something that would be fine too.)
> And yes, we would want both the state and the time remaining in the MIB.

If IdleHold state is included in the draft, it will make it immediatly available
via SNMP in existing Mibs. No need to have bgpmib-v2 implemented to know
about this state.

> Preferably, if the state were IdleHold, we would have a "try #, # of seconds
> remaining, # of seconds in this retry interval.  Eg: BackoffAttemptNumber: 5
> BackoffSecondsRemaining: 38 BackoffSecondsTotalThisAttempt: 960

This could be a work for bgpmib-v2.

I do not have feeling about either we should include it in FSM and/or put a
strong word for this feature. I do not have lot of expericence on draft
nor implementation.
I am much more experienced in operations and BGP monitoring via SNMP
thus i would appreciate to be able to retriew this "Hold" state by an
easy way (SNMP).

Vincent.

Date: Sat, 19 Jan 2002 03:04:01 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Section 9 
Sender: [email-masked]

A few comments here:

-  This has been discussed a few times before on the
list, but never brought to a head.  See the archives:

-  Some prominent bgp implementations would not comply
with the proposed changes (or offer the option of 
non-compliance *shrug*).  

For prevention of loops, it is sufficient that the bgp 
route under consideration have the same nh as the 
exact match route (from protocol with higher relative 
protocol preference) being installed in the routing table.  

Announcement without installation in routing table has
been a neccesary and desired behavior at some large
backbones I have worked at.

On Sat, 18 Jan 2003, Tom Petch wrote:

> For ensuring that advertised routes are present in the
> Routing Table,
> and not just in the Loc-RIB, how about
> 
> 2. Introduction
> ..................
>    To characterize the set of policy decisions that can be
> enforced
>    using BGP, one must focus on the rule that a BGP speaker
> advertises
>    to its peers (other BGP speakers which it communicates
> with) in
>    neighboring ASs only those routes that it itself uses,
> ---add--------------
> that is, are present in the BGP speaker's Routing Table.
> ----------------
>    This rule
>    reflects the "hop-by-hop" routing paradigm generally used
> throughout
>    the current Internet.
> ................................
> 
> 3.2 (no change needed)
> 
> 9.1.2 (no change needed)
> 
> 9.1.3 Phase 3: Route Dissemination
> ......................
>    All routes
> ----change to-------------
> that are present in both the Loc-RIB and the Routing Table
> -------------------------------
>  shall be processed into Adj-RIBs-Out
>    according to configured policy.
> ........................
> 
> 
> 9.4 (no change needed)
> 
> Tom Petch, Network Consultant
> [email-masked]
> 
> -----Original Message-----
> From: Yakov Rekhter <[email-masked]>
> To: Tom Petch <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> Date: 14 January 2002 20:15
> Subject: Re: bgp4-17 Section 9
> 
> 
> >>
> >> 9.1.2 Route selection now allows for the best route in
> >> Loc-RIB not to be placed in the Routing table; how does
> this
> >> impact on the principle (2 Introduction) that a BGP
> Speaker
> >> should only advertise routes it itself uses?  Is it
> enough
> >> for the route to be in Loc-RIB and not in the Routing
> Table?
> >>
> {paragraph omitted - covered in previous e-mail}
> >
> >Please propose the specific changes.
> >
> >Yakov.
> 
> { plus an earlier reply from Alex to me}
> 
> > Tom,
> >
> > > 9.1.2 Route selection now allows for the best route in
> > > Loc-RIB not to be placed in the Routing table; how does
> this
> > > impact on the principle (2 Introduction) that a BGP
> Speaker
> > > should only advertise routes it itself uses?  Is it
> enough
> > > for the route to be in Loc-RIB and not in the Routing
> Table?
> >
> > The principle implies that the route is both in Loc-RIB
> and
> > in the routing table, i.e., it needs to be both selected
> as
> > the best and used by the router.
> > However, we can only specify so much about the routing
> table,
> > as it is (strictly speaking) outside of the scope of the
> BGP
> > protocol and administrator do have the "filter" rope in
> > their hands. Section 3.2 also talks about this.
> >
> 

Date: Fri, 18 Jan 2002 13:37:45 -0800 (PST)
From: Pedro Roque Marques <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Russ White <[email-masked]>, "Reddy, Sudhakar" <[email-masked]>, "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Sender: [email-masked]

Jeffrey Haas writes:

> On Fri, Jan 18, 2002 at 10:47:11AM -0800, Pedro Roque Marques wrote:
>> The conter argument is that reaching a deterministic state is worth
>> that extra flap...

> Not flap, singular, flaps plural.

> Consider:

+---+
: A :
+---+
 1 2
+---+
: B :
+---+

> Routers A and B are redundantly connected via networks 1 and 2.  A
> sends to B two routes that are equal preferable in the route
> selection process (prior to the new step g).

> Network 1 has a lower neighbor address than 2 and thus would be
> chosen.

> If network 1 flaps (bad circuit) then we unnecessarily flap the
> reachability.

Jeff,
If you consider that both link 1 and 2 have the same probability of
failure then there is 50% change that it is link 2 that flaps case in
which the first path selection change due to the tie break is helpful.
If they have different probabilities of failure then bgp needs to be
informed of that through one of the several metric parameters...

I still believe that having a deterministic path selection algorithm
(i.e. independent of temporal order of arrival) is a very significant
advantage in terms of being able to debug network/equipment.

  Pedro.

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: rough consensus on SAFI=3
Date: Fri, 18 Jan 2002 13:24:07 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

We need to get WG rough consensus on whether to remove SAFI=3 from
2858bis.

Folks who are in favor of removing SAFI=3 from 2858bis please
send an e-mail to [email-masked] saying "remove".

Folks you are in favor of keeping SAFI=3 in 2858bis please send
an e-mail to [email-masked] saying "keep".

The deadline for this is one week (Jan 25, 2002).

Sue&Yakov.

Date: Fri, 18 Jan 2002 13:01:48 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Tom Petch" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Section 9
Sender: [email-masked]

Tom,

 Though definitely a sane idea, I'm afraid this
 will not match the existing implementations.

-- 
Alex Zinin

P.S. Fix the text wrapping thing, pls :)

Saturday, January 18, 2003, 12:42:45 PM, Tom Petch wrote:

> For ensuring that advertised routes are present in the
> Routing Table,
> and not just in the Loc-RIB, how about

Date: Fri, 18 Jan 2002 16:02:06 -0500
From: Jeffrey Haas <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Section 9
Sender: [email-masked]

On Sat, Jan 18, 2003 at 08:42:45PM -0000, Tom Petch wrote:
> For ensuring that advertised routes are present in the
> Routing Table,
> and not just in the Loc-RIB, how about

The binding you suggest is perhaps too strong for some implementors.
The current wording was suggested to allow implementors who really
wanted to have the routing table and the loc-rib to be potentially
unsynchronized for a short period of time to do so.

-- 
Jeff Haas 
NextHop Technologies

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: bgp4-17 Section 9 
Date: Sat, 18 Jan 2003 20:42:45 -0000
Sender: [email-masked]

For ensuring that advertised routes are present in the
Routing Table,
and not just in the Loc-RIB, how about

2. Introduction
..................
   To characterize the set of policy decisions that can be
enforced
   using BGP, one must focus on the rule that a BGP speaker
advertises
   to its peers (other BGP speakers which it communicates
with) in
   neighboring ASs only those routes that it itself uses,
---add--------------
that is, are present in the BGP speaker's Routing Table.
----------------
   This rule
   reflects the "hop-by-hop" routing paradigm generally used
throughout
   the current Internet.
................................

3.2 (no change needed)

9.1.2 (no change needed)

9.1.3 Phase 3: Route Dissemination
......................
   All routes
----change to-------------
that are present in both the Loc-RIB and the Routing Table
-------------------------------
 shall be processed into Adj-RIBs-Out
   according to configured policy.
........................

9.4 (no change needed)

Tom Petch, Network Consultant
[email-masked]

-----Original Message-----
From: Yakov Rekhter <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 14 January 2002 20:15
Subject: Re: bgp4-17 Section 9

>>
>> 9.1.2 Route selection now allows for the best route in
>> Loc-RIB not to be placed in the Routing table; how does
this
>> impact on the principle (2 Introduction) that a BGP
Speaker
>> should only advertise routes it itself uses?  Is it
enough
>> for the route to be in Loc-RIB and not in the Routing
Table?
>>
{paragraph omitted - covered in previous e-mail}
>
>Please propose the specific changes.
>
>Yakov.

{ plus an earlier reply from Alex to me}

> Tom,
>
> > 9.1.2 Route selection now allows for the best route in
> > Loc-RIB not to be placed in the Routing table; how does
this
> > impact on the principle (2 Introduction) that a BGP
Speaker
> > should only advertise routes it itself uses?  Is it
enough
> > for the route to be in Loc-RIB and not in the Routing
Table?
>
> The principle implies that the route is both in Loc-RIB
and
> in the routing table, i.e., it needs to be both selected
as
> the best and used by the router.
> However, we can only specify so much about the routing
table,
> as it is (strictly speaking) outside of the scope of the
BGP
> protocol and administrator do have the "filter" rope in
> their hands. Section 3.2 also talks about this.
>

Date: Fri, 18 Jan 2002 12:23:30 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Russ White <[email-masked]>
Cc: Russ White <[email-masked]>, Susan Hares <[email-masked]>, randy Bush <[email-masked]>, <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

>> On the other hand, I think it would be equally good if the
>> spec did not spell out the details and we had another
>> document discussing the topic in detail... if we have such a
>> commitment, of course ;-)

> But I prefer this, even if there isn't a commitment for a doc
> (yet).

I'm fine with either approach. Let's see what Sue says.

Alex.

Date: Fri, 18 Jan 2002 15:19:10 -0500
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: Russ White <[email-masked]>, "Reddy, Sudhakar" <[email-masked]>, "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Sender: [email-masked]

On Fri, Jan 18, 2002 at 10:47:11AM -0800, Pedro Roque Marques wrote:
> The conter argument is that reaching a deterministic state is worth
> that extra flap...

Not flap, singular, flaps plural.

Consider:

+---+
: A :
+---+
 1 2
+---+
: B :
+---+

Routers A and B are redundantly connected via networks 1 and 2.
A sends to B two routes that are equal preferable in the route
selection process (prior to the new step g).

Network 1 has a lower neighbor address than 2 and thus would be
chosen.

If network 1 flaps (bad circuit) then we unnecessarily flap the
reachability.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 18 Jan 2002 10:36:05 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Kunihiro Ishiguro <[email-masked]>, [email-masked], Susan Hares <[email-masked]>
Subject: Re: Comments on FSM
Sender: [email-masked]

On Wed, Jan 16, 2002 at 06:44:44PM -0800, Alex Zinin wrote:
> No strong opinion on this.
> If exponential back-off is optional and has been implemented
> in some implementations, I think it can stay in the main spec.

Implementation note: GateD currently uses a step function rather
than fully exponential backoff, but we do backoff.

> Alex.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 18 Jan 2002 10:32:49 -0500
From: Jeffrey Haas <[email-masked]>
To: Russ White <[email-masked]>
Cc: "Reddy, Sudhakar" <[email-masked]>, "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Sender: [email-masked]

On Fri, Jan 18, 2002 at 09:30:43AM -0500, Russ White wrote:
> Not when you're announcing, but you've received the same route
> from two peers which are otherwise 'identical' in metrics.

Where the routes are non-identical, but equally preferable, 
selecting the candidate based on peering session address is 
potentially less preferable to selecting based on age.  The more
stable route would be more preferable to the route with the
"better" peer address.

I even seem to remember a certain $LARGE_ROUTER_VENDOR behaving
that way once-upon-a-release. :-)

> Russ

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: Russ White <[email-masked]>, "Reddy,     Sudhakar" <[email-masked]>, [email-masked], "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) 
Date: Fri, 18 Jan 2002 06:51:19 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Jeff,
Just consider the case of parallel sessions (using different interfaces
with different speeds) between two routers, the route selection algorithm
would not terminate without Step g).  EBGP parallel sessions are used widely
in practice.

-- Enke

> Date: Fri, 18 Jan 2002 09:22:38 -0500
> From: Jeffrey Haas <[email-masked]>
> To: Russ White <[email-masked]>
> Cc: "Reddy, Sudhakar" <[email-masked]>,
> 	"'Manav Bhatia'" <[email-masked]>, [email-masked]
> Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
> Message-ID: <[email-masked]>
> References: <[email-masked]> <[email-masked]>
> 
> On Fri, Jan 18, 2002 at 08:12:13AM -0500, Russ White wrote:
> > Actually, this rule is designed to prevent the route flap when a
> > new path, identical in all respects other than the peer it is
> > learned from, is newly learned. The older route wins, which means
> > the decision algorithm won't flip over to the newer route if the
> > route from which it is learned has a lower rid.
> 
> A different question is why you're announcing the route when
> it is identical, but just from another peer and you've already
> announced that reachability.
> 
> Flapping the stuff on the wire just because you've changed the stuff
> in your internal route instances is silly.
> 
> IOW - g) wasn't necessary at all.  g) even causes flaps where there
> shouldn't need to be any.
> 
> > Russ
> 
> -- 
> Jeff Haas 
> NextHop Technologies

Date: Fri, 18 Jan 2002 09:30:43 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: "Reddy, Sudhakar" <[email-masked]>, "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Sender: [email-masked]

Not when you're announcing, but you've received the same route
from two peers which are otherwise 'identical' in metrics.

:-)

Russ

On Fri, 18 Jan 2002, Jeffrey Haas wrote:

> On Fri, Jan 18, 2002 at 08:12:13AM -0500, Russ White wrote:
> > Actually, this rule is designed to prevent the route flap when a
> > new path, identical in all respects other than the peer it is
> > learned from, is newly learned. The older route wins, which means
> > the decision algorithm won't flip over to the newer route if the
> > route from which it is learned has a lower rid.
> 
> A different question is why you're announcing the route when
> it is identical, but just from another peer and you've already
> announced that reachability.
> 
> Flapping the stuff on the wire just because you've changed the stuff
> in your internal route instances is silly.
> 
> IOW - g) wasn't necessary at all.  g) even causes flaps where there
> shouldn't need to be any.
> 
> > Russ
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Fri, 18 Jan 2002 09:22:38 -0500
From: Jeffrey Haas <[email-masked]>
To: Russ White <[email-masked]>
Cc: "Reddy, Sudhakar" <[email-masked]>, "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Sender: [email-masked]

On Fri, Jan 18, 2002 at 08:12:13AM -0500, Russ White wrote:
> Actually, this rule is designed to prevent the route flap when a
> new path, identical in all respects other than the peer it is
> learned from, is newly learned. The older route wins, which means
> the decision algorithm won't flip over to the newer route if the
> route from which it is learned has a lower rid.

A different question is why you're announcing the route when
it is identical, but just from another peer and you've already
announced that reachability.

Flapping the stuff on the wire just because you've changed the stuff
in your internal route instances is silly.

IOW - g) wasn't necessary at all.  g) even causes flaps where there
shouldn't need to be any.

> Russ

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 18 Jan 2002 08:29:37 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: "Reddy, Sudhakar" <[email-masked]>
Cc: "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t  xt)
Sender: [email-masked]

The older route still wins--you don't pay attention to the router
id at all, since one of the two otherwise identical prefixes will
always be older.

:-)

Russ

On Fri, 18 Jan 2002, Reddy, Sudhakar wrote:

> What happens if the older route which is identical in all respects other
> than rid, is having higher rid than the newer route? 
> 
> Thanks,
> Sudhakar
> 
> -----Original Message-----
> From: Russ White [mailto:[email-masked]]
> Sent: Friday, January 18, 2002 6:42 PM
> To: Reddy, Sudhakar
> Cc: 'Manav Bhatia'; [email-masked]
> Subject: RE: A Question about Tie breaking rules
> (draft-ietf-idr-bgp4-17.t xt)
> 
> 
> 
> Actually, this rule is designed to prevent the route flap when a
> new path, identical in all respects other than the peer it is
> learned from, is newly learned. The older route wins, which means
> the decision algorithm won't flip over to the newer route if the
> route from which it is learned has a lower rid.
> 
> :-)
> 
> Russ
> 
> On Fri, 18 Jan 2002, Reddy, Sudhakar wrote:
> 
> > Hi Manav,
> > I can understand that this rule will help to avoided routing loops, and
> > ensures a consistent best path selection. But at the same time say if two
> > paths are from external peers, this may create a route-flap.(since a newer
> > path may displace on older one). 
> > 
> > Thanks,
> > Sudhakar
> > 
> > -----Original Message-----
> > From: Manav Bhatia [mailto:[email-masked]]
> > Sent: Friday, January 18, 2002 2:23 PM
> > To: Reddy, Sudhakar; [email-masked]
> > Subject: Re: A Question about Tie breaking rules
> > (draft-ietf-idr-bgp4-17.txt)
> > 
> > 
> > Hi Reddy,
> > This tie breaking rule is followed by a lot of BGP implementations in the
> > Internet. This is generally kept as the last resort for tie breaking and
> is
> > followed in a lot of BGP implementations. CISCO also suggests this in its
> > BGP Best Path Selection Algorithm.
> > 
> > Infact even ZEBRA supports this!
> > 
> > Regards,
> > Manav
> > 
> > ----- Original Message -----
> > From: "Reddy, Sudhakar" <[email-masked]>
> > To: <[email-masked]>
> > Cc: "Reddy, Sudhakar" <[email-masked]>
> > Sent: Friday, January 18, 2002 2:10 PM
> > Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
> > 
> > 
> > | Hi,
> > | I have a question about BGP tie braking rules. In the BGP new draft
> > | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule
> > g)
> > | is as follows:
> > | "g) Prefer the route received from the lowest neighbor address."
> > |
> > | What is the relevance of this rule? Is this tie breaking rule
> > | present in BGP implementations in the Internet?
> > |
> > | Thanks in advance,
> > | Sudhakar
> > |
> -------------------------------------------------------------------------
> > ---
> > | -
> > | R. Sudhakar Reddy                      mailto:[email-masked]
> > |
> > | NetPlane Network Technologies (India) Pvt. Ltd.
> <http://www.netplane.com>
> > | A Mindspeed Technologies Company
> > <http://www.mindspeed.com>
> > | 189, Prashasan Nagar,               Ph: +91-40-3553709 ~ 12 (Ext
> > | 1127)
> > | Road # 72, Jublee Hills,
> > | Hyderabad - 500033
> > 
> > 
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> 
> _____________________________
> [email-masked] <>< Grace Alone
> 

_____________________________
[email-masked] <>< Grace Alone

From: "Reddy, Sudhakar" <[email-masked]>
To: "'Russ White'" <[email-masked]>, "Reddy, Sudhakar" <[email-masked]>
Cc: "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Date: Fri, 18 Jan 2002 08:28:26 -0500
Sender: [email-masked]

What happens if the older route which is identical in all respects other
than rid, is having higher rid than the newer route? 

Thanks,
Sudhakar

-----Original Message-----
From: Russ White [mailto:[email-masked]]
Sent: Friday, January 18, 2002 6:42 PM
To: Reddy, Sudhakar
Cc: 'Manav Bhatia'; [email-masked]
Subject: RE: A Question about Tie breaking rules
(draft-ietf-idr-bgp4-17.t xt)

Actually, this rule is designed to prevent the route flap when a
new path, identical in all respects other than the peer it is
learned from, is newly learned. The older route wins, which means
the decision algorithm won't flip over to the newer route if the
route from which it is learned has a lower rid.

:-)

Russ

On Fri, 18 Jan 2002, Reddy, Sudhakar wrote:

> Hi Manav,
> I can understand that this rule will help to avoided routing loops, and
> ensures a consistent best path selection. But at the same time say if two
> paths are from external peers, this may create a route-flap.(since a newer
> path may displace on older one). 
> 
> Thanks,
> Sudhakar
> 
> -----Original Message-----
> From: Manav Bhatia [mailto:[email-masked]]
> Sent: Friday, January 18, 2002 2:23 PM
> To: Reddy, Sudhakar; [email-masked]
> Subject: Re: A Question about Tie breaking rules
> (draft-ietf-idr-bgp4-17.txt)
> 
> 
> Hi Reddy,
> This tie breaking rule is followed by a lot of BGP implementations in the
> Internet. This is generally kept as the last resort for tie breaking and
is
> followed in a lot of BGP implementations. CISCO also suggests this in its
> BGP Best Path Selection Algorithm.
> 
> Infact even ZEBRA supports this!
> 
> Regards,
> Manav
> 
> ----- Original Message -----
> From: "Reddy, Sudhakar" <[email-masked]>
> To: <[email-masked]>
> Cc: "Reddy, Sudhakar" <[email-masked]>
> Sent: Friday, January 18, 2002 2:10 PM
> Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
> 
> 
> | Hi,
> | I have a question about BGP tie braking rules. In the BGP new draft
> | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule
> g)
> | is as follows:
> | "g) Prefer the route received from the lowest neighbor address."
> |
> | What is the relevance of this rule? Is this tie breaking rule
> | present in BGP implementations in the Internet?
> |
> | Thanks in advance,
> | Sudhakar
> |
-------------------------------------------------------------------------
> ---
> | -
> | R. Sudhakar Reddy                      mailto:[email-masked]
> |
> | NetPlane Network Technologies (India) Pvt. Ltd.
<http://www.netplane.com>
> | A Mindspeed Technologies Company
> <http://www.mindspeed.com>
> | 189, Prashasan Nagar,               Ph: +91-40-3553709 ~ 12 (Ext
> | 1127)
> | Road # 72, Jublee Hills,
> | Hyderabad - 500033
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Fri, 18 Jan 2002 08:12:13 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: "Reddy, Sudhakar" <[email-masked]>
Cc: "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Sender: [email-masked]

Actually, this rule is designed to prevent the route flap when a
new path, identical in all respects other than the peer it is
learned from, is newly learned. The older route wins, which means
the decision algorithm won't flip over to the newer route if the
route from which it is learned has a lower rid.

:-)

Russ

On Fri, 18 Jan 2002, Reddy, Sudhakar wrote:

> Hi Manav,
> I can understand that this rule will help to avoided routing loops, and
> ensures a consistent best path selection. But at the same time say if two
> paths are from external peers, this may create a route-flap.(since a newer
> path may displace on older one). 
> 
> Thanks,
> Sudhakar
> 
> -----Original Message-----
> From: Manav Bhatia [mailto:[email-masked]]
> Sent: Friday, January 18, 2002 2:23 PM
> To: Reddy, Sudhakar; [email-masked]
> Subject: Re: A Question about Tie breaking rules
> (draft-ietf-idr-bgp4-17.txt)
> 
> 
> Hi Reddy,
> This tie breaking rule is followed by a lot of BGP implementations in the
> Internet. This is generally kept as the last resort for tie breaking and is
> followed in a lot of BGP implementations. CISCO also suggests this in its
> BGP Best Path Selection Algorithm.
> 
> Infact even ZEBRA supports this!
> 
> Regards,
> Manav
> 
> ----- Original Message -----
> From: "Reddy, Sudhakar" <[email-masked]>
> To: <[email-masked]>
> Cc: "Reddy, Sudhakar" <[email-masked]>
> Sent: Friday, January 18, 2002 2:10 PM
> Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
> 
> 
> | Hi,
> | I have a question about BGP tie braking rules. In the BGP new draft
> | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule
> g)
> | is as follows:
> | "g) Prefer the route received from the lowest neighbor address."
> |
> | What is the relevance of this rule? Is this tie breaking rule
> | present in BGP implementations in the Internet?
> |
> | Thanks in advance,
> | Sudhakar
> | -------------------------------------------------------------------------
> ---
> | -
> | R. Sudhakar Reddy                      mailto:[email-masked]
> |
> | NetPlane Network Technologies (India) Pvt. Ltd. <http://www.netplane.com>
> | A Mindspeed Technologies Company
> <http://www.mindspeed.com>
> | 189, Prashasan Nagar,               Ph: +91-40-3553709 ~ 12 (Ext
> | 1127)
> | Road # 72, Jublee Hills,
> | Hyderabad - 500033
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Fri, 18 Jan 2002 08:10:08 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Kunihiro Ishiguro <[email-masked]>
Cc: Susan Hares <[email-masked]>, Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

> 8.1 Exponential Back-off.
> 
>    If a BGP speaker detects an error, it shuts down the connection and
>    changes its state to Idle.  Getting out of the Idle state requires
>    generation of the Start event.  If such an event is generated
>    automatically, then persistent BGP errors may result in persistent
>    flapping of the speaker.  To avoid such a condition it is
>    recommended that Start events should not be generated immediately
>    for a peer that was previously transitioned to Idle due to an
>    error.  For a peer that was previously transitioned to Idle due to
>    an error, the time between consecutive generation of Start events,
>    if such events are generated automatically, shall exponentially

MAY rather than shall....

>    increase. The value of the initial timer shall be 60 seconds. The

....increase. If exponential backoff is used, ....

>    time shall be doubled for each consecutive retry.  Suggested value
>    for this timer is:
> 
>    2**(consecutive retry count)*60
> 
>    An implementation MAY impose a configurable upper bound on that
>    timer value. Once the upper bound is reached, the speaker shall
>    stop the timer then no longer automatically generate the Start
>    event for the peer.

:-)

Russ

_____________________________
[email-masked] <>< Grace Alone

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: "Reddy, Sudhakar" <[email-masked]>, <[email-masked]>
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
Date: Fri, 18 Jan 2002 18:22:21 +0530
Sender: [email-masked]

Hi Sudhakar,
There are some 13 tie breaking rules which help BGP decide the best path.
After checking some 9 rules and even then IF there is a tie AND if the
routers are not configured for "bgp best path compare router-id" AND if
both the routes are external, the path that was received first is accepted
(the oldest one). This step is done to minimize route-flap (as you
suggested) , since the newer path wont displace the older one, even if it
is the preferred route based on the rules which follow (its here that a
route from a lower router ID is selected OR else minimum cluster length OR
path coming from the lowest neighbor address)

It is generally recommended that we apply the additional decision steps to
IBGP paths only, in order to ensure a consistent best path decision within
the network, and thereby avoiding loops.

So the problem which you suggested should not arise.

Hope it helps.

Regards,
Manav

----- Original Message -----
From: "Reddy, Sudhakar" <[email-masked]>
To: "'Manav Bhatia'" <[email-masked]>; <[email-masked]>
Sent: Friday, January 18, 2002 3:29 PM
Subject: RE: A Question about Tie breaking rules
(draft-ietf-idr-bgp4-17.txt)

| Hi Manav,
| I can understand that this rule will help to avoided routing loops, and
| ensures a consistent best path selection. But at the same time say if two
| paths are from external peers, this may create a route-flap.(since a
newer
| path may displace on older one).
|
| Thanks,
| Sudhakar
|
| -----Original Message-----
| From: Manav Bhatia [mailto:[email-masked]]
| Sent: Friday, January 18, 2002 2:23 PM
| To: Reddy, Sudhakar; [email-masked]
| Subject: Re: A Question about Tie breaking rules
| (draft-ietf-idr-bgp4-17.txt)
|
|
| Hi Reddy,
| This tie breaking rule is followed by a lot of BGP implementations in the
| Internet. This is generally kept as the last resort for tie breaking and
is
| followed in a lot of BGP implementations. CISCO also suggests this in its
| BGP Best Path Selection Algorithm.
|
| Infact even ZEBRA supports this!
|
| Regards,
| Manav
|
| ----- Original Message -----
| From: "Reddy, Sudhakar" <[email-masked]>
| To: <[email-masked]>
| Cc: "Reddy, Sudhakar" <[email-masked]>
| Sent: Friday, January 18, 2002 2:10 PM
| Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
|
|
| | Hi,
| | I have a question about BGP tie braking rules. In the BGP new draft
| | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking
rule
| g)
| | is as follows:
| | "g) Prefer the route received from the lowest neighbor address."
| |
| | What is the relevance of this rule? Is this tie breaking rule
| | present in BGP implementations in the Internet?
| |
| | Thanks in advance,
| | Sudhakar
|
| -------------------------------------------------------------------------
| ---
| | -
| | R. Sudhakar Reddy                      mailto:[email-masked]
| |
| | NetPlane Network Technologies (India) Pvt. Ltd.
<http://www.netplane.com>
| | A Mindspeed Technologies Company
| <http://www.mindspeed.com>
| | 189, Prashasan Nagar,               Ph: +91-40-3553709 ~ 12 (Ext
| | 1127)
| | Road # 72, Jublee Hills,
| | Hyderabad - 500033
|
|
| _________________________________________________________
| Do You Yahoo!?
| Get your free @yahoo.com address at http://mail.yahoo.com

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Fri, 18 Jan 2002 07:38:18 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Susan Hares <[email-masked]>, randy Bush <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

> > My primary question at this point isn't over leaving in text
> > about somehow controlling flapping sessions, but whether or not
> > we should say that exponential backup is the right way to do
> > this. There might be more interesting ways that crop up in the
> > future, so we should leave this open for thought, I think.
> 
> I thought about this as well, and it seemed to me that if
> this feature was documented as optional, that would leave
> enough flexibility for the implementers to either not use it
> at all (this would also solve the question of whether the
> current implementations that do not do so are RFC-compliant)
> or come up with a different scheme that would solve the
> problem in another way, and, at the same time, give some clue
> on one way of doing this thing.

This would work (as I said before)....

> On the other hand, I think it would be equally good if the
> spec did not spell out the details and we had another
> document discussing the topic in detail... if we have such a
> commitment, of course ;-)

But I prefer this, even if there isn't a commitment for a doc
(yet).

:-)

Russ

_____________________________
[email-masked] <>< Grace Alone

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: "Reddy, Sudhakar" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
Date: Fri, 18 Jan 2002 15:53:08 +0530
Sender: [email-masked]

Hi Sudhakar,
I am not able to think of a scenario when this shall create a route flap or
when it shall help in avoiding routing loops? Can you please explain such a
scenario to me?

Regards,
Manav
----- Original Message -----
From: "Reddy, Sudhakar" <[email-masked]>
To: "'Manav Bhatia'" <[email-masked]>; <[email-masked]>
Sent: Friday, January 18, 2002 3:29 PM
Subject: RE: A Question about Tie breaking rules
(draft-ietf-idr-bgp4-17.txt)

| Hi Manav,
| I can understand that this rule will help to avoided routing loops, and
| ensures a consistent best path selection. But at the same time say if two
| paths are from external peers, this may create a route-flap.(since a
newer
| path may displace on older one).
|
| Thanks,
| Sudhakar

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: "Reddy, Sudhakar" <[email-masked]>
To: "'Manav Bhatia'" <[email-masked]>, [email-masked]
Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt)
Date: Fri, 18 Jan 2002 04:59:35 -0500
Sender: [email-masked]

Hi Manav,
I can understand that this rule will help to avoided routing loops, and
ensures a consistent best path selection. But at the same time say if two
paths are from external peers, this may create a route-flap.(since a newer
path may displace on older one). 

Thanks,
Sudhakar

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]]
Sent: Friday, January 18, 2002 2:23 PM
To: Reddy, Sudhakar; [email-masked]
Subject: Re: A Question about Tie breaking rules
(draft-ietf-idr-bgp4-17.txt)

Hi Reddy,
This tie breaking rule is followed by a lot of BGP implementations in the
Internet. This is generally kept as the last resort for tie breaking and is
followed in a lot of BGP implementations. CISCO also suggests this in its
BGP Best Path Selection Algorithm.

Infact even ZEBRA supports this!

Regards,
Manav

----- Original Message -----
From: "Reddy, Sudhakar" <[email-masked]>
To: <[email-masked]>
Cc: "Reddy, Sudhakar" <[email-masked]>
Sent: Friday, January 18, 2002 2:10 PM
Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)

| Hi,
| I have a question about BGP tie braking rules. In the BGP new draft
| "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule
g)
| is as follows:
| "g) Prefer the route received from the lowest neighbor address."
|
| What is the relevance of this rule? Is this tie breaking rule
| present in BGP implementations in the Internet?
|
| Thanks in advance,
| Sudhakar
| -------------------------------------------------------------------------
---
| -
| R. Sudhakar Reddy                      mailto:[email-masked]
|
| NetPlane Network Technologies (India) Pvt. Ltd. <http://www.netplane.com>
| A Mindspeed Technologies Company
<http://www.mindspeed.com>
| 189, Prashasan Nagar,               Ph: +91-40-3553709 ~ 12 (Ext
| 1127)
| Road # 72, Jublee Hills,
| Hyderabad - 500033

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: "Reddy, Sudhakar" <[email-masked]>, <[email-masked]>
Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
Date: Fri, 18 Jan 2002 14:22:50 +0530
Sender: [email-masked]

Hi Reddy,
This tie breaking rule is followed by a lot of BGP implementations in the
Internet. This is generally kept as the last resort for tie breaking and is
followed in a lot of BGP implementations. CISCO also suggests this in its
BGP Best Path Selection Algorithm.

Infact even ZEBRA supports this!

Regards,
Manav

----- Original Message -----
From: "Reddy, Sudhakar" <[email-masked]>
To: <[email-masked]>
Cc: "Reddy, Sudhakar" <[email-masked]>
Sent: Friday, January 18, 2002 2:10 PM
Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)

| Hi,
| I have a question about BGP tie braking rules. In the BGP new draft
| "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule
g)
| is as follows:
| "g) Prefer the route received from the lowest neighbor address."
|
| What is the relevance of this rule? Is this tie breaking rule
| present in BGP implementations in the Internet?
|
| Thanks in advance,
| Sudhakar
| -------------------------------------------------------------------------
---
| -
| R. Sudhakar Reddy                      mailto:[email-masked]
|
| NetPlane Network Technologies (India) Pvt. Ltd. <http://www.netplane.com>
| A Mindspeed Technologies Company
<http://www.mindspeed.com>
| 189, Prashasan Nagar,               Ph: +91-40-3553709 ~ 12 (Ext
| 1127)
| Road # 72, Jublee Hills,
| Hyderabad - 500033

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: "Reddy, Sudhakar" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Reddy, Sudhakar" <[email-masked]>
Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt)
Date: Fri, 18 Jan 2002 03:40:42 -0500
Sender: [email-masked]

Hi, 
	I have a question about BGP tie braking rules. In the BGP new draft
"draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule g)
is as follows:
	"g) Prefer the route received from the lowest neighbor address."

	What is the relevance of this rule? Is this tie breaking rule
present in BGP implementations in the Internet?

Thanks in advance,
Sudhakar
----------------------------------------------------------------------------
-
R. Sudhakar Reddy                      mailto:[email-masked]

NetPlane Network Technologies (India) Pvt. Ltd. <http://www.netplane.com>
A Mindspeed Technologies Company                <http://www.mindspeed.com>
189, Prashasan Nagar,		              Ph: +91-40-3553709 ~ 12 (Ext
1127)
Road # 72, Jublee Hills,			
Hyderabad - 500033

Date: Thu, 17 Jan 2002 19:48:00 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Russ White <[email-masked]>
Cc: Russ White <[email-masked]>, Susan Hares <[email-masked]>, randy Bush <[email-masked]>, <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Russ:

> My primary question at this point isn't over leaving in text
> about somehow controlling flapping sessions, but whether or not
> we should say that exponential backup is the right way to do
> this. There might be more interesting ways that crop up in the
> future, so we should leave this open for thought, I think.

I thought about this as well, and it seemed to me that if
this feature was documented as optional, that would leave enough
flexibility for the implementers to either not use it at all
(this would also solve the question of whether the current
implementations that do not do so are RFC-compliant) or come up
with a different scheme that would solve the problem in another
way, and, at the same time, give some clue on one way of doing
this thing.

On the other hand, I think it would be equally good if the spec did
not spell out the details and we had another document discussing
the topic in detail... if we have such a commitment, of course ;-)

Alex.

Date: Thu, 17 Jan 2002 18:46:46 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

>Here's the state machine diagram and event plan that
>matches the state machine.   You could
>look at the state machine diagram to easily walk through
>the words.

Thanks Sue.  It's very helpful to understand the whole picture.  Here
is a draft of FSM section based upon bgp4-16 description and your FSM
chart.  I tried:

 o Create a new sub-section 8.1 for Exponential Back-off.
 o Do not add IdelHold status.
 o Use new bgp4-17 like action description format (I use bullet for
   each action).

Any comments are welcome.

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

8. BGP Finite State machine.

   This section specifies BGP operation in terms of a Finite State
   Machine (FSM). Following is a brief summary and overview of BGP
   operations by state as determined by this FSM.

      Initially BGP is in the Idle state.

      Idle state:

         In this state BGP refuses all incoming BGP connections. No
         resources are allocated to the peer. In response to the Start
         event initiated by either system or operator (see Section
         8.1) the local system:

            o Initializes all BGP resources.

            o Starts the ConnectRetry timer.

            o Initiates a transport connection to other BGP peer.

            o Changes its state to Connect.

         The exact value of the ConnectRetry timer is a local matter,
         but should be sufficiently large to allow TCP initialization.

         Any other event received in the Idle state is ignored.

      Connect state:

         In this state BGP is waiting for the transport protocol
         connection to be completed.

         If the transport protocol connection succeeds, the local
         system:

            o Clears the ConnectRetry timer.

            o Completes initialization.

	    o Sends an OPEN message to its peer.

	    o Changes its state to OpenSent.

         If the transport protocol connect fails (e.g., retransmission
         timeout), the local system:

            o Restarts the ConnectRetry timer.

            o Continues to listen for a connection that may be
              initiated by the remote BGP peer.

            o Changes its state to Active state.

         In response to the ConnectRetry timer expired event, the local
         system:

	    o Restarts the ConnectRetry timer.

            o Initiates a transport connection to other BGP peer.

            o Continues to listen for a connection that may be
              initiated by the remote BGP peer.

            o Stays in the Connect state.

         The Start event is ignored in the Connect state.

         In response to any other event (initiated by either system or
         operator), the local system releases all BGP resources
         associated with this connection and changes its state to Idle.

      Active state:

         In this state BGP is trying to acquire a peer by listening for
         and accepting a transport protocol connection.

         If the transport protocol connection succeeds, the local
         system:

            o Clears the ConnectRetry timer.

            o Completes initialization.

            o Sends an OPEN message to its peer.

            o Sets its Hold Timer to a large value.

            o Changes its state to OpenSent.

         A Hold Timer value of 4 minutes is suggested.

         In response to the ConnectRetry timer expired event, the local
         system:

	    o Restarts the ConnectRetry timer.

            o Initiates a transport connection to the other BGP peer.

	    o Continues to listen for a connection that may be
	      initiated by the remote BGP peer.

	    o Changes its state to Connect.

         If the local system does not allow BGP connections with
         unconfigured peers, then the local system:

	    o Rejects connections from IP addresses that are not
              configured peers.

	    o Remains in the Active state.

         The Start event is ignored in the Active state.

         In response to any other event (initiated by either system or
         operator), the local system releases all BGP resources
         associated with this connection and changes its state to Idle.

      OpenSent state:

         In this state BGP waits for an OPEN message from its peer.
         When an OPEN message is received, all fields are checked for
         correctness. If the BGP message header checking or OPEN message
         checking detects an error (see Section 6.2), or a connection
         collision (see Section 6.8) the local system sends a
         NOTIFICATION message and changes its state to Idle.

         If there are no errors in the OPEN message, the local system:

	    o Sends a KEEPALIVE message.

            o Sets a KeepAlive timer.

            o Sets a Hold timer according to the negotiated Hold time
              value (see section 4.2).

            o Changes its state to OpenConfirm.

         If the negotiated Hold time value is zero, then the Hold
         timer and KeepAlive timers are not started.  If the value of
         the Autonomous System field is the same as the local
         Autonomous System number, then the connection is an
         "internal" connection; otherwise, it is an "external"
         connection.  (This will impact UPDATE processing as described
         below.)

         If a disconnect notification is received from the underlying
         transport protocol, the local system:

	    o Closes the BGP connection.

            o Restarts the ConnectRetry timer.

            o Continue listening for connection that may be initiated
              by the remote BGP peer.

	    o Changes its state to Active.

         If the Hold Timer expires, the local system:

            o Sends NOTIFICATION message with error code Hold Timer
              Expired.

            o Changes its state to Idle.

         In response to the Stop event (initiated by either system or
         operator) the local system:

	    o Sends NOTIFICATION message with Error Code Cease.

            o Changes its state to Idle.

         The Start event is ignored in the OpenSent state.

         In response to any other event the local system:

	    o Sends NOTIFICATION message with Error Code Finite State
	      Machine Error

            o Changes its state to Idle.

         Whenever BGP changes its state from OpenSent to Idle, it closes
         the BGP (and transport-level) connection and releases all
         resources associated with that connection.

      OpenConfirm state:

         In this state BGP waits for a KEEPALIVE or NOTIFICATION
         message.

         If the local system receives a KEEPALIVE message, the local
         system:

            o Changes its state to Established.

         If the Hold Timer expires before a KEEPALIVE message is
         received, the local system:

	    o Sends NOTIFICATION message with error code Hold Timer
	      Expired.

            o Changes its state to Idle.

         If the local system receives a NOTIFICATION message, the
         local system:

            o Changes its state to Idle.

         If the KeepAlive timer expires, the local system:

	    o Sends a KEEPALIVE message.

	    o Restarts its KeepAlive timer.

         If a disconnect notification is received from the underlying
         transport protocol, the local system:

            o Changes its state to Idle.

         In response to the Stop event (initiated by either system or
         operator) the local system:

	    o Sends NOTIFICATION message with Error Code Cease.

	    o Changes its state to Idle.

         The Start event is ignored in the OpenConfirm state.

         In response to any other event the local system:

	    o Sends NOTIFICATION message with Error Code Finite State
	      Machine Error.

            o Changes its state to Idle.

         Whenever BGP changes its state from OpenConfirm to Idle, it
         closes the BGP (and transport-level) connection and releases
         all resources associated with that connection.

      Established state:

         In the Established state BGP can exchange UPDATE, NOTIFICATION,
         and KEEPALIVE messages with its peer.

         If the local system receives an UPDATE or KEEPALIVE message,
         the local system: 

            o Restarts its Hold Timer, if the negotiated Hold Time
              value is non-zero.

         If the local system receives a NOTIFICATION message, the
	 local system: 

	    o Changes its state to Idle.

         If the local system receives an UPDATE message and the UPDATE
         message error handling procedure (see Section 6.3) detects an
         error, the local system:

	    o Sends a NOTIFICATION message.

	    o Changes its state to Idle.

         If a disconnect notification is received from the underlying
         transport protocol, the local system:

	    o Changes its state to Idle.

         If the Hold Timer expires, the local system:

	    o Sends a NOTIFICATION message with Error Code Hold Timer
              Expired.

	    o Changes its state to Idle.

         If the KeepAlive timer expires, the local system:

	    o Sends a KEEPALIVE message.

	    o Restarts its KeepAlive timer. if the negotiated Hold
	      time value is non-zero.

         Each time the local system sends a KEEPALIVE or UPDATE
         message, it restarts its KeepAlive timer, if the negotiated
         Hold Time value is non-zero.

         In response to the Stop event (initiated by either system or
         operator), the local system sends a NOTIFICATION message with
         Error Code Cease and changes its state to Idle.

         The Start event is ignored in the Established state.

         In response to any other event, the local system:

	    o Sends NOTIFICATION message with Error Code Finite State
	      Machine Error.

            o Changes its state to Idle.

         Whenever BGP changes its state from Established to Idle, it
         closes the BGP (and transport-level) connection, releases all
         resources associated with that connection, and deletes all
         routes derived from that connection.

8.1 Exponential Back-off.

   If a BGP speaker detects an error, it shuts down the connection and
   changes its state to Idle.  Getting out of the Idle state requires
   generation of the Start event.  If such an event is generated
   automatically, then persistent BGP errors may result in persistent
   flapping of the speaker.  To avoid such a condition it is
   recommended that Start events should not be generated immediately
   for a peer that was previously transitioned to Idle due to an
   error.  For a peer that was previously transitioned to Idle due to
   an error, the time between consecutive generation of Start events,
   if such events are generated automatically, shall exponentially
   increase. The value of the initial timer shall be 60 seconds. The
   time shall be doubled for each consecutive retry.  Suggested value
   for this timer is:

   2**(consecutive retry count)*60

   An implementation MAY impose a configurable upper bound on that
   timer value. Once the upper bound is reached, the speaker shall
   stop the timer then no longer automatically generate the Start
   event for the peer.

Date: Thu, 17 Jan 2002 22:21:23 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Susan Hares <[email-masked]>, randy Bush <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Alex:

My primary question at this point isn't over leaving in text
about somehow controlling flapping sessions, but whether or not
we should say that exponential backup is the right way to do
this. There might be more interesting ways that crop up in the
future, so we should leave this open for thought, I think.

:-)

Russ

On Thu, 17 Jan 2002, Alex Zinin wrote:

> 
> Sue,
> 
>  To clarify my position: I think that recommendation for an
>  exponential back-off is a good thing and solves a real
>  problem. However, I think that the IdleHold state should not
>  be in the FSM because:
> 
>    1) It seems to be redundant. See (*) below.
>    2) It introduces changes to the base FSM to account for
>       a feature of an optional nature. People who didn't
>       implement it would be put in a non-compliant position,
>       people who won't implement it will have to take things
>       out of the FSM.
>    3) I am under impression (though I might be wrong) that
>       it does not match the majority of deployed implementations
>       that do not have this state and hence would ago against the
>       objective of this spec review round.
>  ---
>  *) When it comes to FSMs, one almost always can achieve the same
>     results by either using an existing state with flags or by adding
>     another state. It is often hard to decide which approach to follow.
>     One simple test I find useful is to see how different periodic
>     activities, packet and event processing are for the two states.
>     If there is a considerable difference, separate states are most
>     probably a good idea. In our case, the two states are practically
>     the same---we don't do anything on a periodic basis (no messages,
>     no outbound connections), we do not accept incoming connections,
>     we ignore all events but Start. The difference is essentially in
>     the reason we get to either state, which affects the name of
>     the state and when the Start event is generated. IMHO it does not
>     justify a new state, but that's my personal opinion :) I think
>     the original text from -12 (maybe revised a bit) should be good
>     enough...
>     
> -- 
> Alex Zinin
> 
> Thursday, January 17, 2002, 5:51:35 AM, Susan Hares wrote:
> 
> 
> > Alex and Randy:
> 
> > Let's go back to first principles here on the FSM?
> 
> > 1st)  The original text is below from draft-12.
> 
> >     This explanation gives "flag" that has implications
> >     for the full state machine.   The definition of
> >     state machines that Alex proposes, is all inputs
> >     and all actions are determined by state machine in
> >     clear text.
> 
> > 2nd) Is the bug real?
> 
> >     The text was fixing a " persistent bgp flapping"
> >     bug.  According to the text there is a
> >     state within a state with fairly vague
> >     descriptions.
> 
> > The second question belongs to Randy, since he wears 2 hats (Operations
> > and Routing temp AD), was this a real problem?  Has it gone away?
> 
> > 1) At least one routing vendor doesn't implement it [cisco]
> >     and I know this vendor is utilized in BGP peering sessions
> >     in the network.
> 
> > 2) What was the operational concern this text implies?
> 
> > If there is no operational issue and no operational usage,
> > return to the original FSM text and out the comments on
> > "hold down."
> 
> > So, Randy and all other operators - Is the problem it describes real?
> > Does anyone need it?   Let's answer that question first.
> 
> 
> 
> 
> > Sue Hares
> 
> > ----------------------
> 
> 
> >            If a BGP speaker detects an error, it shuts down the connection
> >           and changes its state to Idle. Getting out of the Idle state
> >           requires generation of the Start event.  If such an event is
> >           generated automatically, then persistent BGP errors may result
> >           in persistent flapping of the speaker.  To avoid such a
> >           condition it is recommended that Start events should not be
> >           generated immediately for a peer that was previously
> >           transitioned to Idle due to an error. For a peer that was
> >           previously transitioned to Idle due to an error, the time
> 
> 
> 
> > Expiration Date July 2001                                      [Page 31]
> 
> 
> 
> 
> 
> > RFC DRAFT                                                   January 2001
> 
> 
> >           between consecutive generation of Start events, if such events
> >           are generated automatically, shall exponentially increase. The
> >           value of the initial timer shall be 60 seconds. The time shall
> >           be doubled for each consecutive retry.
> 
> >           Any other event received in the Idle state is ignored.
> 
> 
> 
> > At 11:10 AM 1/16/2002 -0800, you wrote:
> 
> >>Sue,
> >>
> >>  Introduction of the IdleHold does change the FSM,
> >>  and I thought we wanted the spec to reflect the current
> >>  running code as much as possible.
> >>
> >>  I agree with Russ and Ishi---the new state does not
> >>  seem to be necessary, instead it could be as easy
> >>  as holding the session in Idle and giving clue on
> >>  how to make the delay exponential. I don't think
> >>  there's an interoperability issue if people decide
> >>  to keep the session in Idle using different internal
> >>  mechanisms.
> >>
> >>  Regards,
> >>
> >>--
> >>Alex Zinin
> >>
> >>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:
> >>
> >> > Kunihiro:
> >>
> >> > We are not changing the FSM so I would be surprised if the change
> >> > was anything but modest. Usually specifications with "no big" deal get
> >> > interpreted differently.  Inter-operable code means you tie down the 
> >> details.
> >>
> >> > The comment was on the clarity of the specification.
> >>
> >> > If you have a specific comment on the text of the state machine,
> >> > can you propose the concerns you have as a revision to the text.
> >>
> >> > Sue
> >>
> >> > PS -- I just love last call on a draft...  It's when
> >> >        everyone finally reads a new section  ;-)...
> >>
> >>
> >> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
> >> >> >> > Is the expoential backoff in the FSM in current implementations?
> >> >> >>
> >> >> >> I guess we are going to find this out as part of the implementation
> >> >> >> report. And if it is not in (at least two) current implementations,
> >> >> >> we'll take it out of the text.
> >> >> >
> >> >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
> >> >> >I checked that new subcode does not put other BGP stack in trouble
> >> >> >(checked Cisco and Juniper).
> >> >>
> >> >>First of all, sorry for talking about specific implementation.  In
> >> >>Zebra implementation we've implemented Cease subcode.  The code is in
> >> >>CVS repository.  I'll prepare a release version for that.
> >> >>
> >> >>And also we've implemented exponetial backoff.  It is done without
> >> >>introducing new FSM status.  It is not a big deal.  Just check a flag
> >> >>in a few functions.
> >>
> >>
> >> >>Exponential backoff is a good feature.  I can't understand why it
> >> >>require change to FSM.
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Thu, 17 Jan 2002 17:46:30 -0800
From: [email-masked]
To: Susan Hares <[email-masked]>
Cc: Alex Zinin <[email-masked]>, randy Bush <[email-masked]>, [email-masked], [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

> 3)bgp exponential back-off

One operator's view:

The vendor we use for our peering and backbone boxes doesn't implement this 
feature.  However, we would like it.  What usually happens when we have a 
flapping BGP session, due to say, a bad circuit, is someone is forced to come in
and shut it down manually, then bring it back up at some point when the
circuit is stable again.  With exponential backoff the lengths of the 
retrys would rapidly get to the point where human intervention to shut
the session down manually would not be required.  And the box would still try to
bring up the session occasionally, eliminating the "Oops, I forgot to bring
that back up" problem.

As for the FSM, were we to have this feature we would demand a command from 
the vendor that would indicate what the status of the backoff is.  So when
we did a "sh ip bgp summ" we could see either that it was transitioned to
idle for x reason and it had y seconds/minutes/hours remaining.  The 
proposal to call that state "IdleHold" is a sound one.  Although if
it were called ("Idle - Hold Flag Set" or something that would be fine too.)
And yes, we would want both the state and the time remaining in the MIB.
Preferably, if the state were IdleHold, we would have a "try #, # of seconds
remaining, # of seconds in this retry interval.  Eg: BackoffAttemptNumber: 5
BackoffSecondsRemaining: 38 BackoffSecondsTotalThisAttempt: 960

And being the generally knob-happy types we operators are :), a max-backoff
value or the like would be good as an enhancement.

Andrew

Date: Thu, 17 Jan 2002 17:44:11 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Subject: More thoughts on FSM
Sender: [email-masked]

Folks,

 I mentioned multiple times that I'd like the FSM to
 be represented in a more formal way. Below is what
 I have in mind. It is just a scratch, by no means
 complete. I'd like to know what people think about
 the idea. If there's a common feeling that this
 would be useful, I would invest more time in it...
 
--
Alex.

1. Session attributes

   The following attributes required for FSM operation are associated
   with each BGP session:

   State: 
     Indicates the current state of the BGP session FSM.
     Possible FSM states are described in Section 3.

   Start timer:
     A timer used for automatic generation of the evStart
     event.
   
   ConnectRetry timer:
     A timer used for periodic initialization of an outgoing
     transport session when FSM is in stConnected and stActive
     states. Expiration of this timer triggers generation of
     the evConnectRetryExp FSM event.

     NOTE: The exact value of the ConnectRetry timer is a 
           local matter, but it should be sufficiently large 
           to allow TCP initialization.

   HoldTime:
     Period of time negotiated between BGP peers and used to
     detect unreachable speakers. If no UPDATE or KEEPALIVE
     message has been received through a BGP session during
     the HoldTime period, the remote peer is declared unreachable
     and the session is reset.

   Hold timer:
     A one shot timer initialized with HoldTime value and
     indicating that no valid messages have been received
     through the BGP session. Expiration of this timer
     triggers generation of the evHoldTimerExp FSM event.

     NOTE: If the negotiated HoldTime value is zero, 
           the Hold timer is not started.

   KeepAlive timer:
     A periodic timer used to send a KEEPALIVE message to
     the remote BGP peer if no UPDATE message have been
     sent to it within a period of time (the timer is reset
     every time an UPDATE message is sent out).

     NOTE: If the negotiated HoldTime value is zero, the
           KeepAlive timer is not started.

2. Events:

 Timer-based events:

   evKeepAliveTimerExp:
     A periodic event generated due to expiration of 
     the KeepAlive timer. This event is processed in
     FSM states stOpenConfirmed and stEstablished and
     triggers transmition of a KEEPALIVE message.
   
   evConnectRetryExp:
     An event triggered by expiration of the ConnectRetry
     timer. Processed in states stConnect and stActive,
     this event leads to initiation of an outbound transport
     session.
   
   evHoldTimerExp:
     An event generated when the session's HoldTimer expires.
     Processed in states stOpenConfirmed and higher, this
     event indicates that no UPDATE or KEEPALIVE messages
     have been received from the peer and the FSM needs to
     be reset.

 Message-processing related events:

   evTransSucc:
     An event indicating that the oubound transport session
     initiated previously has been successfully established.
  
   evTransFail:
     An event indicating that the oubound transport session
     initiated previously could not be established.     
  
   evTransDisc:
     An event indicating that the transport session associated
     with the FSM instance has been disconnected.
  
   evOpenMsgRcvd:
     An event indicating that a valid OPEN message has been
     received and no connection collision has been detected.
   
   evOpenMsgErr:
     An event indicating that received OPEN messages is not
     correct.
  
   evCollision:
     An event generated when a connection collision has been
     detected while processing an incoming OPEN message.
     See section XXX for more information on collision detection.
  
   evNotifMsg:
     An event triggered by reception of a NOTIFICATION message.
  
   evNotifMsgVerErr:
     An event generated when a NOTIFICATION message with "Version
     Error" code is received.
  
   evKeepAliveMsg:
     An event generated when a KEEPALIVE message is received.
  
   evUpdateMsg:
     An event indicating that an UPDATE message has been received
  
   evUpdateMsgErr:
     An event indicating that received UPDATE message is not correct.

 Administrative events:
      
   evStart:
      An event initiated by an operator or the system in response
      to Start timer expiration to initiate the BGP session 
      establishment procedure. This event affects only sessions 
      in the stIdle state and is ignored in others.

      If this event is generated automatically, then persistent BGP 
      errors may result in persistent flapping of a BGP session.
      To avoid such a condition it is recommended that evStart events
      are not generated immediately for a session that was previously
      transitioned to stIdle due to an error. For a session that was
      previously transitioned to stIdle due to an error, the time
      between consecutive generation of evStart events, if such events
      are generated automatically, should exponentially increase. The
      value of the initial timer should be 60 seconds. The time should
      be doubled for each consecutive retry.
  
   evStopManual:
      An event initiated by an operator and indicating that the
      BGP session should be administratively torn down.
  
   evStopAuto:
      An event generated by the system to bring a BGP session down.
      An example when this event can be generated is exceeding 
      the maximum number of prefixes allowed for a given peer.
  
      XXX: we could combine evStopManual and evStopAuto in one.

3. States 

 A BGP speaker creates an instance of a BGP session FSM 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. FSMs created
 for configured peers are initially put in the Idle state. See section
 XXX for more information on incoming transport connection processing.

 Each state is described below, including the list of processed
 and ignored events. Also, a list of actions performed when
 the FSM transitions to a specific state is provided (In-Actions).
 For some states, a list of actions performed when transitioning
 from the state is included (Out-Actions).

 stIdle: 
 
   This is the initial state of the FSM. This state is also
   used to keep BGP sessions in the inactive state when
   necessary. An evStart event (manual or automatic) is necessary
   to get the FSM out of the Idle state.
                                                            
    Valid events   : evStart
    Ignored events : all others
    Ivalid events  : None
                                              
    In-Actions:

      1. If transitioning from a higher state:

           o If the associated transport connection is open, 
             close it.

           o Stop all timers except for the Start timer

           o Release resources allocated for the session,
             including invalidation of all routes possibly 
             received from the peer

      2. Start the Start timer. See Section XXX for more info.

 stConnect:
  In this state, BGP has initiated an outbound transport
  connection and is waiting for it to be completed.

    Valid events   : evConnectRetryExp,  evTransSucc,
                     evTransFail,        evStopManual,
                     evStopAuto

    Ignored events : evStart
    Invalid events : all others

    In-Actions:

      1. If necessary (e.g., previous state is Idle),
         initialize resources for the BGP session

      2. Start (or restart if already running) 
         the ConnectRetry timer.

      3. Initiate a transport connection to the peer.

      4. Listen (or continue listening) for a connection 
         that may be initiated by the peer

 stActive:
  In this state BGP is not actively initiating an outbound
  transport connection, but is trying to acquire a peer 
  by listening for and accepting an incoming one.

    Valid events   : evConnectRetryExp,  evTransSucc
                     evStopManual,       evStopAuto

    Ignored events : evStart

    Invalid events : all others

    In-Actions:

      1. If necessary, close the transport connection

      2. Restart the ConnectRetry timer

      3. Continue to listen for a connection that may be
         initiated by the remote BGP peer

 stOpenSent:
    In this state, the local system has sent out an OPEN
    messages and awaits an OPEN message from the peer.

      Valid events   : evOpenMsgRcvd,     evNotifMsg,
                       evStopManual,      evStopAuto 
                       evHoldTimerExp

      Ignored events : evStart

      Invalid events : all others

      In-Actions:

        1. Stop the ConnectRetry timer

        2. Complete session initialization (don't know
           what this really means spec-wise)

        3. Send an OPEN message to the peer

        4. Set Hold timer to a large value (see note below)

        5. Stop listening for an incoming transort connection

        NOTE: A hold timer value of 4 minutes is suggested.

 stOpenConfirm:
    In this state, the local system has received an OPEN message
    from the peer, confirmed its reception by sending out
    a KEEPALIVE message, and awaits an incoming KEEPALIVE message
    confirming that the remote peer received the OPEN message
    sent before, or an icoming NOTIFICATION message reporting
    a problem.
    
      Valid events   : evKeepAliveTimerExp, evKeepAliveMsg
                       evCollision,         evNotifMsg,
                       evStopManual,        evStopAuto,
                       evHoldTimerExp

      Ignored events : evStart

      Invalid events : all others

      In-Actions:

        1. Send a KEEPALIVE message
        2. Set the KeepAlive timer (see note below)
        3. Set the Hold timer according to the negotiated
           value (see section 4.2 and note below)

        NOTE: If the negotiated Hold time value is zero, then the Hold
        and KeepAlive timers are not started.   If the value of 
        the Autonomous System field is the same as the local Autonomous
        System number, then the connection is an "internal" connection;
        otherwise, it is an "external" connection.   (This will impact
        UPDATE processing as described below.)

 stEstablished:
    This is the most advanced state of the FSM.
    In the Established state, BGP can exchange UPDATE, NOTFICATION,
    and KEEPALIVE messages with its peer.

      Valid events   : evKeepAliveTimerExp, evNotifMsg,
                       evKeepAliveMsg,      evUpdateMsg,
                       evUpdateMsgErr,      evStopManual,
                       evStopAuto,          evHoldTimerExp

      Ignored events : evStart

      In-Actions: No standard actions

4. Incoming transport connection processing

   When an incoming connection is detected, the system
   performs the following steps:

     o Look up an existing instance of the session FSM,
       using the remote IP addresses as the key.

     o If the BGP session is not found:

         - If the system is configured to not allow BGP 
           connections with unconfigured peers, reject
           the connection.
           
         - Otherwise, create a new instance of FSM,
           set the FSM state to stActive (without performing
           In-Actions for stActive) and generate evTransSucc
           event.

     o Otherwise (the session is found), processing depends
       on the state of the existing FSM:

         - If state is stIdle, reject the incoming connection
           (No incoming connections are allowed in the stIdle
           state.)

         - If state is stConnected, accept the incoming connection,
           create a new instance of FSM, set the FSM state to 
           stActive (without performing In-Actions for stActive)
           and generate evTransSucc event.

           /* I don't believe in this, but the spec treats
            * competing connections as seperate BGP sessions
            */ 
         
         - If state is stActive, accept the incoming connection,
           associate it with the existing session and generate
           the evTransSucc FSM event.

         - Otherwise (the FSM state is none of the above),
           reject the incoming connection.
           
           /* We could also generate an event here, but that
            * would cause an FSM restart
            */

   While in stConnected, a BGP speaker can initiate an outbound
   connection and accept an incoming one (this specification
   treats these connections as separate BGP sessions). 
   See section XXX for more information on how the situation
   of connection collision is handled.

5. Event processing and state transitions

   FSM operation is described below as follows. All state transitions
   are grouped by the initial FSM state. For each state, event 
   processing rules with associated actions are described. 

State: stIdle
-------------
    
     Event     : evStart
     New State : stConnect 
     Actions   : Standard stConnect In-Actions

     All other events are ignored.

State: stConnect
----------------
           
     Event     : evTransSucc
     New State : stOpenSent
     Actions   : Standard stOpenSent In-Actions

     Event     : evTransFail
     New State : stActive
     Actions   : Standard stActive In-Actions

     Event     : evConnectRetryExp
     New State : stConnect
     Actions   : Standard stConnect In-Actions

     Event     : invalid events
     New State : stIdle
     Actions   : Standard stIdle In-Actions.

     All other events are ignored.

State: stActive
---------------
    
     Event     : evTransSucc
     New State : stOpenSent
     Actions   : Standard stOpenSent In-Actions
    
     Event     : evConnectRetryExp
     New State : stConnect
     Actions   : Standard stConnect In-Actions
               
     Event     : invalid events
     New State : stIdle
     Actions   : Standard stIdle In-Actions
    
     All other events are ignored.
 
State: stOpenSent
-----------------       
    
     Event     : evOpenMsgErr, evCollision
     New State : stIdle
     Actions   : Standard stIdle In-Actions

     Event     : evOpenMsgRcvd
     New State : stOpenConfirm
     Actions   : Standard stOpenConfirm In-Actions

     Event     : evTransDisc
     New State : stActive
     Actions   : Standard stActive In-Actions

     Event     : evHoldTimerExp
     New State : stIdle
     Actions   :
                 1. Send a NOTIFICATION message with error code 
                    "Hold Timer Expired"
                 2. Standard stIdle In-Actions
    
     Event     : evNotifMsgVerErr
     New State : stIdle
     Actions   : Standard stIdle In-Actions

     Event     : evNotifMsg, and others
     New State : stIdle
     Actions   : Standard stIdle In-Actions
           
     All other events are ignored.

State: stOpenConfirmed
----------------------

     Event     : evKeepAliveMsg
     New State : stEstablished
     Actions   : none
    
     Event     : evHoldTimerExp
     New State : stIdle
     Actions   :
                 1. Send a NOTIFICATION message with the error 
                    code "Hold Timer Expired"
                 2. Standard stIdle In-Actions
    
     Event     : evNotifMsg, evTransDisc
     New State : stIdle
     Actions   : Standard stIdle In-Actions

     Event     : evStopAuto
     New State : stIdle
     Actions   :
                 1. Send a NOTIFICATION message with the error 
                    code "Cease"
                 2. Standard stIdle In-Actions

     Event     : evStopManual
     New State : stIdle
     Actions   :
                 1. Send a NOTIFICATION message with the error 
                    code "Cease"
                 2. Standard stIdle In-Actions

     Event     : invalid events
     New State : stIdle
     Actions   :
                 1. Send a NOTIFICATION message with the error 
                    code "FSM Error"
                 2. Standard stIdle In-Actions
               
     All other events are ignored.
 
State: stEstablished
--------------------

     Event     : evKeepAliveMsg, evUpdateMsg
     New State : stEstablished
     Actions   : 
                 Restart the Hold timer, if the negotiated Hold Time 
                 value is non-zero.
    
     Event     : evNotifMsg, evTransDisc
     New State : stIdle
     Actions   : Standard stIdle In-Actions

     Event     : evUpdateMsgErr
     New State : stIdle
     Actions   : 
                 1. Send a NOTIFICATION message with the error 
                    code "Update Error"
                 2. Standard stIdle In-Actions

     Event     : evUpdateMsgErr
     New State : stIdle
     Actions   : 
                1. Send a NOTIFICATION message with the error 
                   code "Hold Timer Expired"
                2. Standard stIdle In-Actions

     Event     : evKeepAliveTimerExp
     New State : stEstablished
     Actions   : 
                1. Send a KEEPALIVE message
                2. Restart the KeepAlive timer, unless the negotiated 
                   Hold Time value is zero.

     Event     : evStopAuto
     New State : stIdle
     Actions   : 
                1. Send a NOTIFICATION message with the error 
                   code "Cease"
                2. Standard stIdle In-Actions
                3. Deletes all routes (in stIdle In-Actions already)

     Event     : evStopManual
     New State : stIdle
     Actions   : 
                1. Send a NOTIFICATION message with the error
                   code "Cease" ??? (it was not in Sue's FSM)
                2. Standard stIdle In-Actions

     Event     : invalid events
     New State : stIdle
     Actions   :
                1. Send a NOTIFICATION message with the error 
                   code "FSM Error"
                2. Standard stIdle In-Actions
                3. Deletes all routes (in stIdle In-Actions already)
    
     All other events are ignored.

*Incomplete* state transition diagram below.
Only main state transitions are shown.

                               +---------+
                  evStart      |         |
                      +--------|  Idle   |
                      |        |         |
                      |        +---------+
                      |
                      | 
                      v        
                +---------+    evTransFail     +---------+
             +->|         |------------------->|         |
evConnRtrExp |  | Connect |                    | Active  |
             +--|         |<-------------------|         | 
                +---------+  evConnectRetryExp +---------+
                     |                            |  ^
                     |                evTransSucc |  |
          evTransSucc|                            |  | evTransDisc
                     |       +-------------+      |  |
                     |       |             |<-----+  |
                     +------>|  OpenSent   |         |
                             |             |---------+
                             +-------------+
                                    |
                                    | evOpenMsgRcvd
                                    v
                             +-------------+
                          +->|             |
      evKeepAliveTimerExp |  | OpenConfirm |
                          +--|             |
                             +-------------+
                                    |
                                    | evKeepAliveMsgRcvd
                                    v
                             +-------------+
          evKeepAliveMsg  +->|             |
             evUpdateMsg  |  | Established |
     evKeepAliveTimerExp  +--|             |
                             +-------------+

From: "Xie, Feng" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: A Question about MinASOriginationInterval
Date: Thu, 17 Jan 2002 18:42:03 -0500
Sender: [email-masked]

Hi, 

      I have a question about MinASOriginationInterval. In the BGP
specification (RFC1771), section 9.2.3.2, there is a statement as follows:

         "The parameter MinASOriginationInterval determines the minimum
amount
   of time that must elapse between successive advertisements of UPDATE
   messages that report changes within the advertising BGP speaker's own
   autonomous systems."

       My  question is that whether there is an easy way to figure out
whether a route update is for some change in my own AS or not. Suppose P1
and P2 are IBGP peers in AS#1. P1 receives an EBGP route and exports it to
P2. For P1, the route is outside of AS#1, i.e., it is an EBGP route.
However, for P2, the route is an IBGP route. How can P2 figure out whether
the route is inside or outside of AS#1? Or maybe P2 can check its routing
table. If it finds an IGP route for the same prefix, then the route is
inside AS#2. If the route is owned by BGP, then it is from outside of AS#1. 

Feng Xie

        

       

This e-mail and any attachments are confidential. If you are not the
intended recipient, please notify us immediately by reply e-mail and then
delete this message from your system. Do not copy this e-mail or any
attachment, use the contents for any purposes, or disclose the contents to
any other person: to do so could be a breach of confidence.

Date: Thu, 17 Jan 2002 11:34:03 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: randy Bush <[email-masked]>, [email-masked], [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Sue,

> 1) Thanks for your note.

>    Glad you think the bgp exponential back off is good.

>    We should get operator input to answer questions in #3.
>    I want to go with whatever the operator community has
>    deployed for this draft.

OK.

> 2) State machine text clean up was more than
>     the Idle Hold state

>   Just to let you know the FSM text was tighted up based on the
>   word document with the diagram I sent out.  There were other
>   inconsistencies in the FSM that I fixed based on the states
>   not being consistent with this diagram.

I understand, I meant the text about exp. back-off specifically
should be all right.

>   I will generate the state machine table without
>   the idle hold state to indicate those differences first.
>   [Warning - this plus the 2 other state machines you
>   sent me to review will take me a while.  Warning -- day turnaround
>   most likely]

All right, thanks. I think I'll send my version out to the list
today to get the feeling of what people think.

> 3)bgp exponential back-off

[stuff for SPs ;) ]

> 4) comparing all your input --- still processing

> I am plugging through the 2 versions of state
> machine you sent.   Did you send me a review
> of the diagram (word document) I'm attaching again.

> I didn't find that even though you mentioned
> you had done it.   Did I miss it?  That would
> speed up this process since a 5 page form is quicker to
> review and glance over.

Sue, I've briefly gone through several states in
the table and had some questions and bugs:

Event 3 (IdleHold expired, value under ceiling): I think this
        event should be ignored in Idle and higher
        
Idle x 3: "FSM Error" is not an action, is it?

Event 4: This event should be ignored in Idle and higher as well

Connect x 7: There's no associated transport session yet,
        the event should be ignored

OpenSent x 8: Ignore here?

Event 9: Should be Rcv TCP Connect & peer accepted

Connect x 9: Why incoming connection resets the FSM here?

OpenSent x 9: Ignore here?

Event 10: Should be Rcv TCP Connect & peer rejected

Connect x 10: Why incoming connection resets the FSM here?

OpenSent x 10: Ignore here?

Connect x 11: Hold timer is not running here, ignore?

Idle x 12: Idle here?

Connect x 12: Events from here down should be ignored?

IdleHold x 22: Should it be ignored and stay in IdleHold?

Idle x 23: Idle/Ignore here?

And probably the major one: there's no event that causes
OpenSent->OpenConfirmed transition... Here I stopped.
You should probably take another look and see if the
table is generated correctly.

Thanks.

Alex.

Date: Thu, 17 Jan 2002 13:28:40 -0500
To: Alex Zinin <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: randy Bush <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

--=====================_37894649==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Alex:

1) Thanks for your note.

   Glad you think the bgp exponential back off is good.

   We should get operator input to answer questions in #3.
   I want to go with whatever the operator community has
   deployed for this draft.

2) State machine text clean up was more than
    the Idle Hold state

  Just to let you know the FSM text was tighted up based on the
  word document with the diagram I sent out.  There were other
  inconsistencies in the FSM that I fixed based on the states
  not being consistent with this diagram.

  I will generate the state machine table without
  the idle hold state to indicate those differences first.
  [Warning - this plus the 2 other state machines you
  sent me to review will take me a while.  Warning -- day turnaround
  most likely]

3)bgp exponential back-off

  I would still like to hear from operators what
  was the problem and what this is being used for.
  If it is a serious problem, and people need it
  we can get feedback on:

a) Do operators use the flapping bgp speaker
    upon automatic configuration on any
    router in their network?

         If so, why?

b) If they utilize this feature, how do they
    detect that the back-off is going on?
    If they do want to detect it,  what
    do they want to know?   How critical is
    it?

    - if it is critical to know about, then something
      that can be queried in a standard manner is useful
      in the mib.  The specific state may be useful.

    - if the ISPs don't use it, we'll pull the feature.

    - if it is important, but they don't want to have
      a state to manage it then we can recombine the
      states.

      When the IESG calls (protocol monitors that they
      are), we can point to the market request on this
      issue.

    anyone who can ask ISPs to query this?

4) comparing all your input --- still processing

I am plugging through the 2 versions of state
machine you sent.   Did you send me a review
of the diagram (word document) I'm attaching again.

I didn't find that even though you mentioned
you had done it.   Did I miss it?  That would
speed up this process since a 5 page form is quicker to
review and glance over.

Sue

At 09:14 AM 1/17/2002 -0800, you wrote:

>Sue,
>
>  To clarify my position: I think that recommendation for an
>  exponential back-off is a good thing and solves a real
>  problem. However, I think that the IdleHold state should not
>  be in the FSM because:
>
>    1) It seems to be redundant. See (*) below.

>    2) It introduces changes to the base FSM to account for
>       a feature of an optional nature. People who didn't
>       implement it would be put in a non-compliant position,
>       people who won't implement it will have to take things
>       out of the FSM.
>    3) I am under impression (though I might be wrong) that
>       it does not match the majority of deployed implementations
>       that do not have this state and hence would ago against the
>       objective of this spec review round.
>  ---
>  *) When it comes to FSMs, one almost always can achieve the same
>     results by either using an existing state with flags or by adding
>     another state. It is often hard to decide which approach to follow.
>     One simple test I find useful is to see how different periodic
>     activities, packet and event processing are for the two states.
>     If there is a considerable difference, separate states are most
>     probably a good idea. In our case, the two states are practically
>     the same---we don't do anything on a periodic basis (no messages,
>     no outbound connections), we do not accept incoming connections,
>     we ignore all events but Start. The difference is essentially in
>     the reason we get to either state, which affects the name of
>     the state and when the Start event is generated. IMHO it does not
>     justify a new state, but that's my personal opinion :) I think
>     the original text from -12 (maybe revised a bit) should be good
>     enough...
>
>--
>Alex Zinin
>
>Thursday, January 17, 2002, 5:51:35 AM, Susan Hares wrote:
>
>
> > Alex and Randy:
>
> > Let's go back to first principles here on the FSM?
>
> > 1st)  The original text is below from draft-12.
>
> >     This explanation gives "flag" that has implications
> >     for the full state machine.   The definition of
> >     state machines that Alex proposes, is all inputs
> >     and all actions are determined by state machine in
> >     clear text.
>
> > 2nd) Is the bug real?
>
> >     The text was fixing a " persistent bgp flapping"
> >     bug.  According to the text there is a
> >     state within a state with fairly vague
> >     descriptions.
>
> > The second question belongs to Randy, since he wears 2 hats (Operations
> > and Routing temp AD), was this a real problem?  Has it gone away?
>
> > 1) At least one routing vendor doesn't implement it [cisco]
> >     and I know this vendor is utilized in BGP peering sessions
> >     in the network.
>
> > 2) What was the operational concern this text implies?
>
> > If there is no operational issue and no operational usage,
> > return to the original FSM text and out the comments on
> > "hold down."
>
> > So, Randy and all other operators - Is the problem it describes real?
> > Does anyone need it?   Let's answer that question first.
>
>
>
>
> > Sue Hares
>
> > ----------------------
>
>
> >            If a BGP speaker detects an error, it shuts down the connection
> >           and changes its state to Idle. Getting out of the Idle state
> >           requires generation of the Start event.  If such an event is
> >           generated automatically, then persistent BGP errors may result
> >           in persistent flapping of the speaker.  To avoid such a
> >           condition it is recommended that Start events should not be
> >           generated immediately for a peer that was previously
> >           transitioned to Idle due to an error. For a peer that was
> >           previously transitioned to Idle due to an error, the time
>
>
>
> > Expiration Date July 2001                                      [Page 31]
>
>
>
>
>
> > RFC DRAFT                                                   January 2001
>
>
> >           between consecutive generation of Start events, if such events
> >           are generated automatically, shall exponentially increase. The
> >           value of the initial timer shall be 60 seconds. The time shall
> >           be doubled for each consecutive retry.
>
> >           Any other event received in the Idle state is ignored.
>
>
>
> > At 11:10 AM 1/16/2002 -0800, you wrote:
>
> >>Sue,
> >>
> >>  Introduction of the IdleHold does change the FSM,
> >>  and I thought we wanted the spec to reflect the current
> >>  running code as much as possible.
> >>
> >>  I agree with Russ and Ishi---the new state does not
> >>  seem to be necessary, instead it could be as easy
> >>  as holding the session in Idle and giving clue on
> >>  how to make the delay exponential. I don't think
> >>  there's an interoperability issue if people decide
> >>  to keep the session in Idle using different internal
> >>  mechanisms.
> >>
> >>  Regards,
> >>
> >>--
> >>Alex Zinin
> >>
> >>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:
> >>
> >> > Kunihiro:
> >>
> >> > We are not changing the FSM so I would be surprised if the change
> >> > was anything but modest. Usually specifications with "no big" deal get
> >> > interpreted differently.  Inter-operable code means you tie down the
> >> details.
> >>
> >> > The comment was on the clarity of the specification.
> >>
> >> > If you have a specific comment on the text of the state machine,
> >> > can you propose the concerns you have as a revision to the text.
> >>
> >> > Sue
> >>
> >> > PS -- I just love last call on a draft...  It's when
> >> >        everyone finally reads a new section  ;-)...
> >>
> >>
> >> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
> >> >> >> > Is the expoential backoff in the FSM in current implementations?
> >> >> >>
> >> >> >> I guess we are going to find this out as part of the implementation
> >> >> >> report. And if it is not in (at least two) current implementations,
> >> >> >> we'll take it out of the text.
> >> >> >
> >> >> >I implemented Cease subcode in zebra-0.92a but not exponential 
> backoff.
> >> >> >I checked that new subcode does not put other BGP stack in trouble
> >> >> >(checked Cisco and Juniper).
> >> >>
> >> >>First of all, sorry for talking about specific implementation.  In
> >> >>Zebra implementation we've implemented Cease subcode.  The code is in
> >> >>CVS repository.  I'll prepare a release version for that.
> >> >>
> >> >>And also we've implemented exponetial backoff.  It is done without
> >> >>introducing new FSM status.  It is not a big deal.  Just check a flag
> >> >>in a few functions.
> >>
> >>
> >> >>Exponential backoff is a good feature.  I can't understand why it
> >> >>require change to FSM.

--=====================_37894649==_
Content-Type: application/msword; name="statemt.doc";
 x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="statemt.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAgAAAAAAAAAAA
EAAAggAAAAEAAAD+////AAAAAH4AAAB/AAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
--=====================_37894649==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_37894649==_--

Date: Thu, 17 Jan 2002 09:14:13 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: randy Bush <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Sue,

 To clarify my position: I think that recommendation for an
 exponential back-off is a good thing and solves a real
 problem. However, I think that the IdleHold state should not
 be in the FSM because:

   1) It seems to be redundant. See (*) below.
   2) It introduces changes to the base FSM to account for
      a feature of an optional nature. People who didn't
      implement it would be put in a non-compliant position,
      people who won't implement it will have to take things
      out of the FSM.
   3) I am under impression (though I might be wrong) that
      it does not match the majority of deployed implementations
      that do not have this state and hence would ago against the
      objective of this spec review round.
 ---
 *) When it comes to FSMs, one almost always can achieve the same
    results by either using an existing state with flags or by adding
    another state. It is often hard to decide which approach to follow.
    One simple test I find useful is to see how different periodic
    activities, packet and event processing are for the two states.
    If there is a considerable difference, separate states are most
    probably a good idea. In our case, the two states are practically
    the same---we don't do anything on a periodic basis (no messages,
    no outbound connections), we do not accept incoming connections,
    we ignore all events but Start. The difference is essentially in
    the reason we get to either state, which affects the name of
    the state and when the Start event is generated. IMHO it does not
    justify a new state, but that's my personal opinion :) I think
    the original text from -12 (maybe revised a bit) should be good
    enough...
    
-- 
Alex Zinin

Thursday, January 17, 2002, 5:51:35 AM, Susan Hares wrote:

> Alex and Randy:

> Let's go back to first principles here on the FSM?

> 1st)  The original text is below from draft-12.

>     This explanation gives "flag" that has implications
>     for the full state machine.   The definition of
>     state machines that Alex proposes, is all inputs
>     and all actions are determined by state machine in
>     clear text.

> 2nd) Is the bug real?

>     The text was fixing a " persistent bgp flapping"
>     bug.  According to the text there is a
>     state within a state with fairly vague
>     descriptions.

> The second question belongs to Randy, since he wears 2 hats (Operations
> and Routing temp AD), was this a real problem?  Has it gone away?

> 1) At least one routing vendor doesn't implement it [cisco]
>     and I know this vendor is utilized in BGP peering sessions
>     in the network.

> 2) What was the operational concern this text implies?

> If there is no operational issue and no operational usage,
> return to the original FSM text and out the comments on
> "hold down."

> So, Randy and all other operators - Is the problem it describes real?
> Does anyone need it?   Let's answer that question first.

> Sue Hares

> ----------------------

>            If a BGP speaker detects an error, it shuts down the connection
>           and changes its state to Idle. Getting out of the Idle state
>           requires generation of the Start event.  If such an event is
>           generated automatically, then persistent BGP errors may result
>           in persistent flapping of the speaker.  To avoid such a
>           condition it is recommended that Start events should not be
>           generated immediately for a peer that was previously
>           transitioned to Idle due to an error. For a peer that was
>           previously transitioned to Idle due to an error, the time

> Expiration Date July 2001                                      [Page 31]

> RFC DRAFT                                                   January 2001

>           between consecutive generation of Start events, if such events
>           are generated automatically, shall exponentially increase. The
>           value of the initial timer shall be 60 seconds. The time shall
>           be doubled for each consecutive retry.

>           Any other event received in the Idle state is ignored.

> At 11:10 AM 1/16/2002 -0800, you wrote:

>>Sue,
>>
>>  Introduction of the IdleHold does change the FSM,
>>  and I thought we wanted the spec to reflect the current
>>  running code as much as possible.
>>
>>  I agree with Russ and Ishi---the new state does not
>>  seem to be necessary, instead it could be as easy
>>  as holding the session in Idle and giving clue on
>>  how to make the delay exponential. I don't think
>>  there's an interoperability issue if people decide
>>  to keep the session in Idle using different internal
>>  mechanisms.
>>
>>  Regards,
>>
>>--
>>Alex Zinin
>>
>>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:
>>
>> > Kunihiro:
>>
>> > We are not changing the FSM so I would be surprised if the change
>> > was anything but modest. Usually specifications with "no big" deal get
>> > interpreted differently.  Inter-operable code means you tie down the 
>> details.
>>
>> > The comment was on the clarity of the specification.
>>
>> > If you have a specific comment on the text of the state machine,
>> > can you propose the concerns you have as a revision to the text.
>>
>> > Sue
>>
>> > PS -- I just love last call on a draft...  It's when
>> >        everyone finally reads a new section  ;-)...
>>
>>
>> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
>> >> >> > Is the expoential backoff in the FSM in current implementations?
>> >> >>
>> >> >> I guess we are going to find this out as part of the implementation
>> >> >> report. And if it is not in (at least two) current implementations,
>> >> >> we'll take it out of the text.
>> >> >
>> >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
>> >> >I checked that new subcode does not put other BGP stack in trouble
>> >> >(checked Cisco and Juniper).
>> >>
>> >>First of all, sorry for talking about specific implementation.  In
>> >>Zebra implementation we've implemented Cease subcode.  The code is in
>> >>CVS repository.  I'll prepare a release version for that.
>> >>
>> >>And also we've implemented exponetial backoff.  It is done without
>> >>introducing new FSM status.  It is not a big deal.  Just check a flag
>> >>in a few functions.
>>
>>
>> >>Exponential backoff is a good feature.  I can't understand why it
>> >>require change to FSM.

Date: Thu, 17 Jan 2002 10:27:12 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: [email-masked]
Sender: [email-masked]

Greg:

The real question is:

         1) Was persistent BGP peer flapping a problem?
         2) Do ISPs need to track why their peers are flapping?
         3) How is it really used?

If the feature is:

         - not needed - stay with 1st state machine
         - if needed, we'll find out why it is needed.

Sue

At 07:08 PM 1/16/2002 -0500, Greg Hankins wrote:
>On Wed, Jan 16, 2002 at 11:10:47AM -0800, Alex Zinin wrote:
> > Introduction of the IdleHold does change the FSM,
> > and I thought we wanted the spec to reflect the current
> > running code as much as possible.
>
>Agreed.  Changing the FSM at this point doesn't seem like it is worth the
>impact that this change would have on existing implementations, given that
>there are other implementation-dependant ways of doing the same thing.
>
>A change in the FSM would make every BGP implementation and every piece of
>documentation written on BGP outdated.  I'm not saying that this shouldn't
>be done if, there is a valid technical reason.
>
>Maybe the exponential backoff parts could be published as a separate draft
>instead of including it in the base specification?
>
>Greg
>
>--
>Greg Hankins <[email-masked]> | Riverstone Networks, Inc.
>Corporate Systems Engineering             | 5200 Great America Parkway
>http://www.riverstonenet.com/             | Santa Clara, CA 95054
>+1 404 434 0355                           | +1 408 878 6500

Date: Thu, 17 Jan 2002 10:04:03 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd: IPv6 Router ID draft
Sender: [email-masked]

You'd have to ask, wouldn't you? :-) We can't do ipv6 only as far
as I know at this point, so ipv4 has to be configured/etc.
Perhaps an informational would be better than an bcp, since there
doesn't seem to be a good number of implementations of ipv6 only
speakers (?), so while the issue is interesting and useful, there
isn't any 'best practice' at this point?

Russ

On Thu, 17 Jan 2002, Susan Hares wrote:

> Russ:
> 
> Thank you for your vote on this matter.  Can you tell
> what your implementations does for Router-ID for IP v6 networks?
> 
> Sue Hares
> 
> 
> At 09:11 AM 1/17/2002 -0500, Russ White wrote:
> 
> >I don't see any reason not to make it a working group BCP
> >doc....
> >
> >Russ
> >
> >On Thu, 17 Jan 2002, Susan Hares wrote:
> >
> > >
> > > In Dec 13th IETF meeting (IETF 52), this draft was
> > > presented as a BCP draft for IP v6.   Should this
> > > draft be a working group draft?   A discussion period
> > > for this will last for 2 weeks, and close on 1/31/02.
> > >
> > > The Minutes and presentations are available at:
> > >
> > > http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml
> > >
> > >
> > > Please make your comments on this becoming a working group
> > > draft destined to be a Best Common Practice document.
> > >
> > >
> > > Sue Hares
> > >
> > > --------------------------
> > >
> > > >I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> > > >and I would like to request this working group to consider it as
> > > >a wg item candidate for BCP.
> > > >
> > > >     - Alain.
> > > >
> > > >
> > > >A New Internet-Draft is available from the on-line Internet-Drafts
> > > >directories.
> > > >
> > > >
> > > >         Title           : BGP4 router ID for IPv6 only routers
> > > >         Author(s)       : F. Dupont, A. Durand
> > > >         Filename        :
> > > >draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> > > >         Pages           : 3
> > > >         Date            : 15-Jan-02
> > > >
> > > >BGP4 [1] uses a 32 bit field to identify router (the so called
> > > >'router-IDs'). In IPv4 domain, an IPv4 address of the router
> > > >is typically used in this field.
> > > >In an IPv6 routing domain, routers may very well not have any IPv4
> > > >Addresses. This document provides a simple way to form a globally
> > > >Unique ID in such a case.
> > > >
> > > >A URL for this Internet-Draft is:
> > > >http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-ro 
> > uterid-01.txt
> > >
> > >
> >
> >_____________________________
> >[email-masked] <>< Grace Alone
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Thu, 17 Jan 2002 09:57:01 -0500
To: Russ White <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Fwd: IPv6 Router ID draft
Cc: Susan Hares <[email-masked]>, [email-masked]
Sender: [email-masked]

Russ:

Thank you for your vote on this matter.  Can you tell
what your implementations does for Router-ID for IP v6 networks?

Sue Hares

At 09:11 AM 1/17/2002 -0500, Russ White wrote:

>I don't see any reason not to make it a working group BCP
>doc....
>
>Russ
>
>On Thu, 17 Jan 2002, Susan Hares wrote:
>
> >
> > In Dec 13th IETF meeting (IETF 52), this draft was
> > presented as a BCP draft for IP v6.   Should this
> > draft be a working group draft?   A discussion period
> > for this will last for 2 weeks, and close on 1/31/02.
> >
> > The Minutes and presentations are available at:
> >
> > http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml
> >
> >
> > Please make your comments on this becoming a working group
> > draft destined to be a Best Common Practice document.
> >
> >
> > Sue Hares
> >
> > --------------------------
> >
> > >I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> > >and I would like to request this working group to consider it as
> > >a wg item candidate for BCP.
> > >
> > >     - Alain.
> > >
> > >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >
> > >
> > >         Title           : BGP4 router ID for IPv6 only routers
> > >         Author(s)       : F. Dupont, A. Durand
> > >         Filename        :
> > >draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> > >         Pages           : 3
> > >         Date            : 15-Jan-02
> > >
> > >BGP4 [1] uses a 32 bit field to identify router (the so called
> > >'router-IDs'). In IPv4 domain, an IPv4 address of the router
> > >is typically used in this field.
> > >In an IPv6 routing domain, routers may very well not have any IPv4
> > >Addresses. This document provides a simple way to form a globally
> > >Unique ID in such a case.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-ro 
> uterid-01.txt
> >
> >
>
>_____________________________
>[email-masked] <>< Grace Alone

Date: Thu, 17 Jan 2002 09:48:16 -0500
From: Jeffrey Haas <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Subject: Re: Maximum Prefix Limit
Sender: [email-masked]

On Thu, Jan 17, 2002 at 07:09:15PM +0530, Manav Bhatia wrote:
> Does it mean that the next time the session comes up there is no
> ipv4/multicast capability supported? Once again, this is implementation
> specific and we could work both ways.

Exactly.  But the MIB just needs to provide the appropriate ability
to cover both situations.

Just to postulate a vendor-specific for-example, Cisco scopes
many of their commands under an address-family scope.  If prefix
limits were setable from the scope rather than globally (don't
know if they are, don't feel like diving throught the TAC
to figure it out), then the MIB needs to support it.

Even if they don't now, they may in the future.

> The session comes up after idle timer
> hoping that the sys admin would have looked into the matter OR we dont
> support ipv4/multicast (or which ever SAFI limit exceeded).

Vendor dependant.  Allowing a router to be used for transport of
some AFI/SAFI which is stable may be reasonable while yet protecting
the rest of the network from an "unstable" variation.

> Manav

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 17 Jan 2002 09:11:33 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd: IPv6 Router ID draft
Sender: [email-masked]

I don't see any reason not to make it a working group BCP
doc.... 

Russ

On Thu, 17 Jan 2002, Susan Hares wrote:

> 
> In Dec 13th IETF meeting (IETF 52), this draft was
> presented as a BCP draft for IP v6.   Should this
> draft be a working group draft?   A discussion period
> for this will last for 2 weeks, and close on 1/31/02.
> 
> The Minutes and presentations are available at:
> 
> http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml
> 
> 
> Please make your comments on this becoming a working group
> draft destined to be a Best Common Practice document.
> 
> 
> Sue Hares
> 
> --------------------------
> 
> >I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> >and I would like to request this working group to consider it as
> >a wg item candidate for BCP.
> >
> >     - Alain.
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >
> >         Title           : BGP4 router ID for IPv6 only routers
> >         Author(s)       : F. Dupont, A. Durand
> >         Filename        :
> >draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> >         Pages           : 3
> >         Date            : 15-Jan-02
> >
> >BGP4 [1] uses a 32 bit field to identify router (the so called
> >'router-IDs'). In IPv4 domain, an IPv4 address of the router
> >is typically used in this field.
> >In an IPv6 routing domain, routers may very well not have any IPv4
> >Addresses. This document provides a simple way to form a globally
> >Unique ID in such a case.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Thu, 17 Jan 2002 09:05:43 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Fwd: IPv6 Router ID draft
Sender: [email-masked]

In Dec 13th IETF meeting (IETF 52), this draft was
presented as a BCP draft for IP v6.   Should this
draft be a working group draft?   A discussion period
for this will last for 2 weeks, and close on 1/31/02.

The Minutes and presentations are available at:

http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml

Please make your comments on this becoming a working group
draft destined to be a Best Common Practice document.

Sue Hares

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

>I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
>and I would like to request this working group to consider it as
>a wg item candidate for BCP.
>
>     - Alain.
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>         Title           : BGP4 router ID for IPv6 only routers
>         Author(s)       : F. Dupont, A. Durand
>         Filename        :
>draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
>         Pages           : 3
>         Date            : 15-Jan-02
>
>BGP4 [1] uses a 32 bit field to identify router (the so called
>'router-IDs'). In IPv4 domain, an IPv4 address of the router
>is typically used in this field.
>In an IPv6 routing domain, routers may very well not have any IPv4
>Addresses. This document provides a simple way to form a globally
>Unique ID in such a case.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt

Date: Thu, 17 Jan 2002 09:02:36 -0500
To: Alex Zinin <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: Susan Hares <[email-masked]>, Kunihiro Ishiguro <[email-masked]>, Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Alex:

I think we need to query the people who operate
the network about the problem this text was trying to solve.
If the problem is still important, the problem
will guide us in determining how this should be solved.

The problem definition that the specification
hints at is:

a) automatic restarts of bgp sessions
    were being enabled on certain routers,

b) the repeated OPENs were causing problems,

c) People wanted to "recommend" (a strong word, but
    not as strong as must), it must have been important.

If it is important, then is it important
that all routers back off in the same way.
The earlier specification wording would suggest that
to be true.  If not, it is not an inter-operability
issue.

If it is important, then it is important to know
when your routers are in "back-off" state to
operate the network.

At this time, I'd like to hear from anyone who
uses this function or had this problem.

Sue

At 11:10 AM 1/16/2002 -0800, Alex Zinin wrote:

>Sue,
>
>  Introduction of the IdleHold does change the FSM,
>  and I thought we wanted the spec to reflect the current
>  running code as much as possible.
>
>  I agree with Russ and Ishi---the new state does not
>  seem to be necessary, instead it could be as easy
>  as holding the session in Idle and giving clue on
>  how to make the delay exponential. I don't think
>  there's an interoperability issue if people decide
>  to keep the session in Idle using different internal
>  mechanisms.

>  Regards,
>
>--
>Alex Zinin
>
>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:
>
> > Kunihiro:
>
> > We are not changing the FSM so I would be surprised if the change
> > was anything but modest. Usually specifications with "no big" deal get
> > interpreted differently.  Inter-operable code means you tie down the 
> details.
>
> > The comment was on the clarity of the specification.
>
> > If you have a specific comment on the text of the state machine,
> > can you propose the concerns you have as a revision to the text.
>
> > Sue
>
> > PS -- I just love last call on a draft...  It's when
> >        everyone finally reads a new section  ;-)...
>
>
> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
> >> >> > Is the expoential backoff in the FSM in current implementations?
> >> >>
> >> >> I guess we are going to find this out as part of the implementation
> >> >> report. And if it is not in (at least two) current implementations,
> >> >> we'll take it out of the text.
> >> >
> >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
> >> >I checked that new subcode does not put other BGP stack in trouble
> >> >(checked Cisco and Juniper).
> >>
> >>First of all, sorry for talking about specific implementation.  In
> >>Zebra implementation we've implemented Cease subcode.  The code is in
> >>CVS repository.  I'll prepare a release version for that.
> >>
> >>And also we've implemented exponetial backoff.  It is done without
> >>introducing new FSM status.  It is not a big deal.  Just check a flag
> >>in a few functions.
>
>
> >>Exponential backoff is a good feature.  I can't understand why it
> >>require change to FSM.

Date: Thu, 17 Jan 2002 08:51:35 -0500
To: Alex Zinin <[email-masked]>, randy Bush <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: [email-masked]
Sender: [email-masked]

Alex and Randy:

Let's go back to first principles here on the FSM?

1st)  The original text is below from draft-12.

    This explanation gives "flag" that has implications
    for the full state machine.   The definition of
    state machines that Alex proposes, is all inputs
    and all actions are determined by state machine in
    clear text.

2nd) Is the bug real?

    The text was fixing a " persistent bgp flapping"
    bug.  According to the text there is a
    state within a state with fairly vague
    descriptions.

The second question belongs to Randy, since he wears 2 hats (Operations
and Routing temp AD), was this a real problem?  Has it gone away?

1) At least one routing vendor doesn't implement it [cisco]
    and I know this vendor is utilized in BGP peering sessions
    in the network.

2) What was the operational concern this text implies?

If there is no operational issue and no operational usage,
return to the original FSM text and out the comments on
"hold down."

So, Randy and all other operators - Is the problem it describes real?
Does anyone need it?   Let's answer that question first.

Sue Hares

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

           If a BGP speaker detects an error, it shuts down the connection
          and changes its state to Idle. Getting out of the Idle state
          requires generation of the Start event.  If such an event is
          generated automatically, then persistent BGP errors may result
          in persistent flapping of the speaker.  To avoid such a
          condition it is recommended that Start events should not be
          generated immediately for a peer that was previously
          transitioned to Idle due to an error. For a peer that was
          previously transitioned to Idle due to an error, the time

Expiration Date July 2001                                      [Page 31]

RFC DRAFT                                                   January 2001

          between consecutive generation of Start events, if such events
          are generated automatically, shall exponentially increase. The
          value of the initial timer shall be 60 seconds. The time shall
          be doubled for each consecutive retry.

          Any other event received in the Idle state is ignored.

At 11:10 AM 1/16/2002 -0800, you wrote:

>Sue,
>
>  Introduction of the IdleHold does change the FSM,
>  and I thought we wanted the spec to reflect the current
>  running code as much as possible.
>
>  I agree with Russ and Ishi---the new state does not
>  seem to be necessary, instead it could be as easy
>  as holding the session in Idle and giving clue on
>  how to make the delay exponential. I don't think
>  there's an interoperability issue if people decide
>  to keep the session in Idle using different internal
>  mechanisms.
>
>  Regards,
>
>--
>Alex Zinin
>
>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:
>
> > Kunihiro:
>
> > We are not changing the FSM so I would be surprised if the change
> > was anything but modest. Usually specifications with "no big" deal get
> > interpreted differently.  Inter-operable code means you tie down the 
> details.
>
> > The comment was on the clarity of the specification.
>
> > If you have a specific comment on the text of the state machine,
> > can you propose the concerns you have as a revision to the text.
>
> > Sue
>
> > PS -- I just love last call on a draft...  It's when
> >        everyone finally reads a new section  ;-)...
>
>
> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
> >> >> > Is the expoential backoff in the FSM in current implementations?
> >> >>
> >> >> I guess we are going to find this out as part of the implementation
> >> >> report. And if it is not in (at least two) current implementations,
> >> >> we'll take it out of the text.
> >> >
> >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
> >> >I checked that new subcode does not put other BGP stack in trouble
> >> >(checked Cisco and Juniper).
> >>
> >>First of all, sorry for talking about specific implementation.  In
> >>Zebra implementation we've implemented Cease subcode.  The code is in
> >>CVS repository.  I'll prepare a release version for that.
> >>
> >>And also we've implemented exponetial backoff.  It is done without
> >>introducing new FSM status.  It is not a big deal.  Just check a flag
> >>in a few functions.
>
>
> >>Exponential backoff is a good feature.  I can't understand why it
> >>require change to FSM.

Date: Thu, 17 Jan 2002 08:34:11 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: graceful restart
Sender: [email-masked]

On Wed, Jan 16, 2002 at 07:17:08PM -0600, [email-masked] wrote:
> a question on draft-ietf-idr-restart-01.txt.  Why were exactly 12 bits 
> chosen for the "Restart time in seconds"? What failures are supposed to 
> be repaired within 2^12 seconds ? How shall one proceed with failures 
> that need more time to be repaired ?

If you need more than 60 minutes to restart your peering session
something is horribly wrong anyway.

ANd I'd seriously hope that the stale routes don't stay stale that
long...

> Claus

-- 
Jeff Haas 
NextHop Technologies

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: "Jeffrey Haas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Maximum Prefix Limit
Date: Thu, 17 Jan 2002 19:09:15 +0530
Sender: [email-masked]

| > The session in any case will be torn even if the threshold for a single
| > SAFI crosses. Does it make much sense in saying that," i will accept x
SAFI
| > 1 routes, y SAFI 2 routes, etc"?
|
| No, but it may make sense to say "I'll accept X ipv4/unicast routes, but
| if I get > Y ipv4/multicast routes, drop the peer session, potentially
| removing the ipv4/multicast capability".

Does it mean that the next time the session comes up there is no
ipv4/multicast capability supported? Once again, this is implementation
specific and we could work both ways. The session comes up after idle timer
hoping that the sys admin would have looked into the matter OR we dont
support ipv4/multicast (or which ever SAFI limit exceeded).

Regards,
Manav

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Thu, 17 Jan 2002 08:29:40 -0500
From: Jeffrey Haas <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Subject: Re: Maximum Prefix Limit
Sender: [email-masked]

On Thu, Jan 17, 2002 at 10:35:23AM +0530, Manav Bhatia wrote:
> Does it really make sense to have seperate counters for each SAFI?

The MIB needs to allow for implementations tomake that choice.
A per AFI/SAFI counter may be reasonable.  A per AFI counter is also
reasonable.

> The session in any case will be torn even if the threshold for a single
> SAFI crosses. Does it make much sense in saying that," i will accept x SAFI
> 1 routes, y SAFI 2 routes, etc"?

No, but it may make sense to say "I'll accept X ipv4/unicast routes, but
if I get > Y ipv4/multicast routes, drop the peer session, potentially
removing the ipv4/multicast capability".

> Manav

-- 
Jeff Haas 
NextHop Technologies

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: "Jeffrey Haas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Maximum Prefix Limit
Date: Thu, 17 Jan 2002 10:35:23 +0530
Sender: [email-masked]

| > - Should there be counters for individual SAFI or should there be a
| > consolidated one for the entire AFI?
|
| Those of us working on the v2MIB would like to hear opinions on this!

Does it really make sense to have seperate counters for each SAFI?
The session in any case will be torn even if the threshold for a single
SAFI crosses. Does it make much sense in saying that," i will accept x SAFI
1 routes, y SAFI 2 routes, etc"?

Rather than this there should be a single max limit for each AFI family
which when violated should tear down the BGP session.

Regards,
Manav

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: Vivek Menezes <[email-masked]>
To: "'Enke Chen'" <[email-masked]>, Vivek Menezes <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: graceful restart 
Date: Wed, 16 Jan 2002 19:00:43 -0800
Sender: [email-masked]

yeah I guess milliseconds makes no sense especially considering that the
keepalive timers are in seconds. Do you think adding in my suggestion on the
restart bit makes sense though.

Vivek.

> -----Original Message-----
> From: Enke Chen [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 5:43 PM
> To: Vivek Menezes
> Cc: [email-masked]'; [email-masked]
> Subject: Re: graceful restart 
> 
> 
> > Message-ID: 
> <[email-masked]>
> > From: Vivek Menezes <[email-masked]>
> > To: "[email-masked]'" <[email-masked]>,
> > 	[email-masked]
> > Subject: RE: graceful restart
> > Date: Wed, 16 Jan 2002 17:27:14 -0800
> > MIME-Version: 1.0
> > 
> > I think 28 bits makes more sense. Its better that the time were in
> > milliseconds. In the future 
> > routers might be able to restart in milliseconds :-)
> 
> Does millisecond make sense considering all other timers in 
> the BGP spec
> are in seconds and even minutes?   -- Enke
> 
> > I sent this message a while ago. I havent heard from the authors. 
> > 
> > in the Restart Flags section in section 5 of the restart 
> draft it would be
> > better if we added
> > 
> > " when the receiving system has not restarted and it 
> receives the restart
> > flag with the bit not set it should not wait for the 
> end-of-rib marker 
> > from the speaker before advertising routing information to 
> the speaker" or
> > equivalently
> > "if a system doesnt restart it should ignore the restart 
> flag for the
> > purposes of advertising routes"
> > 
> > I think its better if we made it clear.
> > 
> > Also the restart time in seconds could be changed to a 28 
> bit time in
> > milliseconds.
> > 
> > Vivek.
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, January 16, 2002 5:17 PM
> > > To: [email-masked]
> > > Subject: graceful restart
> > > 
> > > 
> > > Hi
> > > 
> > > a question on draft-ietf-idr-restart-01.txt.  Why were 
> > > exactly 12 bits 
> > > chosen for the "Restart time in seconds"? What failures are 
> > > supposed to 
> > > be repaired within 2^12 seconds ? How shall one proceed 
> with failures 
> > > that need more time to be repaired ?
> > > 
> > > Claus
> > > 
> > > 
> > >  
> > > 
> 

From: Randy Bush <[email-masked]>
To: Alex Zinin <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Date: Wed, 16 Jan 2002 18:54:53 -0800
Sender: [email-masked]

> if the introduction of idlehold makes life clearer for implementors, yet
> it changes the fsm but not in incompatible ways (i.e. old would interop
> with new and wire looks the same, as jeff asserts.  maybe sufficient
> sushi could convince an area director not to ding the progress status of
> the document.

it looks to be a real change.  my bad.  typed on airplane and did not check
fsa.

randy

Date: Wed, 16 Jan 2002 18:52:26 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Randy Bush <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Randy,

> if the introduction of idlehold makes life clearer for implementors,

This is what I'm not sure about...

Controlling [existing] Start event generation that lets the FSM
out of the [existing] Idle state seems easier than introducing,
documenting, coding, and checking of a new one...

Alex.

> yet
> it changes the fsm but not in incompatible ways (i.e. old would interop
> with new and wire looks the same, as jeff asserts.  maybe sufficient
> sushi could convince an area director not to ding the progress status of
> the document.

> randy

Date: Wed, 16 Jan 2002 18:44:44 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], Susan Hares <[email-masked]>
Subject: Re: Comments on FSM
Sender: [email-masked]

Kunihiro,

> Instead of IdleHold timer we should explicitly mention about Start
> timer.  It is already implicitly used in RFC1771.  It is almost same
> as IdleHold timer but hopefully does not have impact on current
> implementation.

Or just say that implementations may use internal mechanisms
to generate the Start event and encourage people to implement
exponential holddown.

> We don't need Keep Idle flag.  Instead of that just stop Start timer.
> This mechanism can be used not only exponential backoff but also
> administratively shutdown or maximum prefix overflow.  So let's keep
> it simple.

Agreed.

> In IdleHold state there is a description for local limit of
> IdleHoldTimer.

>>         Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
>>         the local limit the "Keep Idle" flag is set.

> This should be clearly defined.  For example StartTimer Ceiling.

Not sure if we even need this. See above.

> Difference between manual start and auto start is small.  I'm not sure
> separating Start event into Manual start event and Auto start event is
> good idea or not.

Yes, looks like it is the same event for FSM.
If so, it should be one event with two ways of generation.

> So my proposal is liek this.

> Status  : No new status
> Timer   : Start timer
> Variable: StartTimer
>           StartTimer Ceiling
>           Connect Retry Count

> (Possible addition
> Event   : Manual start
>           Auto start)

> IMHO, this topic needs more discussion and clarification.

>>Maybe the exponential backoff parts could be published as a separate draft
>>instead of including it in the base specification?

> I agrree with Greg.  A separate draft for exponential back off make
> sense.  I think even we have a separate draft for exponential back
> off, previous draft bgp4-16 FSM description still work fine with that.

No strong opinion on this.
If exponential back-off is optional and has been implemented
in some implementations, I think it can stay in the main spec.

Alex.

From: Randy Bush <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Cease subcode
Date: Wed, 16 Jan 2002 17:15:36 -0800
Sender: [email-masked]

>  Introduction of the IdleHold does change the FSM,
>  and I thought we wanted the spec to reflect the current
>  running code as much as possible.
>  
>  I agree with Russ and Ishi---the new state does not
>  seem to be necessary, instead it could be as easy
>  as holding the session in Idle and giving clue on
>  how to make the delay exponential. I don't think
>  there's an interoperability issue if people decide
>  to keep the session in Idle using different internal
>  mechanisms.

if the introduction of idlehold makes life clearer for implementors, yet
it changes the fsm but not in incompatible ways (i.e. old would interop
with new and wire looks the same, as jeff asserts.  maybe sufficient
sushi could convince an area director not to ding the progress status of
the document.

randy

Date: Wed, 16 Jan 2002 16:54:30 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked], Susan Hares <[email-masked]>
Subject: Re: Comments on FSM
Sender: [email-masked]

Thanks Alex.  I've check bgp4-17 FSM.  Below new items are added.

Status  : IdleHold
Timer   : IdleHold timer
Variable: IdleHoldtimer
          IdleHoldtimer ceiling mentioned as "local limit"
          ConnectRetryCnt
Event   : Manual start
          Auto start
Flag    : Keep Idle

Instead of IdleHold timer we should explicitly mention about Start
timer.  It is already implicitly used in RFC1771.  It is almost same
as IdleHold timer but hopefully does not have impact on current
implementation.

We don't need Keep Idle flag.  Instead of that just stop Start timer.
This mechanism can be used not only exponential backoff but also
administratively shutdown or maximum prefix overflow.  So let's keep
it simple.

In IdleHold state there is a description for local limit of
IdleHoldTimer.

>         Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
>         the local limit the "Keep Idle" flag is set.

This should be clearly defined.  For example StartTimer Ceiling.

Difference between manual start and auto start is small.  I'm not sure
separating Start event into Manual start event and Auto start event is
good idea or not.  So my proposal is liek this.

Status  : No new status
Timer   : Start timer
Variable: StartTimer
          StartTimer Ceiling
          Connect Retry Count

(Possible addition
Event   : Manual start
          Auto start)

IMHO, this topic needs more discussion and clarification.

>Maybe the exponential backoff parts could be published as a separate draft
>instead of including it in the base specification?

I agrree with Greg.  A separate draft for exponential back off make
sense.  I think even we have a separate draft for exponential back
off, previous draft bgp4-16 FSM description still work fine with that.
-- 
Kunihiro Ishiguro

To: Vivek Menezes <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: graceful restart 
Date: Wed, 16 Jan 2002 17:43:24 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Message-ID: <[email-masked]>
> From: Vivek Menezes <[email-masked]>
> To: "[email-masked]'" <[email-masked]>,
> 	[email-masked]
> Subject: RE: graceful restart
> Date: Wed, 16 Jan 2002 17:27:14 -0800
> MIME-Version: 1.0
> 
> I think 28 bits makes more sense. Its better that the time were in
> milliseconds. In the future 
> routers might be able to restart in milliseconds :-)

Does millisecond make sense considering all other timers in the BGP spec
are in seconds and even minutes?   -- Enke

> I sent this message a while ago. I havent heard from the authors. 
> 
> in the Restart Flags section in section 5 of the restart draft it would be
> better if we added
> 
> " when the receiving system has not restarted and it receives the restart
> flag with the bit not set it should not wait for the end-of-rib marker 
> from the speaker before advertising routing information to the speaker" or
> equivalently
> "if a system doesnt restart it should ignore the restart flag for the
> purposes of advertising routes"
> 
> I think its better if we made it clear.
> 
> Also the restart time in seconds could be changed to a 28 bit time in
> milliseconds.
> 
> Vivek.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, January 16, 2002 5:17 PM
> > To: [email-masked]
> > Subject: graceful restart
> > 
> > 
> > Hi
> > 
> > a question on draft-ietf-idr-restart-01.txt.  Why were 
> > exactly 12 bits 
> > chosen for the "Restart time in seconds"? What failures are 
> > supposed to 
> > be repaired within 2^12 seconds ? How shall one proceed with failures 
> > that need more time to be repaired ?
> > 
> > Claus
> > 
> > 
> >  
> > 

From: Vivek Menezes <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: graceful restart
Date: Wed, 16 Jan 2002 17:27:14 -0800
Sender: [email-masked]

I think 28 bits makes more sense. Its better that the time were in
milliseconds. In the future 
routers might be able to restart in milliseconds :-)
I sent this message a while ago. I havent heard from the authors. 

in the Restart Flags section in section 5 of the restart draft it would be
better if we added

" when the receiving system has not restarted and it receives the restart
flag with the bit not set it should not wait for the end-of-rib marker 
from the speaker before advertising routing information to the speaker" or
equivalently
"if a system doesnt restart it should ignore the restart flag for the
purposes of advertising routes"

I think its better if we made it clear.

Also the restart time in seconds could be changed to a 28 bit time in
milliseconds.

Vivek.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 5:17 PM
> To: [email-masked]
> Subject: graceful restart
> 
> 
> Hi
> 
> a question on draft-ietf-idr-restart-01.txt.  Why were 
> exactly 12 bits 
> chosen for the "Restart time in seconds"? What failures are 
> supposed to 
> be repaired within 2^12 seconds ? How shall one proceed with failures 
> that need more time to be repaired ?
> 
> Claus
> 
> 
>  
> 

Date: Wed, 16 Jan 2002 19:17:08 -0600
Subject: graceful restart
From: [email-masked]
To: [email-masked]
Sender: [email-masked]

Hi

a question on draft-ietf-idr-restart-01.txt.  Why were exactly 12 bits 
chosen for the "Restart time in seconds"? What failures are supposed to 
be repaired within 2^12 seconds ? How shall one proceed with failures 
that need more time to be repaired ?

Claus

 

To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: draft-chen-bgp-identifier-01.txt
Date: Wed, 16 Jan 2002 16:35:05 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Yakov and Sue:
I would like to request this draft be accepted as an IDR WG document.

Thank you in advance for your consideration.  -- Enke

------- Forwarded Message

Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-identifier-01.txt
Date: Mon, 14 Jan 2002 10:39:16 -0500
Sender: [email-masked]

- --NextPart

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

	Title		: AS-wide Unique BGP Identifier for BGP-4
	Author(s)	: E. Chen, J. Yuan
	Filename	: draft-chen-bgp-identifier-01.txt
	Pages		: 4
	Date		: 11-Jan-02
	
To deal with situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP
specification does not introduce any backward compatibility issue.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-identifier-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-chen-bgp-identifier-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Date: Wed, 16 Jan 2002 16:29:16 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Cc: Susan Hares <[email-masked]>
Subject: Comments on FSM
Sender: [email-masked]

Sue,

 Some comments on the FSM text below.
 I constrained myself to mostly editorial changes,
 as I'd prefer to see the FSM description in a
 different form (the one I'm working on).

 Also, I think that the connection collision related
 issue brought by Dennis is still not addressed.
 Frankly, I'm not sure how well this can be addressed
 if the spec continues to treat competing transport
 connections for the same peer as separate BGP sessions
 and FSMs...

 Thanks,
 
-- 
Alex Zinin

General notes:

 - there should be a separate section describing all
   session attributes (such as timers and flags) involved
   in FSM operation.
 
 - there should be a separate subsection where all events
   would be formally defined and named. Defined names
   should then be used in the text.

 - there should be a section specifically describing 
   processing of incoming transport connections

 - I think IdleHold should go. (stet'ed the text for now)

 - Processing of manual Stop in Established lacked
   a NOTIFICATION message.

 - Thorough check of FSM text correctness is hard because
   events are not documented and one would need to
   parse the text and formalize the description to do so,
   i.e., pretty much what I'm doing with the other
   representation.

 - I think we need a state transition diagram (not table)
   in the text for better visualization (I'm going to
   have one). This won't be possible without proper
   event documentation.

 - NOTIFICATION codes and subcodes need verification.
   (some changes are in the text.)

 - Sessions "killed" due to connection collision should
   not go to Idle, but be destroyed. (Not addressed in
   the text below.)

Below is corrected text of the section . You'll be able to
do a "diff -u" or something against the original one to
see line-by-line changes.

8. BGP Finite State machine.

   This section specifies BGP operation in terms of a Finite State
   Machine (FSM) of a peering session. Following is a brief summary
   and overview of BGP operations by state as determined by this FSM.

   /* a "brief summary" of FSM? There should be a complete one */

   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. FSMs created
   for configured peers are initially put in the Idle state. See section
   XXX for more information on incoming transport connection processing.

   Each FSM state with corresponding event processing rules is described
   below.
      
      Idle state:

         This is the initial state of the FSM. This state is also
         used to keep BGP sessions in the inactive state when    
         necessary. In this state BGP refuses all incoming BGP
         connections from the peer. No resources are allocated to
         the session.

         /* Here, I assume that the IdleHold will be removed and
          * Idle be used for session hold down
          */

         A manual start event is a start event initiated by an operator
         to initiate BGP session establishment. An automatic start event
         is a start event generated by the system.

         /* The above should go to the event description section
          */

         In response to a Start event (manual or automatic), the following
         steps are performed:

            - Allocate resources for the session,

            - Start the ConnectRetry timer (see note below),

            - Initiate an outbound transport connection to the peer,

            - Start listening for a connection that may be initiated
              by the peer,

            - Transition to Connect.

         NOTE: The exact value of the ConnectRetry timer is a local 
               matter, but it should be sufficiently large to allow TCP
               initialization.

         Any other event received in the IDLE state, is ignored.

         /* I have a problem with this. Until all events are properly
          * documented, saying "any other event" is inappropriate.
          */

Expiration Date July 2002                                      [Page 33]

RFC DRAFT                                                   January 2002

      IdleHold state:

      /* I think this state should go and Idle be used for the same
       * purpose with local mechanisms used to control how long
       * the session stays there... I'm skipping this state...
       */

         The IdleHold state keeps the system in "Idle" mode until a
         certain time period has passed or an operator intervenes to
         manually restart the connection.  This "IdleHold timeout"
         prevents persistent flapping of a BGP peering session.

         Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
         the local limit the "Keep Idle" flag is set.

         Upon receiving a Manual start, the local system:

            - clears the IdleHoldtimer,

            - clears "keep Idle" flag

            - initializes all BGP resources,

            - starts the ConnectRetry timer,

            - initiates a transport connection to the other BGP peer,

            - listens for a connection that may be initiated by the
            remote BGPPeer, and

            - changes its state to connect.

         Upon receiving a IdleHoldtimer expired event, the local system
         checks to see that the Keep Idle flag is set.  If the Keep Idle
         flag is set, the system stays in the "Idle Hold" state.

         If the Keep Idle flag is not set, the local system:

            - clears the IdleHoldtimer,

            - and transitions the state to Idle.

         Getting out of the IdleHoldstate requires either operator
         intervention via a manual start or the IdleHoldtimer to expire
         with the "Keep Idle" flag to be clear.

         Any other event received in the IdleHold state is ignored.

      Connect State:

         In this state, BGP has initiated an outbound transport
         connection and is waiting it to be completed.

Expiration Date July 2002                                      [Page 34]

RFC DRAFT                                                   January 2002

         If the transport connection succeeds, the following steps
         are performed:

            - Clear the ConnectRetry timer,

            - Complete initialization
              /* What does this really mean spec-wise? Just remove ? */

            - Send an Open message to the peer,

            - Set Hold timer to a large value (see note below)

            - Transition to OpenSent.

            /* Stop listening to the incoming connection here ? */

         NOTE: A hold timer value of 4 minutes is suggested.

         If the transport protocol connection fails (e.g.,
         retransmission timeout), the following steps are performed:

            - Restart the ConnectRetry timer,

            - Continue to listen for a connection that may be 
              initiated by the peer,

              /* Remove this and specify when I should stop
               * listening?
               */

            - Transition to Active state.

         In response to the ConnectRetry timer expired event, the local
         system performs the following steps:

            - Restart the ConnectRetry timer,

            - Initiate an outbound transport connection to the peer,

            - Continue to listen for a connection that may be initiated
              by the remote BGP peer, and

              /* Remove this and specify when I should stop
               * listening?
               */

            - Stay in Connect state.

         The start event (manual or automatic) is ignored in the Connect
         state.

         In response to any other event (initiated by the system or
         operator), the following steps are executed:

         /* Again, the same comment about "any other event"...*/

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

Expiration Date July 2002                                      [Page 35]

RFC DRAFT                                                   January 2002

            - Drop the transport connection,

            - Release resources allocated for the session,

            - Transition to IdleHoldstate /* Idle */

      Active State:

         In this state BGP is not actively initiating an outbound
         transport connection, but is trying to acquire a peer 
         by listening for and accepting an incoming one.

         If the local system does not allow BGP connections with
         unconfigured peers, then the local system rejects connections
         from IP addresses that are not configured peers, and remains
         in the Active state.

         If the transport connection succeeds, the following
         steps are performed:

            - Stop the ConnectRetry timer,

            - Complete the initialization, /* Remove this ?*/

            - Send the Open message to the peer,

            - Set the Hold timer to a large value (see note below)

            - Transition to the OpenSent state.

            /* Stop listening here? */

         NOTE: A Hold timer value of 4 minutes is suggested.

         In response the ConnectRetry timer expired event, the local
         system performs the following:

            - Restart the ConnectRetry timer,

            - Initiate an outbound transport connection to the peer,

            - Continue to listen for connection that may be initiated
              by the peer, /* Remove this ?*/

            - Transition to Connect.

         The start events (initiated by the system or operator) are
         ignored in the Active state.

Expiration Date July 2002                                      [Page 36]

RFC DRAFT                                                   January 2002

         In response to any other event (initiated by the system or
         operator), the following steps are taken:

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer

            - Drops the transport connection,

            - Releases resources allocated for the session

            - Transition to IdleHold state. /* Idle */

            /* Stop listening here ?*/

      OpenSent:

         In this state, the local system has sent out an OPEN
         message and awaits an OPEN message from the peer.
         When an OPEN message is received, all fields are checked for
         correctness.  If the BGP message header checking or OPEN
         message check detects an error (see Section 6.2), or a
         connection collision (see Section 6.8) the following
         steps are performed:

            - Send a NOTIFICATION message /* Need code here */

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer 

            - Drop the transport connection,

            - Release resources allocated for the session,

            - Transition to the IdleHold state. /* Idle */

         If there are no errors in the OPEN message, the local system
         does the following steps:

            - Send a KEEPALIVE message,

            - Start the KeepAlive timer (see note below)

            - Start the Hold timer according to the negotiated value 
              (see section 4.2 and note below),

            - Transition to OpenConfirm.

Expiration Date July 2002                                      [Page 37]

RFC DRAFT                                                   January 2002

         NOTE: If the negotiated Hold time value is zero, then the HoldTime
         timer and KeepAlive timers are not started.   
         
         If the value of the Autonomous System field is the same as 
         the local Autonomous System number, then the connection is an 
         "internal" connection; otherwise, it is an "external" connection.
         (This will impact UPDATE processing as described below.)

         /* Does this above para really belong to the FSM description?
          * I think not. Move to OPEN message section?
          */

         If a disconnect signal is received from the underlying
         transport protocol, the following steps are done:

            - Close the transport connection,

            - Restart the ConnectRetry timer,

            - Listen for a connection that may be initiated by 
              the remote peer,
              
            - Transition to the Active state.

         If the HoldTimer expires:

            - Send a NOTIFICATION message with error code 
              "Hold Timer Expired",

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session

            - Transition to IdleHold state.

         The Start event (manual and automatic) is ignored in the
         OpenSent state.

         If a NOTIFICATION message is received with the "Unsupported
         Version Number" code, the following steps are peformed:

            - Close the transport connection

            - Release resources allocated for the session,

            - Reset ConnectRetryCnt

            - Stop the ConnectRetry timer,

Expiration Date July 2002                                      [Page 38]

RFC DRAFT                                                   January 2002

            - Transition to Idle state.

         If any other NOTIFICATION is received, the following
         steps are executed:

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session

            - Transition to IdleHold state. /* Idle */

         In response to any other event, the local system performs
         the following steps:

            - Send the NOTFICATION message with Error Code "Finite State
            Machine Error",

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer

            - Drop the transport connection,

            - Release resources allocated for the session

            - Transition to IdleHold state. /* Idle */

      OpenConfirm state

         In this state, the local system has received an OPEN message
         from the peer, confirmed its reception by sending out
         a KEEPALIVE message, and awaits an incoming KEEPALIVE message
         confirming that the remote peer received the OPEN message
         sent before, or an incoming NOTIFICATION message reporting
         a problem.

         If the local system receives a KEEPALIVE message, the FSM
         transitions to Established state.

         Upon expiration of the HoldTimer:

            - Send the NOTIFICATION message with the error code "Hold
              Timer Expired",

            - Set IdleHoldTimer to 2**(ConnectRetryCnt)*60

Expiration Date July 2002                                      [Page 39]

RFC DRAFT                                                   January 2002

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Releases resources allocated for the session

            - Transition to IdleHold state. /* Idle */

         If the local system receives a NOTIFICATION message or receives
         a disconnect signal from the underlying transport
         protocol, the following steps are done:

            - Set IdleHold Timer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,

            - Transition to IdleHold state. /* Idle */

         In response to the automatic Stop event:

            - Send the NOTIFICATION message with "Cease" error code,

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,

            - Transition to IdleHold state. /* Idle */

         In response to a manual Stop event:

            - Send the NOTIFICATION message with "Cease" error code,

Expiration Date July 2002                                      [Page 40]

RFC DRAFT                                                   January 2002

            - Release resources allocated for the session,

            - Reset ConnectRetryCnt 

            - Stop the ConnectRetry timer,

            - Transition to Idle state.

         The Start event is ignored in the OpenConfirm state.

         In response to any other event:

            - Send a NOTIFICATION with a code of "Finite State Machine
              Error",

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,

            - Transition to IdleHold state. /* Idle */

      Established State:

         This is the most advanced state of the FSM. In the Established 
         state the peers can exchange UPDATE, NOTFICATION, and KEEPALIVE
         messages.

         On reception of an UPDATE or KEEPALIVE message:

            - Restarts the Hold timer, if the negotiated HoldTime 
              value is non-zero,

            - Stay in Established state.

         If the local system receives a NOTIFICATION message or a
         disconnect signal from the underlying transport protocol:

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60,

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,

Expiration Date July 2002                                      [Page 41]

RFC DRAFT                                                   January 2002

            - Transition to IdleHoldstate. /* Idle */

         If the local system receives an UPDATE message, and the Update
         message error handling procedure (see Section 6.3) detects an
         error, the following steps are performed:

            - Send a NOTIFICATION message with "Update Message Error"
              error code,

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,

            - Transition to IdleHold state. /* Idle */

         On expiration of the Hold timer:

            - Send a NOTIFICATION message with error code "Hold Timer
              Expired",

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,

            - Transition to IdleHold state. /* Idle */

         On expiration of the KeepAlive timer:

            - Send a KEEPALIVE message,

            - Restart the KeepAlive timer, unless the negotiated
              Hold Time value is zero.

         NOTE: The KeepAlive timer is also restarted each time a 
               KEEPALIVE or UPDATE message is sent it restarts,
               unless the negotiated Hold Time value is zero.

         In response to an automatic Stop event:

Expiration Date July 2002                                      [Page 42]

RFC DRAFT                                                   January 2002

            - Send a NOTIFICATION with "Cease" error code,

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,
              including invalidation of all routes possibly 
              received from the peer

            - Transition to IdleHold state. /* Idle */

         NOTE: An example of when an automatic Stop event can be 
              generated is exceeding  the maximum number of prefixes
              allowed to be received from a given peer.

         In response to a manual Stop event:

            - Send a NOTIFICATION with "Cease" error code,

            - Reset ConnectRetryCnt

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,
              including invalidation of all routes possibly 
              received from the peer

            - Transition to Idle state. /* Idle */

         The Start event is ignored in the Established state.

         In response to any other event, the local system:

            - Send a NOTIFICATION with "Finite State
              Machine Error" error code,

            - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60

            - Increment ConnectRetryCnt by 1,

            - Stop the ConnectRetry timer,

            - Drop the transport connection,

            - Release resources allocated for the session,
              including invalidation of all routes possibly 
              received from the peer

            - Transition to IdleHold state. /* Idle */

Expiration Date July 2002                                      [Page 43]

RFC DRAFT                                                   January 2002

To: Alex Zinin <[email-masked]>
Cc: Susan Hares <[email-masked]>, Kunihiro Ishiguro <[email-masked]>, Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode 
Date: Wed, 16 Jan 2002 16:24:13 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Yes, please do not introduce the IdleHold State at this stage of the
BGP deployment.  -- Enke

> Date: Wed, 16 Jan 2002 11:10:47 -0800
> From: Alex Zinin <[email-masked]>
> X-Mailer: The Bat! (v1.51) Personal
> Reply-To: Alex Zinin <[email-masked]>
> Organization: Nexsi Systems
> X-Priority: 3 (Normal)
> Message-ID: <[email-masked]>
> To: Susan Hares <[email-masked]>
> Cc: Kunihiro Ishiguro <[email-masked]>,
> 	Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>,
> 	Jeffrey Haas <[email-masked]>, <[email-masked]>
> Subject: Re: bgp4-17 Cease subcode
> 
> Sue,
> 
>  Introduction of the IdleHold does change the FSM,
>  and I thought we wanted the spec to reflect the current
>  running code as much as possible.
>  
>  I agree with Russ and Ishi---the new state does not
>  seem to be necessary, instead it could be as easy
>  as holding the session in Idle and giving clue on
>  how to make the delay exponential. I don't think
>  there's an interoperability issue if people decide
>  to keep the session in Idle using different internal
>  mechanisms.
> 
>  Regards,
>  
> -- 
> Alex Zinin
> 
> Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:
> 
> > Kunihiro:
> 
> > We are not changing the FSM so I would be surprised if the change
> > was anything but modest. Usually specifications with "no big" deal get 
> > interpreted differently.  Inter-operable code means you tie down the details.
> 
> > The comment was on the clarity of the specification.
> 
> > If you have a specific comment on the text of the state machine,
> > can you propose the concerns you have as a revision to the text.
> 
> > Sue
> 
> > PS -- I just love last call on a draft...  It's when
> >        everyone finally reads a new section  ;-)...
> 
> 
> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
> >> >> > Is the expoential backoff in the FSM in current implementations?
> >> >>
> >> >> I guess we are going to find this out as part of the implementation
> >> >> report. And if it is not in (at least two) current implementations,
> >> >> we'll take it out of the text.
> >> >
> >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
> >> >I checked that new subcode does not put other BGP stack in trouble
> >> >(checked Cisco and Juniper).
> >>
> >>First of all, sorry for talking about specific implementation.  In
> >>Zebra implementation we've implemented Cease subcode.  The code is in
> >>CVS repository.  I'll prepare a release version for that.
> >>
> >>And also we've implemented exponetial backoff.  It is done without
> >>introducing new FSM status.  It is not a big deal.  Just check a flag
> >>in a few functions.
> 
> 
> >>Exponential backoff is a good feature.  I can't understand why it
> >>require change to FSM.
> 
> 

Date: Wed, 16 Jan 2002 19:08:51 -0500
From: Greg Hankins <[email-masked]>
To: [email-masked]
Subject: Re: bgp4-17 Cease subcode
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Jan 16, 2002 at 11:10:47AM -0800, Alex Zinin wrote:
> Introduction of the IdleHold does change the FSM,
> and I thought we wanted the spec to reflect the current
> running code as much as possible.

Agreed.  Changing the FSM at this point doesn't seem like it is worth the
impact that this change would have on existing implementations, given that
there are other implementation-dependant ways of doing the same thing.

A change in the FSM would make every BGP implementation and every piece of
documentation written on BGP outdated.  I'm not saying that this shouldn't
be done if, there is a valid technical reason.

Maybe the exponential backoff parts could be published as a separate draft
instead of including it in the base specification?

Greg

-- 
Greg Hankins <[email-masked]> | Riverstone Networks, Inc.
Corporate Systems Engineering             | 5200 Great America Parkway
http://www.riverstonenet.com/             | Santa Clara, CA 95054
+1 404 434 0355                           | +1 408 878 6500

Date: Wed, 16 Jan 2002 18:12:57 -0500
To: Kunihiro Ishiguro <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: Susan Hares <[email-masked]>, Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Sender: [email-masked]

--=====================_4999358==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Kunihiro:

Here's the state machine diagram and event plan that
matches the state machine.   You could
look at the state machine diagram to easily walk through
the words.

Sue

At 01:33 PM 1/16/2002 -0800, Kunihiro Ishiguro wrote:
> >If you have a specific comment on the text of the state machine,
> >can you propose the concerns you have as a revision to the text.
>
>OK.  Let me do some updates.
>
> >PS -- I just love last call on a draft...  It's when
> >       everyone finally reads a new section  ;-)...
>
>Exactly...  And engineers suddenly realize how important it is ;-).
>--
>Kunihiro Ishiguro

--=====================_4999358==_
Content-Type: application/msword; name="statemt.doc";
 x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="statemt.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAfAAAAAAAAAAA
EAAAfgAAAAEAAAD+////AAAAAHsAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--=====================_4999358==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

--=====================_4999358==_--

Date: Wed, 16 Jan 2002 13:33:09 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

>If you have a specific comment on the text of the state machine,
>can you propose the concerns you have as a revision to the text.

OK.  Let me do some updates.

>PS -- I just love last call on a draft...  It's when
>       everyone finally reads a new section  ;-)...

Exactly...  And engineers suddenly realize how important it is ;-).
-- 
Kunihiro Ishiguro

To: Jeffrey Haas <[email-masked]>
Cc: Manav Bhatia <[email-masked]>, [email-masked]
Subject: Re: Maximum Prefix Limit 
Date: Wed, 16 Jan 2002 14:16:56 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Jeff:

> Date: Wed, 16 Jan 2002 10:35:29 -0500
> From: Jeffrey Haas <[email-masked]>
> To: Manav Bhatia <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Maximum Prefix Limit
> Message-ID: <[email-masked]>
> References: <03b001c19e4e$aa86e750$b4036c6b@Manav>

[snip]

> Enke,
> 
> MPBGP's NLRI sends AFI,SAFI as a 3 octet field.  The capability
> advertisement version sends it as 4 octets with the third octet
> being "reserved".

Please note that the Graceful Restart draft also uses 3 bytes.

> 
> Did we want to reserve the space in the notification data for
> the "reserved" portion or just stick to what we have in the NLRI?

The extra byte is not needed.

-- Enke

> 
> > Manav
> 
> -- 
> Jeff Haas 
> NextHop Technologies

Date: Wed, 16 Jan 2002 11:18:48 -0800
From: Alain Durand <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: IPv6 Router ID draft
Sender: [email-masked]

I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
and I would like to request this working group to consider it as
a wg item candidate for BCP.

    - Alain.

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

        Title           : BGP4 router ID for IPv6 only routers
        Author(s)       : F. Dupont, A. Durand
        Filename        :
draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
        Pages           : 3
        Date            : 15-Jan-02

BGP4 [1] uses a 32 bit field to identify router (the so called
'router-IDs'). In IPv4 domain, an IPv4 address of the router
is typically used in this field.
In an IPv6 routing domain, routers may very well not have any IPv4
Addresses. This document provides a simple way to form a globally
Unique ID in such a case.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt

Date: Wed, 16 Jan 2002 11:10:47 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: Kunihiro Ishiguro <[email-masked]>, Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Sue,

 Introduction of the IdleHold does change the FSM,
 and I thought we wanted the spec to reflect the current
 running code as much as possible.
 
 I agree with Russ and Ishi---the new state does not
 seem to be necessary, instead it could be as easy
 as holding the session in Idle and giving clue on
 how to make the delay exponential. I don't think
 there's an interoperability issue if people decide
 to keep the session in Idle using different internal
 mechanisms.

 Regards,
 
-- 
Alex Zinin

Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote:

> Kunihiro:

> We are not changing the FSM so I would be surprised if the change
> was anything but modest. Usually specifications with "no big" deal get 
> interpreted differently.  Inter-operable code means you tie down the details.

> The comment was on the clarity of the specification.

> If you have a specific comment on the text of the state machine,
> can you propose the concerns you have as a revision to the text.

> Sue

> PS -- I just love last call on a draft...  It's when
>        everyone finally reads a new section  ;-)...

> At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
>> >> > Is the expoential backoff in the FSM in current implementations?
>> >>
>> >> I guess we are going to find this out as part of the implementation
>> >> report. And if it is not in (at least two) current implementations,
>> >> we'll take it out of the text.
>> >
>> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
>> >I checked that new subcode does not put other BGP stack in trouble
>> >(checked Cisco and Juniper).
>>
>>First of all, sorry for talking about specific implementation.  In
>>Zebra implementation we've implemented Cease subcode.  The code is in
>>CVS repository.  I'll prepare a release version for that.
>>
>>And also we've implemented exponetial backoff.  It is done without
>>introducing new FSM status.  It is not a big deal.  Just check a flag
>>in a few functions.

>>Exponential backoff is a good feature.  I can't understand why it
>>require change to FSM.

Date: Wed, 16 Jan 2002 10:37:26 -0500
From: Jeffrey Haas <[email-masked]>
To: Vincent Gillet <[email-masked]>
Cc: [email-masked]
Subject: Re: Maximum Prefix Limit
Sender: [email-masked]

On Wed, Jan 16, 2002 at 04:31:27PM +0100, Vincent Gillet wrote:
> bgpPeerLastError OID is nice to know from remote peer.

Present in the new MIB.

> We may need a "bgpPeerSentLastError" to know the exact reason we ceased
> BGP session.

Good suggestion.  This goes in the new MIB.

> Vincent.

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 16 Jan 2002 10:35:29 -0500
From: Jeffrey Haas <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Subject: Re: Maximum Prefix Limit
Sender: [email-masked]

On Wed, Jan 16, 2002 at 10:58:43AM +0530, Manav Bhatia wrote:
> - Should there be counters for individual SAFI or should there be a
> consolidated one for the entire AFI?

Those of us working on the v2MIB would like to hear opinions on this!

> We must have a mechanism wherein we can inform admin guys in the network
> leaking routes causing an overflow for us. This issue was brought up some
> time back in the list but i saw no apparent conclusion to the whole
> discussion ;-)
> 
> Is there any intention of introducing a new cease sub-code in the
> NOTIFICATION message which will inform both the parties of the reason why
> the session was brought down!

SNMP traps are certainly appropriate here.
The NOTIFICATION subcode has already been discussed.

One thing that I'm noting:
Enke,

MPBGP's NLRI sends AFI,SAFI as a 3 octet field.  The capability
advertisement version sends it as 4 octets with the third octet
being "reserved".

Did we want to reserve the space in the notification data for
the "reserved" portion or just stick to what we have in the NLRI?

> Manav

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 16 Jan 2002 16:31:27 +0100
From: Vincent Gillet <[email-masked]>
To: Manav Bhatia <[email-masked]>
Cc: [email-masked]
Subject: Re: Maximum Prefix Limit
Sender: [email-masked]

[email-masked] disait :

> Hi,
> 
> - Should  the BGP session be restarted after some configured Idle Timer
> expiration?

As Enke stated, this is important question for implementation.

Vendors are having different behaviour today but are also adding feature
to their BGP stack to let user select the behaviour they want.
(on Hold, retry timers, ....).

Vendors are aware of this question.

> Is there any intention of introducing a new cease sub-code in the
> NOTIFICATION message which will inform both the parties of the reason why
> the session was brought down!

Cease sub-code would be available via SNMP with existing BGP MIB.
It would inform that remote BGP closed for that reason, but there
is no way to know via existing MIB that your box received too many
prefixes and closed BGP.

bgpPeerLastError OID is nice to know from remote peer.

We may need a "bgpPeerSentLastError" to know the exact reason we ceased
BGP session.

This is a talk we need to run for bgp4-mibv2 draft.

Vincent.

From: "Tsillas, Jim" <[email-masked]>
To: "'Xie, Feng'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: BGP Route Refresh & Soft-Reconfiguration
Date: Wed, 16 Jan 2002 10:03:41 -0500
Sender: [email-masked]

Feng,

Much of this is implementation dependent and can be done
differently but I'll take a stab at it. Note that when
routes pass import policy they become part of the BGP route
selection process (RIB-in) and should be stored even if they are
not the best route. The reason is that the best route may
be withdrawn or modified such that a new best route will
be selected from the candidates. If you don't store the
non-best you will not be able to select a new best. Using
route-refresh to get your non-best would require a refresh
from all peers whenever a route is withdrawn or changed:
do you really want to do this?

To answer question 2, in order for soft-reconfiguration
(on input policy) to work, you need to keep the routes which
are excluded due to policy. Also, if the routes are modified
by import policy, you also need to keep the original attributes.
If you don't keep this information you can't guarrantee that
soft-reconfiguration will work. Route-refresh allows you
to discard this extra information since you can now rely on
your peer to resubmit the routes (which will get the new
input policy applied to them as they are received). The
advantage of using route-refresh depends on how much routing
information is excluded or modified due to input policy. It
could be significant and could consume alot of resources.
You could let you user decide through configuration whether
soft-reconfiguration will use saved routing information or
route-refresh.

-----Original Message-----
From: Xie, Feng [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 9:53 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: BGP Route Refresh & Soft-Reconfiguration

Hi, 

      I have two questions with respect to BGP Route Refresh (RFC2918). 

1. Suppose Route Refresh Capability is negotiated between two BGP peers, P1
and P2. P2 has some BGP import policies to block some routes from P1 and
accept others. With Route Refresh, should P2 store the routes from P1 which
are accepted by P1 import policies even if they may not be selected by the
decision process on P2? Or should P2 only store the routes from P1 which are
selected by the decision process on P2 and discard all others? If we only
store the best routes, once the best routes are withdrawn, we have to
contact all peers to reselect the best routes since I don't keep the
non-best routes. Is this understanding correct?

2. What is the advantages of Route Refresh over Soft-Reconfiguration? Let me
reuse my previous example. My understanding is that in Soft-Reconfiguration
P2 stores all routes from P1 even if some of them or all of them are blocked
by the import policies but in Route Refresh P2 only stores those routes
which are accepted by its import policies. If this is ture, then Route
Refresh does not buy you too much if there is no blocked route since in both
Route Refresh and Soft-Reconfiguration, at least one copy of a route from P1
will be stored on P2. 

Feng Xie

From: "Xie, Feng" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: BGP Route Refresh & Soft-Reconfiguration
Date: Wed, 16 Jan 2002 09:53:12 -0500
Sender: [email-masked]

Hi, 

      I have two questions with respect to BGP Route Refresh (RFC2918). 

1. Suppose Route Refresh Capability is negotiated between two BGP peers, P1
and P2. P2 has some BGP import policies to block some routes from P1 and
accept others. With Route Refresh, should P2 store the routes from P1 which
are accepted by P1 import policies even if they may not be selected by the
decision process on P2? Or should P2 only store the routes from P1 which are
selected by the decision process on P2 and discard all others? If we only
store the best routes, once the best routes are withdrawn, we have to
contact all peers to reselect the best routes since I don't keep the
non-best routes. Is this understanding correct?

2. What is the advantages of Route Refresh over Soft-Reconfiguration? Let me
reuse my previous example. My understanding is that in Soft-Reconfiguration
P2 stores all routes from P1 even if some of them or all of them are blocked
by the import policies but in Route Refresh P2 only stores those routes
which are accepted by its import policies. If this is ture, then Route
Refresh does not buy you too much if there is no blocked route since in both
Route Refresh and Soft-Reconfiguration, at least one copy of a route from P1
will be stored on P2. 

Feng Xie

Date: Wed, 16 Jan 2002 09:04:36 -0500
To: Kunihiro Ishiguro <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: Vincent Gillet <[email-masked]>, Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Sender: [email-masked]

Kunihiro:

We are not changing the FSM so I would be surprised if the change
was anything but modest. Usually specifications with "no big" deal get 
interpreted differently.  Inter-operable code means you tie down the details.

The comment was on the clarity of the specification.

If you have a specific comment on the text of the state machine,
can you propose the concerns you have as a revision to the text.

Sue

PS -- I just love last call on a draft...  It's when
       everyone finally reads a new section  ;-)...

At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
> >> > Is the expoential backoff in the FSM in current implementations?
> >>
> >> I guess we are going to find this out as part of the implementation
> >> report. And if it is not in (at least two) current implementations,
> >> we'll take it out of the text.
> >
> >I implemented Cease subcode in zebra-0.92a but not exponential backoff.
> >I checked that new subcode does not put other BGP stack in trouble
> >(checked Cisco and Juniper).
>
>First of all, sorry for talking about specific implementation.  In
>Zebra implementation we've implemented Cease subcode.  The code is in
>CVS repository.  I'll prepare a release version for that.
>
>And also we've implemented exponetial backoff.  It is done without
>introducing new FSM status.  It is not a big deal.  Just check a flag
>in a few functions.

>Exponential backoff is a good feature.  I can't understand why it
>require change to FSM.

Date: Wed, 16 Jan 2002 08:56:24 -0500
To: Russ White <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: editorial fixes
Cc: Susan Hares <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

Russ:

Alex and are discussing his text.   next day or two
is a good comment.

Sue

At 10:27 PM 1/15/2002 -0500, Russ White wrote:

>I think Alex is suggesting alternate text altogether--we should
>see it in the next day or two.
>
>Russ
>
>On Tue, 15 Jan 2002, Susan Hares wrote:
>
> >
> > Yakov:
> >
> > The FSM revision I posted as gotten approval from Russ.
> > We are awaiting Alex's review of the text.  That should
> > go on your list if Alex approves.
> >
> > Sue
> >
> > At 03:11 PM 1/15/2002 -0800, Yakov Rekhter wrote:
> > >Folks,
> > >
> > >In the absence of any objections I will incorporate the
> > >changes suggested below.
> > >
> > >Yakov.
> > >------- Forwarded Message
> > >
> > >Date:    Wed, 15 Jan 2003 18:28:48 +0000
> > >From:    "Tom Petch" <[email-masked]>
> > >To:      "Yakov Rekhter" <[email-masked]>
> > >cc:      <[email-masked]>
> > >Subject: Re: bgp4-17 Section 9
> > >
> > >Combining NEXT_HOP resolution into one place (5.1.3) I
> > >suggest
> > >
> > >
> > >Revised 9.1.2 para 7
> > >
> > >The local speaker MUST determine the immediate next-hop
> > >address from the NEXT_HOP attribute of the selected route
> > >(see section 5.1.3).
> > >If either the immediate next hop or the IGP cost to the
> > >NEXT_HOP (where the NEXT_HOP is resolved through an IGP
> > >route) changes, Phase 2: Route Selection should be performed
> > >again.
> > >
> > >- ----------------------------
> > >
> > >Revised 5.1.3
> > >
> > >    The NEXT_HOP attribute is used by the BGP speaker to
> > >determine the
> > >    actual outbound interface and immediate next-hop address
> > >that should
> > >    be used to forward transit packets to the associated
> > >destinations.
> > >
> > >    The immediate next-hop address is determined by
> > >performing a
> > >    recursive route lookup operation for the IP address in
> > >the NEXT_HOP
> > >    attribute using the contents of the Routing Table,
> > >- -----------revised text follows ------------
> > >selecting one entry if multiple entries of equal cost exist.
> > >The Routing Table entry which resolves the NEXT_HOP
> > >attribute will always specify the outbound interface.
> > >If the entry also specifies the next-hop address, this
> > >address should be used as the immediate next-hop address for
> > >packet forwarding.
> > >If the entry specifies an attached subnet (and does not
> > >specify a next-hop address), then the address in the
> > >NEXT_HOP attribute should be used as the immediate next-hop
> > >address.
> > >- ------------end of revision----------
> > >
> > >I (still) believe 'resolving route' is not at all clear,
> > >hence my use of the form
> > >'The Routing Table entry which resolves the NEXT_HOP
> > >attribute ...'
> > >But I am less hung up on whether we mention entry or use
> > >path or drop 'Routing Table'.
> > >I take the point about there being a limit as to how much
> > >we can say about routing tables; I tend to regard RFC1812 as
> > >the sine qua none.
> > >
> > >
> > >
> > >Tom Petch, Network Consultant
> > >[email-masked]
> > >
> > >- -----Original Message-----
> > >From: Yakov Rekhter <[email-masked]>
> > >To: Tom Petch <[email-masked]>
> > >Cc: [email-masked] <[email-masked]>
> > >Date: 14 January 2002 20:15
> > >Subject: Re: bgp4-17 Section 9
> > >
> > >
> > > >>
> > > >> 9.1.2 Route selection now allows for the best route in
> > > >> Loc-RIB not to be placed in the Routing table; how does
> > >this
> > > >> impact on the principle (2 Introduction) that a BGP
> > >Speaker
> > > >> should only advertise routes it itself uses?  Is it
> > >enough
> > > >> for the route to be in Loc-RIB and not in the Routing
> > >Table?
> > > >>
> > > >> I believe the paragraph on immediate next hop should
> > > >> cross-reference the one in 5.1.3; and the latter allows
> > > >> route lookup to resolve to a subnet and not an immediate
> > > >> next hop address, a possibility 9.1.2 appears not to
> > >cater
> > > >> for.
> > > >>
> > > >> Perhaps the information on immediate next hop in 5.1.3
> > >and 9
> > > >> should be combined in one place; 5.1.3 would be my
> > > >> preference.
> > > >
> > > >Please propose the specific changes.
> > > >
> > > >Yakov.
> > >
> > >
> > >
> > >------- End of Forwarded Message
> >
> >
>
>_____________________________
>[email-masked] <>< Grace Alone

To: "Manav Bhatia" <[email-masked]>
Cc: [email-masked]
Subject: Re: Maximum Prefix Limit 
Date: Tue, 15 Jan 2002 21:57:40 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Manav,

> Message-ID: <03f701c19e51$f2d4daa0$b4036c6b@Manav>
> Reply-To: "Manav Bhatia" <[email-masked]>
> From: "Manav Bhatia" <[email-masked]>
> To: "Enke Chen" <[email-masked]>
> Cc: <[email-masked]>
> References: <[email-masked]>
> Subject: Re: Maximum Prefix Limit 
> Date: Wed, 16 Jan 2002 11:22:14 +0530
> 
> Thanks Enke!
> 
> One more thing - Should we restart the session after the Idle timer expires
> or should the session be freezed until a BGP Restart is given?

That is an implementation decision you need to make. -- Enke

> 
> ----- Original Message -----
> From: "Enke Chen" <[email-masked]>
> To: "Manav Bhatia" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 16, 2002 11:07 AM
> Subject: Re: Maximum Prefix Limit
> 
> 
> | Hi, Manav:
> | Regarding the CEASE subcode, please see the following draft:
> |
> |        draft-ietf-idr-cease-subcode-00.txt
> |
> | -- Enke
> |
> | > Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav>
> | > Reply-To: "Manav Bhatia" <[email-masked]>
> | > From: "Manav Bhatia" <[email-masked]>
> | > To: <[email-masked]>
> | > Subject: Maximum Prefix Limit
> | > Date: Wed, 16 Jan 2002 10:58:43 +0530
> | > MIME-Version: 1.0
> | >
> | > Hi,
> | >
> | > I am working on BGP implementation of the "maximum prefix limit"
> feature
> | > which is like a protection mechanism against route leaking. A warning
> flag
> | > will be raised once the number of prefixes start exceeding some
> percentage
> | > for the user to do something about it. If nothing happens and the limit
> | > reaches a configured threshold then the BGP session will be torn down.
> | >
> | > - In the current draft there is no mechanism for the other end to know
> of
> | > the reason why the session went down in the first place. IF this is
> | > achieved then the admin at the other end can take some actions to
> alleviate
> | > the situation.
> | >
> | > - Should  the BGP session be restarted after some configured Idle Timer
> | > expiration?
> | >
> | > This can result in consistent route flappings which is highly
> undesirable.
> | >
> | > - Should the BGP session be freezed until a manual Restart is given?
> | >
> | > - Should there be counters for individual SAFI or should there be a
> | > consolidated one for the entire AFI?
> | >
> | > We must have a mechanism wherein we can inform admin guys in the
> network
> | > leaking routes causing an overflow for us. This issue was brought up
> some
> | > time back in the list but i saw no apparent conclusion to the whole
> | > discussion ;-)
> | >
> | > Is there any intention of introducing a new cease sub-code in the
> | > NOTIFICATION message which will inform both the parties of the reason
> why
> | > the session was brought down!
> | >
> | > Regards,
> | > Manav
> | >
> | >
> | >
> | > ----
> | > "When you are courting a nice girl an hour seems like a second. When
> you
> | > sit on a red-hot cinder a second seems like an hour. That's
> relativity."
> | >
> | > -Albert Einstein, on relativity
> | >
> | >
> | >
> | >
> | > _________________________________________________________
> | > Do You Yahoo!?
> | > Get your free @yahoo.com address at http://mail.yahoo.com
> | >
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: "Enke Chen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Maximum Prefix Limit 
Date: Wed, 16 Jan 2002 11:22:14 +0530
Sender: [email-masked]

Thanks Enke!

One more thing - Should we restart the session after the Idle timer expires
or should the session be freezed until a BGP Restart is given?

----- Original Message -----
From: "Enke Chen" <[email-masked]>
To: "Manav Bhatia" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 16, 2002 11:07 AM
Subject: Re: Maximum Prefix Limit

| Hi, Manav:
| Regarding the CEASE subcode, please see the following draft:
|
|        draft-ietf-idr-cease-subcode-00.txt
|
| -- Enke
|
| > Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav>
| > Reply-To: "Manav Bhatia" <[email-masked]>
| > From: "Manav Bhatia" <[email-masked]>
| > To: <[email-masked]>
| > Subject: Maximum Prefix Limit
| > Date: Wed, 16 Jan 2002 10:58:43 +0530
| > MIME-Version: 1.0
| >
| > Hi,
| >
| > I am working on BGP implementation of the "maximum prefix limit"
feature
| > which is like a protection mechanism against route leaking. A warning
flag
| > will be raised once the number of prefixes start exceeding some
percentage
| > for the user to do something about it. If nothing happens and the limit
| > reaches a configured threshold then the BGP session will be torn down.
| >
| > - In the current draft there is no mechanism for the other end to know
of
| > the reason why the session went down in the first place. IF this is
| > achieved then the admin at the other end can take some actions to
alleviate
| > the situation.
| >
| > - Should  the BGP session be restarted after some configured Idle Timer
| > expiration?
| >
| > This can result in consistent route flappings which is highly
undesirable.
| >
| > - Should the BGP session be freezed until a manual Restart is given?
| >
| > - Should there be counters for individual SAFI or should there be a
| > consolidated one for the entire AFI?
| >
| > We must have a mechanism wherein we can inform admin guys in the
network
| > leaking routes causing an overflow for us. This issue was brought up
some
| > time back in the list but i saw no apparent conclusion to the whole
| > discussion ;-)
| >
| > Is there any intention of introducing a new cease sub-code in the
| > NOTIFICATION message which will inform both the parties of the reason
why
| > the session was brought down!
| >
| > Regards,
| > Manav
| >
| >
| >
| > ----
| > "When you are courting a nice girl an hour seems like a second. When
you
| > sit on a red-hot cinder a second seems like an hour. That's
relativity."
| >
| > -Albert Einstein, on relativity
| >
| >
| >
| >
| > _________________________________________________________
| > Do You Yahoo!?
| > Get your free @yahoo.com address at http://mail.yahoo.com
| >

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

To: "Manav Bhatia" <[email-masked]>
Cc: [email-masked]
Subject: Re: Maximum Prefix Limit 
Date: Tue, 15 Jan 2002 21:37:30 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Manav:
Regarding the CEASE subcode, please see the following draft:

       draft-ietf-idr-cease-subcode-00.txt

-- Enke

> Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav>
> Reply-To: "Manav Bhatia" <[email-masked]>
> From: "Manav Bhatia" <[email-masked]>
> To: <[email-masked]>
> Subject: Maximum Prefix Limit
> Date: Wed, 16 Jan 2002 10:58:43 +0530
> MIME-Version: 1.0
> 
> Hi,
> 
> I am working on BGP implementation of the "maximum prefix limit" feature
> which is like a protection mechanism against route leaking. A warning flag
> will be raised once the number of prefixes start exceeding some percentage
> for the user to do something about it. If nothing happens and the limit
> reaches a configured threshold then the BGP session will be torn down.
> 
> - In the current draft there is no mechanism for the other end to know of
> the reason why the session went down in the first place. IF this is
> achieved then the admin at the other end can take some actions to alleviate
> the situation.
> 
> - Should  the BGP session be restarted after some configured Idle Timer
> expiration?
> 
> This can result in consistent route flappings which is highly undesirable.
> 
> - Should the BGP session be freezed until a manual Restart is given?
> 
> - Should there be counters for individual SAFI or should there be a
> consolidated one for the entire AFI?
> 
> We must have a mechanism wherein we can inform admin guys in the network
> leaking routes causing an overflow for us. This issue was brought up some
> time back in the list but i saw no apparent conclusion to the whole
> discussion ;-)
> 
> Is there any intention of introducing a new cease sub-code in the
> NOTIFICATION message which will inform both the parties of the reason why
> the session was brought down!
> 
> Regards,
> Manav
> 
> 
> 
> ----
> "When you are courting a nice girl an hour seems like a second. When you
> sit on a red-hot cinder a second seems like an hour. That's relativity."
> 
> -Albert Einstein, on relativity
> 
> 
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: <[email-masked]>
Subject: Maximum Prefix Limit
Date: Wed, 16 Jan 2002 10:58:43 +0530
Sender: [email-masked]

Hi,

I am working on BGP implementation of the "maximum prefix limit" feature
which is like a protection mechanism against route leaking. A warning flag
will be raised once the number of prefixes start exceeding some percentage
for the user to do something about it. If nothing happens and the limit
reaches a configured threshold then the BGP session will be torn down.

- In the current draft there is no mechanism for the other end to know of
the reason why the session went down in the first place. IF this is
achieved then the admin at the other end can take some actions to alleviate
the situation.

- Should  the BGP session be restarted after some configured Idle Timer
expiration?

This can result in consistent route flappings which is highly undesirable.

- Should the BGP session be freezed until a manual Restart is given?

- Should there be counters for individual SAFI or should there be a
consolidated one for the entire AFI?

We must have a mechanism wherein we can inform admin guys in the network
leaking routes causing an overflow for us. This issue was brought up some
time back in the list but i saw no apparent conclusion to the whole
discussion ;-)

Is there any intention of introducing a new cease sub-code in the
NOTIFICATION message which will inform both the parties of the reason why
the session was brought down!

Regards,
Manav

----
"When you are courting a nice girl an hour seems like a second. When you
sit on a red-hot cinder a second seems like an hour. That's relativity."

-Albert Einstein, on relativity

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Tue, 15 Jan 2002 22:27:37 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: editorial fixes
Sender: [email-masked]

I think Alex is suggesting alternate text altogether--we should
see it in the next day or two.

Russ

On Tue, 15 Jan 2002, Susan Hares wrote:

> 
> Yakov:
> 
> The FSM revision I posted as gotten approval from Russ.
> We are awaiting Alex's review of the text.  That should
> go on your list if Alex approves.
> 
> Sue
> 
> At 03:11 PM 1/15/2002 -0800, Yakov Rekhter wrote:
> >Folks,
> >
> >In the absence of any objections I will incorporate the
> >changes suggested below.
> >
> >Yakov.
> >------- Forwarded Message
> >
> >Date:    Wed, 15 Jan 2003 18:28:48 +0000
> >From:    "Tom Petch" <[email-masked]>
> >To:      "Yakov Rekhter" <[email-masked]>
> >cc:      <[email-masked]>
> >Subject: Re: bgp4-17 Section 9
> >
> >Combining NEXT_HOP resolution into one place (5.1.3) I
> >suggest
> >
> >
> >Revised 9.1.2 para 7
> >
> >The local speaker MUST determine the immediate next-hop
> >address from the NEXT_HOP attribute of the selected route
> >(see section 5.1.3).
> >If either the immediate next hop or the IGP cost to the
> >NEXT_HOP (where the NEXT_HOP is resolved through an IGP
> >route) changes, Phase 2: Route Selection should be performed
> >again.
> >
> >- ----------------------------
> >
> >Revised 5.1.3
> >
> >    The NEXT_HOP attribute is used by the BGP speaker to
> >determine the
> >    actual outbound interface and immediate next-hop address
> >that should
> >    be used to forward transit packets to the associated
> >destinations.
> >
> >    The immediate next-hop address is determined by
> >performing a
> >    recursive route lookup operation for the IP address in
> >the NEXT_HOP
> >    attribute using the contents of the Routing Table,
> >- -----------revised text follows ------------
> >selecting one entry if multiple entries of equal cost exist.
> >The Routing Table entry which resolves the NEXT_HOP
> >attribute will always specify the outbound interface.
> >If the entry also specifies the next-hop address, this
> >address should be used as the immediate next-hop address for
> >packet forwarding.
> >If the entry specifies an attached subnet (and does not
> >specify a next-hop address), then the address in the
> >NEXT_HOP attribute should be used as the immediate next-hop
> >address.
> >- ------------end of revision----------
> >
> >I (still) believe 'resolving route' is not at all clear,
> >hence my use of the form
> >'The Routing Table entry which resolves the NEXT_HOP
> >attribute ...'
> >But I am less hung up on whether we mention entry or use
> >path or drop 'Routing Table'.
> >I take the point about there being a limit as to how much
> >we can say about routing tables; I tend to regard RFC1812 as
> >the sine qua none.
> >
> >
> >
> >Tom Petch, Network Consultant
> >[email-masked]
> >
> >- -----Original Message-----
> >From: Yakov Rekhter <[email-masked]>
> >To: Tom Petch <[email-masked]>
> >Cc: [email-masked] <[email-masked]>
> >Date: 14 January 2002 20:15
> >Subject: Re: bgp4-17 Section 9
> >
> >
> > >>
> > >> 9.1.2 Route selection now allows for the best route in
> > >> Loc-RIB not to be placed in the Routing table; how does
> >this
> > >> impact on the principle (2 Introduction) that a BGP
> >Speaker
> > >> should only advertise routes it itself uses?  Is it
> >enough
> > >> for the route to be in Loc-RIB and not in the Routing
> >Table?
> > >>
> > >> I believe the paragraph on immediate next hop should
> > >> cross-reference the one in 5.1.3; and the latter allows
> > >> route lookup to resolve to a subnet and not an immediate
> > >> next hop address, a possibility 9.1.2 appears not to
> >cater
> > >> for.
> > >>
> > >> Perhaps the information on immediate next hop in 5.1.3
> >and 9
> > >> should be combined in one place; 5.1.3 would be my
> > >> preference.
> > >
> > >Please propose the specific changes.
> > >
> > >Yakov.
> >
> >
> >
> >------- End of Forwarded Message
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 17:47:25 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked], Jeffrey Haas <[email-masked]>, Dave Thaler <[email-masked]>, Enke Chen <[email-masked]>
Subject: Re: IDR WG Last Call - Who has SAFI 3? 
Sender: [email-masked]

>2 implementations:
>
>a) Zebra - put SAFI 3 in and took it out
>b) GateD - has SAFI 3 support

Just a small comment.

Zebra - accept SAFI 3 do not announce SAFI 3
-- 
Kunihiro Ishiguro

Date: Tue, 15 Jan 2002 17:39:17 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Vincent Gillet <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

>> > Is the expoential backoff in the FSM in current implementations?
>> 
>> I guess we are going to find this out as part of the implementation
>> report. And if it is not in (at least two) current implementations,
>> we'll take it out of the text.
>
>I implemented Cease subcode in zebra-0.92a but not exponential backoff.
>I checked that new subcode does not put other BGP stack in trouble
>(checked Cisco and Juniper).

First of all, sorry for talking about specific implementation.  In
Zebra implementation we've implemented Cease subcode.  The code is in
CVS repository.  I'll prepare a release version for that.

And also we've implemented exponetial backoff.  It is done without
introducing new FSM status.  It is not a big deal.  Just check a flag
in a few functions.

Exponential backoff is a good feature.  I can't understand why it
require change to FSM.
-- 
Kunihiro Ishiguro

Date: Tue, 15 Jan 2002 19:50:48 -0500
To: Kunihiro Ishiguro <[email-masked]>, [email-masked]
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call - Who has SAFI 3? 
Cc: Jeffrey Haas <[email-masked]>, Dave Thaler <[email-masked]>, Enke Chen <[email-masked]>
Sender: [email-masked]

Kunihiro and working group:

OK - just to confirm:

2 implementations:

a) Zebra - put SAFI 3 in and took it out
b) GateD - has SAFI 3 support

Can any other implementor of SAFI please chime in now or
send me a note privately indicating that you have done it.

Also, any deployment using SAFI 3 should chime in with the
usage.

Please send it now as we are trying to finish the last call on
MPBGP.

Sue

At 03:21 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote:
> >While I agree that its nice in theory, you have the added difficulty
> >of having to maintain additional state for things such as WRD
> >and potentially awkward queue mechanisms for outgoing routes.
> >As such, you actually implement at least as much, if not more,
> >infrastructure to deal with the additional overhead of having
> >a SAFI that covers the unicast+multicast case.
> >
> >Additionally, policy is now a real pain - and very ambiguous in
> >the current spec.  If you say "accept unicast and multicast routes",
> >does that mean accept only SAFI 3 or SAFI's 1, 2 and 3?
> >
> >As Sue has mentioned, treating them as bits works fine for these
> >three SAFI's.  But I'd rather not have to.
>
>I agree with this.
>
> >I'm not going to argue very hard for removing SAFI 3 - we already
> >implement it.  But there are complications that don't seem to be
> >accounted for with regards to its supposed information overhead reduction.
>
>Yes.  I also implemented SAFI 3.  But I've changed implementation to
>not to use it.  I know there was some implementation which support
>SAFI 3.  But IMHO some of those implementation already changed their
>implementation to not to send SAFI 3.  We've learned it is not good
>way to send differenct SAFI route with one NLRI.
>--
>Kunihiro Ishiguro

To: Russ White <[email-masked]>
Cc: Anoop Ghanwani <[email-masked]>, Babu Prabesh <[email-masked]>, [email-masked]
Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17) 
Date: Tue, 15 Jan 2002 16:23:48 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Russ,

> Agreed....
> 
> :-)
> 
> Russ
> 
> On Tue, 15 Jan 2002, Anoop Ghanwani wrote:
> 
> > 
> > I think what the text is trying to say is that 
> > it is not possible to deaggregate a route once it
> > has been aggregated.  If so, it would make sense
> > to modify the text in 9.1.4 to say just that.

the text in 9.1.4 seems to be quite clear on this topic:

  A route that carries ATOMIC_AGGREGATE   
  attribute can not be de-aggregated. That is, the NLRI of this route
  can not be made more specific. 

Yakov.

> > 
> > If that's not what the text is saying, then please
> > correct me.
> > 
> > -Anoop
> > 
> > > -----Original Message-----
> > > From: Russ White [mailto:[email-masked]]
> > > Sent: Tuesday, January 15, 2002 5:02 AM
> > > To: Babu Prabesh
> > > Cc: [email-masked]
> > > Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17)
> > > 
> > > 
> > > 
> > > Nope--those woul dbe two seperate routes, with their own as
> > > paths, so it won't matter if you send both of them. Presumably,
> > > rtrb knows about the /16 locally, which is why it has the static,
> > > so no looping should occur. 
> > > 
> > > I'm not certain how you would de-aggregate in this way....
> > > 
> > > :-)
> > > 
> > > Russ
> > > 
> > > On Mon, 14 Jan 2002, Babu Prabesh wrote:
> > > 
> > > > Section 9.1.4: overlapping routes states:
> > > > 
> > > > "If a BGP speaker chooses to aggregate, then it MUST add
> > > > ATOMIC_AGGREGATE attribute
> > > > to the route. A route that carries ATOMIC_AGGREGATE 
> > > attribute can not be
> > > > de-aggregated.
> > > > That is, the NLRI of this route can not be made more specific.
> > > > Forwarding along such a
> > > > route does not guarantee that IP packets will actually 
> > > traverse only ASs
> > > > listed in the
> > > > AS_PATH attribute of the route".
> > > > 
> > > > I was unsure of what de-aggregation means.
> > > > Consider an example
> > > > 
> > > >                bgp                  bgp
> > > >   RTRA---------RTRB----------RTRC
> > > > 
> > > >  RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB.
> > > >  RTRB has a 5/16 route (via static).
> > > > 
> > > > Is the draft indicating that RTRB should only
> > > > advertise 5/8 to RTRC and not advertise 5/16.
> > > > 
> > > > Thanks
> > > >  Babu
> > > > 
> > > > 
> > > ##############################################################
> > > ##############
> > > > ########################## This email communication may 
> > > contain CONFIDENTIAL
> > > > INFORMATION and is intended only for the use of the 
> > > intended recipients
> > > > identified above.  If you are not the intended recipient of this
> > > > communication, you must not use, disclose, distribute, copy 
> > > or print this
> > > > email. If you have received this communication in error, 
> > > please immediately
> > > > notify the sender by reply email, delete the communication 
> > > and destroy all
> > > > copies.
> > > > 
> > > ##############################################################
> > > ##############
> > > > ##########################
> > > > 
> > > 
> > > _____________________________
> > > [email-masked] <>< Grace Alone
> > > 
> > 
> 
> _____________________________
> [email-masked] <>< Grace Alone
> 

Date: Tue, 15 Jan 2002 19:20:17 -0500
To: Yakov Rekhter <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: editorial fixes
Cc: [email-masked]
Sender: [email-masked]

Yakov:

The FSM revision I posted as gotten approval from Russ.
We are awaiting Alex's review of the text.  That should
go on your list if Alex approves.

Sue

At 03:11 PM 1/15/2002 -0800, Yakov Rekhter wrote:
>Folks,
>
>In the absence of any objections I will incorporate the
>changes suggested below.
>
>Yakov.
>------- Forwarded Message
>
>Date:    Wed, 15 Jan 2003 18:28:48 +0000
>From:    "Tom Petch" <[email-masked]>
>To:      "Yakov Rekhter" <[email-masked]>
>cc:      <[email-masked]>
>Subject: Re: bgp4-17 Section 9
>
>Combining NEXT_HOP resolution into one place (5.1.3) I
>suggest
>
>
>Revised 9.1.2 para 7
>
>The local speaker MUST determine the immediate next-hop
>address from the NEXT_HOP attribute of the selected route
>(see section 5.1.3).
>If either the immediate next hop or the IGP cost to the
>NEXT_HOP (where the NEXT_HOP is resolved through an IGP
>route) changes, Phase 2: Route Selection should be performed
>again.
>
>- ----------------------------
>
>Revised 5.1.3
>
>    The NEXT_HOP attribute is used by the BGP speaker to
>determine the
>    actual outbound interface and immediate next-hop address
>that should
>    be used to forward transit packets to the associated
>destinations.
>
>    The immediate next-hop address is determined by
>performing a
>    recursive route lookup operation for the IP address in
>the NEXT_HOP
>    attribute using the contents of the Routing Table,
>- -----------revised text follows ------------
>selecting one entry if multiple entries of equal cost exist.
>The Routing Table entry which resolves the NEXT_HOP
>attribute will always specify the outbound interface.
>If the entry also specifies the next-hop address, this
>address should be used as the immediate next-hop address for
>packet forwarding.
>If the entry specifies an attached subnet (and does not
>specify a next-hop address), then the address in the
>NEXT_HOP attribute should be used as the immediate next-hop
>address.
>- ------------end of revision----------
>
>I (still) believe 'resolving route' is not at all clear,
>hence my use of the form
>'The Routing Table entry which resolves the NEXT_HOP
>attribute ...'
>But I am less hung up on whether we mention entry or use
>path or drop 'Routing Table'.
>I take the point about there being a limit as to how much
>we can say about routing tables; I tend to regard RFC1812 as
>the sine qua none.
>
>
>
>Tom Petch, Network Consultant
>[email-masked]
>
>- -----Original Message-----
>From: Yakov Rekhter <[email-masked]>
>To: Tom Petch <[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Date: 14 January 2002 20:15
>Subject: Re: bgp4-17 Section 9
>
>
> >>
> >> 9.1.2 Route selection now allows for the best route in
> >> Loc-RIB not to be placed in the Routing table; how does
>this
> >> impact on the principle (2 Introduction) that a BGP
>Speaker
> >> should only advertise routes it itself uses?  Is it
>enough
> >> for the route to be in Loc-RIB and not in the Routing
>Table?
> >>
> >> I believe the paragraph on immediate next hop should
> >> cross-reference the one in 5.1.3; and the latter allows
> >> route lookup to resolve to a subnet and not an immediate
> >> next hop address, a possibility 9.1.2 appears not to
>cater
> >> for.
> >>
> >> Perhaps the information on immediate next hop in 5.1.3
>and 9
> >> should be combined in one place; 5.1.3 would be my
> >> preference.
> >
> >Please propose the specific changes.
> >
> >Yakov.
>
>
>
>------- End of Forwarded Message

Date: Tue, 15 Jan 2002 15:21:32 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Dave Thaler <[email-masked]>, Enke Chen <[email-masked]>, [email-masked]
Subject: Re: IDR WG Last Call
Sender: [email-masked]

>While I agree that its nice in theory, you have the added difficulty
>of having to maintain additional state for things such as WRD
>and potentially awkward queue mechanisms for outgoing routes.
>As such, you actually implement at least as much, if not more, 
>infrastructure to deal with the additional overhead of having
>a SAFI that covers the unicast+multicast case.
>
>Additionally, policy is now a real pain - and very ambiguous in
>the current spec.  If you say "accept unicast and multicast routes",
>does that mean accept only SAFI 3 or SAFI's 1, 2 and 3?
>
>As Sue has mentioned, treating them as bits works fine for these
>three SAFI's.  But I'd rather not have to.

I agree with this.  

>I'm not going to argue very hard for removing SAFI 3 - we already
>implement it.  But there are complications that don't seem to be
>accounted for with regards to its supposed information overhead reduction.

Yes.  I also implemented SAFI 3.  But I've changed implementation to
not to use it.  I know there was some implementation which support
SAFI 3.  But IMHO some of those implementation already changed their
implementation to not to send SAFI 3.  We've learned it is not good
way to send differenct SAFI route with one NLRI.
-- 
Kunihiro Ishiguro

Date: Tue, 15 Jan 2002 18:45:00 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: Babu Prabesh <[email-masked]>, [email-masked]
Subject: RE: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17)
Sender: [email-masked]

Agreed....

:-)

Russ

On Tue, 15 Jan 2002, Anoop Ghanwani wrote:

> 
> I think what the text is trying to say is that 
> it is not possible to deaggregate a route once it
> has been aggregated.  If so, it would make sense
> to modify the text in 9.1.4 to say just that.
> 
> If that's not what the text is saying, then please
> correct me.
> 
> -Anoop
> 
> > -----Original Message-----
> > From: Russ White [mailto:[email-masked]]
> > Sent: Tuesday, January 15, 2002 5:02 AM
> > To: Babu Prabesh
> > Cc: [email-masked]
> > Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17)
> > 
> > 
> > 
> > Nope--those woul dbe two seperate routes, with their own as
> > paths, so it won't matter if you send both of them. Presumably,
> > rtrb knows about the /16 locally, which is why it has the static,
> > so no looping should occur. 
> > 
> > I'm not certain how you would de-aggregate in this way....
> > 
> > :-)
> > 
> > Russ
> > 
> > On Mon, 14 Jan 2002, Babu Prabesh wrote:
> > 
> > > Section 9.1.4: overlapping routes states:
> > > 
> > > "If a BGP speaker chooses to aggregate, then it MUST add
> > > ATOMIC_AGGREGATE attribute
> > > to the route. A route that carries ATOMIC_AGGREGATE 
> > attribute can not be
> > > de-aggregated.
> > > That is, the NLRI of this route can not be made more specific.
> > > Forwarding along such a
> > > route does not guarantee that IP packets will actually 
> > traverse only ASs
> > > listed in the
> > > AS_PATH attribute of the route".
> > > 
> > > I was unsure of what de-aggregation means.
> > > Consider an example
> > > 
> > >                bgp                  bgp
> > >   RTRA---------RTRB----------RTRC
> > > 
> > >  RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB.
> > >  RTRB has a 5/16 route (via static).
> > > 
> > > Is the draft indicating that RTRB should only
> > > advertise 5/8 to RTRC and not advertise 5/16.
> > > 
> > > Thanks
> > >  Babu
> > > 
> > > 
> > ##############################################################
> > ##############
> > > ########################## This email communication may 
> > contain CONFIDENTIAL
> > > INFORMATION and is intended only for the use of the 
> > intended recipients
> > > identified above.  If you are not the intended recipient of this
> > > communication, you must not use, disclose, distribute, copy 
> > or print this
> > > email. If you have received this communication in error, 
> > please immediately
> > > notify the sender by reply email, delete the communication 
> > and destroy all
> > > copies.
> > > 
> > ##############################################################
> > ##############
> > > ##########################
> > > 
> > 
> > _____________________________
> > [email-masked] <>< Grace Alone
> > 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 18:16:57 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: [email-masked]
Sender: [email-masked]

Sending as well as receiving on the implementations
that I know about.

Ask Dave Thaler and Dory about deployments.

Sue

At 01:41 PM 1/15/2002 -0800, you wrote:
>Sue,
>
> > Date: Tue, 15 Jan 2002 16:32:23 -0500
> > To: Russ White <[email-masked]>
> > From: Susan Hares <[email-masked]>
> > Subject: Re: IDR WG Last Call
> > Cc: Enke Chen <[email-masked]>, Susan Hares <[email-masked]>,
> >       Jeffrey Haas <[email-masked]>, [email-masked]
> > In-Reply-To: <[email-masked]
> >  .com>
> >
> > I know of at least 2 implementations that do 1,2,3 and
>
>Do we know if "SAFI 3" is used in sending? That would not work without
>the receiver supporting it.
>
>If "SAFI 3" is not used in sending, it seems that it would be safe to
>remove it from the spec..
>
>-- Enke
>
> > I know of at least 2 implementations that do not (1,2 only).
> >
> > Sigh..  Yakov is drafting a change to text to try
> > to address all of these concerns.  I'll await
> > his note.
> >
> > sue
> >
> > At 03:02 PM 1/15/2002 -0500, Russ White wrote:
> >
> > >Correct--SAFI 3.... There aren't any implementations that I've
> > >seen, and it does complicate matters a bit more than needed.
> > >
> > >Russ
> > >
> > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > >
> > > > Sue,
> > > >
> > > > > Date: Tue, 15 Jan 2002 14:49:14 -0500
> > > > > To: Russ White <[email-masked]>
> > > > > From: Susan Hares <[email-masked]>
> > > > > Subject: Re: IDR WG Last Call
> > > > > Cc: Enke Chen <[email-masked]>, Jeffrey Haas <[email-masked]>,
> > > > >     [email-masked]
> > > > > In-Reply-To: 
> <[email-masked]
> > > > >  .com>
> > > > > References: <[email-masked]>
> > > > > Mime-Version: 1.0
> > > > > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > > > > X-NextHop-MailScanner: Found to be clean
> > > > >
> > > > > Russ:
> > > > >
> > > > > We had that vote 1 month ago.  The overwhelming
> > > > > majority was to keep it in. We are not re-opening
> > > > > that issue having closed it on the mail list already.
> > > >
> > > > The issue then was the "BGP State Machine". Russ was talking abut 
> "SAFI 3"
> > > > in his message if I am not mistaken.
> > > >
> > > > -- Enke
> > > >
> > > > >
> > > > >
> > > > > Sue
> > > > >
> > > > > At 01:03 PM 1/15/2002 -0500, Russ White wrote:
> > > > >
> > > > > >I think it's probably a good idea to get rid of this out of the
> > > > > >spec--it would make things cleaner.
> > > > > >
> > > > > >Russ
> > > > > >
> > > > > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > > > > >
> > > > > > > Jeff,
> > > > > > >
> > > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > > > > > > From: Jeffrey Haas <[email-masked]>
> > > > > > > > To: Enke Chen <[email-masked]>
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: Re: IDR WG Last Call
> > > > > > > > Message-ID: <[email-masked]>
> > > > > > > >
> > > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand
> > > much more
> > > > > > > > > complicated.
> > > > > > > >
> > > > > > > > IMO, SAFI 3 was probably not a very good idea.  Dealing 
> with it can
> > > > > > > > be a real pain in the implementation. :-)
> > > > > > >
> > > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem
> > > to add
> > > > > > > much value, but has caused a lot of confusion and complexity. I
> > > am not
> > > > > > > aware of any depolyment either.
> > > > > > >
> > > > > > > >
> > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > > > > > > having one prefix in multiple fields of an update 
> message. How
> > > > > > about the
> > > > > > > > > following text:
> > > > > > > > >
> > > > > > > > >    An UPDATE message should not include the same address
> > > prefix in
> > > > > > more than
> > > > > > > > >    one of the following fields: WITHDRAWN ROUTES field, 
> Network
> > > > > > Reachability
> > > > > > > > >    Information fields, MP_REACH_NLRI field, and 
> MP_UNREACH_NLRI
> > > > > > field. The
> > > > > > > > >    processing of an UPDATE message in this form is 
> un-defined.
> > > > > > > >
> > > > > > > > I think that "undefined" is overkill.  I would suggest the
> > > following
> > > > > > instead:
> > > > > > > >
> > > > > > > > An UPDATE message should not include the same address prefix in
> > > > > > > > more than one of the following fields: WITHDRAWN ROUTES, 
> Network
> > > > > > > > Layer Reachability Information, MP_REACH_NLRI and 
> MP_UNREACH_NLRI.
> > > > > > > > An implementation that receives a packet in this form should
> > > process
> > > > > > > > the Update as if it had processed it in the following order:
> > > > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > > > > > > Reachability Information.
> > > > > > > >
> > > > > > > > The wording could probably use some tightening.
> > > > > > > >
> > > > > > > > The intended result is that reachability rules over 
> unreachability.
> > > > > > >
> > > > > > > If we want to define the behavior, I would like to suggest
> > > sticking to
> > > > > > > the order in the message. That probably would reflect the 
> sender's
> > > > > > > intention more closely, and make the processing simpler.
> > > > > > >
> > > > > > > -- Enke
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >_____________________________
> > > > > >[email-masked] <>< Grace Alone
> > > > >
> > > > >
> > > >
> > >
> > >_____________________________
> > >[email-masked] <>< Grace Alone
> >
> >

To: [email-masked]
Subject: editorial fixes
Date: Tue, 15 Jan 2002 15:11:29 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

In the absence of any objections I will incorporate the
changes suggested below.

Yakov.
------- Forwarded Message

Date:    Wed, 15 Jan 2003 18:28:48 +0000
From:    "Tom Petch" <[email-masked]>
To:      "Yakov Rekhter" <[email-masked]>
cc:      <[email-masked]>
Subject: Re: bgp4-17 Section 9 

Combining NEXT_HOP resolution into one place (5.1.3) I
suggest

Revised 9.1.2 para 7

The local speaker MUST determine the immediate next-hop
address from the NEXT_HOP attribute of the selected route
(see section 5.1.3).
If either the immediate next hop or the IGP cost to the
NEXT_HOP (where the NEXT_HOP is resolved through an IGP
route) changes, Phase 2: Route Selection should be performed
again.

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

Revised 5.1.3

   The NEXT_HOP attribute is used by the BGP speaker to
determine the
   actual outbound interface and immediate next-hop address
that should
   be used to forward transit packets to the associated
destinations.

   The immediate next-hop address is determined by
performing a
   recursive route lookup operation for the IP address in
the NEXT_HOP
   attribute using the contents of the Routing Table,
- -----------revised text follows ------------
selecting one entry if multiple entries of equal cost exist.
The Routing Table entry which resolves the NEXT_HOP
attribute will always specify the outbound interface.
If the entry also specifies the next-hop address, this
address should be used as the immediate next-hop address for
packet forwarding.
If the entry specifies an attached subnet (and does not
specify a next-hop address), then the address in the
NEXT_HOP attribute should be used as the immediate next-hop
address.
- ------------end of revision----------

I (still) believe 'resolving route' is not at all clear,
hence my use of the form
'The Routing Table entry which resolves the NEXT_HOP
attribute ...'
But I am less hung up on whether we mention entry or use
path or drop 'Routing Table'.
I take the point about there being a limit as to how much
we can say about routing tables; I tend to regard RFC1812 as
the sine qua none.

Tom Petch, Network Consultant
[email-masked]

- -----Original Message-----
From: Yakov Rekhter <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 14 January 2002 20:15
Subject: Re: bgp4-17 Section 9

>>
>> 9.1.2 Route selection now allows for the best route in
>> Loc-RIB not to be placed in the Routing table; how does
this
>> impact on the principle (2 Introduction) that a BGP
Speaker
>> should only advertise routes it itself uses?  Is it
enough
>> for the route to be in Loc-RIB and not in the Routing
Table?
>>
>> I believe the paragraph on immediate next hop should
>> cross-reference the one in 5.1.3; and the latter allows
>> route lookup to resolve to a subnet and not an immediate
>> next hop address, a possibility 9.1.2 appears not to
cater
>> for.
>>
>> Perhaps the information on immediate next hop in 5.1.3
and 9
>> should be combined in one place; 5.1.3 would be my
>> preference.
>
>Please propose the specific changes.
>
>Yakov.

------- End of Forwarded Message

Date: Tue, 15 Jan 2002 14:00:01 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: Russ White <[email-masked]>, Eric Gray <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Sue:

> Now to the text:

> Fix to problem 1 -  FSM does not require you to implemented
> the hold off.

Does this mean IdleHold is removed?

> How about replacing this  following text at the IDLE State:

> IDLE
> =============

>  From this text:
>  >A manual start event is a start event initiated
>  >by an operator. An automatic start event is
>  >a start event generated by the system.

> The text can be: a manual event is intended to be
> a start event generated by "manual" intervention.  If the
> presistent flapping suppression option is not set,
> all start events will be manual start events.

The last sentence is too much, I guess.
Can we say that automatic Start event is generated
by the system to initiate the BGP connection procedure
and that it is recommended that persistent flapping
is accounted for and/or the text you give below?

FSM-wise, not describing the behavior when transitioning
from every state is not a problem if we specify actions
performed when FSM reaches a specific state (Idle in our
case). I'm working on such a version, will send out soon.

> How about re-adding this section at the bottom
> of the state machine?

> Manual versus Automatic start in the FSM

> If a BGP speaker detects an error, it shuts down the
> connection and changes its state to Idle-hold. Getting out

Shouldn't this be "Idle"?

BTW, regarding the collision detection, shouldn't the
session that lost the tie-breaker be destroyed rather
than being put in Idle/IdleHold?

Alex.

> of the Idle state requires generation of the Start event.
> Such a start event can either be manual or automatic.

> If this start event is generated automatically, then
> persistent BGP errors may result in persistent flapping
> of the speaker.  To avoid such a condition it is
> recommended that the Start events should not be generated
> immediately for a peer that was previously transitioned
> to Idle due to an error.   For a peer that was previously
> transitioned to Idle due to an error, the time between
> consecutive generation of Start events, if such events are
> generated automatically, shall exponentially increase. The
> value of the initial timer shall be 60 seconds. The time shall
> be doubled for each consecutive retry.The formula for this
> expotential backoff is expressed in the formula:

>          IDLE hold time = 2**(connectRetryCnt)*60

> ----------------

> What do you think?

> Sue Hares

Date: Tue, 15 Jan 2002 13:47:05 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Susan Hares <[email-masked]>
Cc: Russ White <[email-masked]>, Eric Gray <[email-masked]>, Russ White <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Sue:

> Alex:

> I know you have been active on the mailing list.
> And you didn't read it before the last call on the FSM.

Well, I skimmed :)

> And this question was asked on the list because I
> wondered about it.

> ;-)... <giggle on>  --- I guess not even great people are
> perfect.  <giggle off>

> OK, now I've got 2 more against (4 total).  And 15-20 votes
> for it inside the draft.

> I'm sure your vote is a bit more specific.  :-)...

> Is the issue you want to pull exponential out of the draft?
> This is a change to the BGP specification.  This draft
> is about corrections not changes in functionality.

When I was writing the message below, I was hesitating between
leaving the FSM the way it is in -17 and saying any functionally
equivalent implementation is all right, and removing the new state
and encouraging people to "play" with the Idle state.

I inclined towards the second because the new state in the spec
would probably still raise the issue of whether current
implementations comply ("Hey, I never saw "IdleHold" when I
did "sho ip bgp", you guys are not RFC compliant!!!", blah, blah...)

> What do we do?

See my reply to your other message.

Alex.

> Sue Hares

> At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote:

>>Russ, Eric,
>>
>>  I tend to agree here...
>>  I'm currently reviewing the FSM and the impression I'm
>>  getting is that we can go without the IdleHold state
>>  and say that implementations may/should use some local mechanisms
>>  to hold BGP sessions in the *Idle* state to avoid excessive
>>  session flapping. I think this will be simpler and will
>>  match current implementations better...
>>
>>--
>>Alex Zinin
>>

To: Susan Hares <[email-masked]>
Cc: Russ White <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Tue, 15 Jan 2002 13:41:24 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue,

> Date: Tue, 15 Jan 2002 16:32:23 -0500
> To: Russ White <[email-masked]>
> From: Susan Hares <[email-masked]>
> Subject: Re: IDR WG Last Call 
> Cc: Enke Chen <[email-masked]>, Susan Hares <[email-masked]>,
> 	Jeffrey Haas <[email-masked]>, [email-masked]
> In-Reply-To: <[email-masked]
>  .com>
> 
> I know of at least 2 implementations that do 1,2,3 and

Do we know if "SAFI 3" is used in sending? That would not work without
the receiver supporting it.

If "SAFI 3" is not used in sending, it seems that it would be safe to
remove it from the spec..

-- Enke

> I know of at least 2 implementations that do not (1,2 only).
> 
> Sigh..  Yakov is drafting a change to text to try
> to address all of these concerns.  I'll await
> his note.
> 
> sue
> 
> At 03:02 PM 1/15/2002 -0500, Russ White wrote:
> 
> >Correct--SAFI 3.... There aren't any implementations that I've
> >seen, and it does complicate matters a bit more than needed.
> >
> >Russ
> >
> >On Tue, 15 Jan 2002, Enke Chen wrote:
> >
> > > Sue,
> > >
> > > > Date: Tue, 15 Jan 2002 14:49:14 -0500
> > > > To: Russ White <[email-masked]>
> > > > From: Susan Hares <[email-masked]>
> > > > Subject: Re: IDR WG Last Call
> > > > Cc: Enke Chen <[email-masked]>, Jeffrey Haas <[email-masked]>,
> > > >     [email-masked]
> > > > In-Reply-To: <[email-masked]
> > > >  .com>
> > > > References: <[email-masked]>
> > > > Mime-Version: 1.0
> > > > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > > > X-NextHop-MailScanner: Found to be clean
> > > >
> > > > Russ:
> > > >
> > > > We had that vote 1 month ago.  The overwhelming
> > > > majority was to keep it in. We are not re-opening
> > > > that issue having closed it on the mail list already.
> > >
> > > The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3"
> > > in his message if I am not mistaken.
> > >
> > > -- Enke
> > >
> > > >
> > > >
> > > > Sue
> > > >
> > > > At 01:03 PM 1/15/2002 -0500, Russ White wrote:
> > > >
> > > > >I think it's probably a good idea to get rid of this out of the
> > > > >spec--it would make things cleaner.
> > > > >
> > > > >Russ
> > > > >
> > > > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > > > >
> > > > > > Jeff,
> > > > > >
> > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > > > > > From: Jeffrey Haas <[email-masked]>
> > > > > > > To: Enke Chen <[email-masked]>
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: Re: IDR WG Last Call
> > > > > > > Message-ID: <[email-masked]>
> > > > > > >
> > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand 
> > much more
> > > > > > > > complicated.
> > > > > > >
> > > > > > > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > > > > > > be a real pain in the implementation. :-)
> > > > > >
> > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem 
> > to add
> > > > > > much value, but has caused a lot of confusion and complexity. I 
> > am not
> > > > > > aware of any depolyment either.
> > > > > >
> > > > > > >
> > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > > > > > having one prefix in multiple fields of an update message. How
> > > > > about the
> > > > > > > > following text:
> > > > > > > >
> > > > > > > >    An UPDATE message should not include the same address 
> > prefix in
> > > > > more than
> > > > > > > >    one of the following fields: WITHDRAWN ROUTES field, Network
> > > > > Reachability
> > > > > > > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI
> > > > > field. The
> > > > > > > >    processing of an UPDATE message in this form is un-defined.
> > > > > > >
> > > > > > > I think that "undefined" is overkill.  I would suggest the 
> > following
> > > > > instead:
> > > > > > >
> > > > > > > An UPDATE message should not include the same address prefix in
> > > > > > > more than one of the following fields: WITHDRAWN ROUTES, Network
> > > > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > > > > > > An implementation that receives a packet in this form should 
> > process
> > > > > > > the Update as if it had processed it in the following order:
> > > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > > > > > Reachability Information.
> > > > > > >
> > > > > > > The wording could probably use some tightening.
> > > > > > >
> > > > > > > The intended result is that reachability rules over unreachability.
> > > > > >
> > > > > > If we want to define the behavior, I would like to suggest 
> > sticking to
> > > > > > the order in the message. That probably would reflect the sender's
> > > > > > intention more closely, and make the processing simpler.
> > > > > >
> > > > > > -- Enke
> > > > > >
> > > > > >
> > > > >
> > > > >_____________________________
> > > > >[email-masked] <>< Grace Alone
> > > >
> > > >
> > >
> >
> >_____________________________
> >[email-masked] <>< Grace Alone
> 
> 

Date: Tue, 15 Jan 2002 16:35:05 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Alex Zinin <[email-masked]>, Eric Gray <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Yes, this sounds reasonable.

:-)

Russ

On Tue, 15 Jan 2002, Susan Hares wrote:

> 
> Russ:
> 
> Can I change my mind on opening the FSM conversation?
> Two people asking the same question encouraged me to do this.
> Thanks for the input.  (keep those email terminals smokin' with
> the input ;-))....
> 
> How about a 3rd option --- Let's go back to the problem set
> and fix the text from there.
> 
>          Problem 1  - persistent flapping (bad thing), recommended
>                       fix: IDLE hold timer
> 
>          Problem 2 -  FSM text doesn't specify how this features
>                      works from all states.   Result:
>                      inter-operability between implementations is
>                      problematic.  [another bad thing]
> 
> If people are deploying BGP without the recommended (but
> not required) IDLE hold timer for persistent flapping,
> then this specification should allow it. [filter of what is deployed]
> 
> 
> Option 3 - fix both with background text that says:
>                  1) recommended to have IDLE Hold timer, and
>                  2) Not required.
> 
> Now to the text:
> 
> Fix to problem 1 -  FSM does not require you to implemented
> the hold off.
> 
> How about replacing this  following text at the IDLE State:
> 
> IDLE
> =============
> 
>  From this text:
>  >A manual start event is a start event initiated
>  >by an operator. An automatic start event is
>  >a start event generated by the system.
> 
> The text can be: a manual event is intended to be
> a start event generated by "manual" intervention.  If the
> presistent flapping suppression option is not set,
> all start events will be manual start events.
> 
> How about re-adding this section at the bottom
> of the state machine?
> 
> 
> Manual versus Automatic start in the FSM
> 
> If a BGP speaker detects an error, it shuts down the
> connection and changes its state to Idle-hold. Getting out
> of the Idle state requires generation of the Start event.
> Such a start event can either be manual or automatic.
> 
> If this start event is generated automatically, then
> persistent BGP errors may result in persistent flapping
> of the speaker.  To avoid such a condition it is
> recommended that the Start events should not be generated
> immediately for a peer that was previously transitioned
> to Idle due to an error.   For a peer that was previously
> transitioned to Idle due to an error, the time between
> consecutive generation of Start events, if such events are
> generated automatically, shall exponentially increase. The
> value of the initial timer shall be 60 seconds. The time shall
> be doubled for each consecutive retry.The formula for this
> expotential backoff is expressed in the formula:
> 
>          IDLE hold time = 2**(connectRetryCnt)*60
> 
> 
> ----------------
> 
> What do you think?
> 
> 
> Sue Hares
> 
> 
> 
> At 03:01 PM 1/15/2002 -0500, Russ White wrote:
> 
> >So, then it sounds like the way we should approach this (the
> >idlehold state in the fsm) is to think about it seperately from
> >the draft 17 issue (?).
> >
> >Russ
> >
> >On Tue, 15 Jan 2002, Susan Hares wrote:
> >
> > >
> > > Alex:
> > >
> > > I know you have been active on the mailing list.
> > > And you didn't read it before the last call on the FSM.
> > > And this question was asked on the list because I
> > > wondered about it.
> > >
> > > ;-)... <giggle on>  --- I guess not even great people are
> > > perfect.  <giggle off>
> > >
> > > OK, now I've got 2 more against (4 total).  And 15-20 votes
> > > for it inside the draft.
> > >
> > > I'm sure your vote is a bit more specific.  :-)...
> > >
> > > Is the issue you want to pull exponential out of the draft?
> > > This is a change to the BGP specification.  This draft
> > > is about corrections not changes in functionality.
> > >
> > > What do we do?
> > >
> > > Sue Hares
> > >
> > >
> > >
> > > At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote:
> > >
> > > >Russ, Eric,
> > > >
> > > >  I tend to agree here...
> > > >  I'm currently reviewing the FSM and the impression I'm
> > > >  getting is that we can go without the IdleHold state
> > > >  and say that implementations may/should use some local mechanisms
> > > >  to hold BGP sessions in the *Idle* state to avoid excessive
> > > >  session flapping. I think this will be simpler and will
> > > >  match current implementations better...
> > > >
> > > >--
> > > >Alex Zinin
> > > >
> > > >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote:
> > > >
> > > >
> > > > > Something like: "BGP implementations can/should/must
> > > > > (?) implement some method to prevent continuous flapping of
> > > > > peering sessions at a high rate," and then a footbote explaining
> > > > > that an exponential backoff is one such possible method?
> > > >
> > > > > Russ
> > > >
> > > > > On Tue, 15 Jan 2002, Eric Gray wrote:
> > > >
> > > > >> Russ,
> > > > >>
> > > > >>     Very good point.  However, how would you represent "do some
> > > > >> private magic here" in an FSM?  That may make it the dreaded ISM.
> > > > >> Perhaps it might be sufficient to remove this from the FSM and
> > > > >> add a footnote (possibly mentioning an exponential back-off as an
> > > > >> example?).
> > > > >>
> > > > >> You wrote:
> > > > >>
> > > > >> > Well, I just took it as 'do people do this?' I agree that it
> > > > >> > won't cause interop problems either way--it's actually something
> > > > >> > that's implementation local, so I'm not certain why the
> > > > >> > exponential backoff would be in the fsm (?). There are, in other
> > > > >> > words, other ways I could imagine handling this problem that
> > > > >> > wouldn't effect interoperability as well....
> > > > >> >
> > > > >> > :-)
> > > > >> >
> > > > >> > Russ
> > > > >> >
> > > > >> > On Tue, 15 Jan 2002, Eric Gray wrote:
> > > > >> >
> > > > >> > > Russ,
> > > > >> > >
> > > > >> > >     I don't think that NAKs are in order on this question - even
> > > > from the
> > > > >> > > 1500 pound dragon.  :-)
> > > > >> > >
> > > > >> > >     The fact that anyone's implementation doesn't do X is
> > > > important only
> > > > >> > > if not doing X causes interoperability problems with 
> > implementations
> > > > >> > > that do X.   That is not the case here, I believe...
> > > > >> > >
> > > > >> > > You wrote:
> > > > >> > >
> > > > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter 
> > wrote:
> > > > >> > > > > > > Please remember that the goal of the draft is to document
> > > > >> > > > > > > what is *currently* implemented and deployed, *not* what
> > > > >> > > > > > > *could* be implemented and deployed.
> > > > >> > > > > >
> > > > >> > > > > > Is the expoential backoff in the FSM in current 
> > implementations?
> > > > >> > > > >
> > > > >> > > > > I guess we are going to find this out as part of the
> > > > >> > > > > implementation report. And if it is not in (at least two)
> > > > >> > > > > current implementations, we'll take it out of the text.
> > > > >> > > >
> > > > >> > > > Cisco doesn't do this....
> > > > >> > > >
> > > > >> > > > :-)
> > > > >> > > >
> > > > >> > > > Russ
> > > > >> > > >
> > > > >> > > > _____________________________
> > > > >> > > > [email-masked] <>< Grace Alone
> > > > >> > >
> > > > >> > > --
> > > > >> > > Eric Gray (mailto:[email-masked])
> > > > >> > > http://www.mindspring.com/~ewgray
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> > _____________________________
> > > > >> > [email-masked] <>< Grace Alone
> > > > >>
> > > > >> --
> > > > >> Eric Gray (mailto:[email-masked])
> > > > >> http://www.mindspring.com/~ewgray
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > > > _____________________________
> > > > > [email-masked] <>< Grace Alone
> > >
> > >
> >
> >_____________________________
> >[email-masked] <>< Grace Alone
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 16:32:23 -0500
To: Russ White <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: Enke Chen <[email-masked]>, Susan Hares <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Sender: [email-masked]

I know of at least 2 implementations that do 1,2,3 and
I know of at least 2 implementations that do not (1,2 only).

Sigh..  Yakov is drafting a change to text to try
to address all of these concerns.  I'll await
his note.

sue

At 03:02 PM 1/15/2002 -0500, Russ White wrote:

>Correct--SAFI 3.... There aren't any implementations that I've
>seen, and it does complicate matters a bit more than needed.
>
>Russ
>
>On Tue, 15 Jan 2002, Enke Chen wrote:
>
> > Sue,
> >
> > > Date: Tue, 15 Jan 2002 14:49:14 -0500
> > > To: Russ White <[email-masked]>
> > > From: Susan Hares <[email-masked]>
> > > Subject: Re: IDR WG Last Call
> > > Cc: Enke Chen <[email-masked]>, Jeffrey Haas <[email-masked]>,
> > >     [email-masked]
> > > In-Reply-To: <[email-masked]
> > >  .com>
> > > References: <[email-masked]>
> > > Mime-Version: 1.0
> > > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > > X-NextHop-MailScanner: Found to be clean
> > >
> > > Russ:
> > >
> > > We had that vote 1 month ago.  The overwhelming
> > > majority was to keep it in. We are not re-opening
> > > that issue having closed it on the mail list already.
> >
> > The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3"
> > in his message if I am not mistaken.
> >
> > -- Enke
> >
> > >
> > >
> > > Sue
> > >
> > > At 01:03 PM 1/15/2002 -0500, Russ White wrote:
> > >
> > > >I think it's probably a good idea to get rid of this out of the
> > > >spec--it would make things cleaner.
> > > >
> > > >Russ
> > > >
> > > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > > >
> > > > > Jeff,
> > > > >
> > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > > > > From: Jeffrey Haas <[email-masked]>
> > > > > > To: Enke Chen <[email-masked]>
> > > > > > Cc: [email-masked]
> > > > > > Subject: Re: IDR WG Last Call
> > > > > > Message-ID: <[email-masked]>
> > > > > >
> > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand 
> much more
> > > > > > > complicated.
> > > > > >
> > > > > > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > > > > > be a real pain in the implementation. :-)
> > > > >
> > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem 
> to add
> > > > > much value, but has caused a lot of confusion and complexity. I 
> am not
> > > > > aware of any depolyment either.
> > > > >
> > > > > >
> > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > > > > having one prefix in multiple fields of an update message. How
> > > > about the
> > > > > > > following text:
> > > > > > >
> > > > > > >    An UPDATE message should not include the same address 
> prefix in
> > > > more than
> > > > > > >    one of the following fields: WITHDRAWN ROUTES field, Network
> > > > Reachability
> > > > > > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI
> > > > field. The
> > > > > > >    processing of an UPDATE message in this form is un-defined.
> > > > > >
> > > > > > I think that "undefined" is overkill.  I would suggest the 
> following
> > > > instead:
> > > > > >
> > > > > > An UPDATE message should not include the same address prefix in
> > > > > > more than one of the following fields: WITHDRAWN ROUTES, Network
> > > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > > > > > An implementation that receives a packet in this form should 
> process
> > > > > > the Update as if it had processed it in the following order:
> > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > > > > Reachability Information.
> > > > > >
> > > > > > The wording could probably use some tightening.
> > > > > >
> > > > > > The intended result is that reachability rules over unreachability.
> > > > >
> > > > > If we want to define the behavior, I would like to suggest 
> sticking to
> > > > > the order in the message. That probably would reflect the sender's
> > > > > intention more closely, and make the processing simpler.
> > > > >
> > > > > -- Enke
> > > > >
> > > > >
> > > >
> > > >_____________________________
> > > >[email-masked] <>< Grace Alone
> > >
> > >
> >
>
>_____________________________
>[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 16:30:18 -0500
To: Russ White <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: Susan Hares <[email-masked]>, Alex Zinin <[email-masked]>, Eric Gray <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Sender: [email-masked]

Russ:

Can I change my mind on opening the FSM conversation?
Two people asking the same question encouraged me to do this.
Thanks for the input.  (keep those email terminals smokin' with
the input ;-))....

How about a 3rd option --- Let's go back to the problem set
and fix the text from there.

         Problem 1  - persistent flapping (bad thing), recommended
                      fix: IDLE hold timer

         Problem 2 -  FSM text doesn't specify how this features
                     works from all states.   Result:
                     inter-operability between implementations is
                     problematic.  [another bad thing]

If people are deploying BGP without the recommended (but
not required) IDLE hold timer for persistent flapping,
then this specification should allow it. [filter of what is deployed]

Option 3 - fix both with background text that says:
                 1) recommended to have IDLE Hold timer, and
                 2) Not required.

Now to the text:

Fix to problem 1 -  FSM does not require you to implemented
the hold off.

How about replacing this  following text at the IDLE State:

IDLE
=============

 From this text:
 >A manual start event is a start event initiated
 >by an operator. An automatic start event is
 >a start event generated by the system.

The text can be: a manual event is intended to be
a start event generated by "manual" intervention.  If the
presistent flapping suppression option is not set,
all start events will be manual start events.

How about re-adding this section at the bottom
of the state machine?

Manual versus Automatic start in the FSM

If a BGP speaker detects an error, it shuts down the
connection and changes its state to Idle-hold. Getting out
of the Idle state requires generation of the Start event.
Such a start event can either be manual or automatic.

If this start event is generated automatically, then
persistent BGP errors may result in persistent flapping
of the speaker.  To avoid such a condition it is
recommended that the Start events should not be generated
immediately for a peer that was previously transitioned
to Idle due to an error.   For a peer that was previously
transitioned to Idle due to an error, the time between
consecutive generation of Start events, if such events are
generated automatically, shall exponentially increase. The
value of the initial timer shall be 60 seconds. The time shall
be doubled for each consecutive retry.The formula for this
expotential backoff is expressed in the formula:

         IDLE hold time = 2**(connectRetryCnt)*60

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

What do you think?

Sue Hares

At 03:01 PM 1/15/2002 -0500, Russ White wrote:

>So, then it sounds like the way we should approach this (the
>idlehold state in the fsm) is to think about it seperately from
>the draft 17 issue (?).
>
>Russ
>
>On Tue, 15 Jan 2002, Susan Hares wrote:
>
> >
> > Alex:
> >
> > I know you have been active on the mailing list.
> > And you didn't read it before the last call on the FSM.
> > And this question was asked on the list because I
> > wondered about it.
> >
> > ;-)... <giggle on>  --- I guess not even great people are
> > perfect.  <giggle off>
> >
> > OK, now I've got 2 more against (4 total).  And 15-20 votes
> > for it inside the draft.
> >
> > I'm sure your vote is a bit more specific.  :-)...
> >
> > Is the issue you want to pull exponential out of the draft?
> > This is a change to the BGP specification.  This draft
> > is about corrections not changes in functionality.
> >
> > What do we do?
> >
> > Sue Hares
> >
> >
> >
> > At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote:
> >
> > >Russ, Eric,
> > >
> > >  I tend to agree here...
> > >  I'm currently reviewing the FSM and the impression I'm
> > >  getting is that we can go without the IdleHold state
> > >  and say that implementations may/should use some local mechanisms
> > >  to hold BGP sessions in the *Idle* state to avoid excessive
> > >  session flapping. I think this will be simpler and will
> > >  match current implementations better...
> > >
> > >--
> > >Alex Zinin
> > >
> > >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote:
> > >
> > >
> > > > Something like: "BGP implementations can/should/must
> > > > (?) implement some method to prevent continuous flapping of
> > > > peering sessions at a high rate," and then a footbote explaining
> > > > that an exponential backoff is one such possible method?
> > >
> > > > Russ
> > >
> > > > On Tue, 15 Jan 2002, Eric Gray wrote:
> > >
> > > >> Russ,
> > > >>
> > > >>     Very good point.  However, how would you represent "do some
> > > >> private magic here" in an FSM?  That may make it the dreaded ISM.
> > > >> Perhaps it might be sufficient to remove this from the FSM and
> > > >> add a footnote (possibly mentioning an exponential back-off as an
> > > >> example?).
> > > >>
> > > >> You wrote:
> > > >>
> > > >> > Well, I just took it as 'do people do this?' I agree that it
> > > >> > won't cause interop problems either way--it's actually something
> > > >> > that's implementation local, so I'm not certain why the
> > > >> > exponential backoff would be in the fsm (?). There are, in other
> > > >> > words, other ways I could imagine handling this problem that
> > > >> > wouldn't effect interoperability as well....
> > > >> >
> > > >> > :-)
> > > >> >
> > > >> > Russ
> > > >> >
> > > >> > On Tue, 15 Jan 2002, Eric Gray wrote:
> > > >> >
> > > >> > > Russ,
> > > >> > >
> > > >> > >     I don't think that NAKs are in order on this question - even
> > > from the
> > > >> > > 1500 pound dragon.  :-)
> > > >> > >
> > > >> > >     The fact that anyone's implementation doesn't do X is
> > > important only
> > > >> > > if not doing X causes interoperability problems with 
> implementations
> > > >> > > that do X.   That is not the case here, I believe...
> > > >> > >
> > > >> > > You wrote:
> > > >> > >
> > > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter 
> wrote:
> > > >> > > > > > > Please remember that the goal of the draft is to document
> > > >> > > > > > > what is *currently* implemented and deployed, *not* what
> > > >> > > > > > > *could* be implemented and deployed.
> > > >> > > > > >
> > > >> > > > > > Is the expoential backoff in the FSM in current 
> implementations?
> > > >> > > > >
> > > >> > > > > I guess we are going to find this out as part of the
> > > >> > > > > implementation report. And if it is not in (at least two)
> > > >> > > > > current implementations, we'll take it out of the text.
> > > >> > > >
> > > >> > > > Cisco doesn't do this....
> > > >> > > >
> > > >> > > > :-)
> > > >> > > >
> > > >> > > > Russ
> > > >> > > >
> > > >> > > > _____________________________
> > > >> > > > [email-masked] <>< Grace Alone
> > > >> > >
> > > >> > > --
> > > >> > > Eric Gray (mailto:[email-masked])
> > > >> > > http://www.mindspring.com/~ewgray
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> > _____________________________
> > > >> > [email-masked] <>< Grace Alone
> > > >>
> > > >> --
> > > >> Eric Gray (mailto:[email-masked])
> > > >> http://www.mindspring.com/~ewgray
> > > >>
> > > >>
> > > >>
> > >
> > > > _____________________________
> > > > [email-masked] <>< Grace Alone
> >
> >
>
>_____________________________
>[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 16:15:52 -0500
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: IDR WG Last Call
Sender: [email-masked]

On Tue, Jan 15, 2002 at 09:47:16AM -0800, Enke Chen wrote:
> If we want to define the behavior, I would like to suggest sticking to
> the order in the message. That probably would reflect the sender's
> intention more closely, and make the processing simpler.

Two issues:
1. Path attribute order, when sorted, puts MP_UNREACH_NLRI after 
   MP_REACH_NLRI.
2. Path attributes are now explicitly allowed to be unordered.

I'd rather see some determinism across implementations.

> -- Enke

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 15 Jan 2002 16:12:22 -0500
From: Jeffrey Haas <[email-masked]>
To: Dave Thaler <[email-masked]>
Cc: Enke Chen <[email-masked]>, [email-masked]
Subject: Re: IDR WG Last Call
Sender: [email-masked]

Dave,

On Tue, Jan 15, 2002 at 11:13:42AM -0800, Dave Thaler wrote:
> SAFI 3 was put in at operator's requests (Dorian, for one, I forget who
> else now).  They considered it a MUST to avoid doubling the routing
> table size and amount of BGP traffic when one's unicast and multicast
> topology are the same.
> 
> Before taking it out, you might want to check with Dorian.

While I agree that its nice in theory, you have the added difficulty
of having to maintain additional state for things such as WRD
and potentially awkward queue mechanisms for outgoing routes.
As such, you actually implement at least as much, if not more, 
infrastructure to deal with the additional overhead of having
a SAFI that covers the unicast+multicast case.

Additionally, policy is now a real pain - and very ambiguous in
the current spec.  If you say "accept unicast and multicast routes",
does that mean accept only SAFI 3 or SAFI's 1, 2 and 3?

As Sue has mentioned, treating them as bits works fine for these
three SAFI's.  But I'd rather not have to.

I'm not going to argue very hard for removing SAFI 3 - we already
implement it.  But there are complications that don't seem to be
accounted for with regards to its supposed information overhead reduction.

> -Dave

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 15 Jan 2002 16:05:26 -0500
From: Jeffrey Haas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Gentlefolk,

Perhaps this will add some clarification on "what does this mean to me"
to have the "new state" in the FSM:

1. RFC 1771 has exponential backoff documented.
1a. The current draft allows a ceiling on this value.
2. The original FSM documents 6 states.  When you attempt to expand
   the state table from the normative text (even without the
   distinction of a manual vs. automatic start/stop events), you arrive
   at another undocumented state.
3. The draft explicitly documents this state and makes explicit the
   difference between the manual vs. the automatic events.  The
   state table the Sue had posted some time ago (wasn't that supposed
   to be in the appendix?) covers all the events and the states.
4. What does this do to implementations that supported the exponential
   backoff?  Probably not much.  You can LIVE with the existing Idle
   state for both MIB and for CLI display purposes.  What was originally
   implied was that there was a timer (you could show it in your CLI
   for example) that would implement the exponential backoff.
5. The new draft makes the state explicitly visible.  As this primarily
   affects the display within a CLI and the MIB rather than the on-the-wire
   protocol, there's no need to panic.

Implementation:
If you implement exponential backoff, it should be pretty trivial to
insert the new "state" into you FSM to deal with the un-expired timer
event.  It will be 7 in the MIB obviously. :-)

If we don't have enough wiggle room in the spec to deal with those
who don't implment the expoential backoff, perhaps a SHOULD can be
added in the appropriate spot - or the spec should remain silent
on the issue and let people be non-compliant.

Sue, Yakov: Is the fact that the new state would only be visible by
a outside of protocol scope means going to stop us from going to
full standard?  Technically, it is measurable by watching for
the packets and the delays between them but this doesn't break
interoperability.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 15 Jan 2002 15:15:16 -0500
From: Jeffrey Haas <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: IDR WG Last Call
Sender: [email-masked]

On Tue, Jan 15, 2002 at 03:02:55PM -0500, Russ White wrote:
> Correct--SAFI 3.... There aren't any implementations that I've
> seen, and it does complicate matters a bit more than needed.

Ahem.
GateD supports it perfectly fine. 

> Russ

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 15 Jan 2002 15:02:55 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: Susan Hares <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: IDR WG Last Call 
Sender: [email-masked]

Correct--SAFI 3.... There aren't any implementations that I've
seen, and it does complicate matters a bit more than needed.

Russ

On Tue, 15 Jan 2002, Enke Chen wrote:

> Sue,
> 
> > Date: Tue, 15 Jan 2002 14:49:14 -0500
> > To: Russ White <[email-masked]>
> > From: Susan Hares <[email-masked]>
> > Subject: Re: IDR WG Last Call 
> > Cc: Enke Chen <[email-masked]>, Jeffrey Haas <[email-masked]>,
> > 	[email-masked]
> > In-Reply-To: <[email-masked]
> >  .com>
> > References: <[email-masked]>
> > Mime-Version: 1.0
> > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > X-NextHop-MailScanner: Found to be clean
> > 
> > Russ:
> > 
> > We had that vote 1 month ago.  The overwhelming
> > majority was to keep it in. We are not re-opening
> > that issue having closed it on the mail list already.
> 
> The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3"
> in his message if I am not mistaken.
> 
> -- Enke
> 
> > 
> > 
> > Sue
> > 
> > At 01:03 PM 1/15/2002 -0500, Russ White wrote:
> > 
> > >I think it's probably a good idea to get rid of this out of the
> > >spec--it would make things cleaner.
> > >
> > >Russ
> > >
> > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > >
> > > > Jeff,
> > > >
> > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > > > From: Jeffrey Haas <[email-masked]>
> > > > > To: Enke Chen <[email-masked]>
> > > > > Cc: [email-masked]
> > > > > Subject: Re: IDR WG Last Call
> > > > > Message-ID: <[email-masked]>
> > > > >
> > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > > > It seems that the "SAFI 3" certainly makes the issue at hand much more
> > > > > > complicated.
> > > > >
> > > > > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > > > > be a real pain in the implementation. :-)
> > > >
> > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
> > > > much value, but has caused a lot of confusion and complexity. I am not
> > > > aware of any depolyment either.
> > > >
> > > > >
> > > > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > > > having one prefix in multiple fields of an update message. How 
> > > about the
> > > > > > following text:
> > > > > >
> > > > > >    An UPDATE message should not include the same address prefix in 
> > > more than
> > > > > >    one of the following fields: WITHDRAWN ROUTES field, Network 
> > > Reachability
> > > > > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI 
> > > field. The
> > > > > >    processing of an UPDATE message in this form is un-defined.
> > > > >
> > > > > I think that "undefined" is overkill.  I would suggest the following 
> > > instead:
> > > > >
> > > > > An UPDATE message should not include the same address prefix in
> > > > > more than one of the following fields: WITHDRAWN ROUTES, Network
> > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > > > > An implementation that receives a packet in this form should process
> > > > > the Update as if it had processed it in the following order:
> > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > > > Reachability Information.
> > > > >
> > > > > The wording could probably use some tightening.
> > > > >
> > > > > The intended result is that reachability rules over unreachability.
> > > >
> > > > If we want to define the behavior, I would like to suggest sticking to
> > > > the order in the message. That probably would reflect the sender's
> > > > intention more closely, and make the processing simpler.
> > > >
> > > > -- Enke
> > > >
> > > >
> > >
> > >_____________________________
> > >[email-masked] <>< Grace Alone
> > 
> > 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 15:01:38 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Alex Zinin <[email-masked]>, Eric Gray <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

So, then it sounds like the way we should approach this (the
idlehold state in the fsm) is to think about it seperately from
the draft 17 issue (?).

Russ

On Tue, 15 Jan 2002, Susan Hares wrote:

> 
> Alex:
> 
> I know you have been active on the mailing list.
> And you didn't read it before the last call on the FSM.
> And this question was asked on the list because I
> wondered about it.
> 
> ;-)... <giggle on>  --- I guess not even great people are
> perfect.  <giggle off>
> 
> OK, now I've got 2 more against (4 total).  And 15-20 votes
> for it inside the draft.
> 
> I'm sure your vote is a bit more specific.  :-)...
> 
> Is the issue you want to pull exponential out of the draft?
> This is a change to the BGP specification.  This draft
> is about corrections not changes in functionality.
> 
> What do we do?
> 
> Sue Hares
> 
> 
> 
> At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote:
> 
> >Russ, Eric,
> >
> >  I tend to agree here...
> >  I'm currently reviewing the FSM and the impression I'm
> >  getting is that we can go without the IdleHold state
> >  and say that implementations may/should use some local mechanisms
> >  to hold BGP sessions in the *Idle* state to avoid excessive
> >  session flapping. I think this will be simpler and will
> >  match current implementations better...
> >
> >--
> >Alex Zinin
> >
> >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote:
> >
> >
> > > Something like: "BGP implementations can/should/must
> > > (?) implement some method to prevent continuous flapping of
> > > peering sessions at a high rate," and then a footbote explaining
> > > that an exponential backoff is one such possible method?
> >
> > > Russ
> >
> > > On Tue, 15 Jan 2002, Eric Gray wrote:
> >
> > >> Russ,
> > >>
> > >>     Very good point.  However, how would you represent "do some
> > >> private magic here" in an FSM?  That may make it the dreaded ISM.
> > >> Perhaps it might be sufficient to remove this from the FSM and
> > >> add a footnote (possibly mentioning an exponential back-off as an
> > >> example?).
> > >>
> > >> You wrote:
> > >>
> > >> > Well, I just took it as 'do people do this?' I agree that it
> > >> > won't cause interop problems either way--it's actually something
> > >> > that's implementation local, so I'm not certain why the
> > >> > exponential backoff would be in the fsm (?). There are, in other
> > >> > words, other ways I could imagine handling this problem that
> > >> > wouldn't effect interoperability as well....
> > >> >
> > >> > :-)
> > >> >
> > >> > Russ
> > >> >
> > >> > On Tue, 15 Jan 2002, Eric Gray wrote:
> > >> >
> > >> > > Russ,
> > >> > >
> > >> > >     I don't think that NAKs are in order on this question - even 
> > from the
> > >> > > 1500 pound dragon.  :-)
> > >> > >
> > >> > >     The fact that anyone's implementation doesn't do X is 
> > important only
> > >> > > if not doing X causes interoperability problems with implementations
> > >> > > that do X.   That is not the case here, I believe...
> > >> > >
> > >> > > You wrote:
> > >> > >
> > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > >> > > > > > > Please remember that the goal of the draft is to document
> > >> > > > > > > what is *currently* implemented and deployed, *not* what
> > >> > > > > > > *could* be implemented and deployed.
> > >> > > > > >
> > >> > > > > > Is the expoential backoff in the FSM in current implementations?
> > >> > > > >
> > >> > > > > I guess we are going to find this out as part of the
> > >> > > > > implementation report. And if it is not in (at least two)
> > >> > > > > current implementations, we'll take it out of the text.
> > >> > > >
> > >> > > > Cisco doesn't do this....
> > >> > > >
> > >> > > > :-)
> > >> > > >
> > >> > > > Russ
> > >> > > >
> > >> > > > _____________________________
> > >> > > > [email-masked] <>< Grace Alone
> > >> > >
> > >> > > --
> > >> > > Eric Gray (mailto:[email-masked])
> > >> > > http://www.mindspring.com/~ewgray
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> > _____________________________
> > >> > [email-masked] <>< Grace Alone
> > >>
> > >> --
> > >> Eric Gray (mailto:[email-masked])
> > >> http://www.mindspring.com/~ewgray
> > >>
> > >>
> > >>
> >
> > > _____________________________
> > > [email-masked] <>< Grace Alone
> 
> 

_____________________________
[email-masked] <>< Grace Alone

To: Susan Hares <[email-masked]>
Cc: Russ White <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Tue, 15 Jan 2002 12:00:51 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue,

> Date: Tue, 15 Jan 2002 14:49:14 -0500
> To: Russ White <[email-masked]>
> From: Susan Hares <[email-masked]>
> Subject: Re: IDR WG Last Call 
> Cc: Enke Chen <[email-masked]>, Jeffrey Haas <[email-masked]>,
> 	[email-masked]
> In-Reply-To: <[email-masked]
>  .com>
> References: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> X-NextHop-MailScanner: Found to be clean
> 
> Russ:
> 
> We had that vote 1 month ago.  The overwhelming
> majority was to keep it in. We are not re-opening
> that issue having closed it on the mail list already.

The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3"
in his message if I am not mistaken.

-- Enke

> 
> 
> Sue
> 
> At 01:03 PM 1/15/2002 -0500, Russ White wrote:
> 
> >I think it's probably a good idea to get rid of this out of the
> >spec--it would make things cleaner.
> >
> >Russ
> >
> >On Tue, 15 Jan 2002, Enke Chen wrote:
> >
> > > Jeff,
> > >
> > > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > > From: Jeffrey Haas <[email-masked]>
> > > > To: Enke Chen <[email-masked]>
> > > > Cc: [email-masked]
> > > > Subject: Re: IDR WG Last Call
> > > > Message-ID: <[email-masked]>
> > > >
> > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > > It seems that the "SAFI 3" certainly makes the issue at hand much more
> > > > > complicated.
> > > >
> > > > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > > > be a real pain in the implementation. :-)
> > >
> > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
> > > much value, but has caused a lot of confusion and complexity. I am not
> > > aware of any depolyment either.
> > >
> > > >
> > > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > > having one prefix in multiple fields of an update message. How 
> > about the
> > > > > following text:
> > > > >
> > > > >    An UPDATE message should not include the same address prefix in 
> > more than
> > > > >    one of the following fields: WITHDRAWN ROUTES field, Network 
> > Reachability
> > > > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI 
> > field. The
> > > > >    processing of an UPDATE message in this form is un-defined.
> > > >
> > > > I think that "undefined" is overkill.  I would suggest the following 
> > instead:
> > > >
> > > > An UPDATE message should not include the same address prefix in
> > > > more than one of the following fields: WITHDRAWN ROUTES, Network
> > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > > > An implementation that receives a packet in this form should process
> > > > the Update as if it had processed it in the following order:
> > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > > Reachability Information.
> > > >
> > > > The wording could probably use some tightening.
> > > >
> > > > The intended result is that reachability rules over unreachability.
> > >
> > > If we want to define the behavior, I would like to suggest sticking to
> > > the order in the message. That probably would reflect the sender's
> > > intention more closely, and make the processing simpler.
> > >
> > > -- Enke
> > >
> > >
> >
> >_____________________________
> >[email-masked] <>< Grace Alone
> 
> 

Date: Tue, 15 Jan 2002 14:56:05 -0500
To: Alex Zinin <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: Russ White <[email-masked]>, Eric Gray <[email-masked]>, Russ White <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Sender: [email-masked]

Alex:

I know you have been active on the mailing list.
And you didn't read it before the last call on the FSM.
And this question was asked on the list because I
wondered about it.

;-)... <giggle on>  --- I guess not even great people are
perfect.  <giggle off>

OK, now I've got 2 more against (4 total).  And 15-20 votes
for it inside the draft.

I'm sure your vote is a bit more specific.  :-)...

Is the issue you want to pull exponential out of the draft?
This is a change to the BGP specification.  This draft
is about corrections not changes in functionality.

What do we do?

Sue Hares

At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote:

>Russ, Eric,
>
>  I tend to agree here...
>  I'm currently reviewing the FSM and the impression I'm
>  getting is that we can go without the IdleHold state
>  and say that implementations may/should use some local mechanisms
>  to hold BGP sessions in the *Idle* state to avoid excessive
>  session flapping. I think this will be simpler and will
>  match current implementations better...
>
>--
>Alex Zinin
>
>Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote:
>
>
> > Something like: "BGP implementations can/should/must
> > (?) implement some method to prevent continuous flapping of
> > peering sessions at a high rate," and then a footbote explaining
> > that an exponential backoff is one such possible method?
>
> > Russ
>
> > On Tue, 15 Jan 2002, Eric Gray wrote:
>
> >> Russ,
> >>
> >>     Very good point.  However, how would you represent "do some
> >> private magic here" in an FSM?  That may make it the dreaded ISM.
> >> Perhaps it might be sufficient to remove this from the FSM and
> >> add a footnote (possibly mentioning an exponential back-off as an
> >> example?).
> >>
> >> You wrote:
> >>
> >> > Well, I just took it as 'do people do this?' I agree that it
> >> > won't cause interop problems either way--it's actually something
> >> > that's implementation local, so I'm not certain why the
> >> > exponential backoff would be in the fsm (?). There are, in other
> >> > words, other ways I could imagine handling this problem that
> >> > wouldn't effect interoperability as well....
> >> >
> >> > :-)
> >> >
> >> > Russ
> >> >
> >> > On Tue, 15 Jan 2002, Eric Gray wrote:
> >> >
> >> > > Russ,
> >> > >
> >> > >     I don't think that NAKs are in order on this question - even 
> from the
> >> > > 1500 pound dragon.  :-)
> >> > >
> >> > >     The fact that anyone's implementation doesn't do X is 
> important only
> >> > > if not doing X causes interoperability problems with implementations
> >> > > that do X.   That is not the case here, I believe...
> >> > >
> >> > > You wrote:
> >> > >
> >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> >> > > > > > > Please remember that the goal of the draft is to document
> >> > > > > > > what is *currently* implemented and deployed, *not* what
> >> > > > > > > *could* be implemented and deployed.
> >> > > > > >
> >> > > > > > Is the expoential backoff in the FSM in current implementations?
> >> > > > >
> >> > > > > I guess we are going to find this out as part of the
> >> > > > > implementation report. And if it is not in (at least two)
> >> > > > > current implementations, we'll take it out of the text.
> >> > > >
> >> > > > Cisco doesn't do this....
> >> > > >
> >> > > > :-)
> >> > > >
> >> > > > Russ
> >> > > >
> >> > > > _____________________________
> >> > > > [email-masked] <>< Grace Alone
> >> > >
> >> > > --
> >> > > Eric Gray (mailto:[email-masked])
> >> > > http://www.mindspring.com/~ewgray
> >> > >
> >> > >
> >> > >
> >> >
> >> > _____________________________
> >> > [email-masked] <>< Grace Alone
> >>
> >> --
> >> Eric Gray (mailto:[email-masked])
> >> http://www.mindspring.com/~ewgray
> >>
> >>
> >>
>
> > _____________________________
> > [email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 14:49:14 -0500
To: Russ White <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: Enke Chen <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Sender: [email-masked]

Russ:

We had that vote 1 month ago.  The overwhelming
majority was to keep it in. We are not re-opening
that issue having closed it on the mail list already.

Sue

At 01:03 PM 1/15/2002 -0500, Russ White wrote:

>I think it's probably a good idea to get rid of this out of the
>spec--it would make things cleaner.
>
>Russ
>
>On Tue, 15 Jan 2002, Enke Chen wrote:
>
> > Jeff,
> >
> > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > From: Jeffrey Haas <[email-masked]>
> > > To: Enke Chen <[email-masked]>
> > > Cc: [email-masked]
> > > Subject: Re: IDR WG Last Call
> > > Message-ID: <[email-masked]>
> > >
> > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > It seems that the "SAFI 3" certainly makes the issue at hand much more
> > > > complicated.
> > >
> > > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > > be a real pain in the implementation. :-)
> >
> > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
> > much value, but has caused a lot of confusion and complexity. I am not
> > aware of any depolyment either.
> >
> > >
> > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > having one prefix in multiple fields of an update message. How 
> about the
> > > > following text:
> > > >
> > > >    An UPDATE message should not include the same address prefix in 
> more than
> > > >    one of the following fields: WITHDRAWN ROUTES field, Network 
> Reachability
> > > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI 
> field. The
> > > >    processing of an UPDATE message in this form is un-defined.
> > >
> > > I think that "undefined" is overkill.  I would suggest the following 
> instead:
> > >
> > > An UPDATE message should not include the same address prefix in
> > > more than one of the following fields: WITHDRAWN ROUTES, Network
> > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > > An implementation that receives a packet in this form should process
> > > the Update as if it had processed it in the following order:
> > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > Reachability Information.
> > >
> > > The wording could probably use some tightening.
> > >
> > > The intended result is that reachability rules over unreachability.
> >
> > If we want to define the behavior, I would like to suggest sticking to
> > the order in the message. That probably would reflect the sender's
> > intention more closely, and make the processing simpler.
> >
> > -- Enke
> >
> >
>
>_____________________________
>[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 14:13:05 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: Jeffrey Haas <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Enke:

We are back to my original point.

I would suggest a SAFI 2 + SAFI 1 being bit patterns
in the specification.

We could then deal with the (AFI, SAFI) pair.

I would suggest (per the example) that the order of
process is UNREACH and then REACH.  Please see
my example for the example of this problem.

Sue

At 09:47 AM 1/15/2002 -0800, Enke Chen wrote:
>Jeff,
>
> > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > From: Jeffrey Haas <[email-masked]>
> > To: Enke Chen <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: IDR WG Last Call
> > Message-ID: <[email-masked]>
> >
> > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > It seems that the "SAFI 3" certainly makes the issue at hand much more
> > > complicated.
> >
> > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > be a real pain in the implementation. :-)
>
>So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
>much value, but has caused a lot of confusion and complexity. I am not
>aware of any depolyment either.
>
> >
> > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > having one prefix in multiple fields of an update message. How about the
> > > following text:
> > >
> > >    An UPDATE message should not include the same address prefix in 
> more than
> > >    one of the following fields: WITHDRAWN ROUTES field, Network 
> Reachability
> > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI 
> field. The
> > >    processing of an UPDATE message in this form is un-defined.
> >
> > I think that "undefined" is overkill.  I would suggest the following 
> instead:
> >
> > An UPDATE message should not include the same address prefix in
> > more than one of the following fields: WITHDRAWN ROUTES, Network
> > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > An implementation that receives a packet in this form should process
> > the Update as if it had processed it in the following order:
> > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > Reachability Information.
> >
> > The wording could probably use some tightening.
> >
> > The intended result is that reachability rules over unreachability.
>
>If we want to define the behavior, I would like to suggest sticking to
>the order in the message. That probably would reflect the sender's
>intention more closely, and make the processing simpler.
>
>-- Enke

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: bgp4-17 Section 9 
Date: Wed, 15 Jan 2003 18:28:48 -0000
Sender: [email-masked]

Combining NEXT_HOP resolution into one place (5.1.3) I
suggest

Revised 9.1.2 para 7

The local speaker MUST determine the immediate next-hop
address from the NEXT_HOP attribute of the selected route
(see section 5.1.3).
If either the immediate next hop or the IGP cost to the
NEXT_HOP (where the NEXT_HOP is resolved through an IGP
route) changes, Phase 2: Route Selection should be performed
again.

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

Revised 5.1.3

   The NEXT_HOP attribute is used by the BGP speaker to
determine the
   actual outbound interface and immediate next-hop address
that should
   be used to forward transit packets to the associated
destinations.

   The immediate next-hop address is determined by
performing a
   recursive route lookup operation for the IP address in
the NEXT_HOP
   attribute using the contents of the Routing Table,
-----------revised text follows ------------
selecting one entry if multiple entries of equal cost exist.
The Routing Table entry which resolves the NEXT_HOP
attribute will always specify the outbound interface.
If the entry also specifies the next-hop address, this
address should be used as the immediate next-hop address for
packet forwarding.
If the entry specifies an attached subnet (and does not
specify a next-hop address), then the address in the
NEXT_HOP attribute should be used as the immediate next-hop
address.
------------end of revision----------

I (still) believe 'resolving route' is not at all clear,
hence my use of the form
'The Routing Table entry which resolves the NEXT_HOP
attribute ...'
But I am less hung up on whether we mention entry or use
path or drop 'Routing Table'.
I take the point about there being a limit as to how much
we can say about routing tables; I tend to regard RFC1812 as
the sine qua none.

Tom Petch, Network Consultant
[email-masked]

-----Original Message-----
From: Yakov Rekhter <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 14 January 2002 20:15
Subject: Re: bgp4-17 Section 9

>>
>> 9.1.2 Route selection now allows for the best route in
>> Loc-RIB not to be placed in the Routing table; how does
this
>> impact on the principle (2 Introduction) that a BGP
Speaker
>> should only advertise routes it itself uses?  Is it
enough
>> for the route to be in Loc-RIB and not in the Routing
Table?
>>
>> I believe the paragraph on immediate next hop should
>> cross-reference the one in 5.1.3; and the latter allows
>> route lookup to resolve to a subnet and not an immediate
>> next hop address, a possibility 9.1.2 appears not to
cater
>> for.
>>
>> Perhaps the information on immediate next hop in 5.1.3
and 9
>> should be combined in one place; 5.1.3 would be my
>> preference.
>
>Please propose the specific changes.
>
>Yakov.

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: bgp4-17 5.1.3 immediate next hop
Date: Wed, 15 Jan 2003 18:31:52 -0000
Sender: [email-masked]

Well yes, I did understand it (I think).

I still query the use of the term 'resolving route'.  (I
just don't see the term used in this, IP
forwarding, context and there is a disjunction between this
and the previous sentence, which uses the more familiar - to
me - terms such as recursive route lookup).

I find it much clearer when you say, as in your e-mail,
'the route resolving the NEXT_HOP'
or going a bit further
'the routing table entry which resolves the NEXT_HOP
attribute.
I see no harm and positive benefit is spelling it out.

Tom Petch, Network Consultant
[email-masked]

Date: Tue, 15 Jan 2002 10:30:53 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Russ White <[email-masked]>
Cc: Eric Gray <[email-masked]>, Russ White <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Russ, Eric,

 I tend to agree here...
 I'm currently reviewing the FSM and the impression I'm
 getting is that we can go without the IdleHold state
 and say that implementations may/should use some local mechanisms
 to hold BGP sessions in the *Idle* state to avoid excessive
 session flapping. I think this will be simpler and will
 match current implementations better...

-- 
Alex Zinin

Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote:

> Something like: "BGP implementations can/should/must
> (?) implement some method to prevent continuous flapping of
> peering sessions at a high rate," and then a footbote explaining
> that an exponential backoff is one such possible method?

> Russ

> On Tue, 15 Jan 2002, Eric Gray wrote:

>> Russ,
>> 
>>     Very good point.  However, how would you represent "do some
>> private magic here" in an FSM?  That may make it the dreaded ISM.
>> Perhaps it might be sufficient to remove this from the FSM and
>> add a footnote (possibly mentioning an exponential back-off as an
>> example?).
>> 
>> You wrote:
>> 
>> > Well, I just took it as 'do people do this?' I agree that it
>> > won't cause interop problems either way--it's actually something
>> > that's implementation local, so I'm not certain why the
>> > exponential backoff would be in the fsm (?). There are, in other
>> > words, other ways I could imagine handling this problem that
>> > wouldn't effect interoperability as well....
>> >
>> > :-)
>> >
>> > Russ
>> >
>> > On Tue, 15 Jan 2002, Eric Gray wrote:
>> >
>> > > Russ,
>> > >
>> > >     I don't think that NAKs are in order on this question - even from the
>> > > 1500 pound dragon.  :-)
>> > >
>> > >     The fact that anyone's implementation doesn't do X is important only
>> > > if not doing X causes interoperability problems with implementations
>> > > that do X.   That is not the case here, I believe...
>> > >
>> > > You wrote:
>> > >
>> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
>> > > > > > > Please remember that the goal of the draft is to document
>> > > > > > > what is *currently* implemented and deployed, *not* what
>> > > > > > > *could* be implemented and deployed.
>> > > > > >
>> > > > > > Is the expoential backoff in the FSM in current implementations?
>> > > > >
>> > > > > I guess we are going to find this out as part of the
>> > > > > implementation report. And if it is not in (at least two)
>> > > > > current implementations, we'll take it out of the text.
>> > > >
>> > > > Cisco doesn't do this....
>> > > >
>> > > > :-)
>> > > >
>> > > > Russ
>> > > >
>> > > > _____________________________
>> > > > [email-masked] <>< Grace Alone
>> > >
>> > > --
>> > > Eric Gray (mailto:[email-masked])
>> > > http://www.mindspring.com/~ewgray
>> > >
>> > >
>> > >
>> >
>> > _____________________________
>> > [email-masked] <>< Grace Alone
>> 
>> --
>> Eric Gray (mailto:[email-masked])
>> http://www.mindspring.com/~ewgray
>> 
>> 
>> 

> _____________________________
> [email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 13:03:47 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: IDR WG Last Call 
Sender: [email-masked]

I think it's probably a good idea to get rid of this out of the
spec--it would make things cleaner.

Russ

On Tue, 15 Jan 2002, Enke Chen wrote:

> Jeff,
> 
> > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > From: Jeffrey Haas <[email-masked]>
> > To: Enke Chen <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: IDR WG Last Call
> > Message-ID: <[email-masked]>
> > 
> > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > It seems that the "SAFI 3" certainly makes the issue at hand much more
> > > complicated.
> > 
> > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > be a real pain in the implementation. :-)
> 
> So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
> much value, but has caused a lot of confusion and complexity. I am not
> aware of any depolyment either.
> 
> > 
> > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > having one prefix in multiple fields of an update message. How about the
> > > following text:
> > > 
> > >    An UPDATE message should not include the same address prefix in more than
> > >    one of the following fields: WITHDRAWN ROUTES field, Network Reachability
> > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The
> > >    processing of an UPDATE message in this form is un-defined.
> > 
> > I think that "undefined" is overkill.  I would suggest the following instead:
> > 
> > An UPDATE message should not include the same address prefix in
> > more than one of the following fields: WITHDRAWN ROUTES, Network
> > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > An implementation that receives a packet in this form should process
> > the Update as if it had processed it in the following order:
> > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > Reachability Information.
> > 
> > The wording could probably use some tightening.
> > 
> > The intended result is that reachability rules over unreachability.
> 
> If we want to define the behavior, I would like to suggest sticking to
> the order in the message. That probably would reflect the sender's
> intention more closely, and make the processing simpler.
> 
> -- Enke
> 
> 

_____________________________
[email-masked] <>< Grace Alone

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Tue, 15 Jan 2002 09:47:16 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Jeff,

> Date: Mon, 14 Jan 2002 23:21:28 -0500
> From: Jeffrey Haas <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: IDR WG Last Call
> Message-ID: <[email-masked]>
> 
> On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > It seems that the "SAFI 3" certainly makes the issue at hand much more
> > complicated.
> 
> IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> be a real pain in the implementation. :-)

So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
much value, but has caused a lot of confusion and complexity. I am not
aware of any depolyment either.

> 
> > As Yakov and Sue pointed out, it is a good idea to discourage
> > having one prefix in multiple fields of an update message. How about the
> > following text:
> > 
> >    An UPDATE message should not include the same address prefix in more than
> >    one of the following fields: WITHDRAWN ROUTES field, Network Reachability
> >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The
> >    processing of an UPDATE message in this form is un-defined.
> 
> I think that "undefined" is overkill.  I would suggest the following instead:
> 
> An UPDATE message should not include the same address prefix in
> more than one of the following fields: WITHDRAWN ROUTES, Network
> Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> An implementation that receives a packet in this form should process
> the Update as if it had processed it in the following order:
> WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> Reachability Information.
> 
> The wording could probably use some tightening.
> 
> The intended result is that reachability rules over unreachability.

If we want to define the behavior, I would like to suggest sticking to
the order in the message. That probably would reflect the sender's
intention more closely, and make the processing simpler.

-- Enke

Date: Tue, 15 Jan 2002 10:21:06 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Something like: "BGP implementations can/should/must
(?) implement some method to prevent continuous flapping of
peering sessions at a high rate," and then a footbote explaining
that an exponential backoff is one such possible method?

Russ

On Tue, 15 Jan 2002, Eric Gray wrote:

> Russ,
> 
>     Very good point.  However, how would you represent "do some
> private magic here" in an FSM?  That may make it the dreaded ISM.
> Perhaps it might be sufficient to remove this from the FSM and
> add a footnote (possibly mentioning an exponential back-off as an
> example?).
> 
> You wrote:
> 
> > Well, I just took it as 'do people do this?' I agree that it
> > won't cause interop problems either way--it's actually something
> > that's implementation local, so I'm not certain why the
> > exponential backoff would be in the fsm (?). There are, in other
> > words, other ways I could imagine handling this problem that
> > wouldn't effect interoperability as well....
> >
> > :-)
> >
> > Russ
> >
> > On Tue, 15 Jan 2002, Eric Gray wrote:
> >
> > > Russ,
> > >
> > >     I don't think that NAKs are in order on this question - even from the
> > > 1500 pound dragon.  :-)
> > >
> > >     The fact that anyone's implementation doesn't do X is important only
> > > if not doing X causes interoperability problems with implementations
> > > that do X.   That is not the case here, I believe...
> > >
> > > You wrote:
> > >
> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > > > > > > Please remember that the goal of the draft is to document
> > > > > > > what is *currently* implemented and deployed, *not* what
> > > > > > > *could* be implemented and deployed.
> > > > > >
> > > > > > Is the expoential backoff in the FSM in current implementations?
> > > > >
> > > > > I guess we are going to find this out as part of the
> > > > > implementation report. And if it is not in (at least two)
> > > > > current implementations, we'll take it out of the text.
> > > >
> > > > Cisco doesn't do this....
> > > >
> > > > :-)
> > > >
> > > > Russ
> > > >
> > > > _____________________________
> > > > [email-masked] <>< Grace Alone
> > >
> > > --
> > > Eric Gray (mailto:[email-masked])
> > > http://www.mindspring.com/~ewgray
> > >
> > >
> > >
> >
> > _____________________________
> > [email-masked] <>< Grace Alone
> 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 10:14:52 -0500
From: Eric Gray <[email-masked]>
To: Russ White <[email-masked]>
Cc: Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Russ,

    Very good point.  However, how would you represent "do some
private magic here" in an FSM?  That may make it the dreaded ISM.
Perhaps it might be sufficient to remove this from the FSM and
add a footnote (possibly mentioning an exponential back-off as an
example?).

You wrote:

> Well, I just took it as 'do people do this?' I agree that it
> won't cause interop problems either way--it's actually something
> that's implementation local, so I'm not certain why the
> exponential backoff would be in the fsm (?). There are, in other
> words, other ways I could imagine handling this problem that
> wouldn't effect interoperability as well....
>
> :-)
>
> Russ
>
> On Tue, 15 Jan 2002, Eric Gray wrote:
>
> > Russ,
> >
> >     I don't think that NAKs are in order on this question - even from the
> > 1500 pound dragon.  :-)
> >
> >     The fact that anyone's implementation doesn't do X is important only
> > if not doing X causes interoperability problems with implementations
> > that do X.   That is not the case here, I believe...
> >
> > You wrote:
> >
> > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > > > > > Please remember that the goal of the draft is to document
> > > > > > what is *currently* implemented and deployed, *not* what
> > > > > > *could* be implemented and deployed.
> > > > >
> > > > > Is the expoential backoff in the FSM in current implementations?
> > > >
> > > > I guess we are going to find this out as part of the
> > > > implementation report. And if it is not in (at least two)
> > > > current implementations, we'll take it out of the text.
> > >
> > > Cisco doesn't do this....
> > >
> > > :-)
> > >
> > > Russ
> > >
> > > _____________________________
> > > [email-masked] <>< Grace Alone
> >
> > --
> > Eric Gray (mailto:[email-masked])
> > http://www.mindspring.com/~ewgray
> >
> >
> >
>
> _____________________________
> [email-masked] <>< Grace Alone

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Date: Tue, 15 Jan 2002 10:07:34 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Well, I just took it as 'do people do this?' I agree that it
won't cause interop problems either way--it's actually something
that's implementation local, so I'm not certain why the
exponential backoff would be in the fsm (?). There are, in other
words, other ways I could imagine handling this problem that
wouldn't effect interoperability as well....

:-)

Russ

On Tue, 15 Jan 2002, Eric Gray wrote:

> Russ,
> 
>     I don't think that NAKs are in order on this question - even from the
> 1500 pound dragon.  :-)
> 
>     The fact that anyone's implementation doesn't do X is important only
> if not doing X causes interoperability problems with implementations
> that do X.   That is not the case here, I believe...
> 
> You wrote:
> 
> > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > > > > Please remember that the goal of the draft is to document
> > > > > what is *currently* implemented and deployed, *not* what
> > > > > *could* be implemented and deployed.
> > > >
> > > > Is the expoential backoff in the FSM in current implementations?
> > >
> > > I guess we are going to find this out as part of the
> > > implementation report. And if it is not in (at least two)
> > > current implementations, we'll take it out of the text.
> >
> > Cisco doesn't do this....
> >
> > :-)
> >
> > Russ
> >
> > _____________________________
> > [email-masked] <>< Grace Alone
> 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 10:00:00 -0500
From: Eric Gray <[email-masked]>
To: Russ White <[email-masked]>, Inter-Domain Routing Mailing List <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Russ,

    I don't think that NAKs are in order on this question - even from the
1500 pound dragon.  :-)

    The fact that anyone's implementation doesn't do X is important only
if not doing X causes interoperability problems with implementations
that do X.   That is not the case here, I believe...

You wrote:

> > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > > > Please remember that the goal of the draft is to document
> > > > what is *currently* implemented and deployed, *not* what
> > > > *could* be implemented and deployed.
> > >
> > > Is the expoential backoff in the FSM in current implementations?
> >
> > I guess we are going to find this out as part of the
> > implementation report. And if it is not in (at least two)
> > current implementations, we'll take it out of the text.
>
> Cisco doesn't do this....
>
> :-)
>
> Russ
>
> _____________________________
> [email-masked] <>< Grace Alone

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Date: Tue, 15 Jan 2002 08:33:38 -0800
From: Jeff Pickering <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Sue,

We have implemented the exponential backoff with a locally configured
cap.

Jeff

Susan Hares wrote:

> Jeff:
>
> The backoff was in the original FSM.  Your question
> still stands, is it in the implementations.
>
> Sue
>
> At 12:37 PM 1/14/2002 -0500, Jeffrey Haas wrote:
> >On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > > Please remember that the goal of the draft is to document
> > > what is *currently* implemented and deployed, *not* what
> > > *could* be implemented and deployed.
> >
> >Is the expoential backoff in the FSM in current implementations?
> >
> >Note that this change (IdleHold) to the FSM is going to result in
> >an alteration to the MIB.  This is one of the reasons I've held
> >off completion of the RFC 1657 update - to accomodate for this fact
> >to converge.
> >
> > > Therefore, the draft
> > > should not list these new subcodes.
> > >
> > > Yakov.
> >
> >--
> >Jeff Haas
> >NextHop Technologies

Date: Tue, 15 Jan 2002 15:07:11 +0100
From: Vincent Gillet <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

Yakov,

> > Is the expoential backoff in the FSM in current implementations?
> 
> I guess we are going to find this out as part of the implementation
> report. And if it is not in (at least two) current implementations,
> we'll take it out of the text.

I implemented Cease subcode in zebra-0.92a but not exponential backoff.
I checked that new subcode does not put other BGP stack in trouble
(checked Cisco and Juniper).

I have to clean-up patch and wait for another implementation to test
interoperability.
I am in touch with one vendor.

> > Note that this change (IdleHold) to the FSM is going to result in
> > an alteration to the MIB.  This is one of the reasons I've held
> > off completion of the RFC 1657 update - to accomodate for this fact
> > to converge.
> 
> Understood.

Sub-code implementation does not depend on backoff.
Draft only suggest that speaker should have such mechanism. It is
on the way with bgp4-17 draft.

Vincent.

To: Bill Fenner <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: 2842 to Draft Standard 
Date: Tue, 15 Jan 2002 05:55:40 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Bill,

> IDR WG,
> 
>   In order to progress to Draft Standard, an implementation report
> is required (see section 4.1.2 of RFC 2026).  In particular:
> 
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.
> 
> RFC 2842 has several optional portions (e.g. sending Notifications
> and whether to include the capability in question in the Notification),
> which the implementation report that you included in the original
> request did not mention.

Attached is an update version of the implementation report.

Yakov.
-------------------------------------------------------------------
The following is the list of some of the implementations of rfc2842:

Ericsson:
Interoperates with: Cisco, Juniper

Juniper Networks
Interoperates with: Cisco

Laurel Networks:
Interoperates with: Cisco, Juniper

NetPlane Systems Inc.
Interoperates with: Cisco, Juniper

Redback
Interoperates with: Cisco, Juniper

Riverstone:
Interoperates with: Cisco, Juniper, Zebra, Foundry

Unisphere Networks:
Interoperates with: Cisco, Juniper 

Gated:
Interoperates with: Cisco

If a BGP speaker that supports a certain capability determines that
its peer doesn't support this capability, 2 implementations never
send a NOTIFICATION message to the peer, and 5 implementations
sometimes send a NOTIFICATION message to the peer.

Out of the 5 implementations that send the NOTIFICATION message
(when the peer doesn't support a particular capability), 2
implementations never include the Capability in question in the
message, and 3 implementations always include the Capability in
question in the message.

Five implementors reported that they always terminate BGP
session when receive the NOTIFICATION message with subcode 7
(unsupported capability).

Date: Tue, 15 Jan 2002 08:02:12 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Babu Prabesh <[email-masked]>
Cc: [email-masked]
Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17)
Sender: [email-masked]

Nope--those woul dbe two seperate routes, with their own as
paths, so it won't matter if you send both of them. Presumably,
rtrb knows about the /16 locally, which is why it has the static,
so no looping should occur. 

I'm not certain how you would de-aggregate in this way....

:-)

Russ

On Mon, 14 Jan 2002, Babu Prabesh wrote:

> Section 9.1.4: overlapping routes states:
> 
> "If a BGP speaker chooses to aggregate, then it MUST add
> ATOMIC_AGGREGATE attribute
> to the route. A route that carries ATOMIC_AGGREGATE attribute can not be
> de-aggregated.
> That is, the NLRI of this route can not be made more specific.
> Forwarding along such a
> route does not guarantee that IP packets will actually traverse only ASs
> listed in the
> AS_PATH attribute of the route".
> 
> I was unsure of what de-aggregation means.
> Consider an example
> 
>                bgp                  bgp
>   RTRA---------RTRB----------RTRC
> 
>  RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB.
>  RTRB has a 5/16 route (via static).
> 
> Is the draft indicating that RTRB should only
> advertise 5/8 to RTRC and not advertise 5/16.
> 
> Thanks
>  Babu
> 
> ############################################################################
> ########################## This email communication may contain CONFIDENTIAL
> INFORMATION and is intended only for the use of the intended recipients
> identified above.  If you are not the intended recipient of this
> communication, you must not use, disclose, distribute, copy or print this
> email. If you have received this communication in error, please immediately
> notify the sender by reply email, delete the communication and destroy all
> copies.
> ############################################################################
> ##########################
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Tue, 15 Jan 2002 07:47:51 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Cease subcode 
Sender: [email-masked]

> > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > > Please remember that the goal of the draft is to document
> > > what is *currently* implemented and deployed, *not* what
> > > *could* be implemented and deployed.
> > 
> > Is the expoential backoff in the FSM in current implementations?
> 
> I guess we are going to find this out as part of the
> implementation report. And if it is not in (at least two)
> current implementations, we'll take it out of the text.

Cisco doesn't do this....

:-)

Russ

_____________________________
[email-masked] <>< Grace Alone

Date: Mon, 14 Jan 2002 23:21:28 -0500
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: IDR WG Last Call
Sender: [email-masked]

On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> It seems that the "SAFI 3" certainly makes the issue at hand much more
> complicated.

IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
be a real pain in the implementation. :-)

> As Yakov and Sue pointed out, it is a good idea to discourage
> having one prefix in multiple fields of an update message. How about the
> following text:
> 
>    An UPDATE message should not include the same address prefix in more than
>    one of the following fields: WITHDRAWN ROUTES field, Network Reachability
>    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The
>    processing of an UPDATE message in this form is un-defined.

I think that "undefined" is overkill.  I would suggest the following instead:

An UPDATE message should not include the same address prefix in
more than one of the following fields: WITHDRAWN ROUTES, Network
Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
An implementation that receives a packet in this form should process
the Update as if it had processed it in the following order:
WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
Reachability Information.

The wording could probably use some tightening.

The intended result is that reachability rules over unreachability.

> -- Enke

-- 
Jeff Haas 
NextHop Technologies

From: Babu Prabesh <[email-masked]>
Reply-To: Babu Prabesh <[email-masked]>
To: [email-masked]
Subject: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17)
Date: Mon, 14 Jan 2002 18:13:09 -0800
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C19D69.B9F43200
Content-Type: text/plain;
	charset="iso-8859-1"

Section 9.1.4: overlapping routes states:

"If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute
to the route. A route that carries ATOMIC_AGGREGATE attribute can not be
de-aggregated.
That is, the NLRI of this route can not be made more specific.
Forwarding along such a
route does not guarantee that IP packets will actually traverse only ASs
listed in the
AS_PATH attribute of the route".

I was unsure of what de-aggregation means.
Consider an example

               bgp                  bgp
  RTRA---------RTRB----------RTRC

 RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB.
 RTRB has a 5/16 route (via static).

Is the draft indicating that RTRB should only
advertise 5/8 to RTRC and not advertise 5/16.

Thanks
 Babu

############################################################################
########################## This email communication may contain CONFIDENTIAL
INFORMATION and is intended only for the use of the intended recipients
identified above.  If you are not the intended recipient of this
communication, you must not use, disclose, distribute, copy or print this
email. If you have received this communication in error, please immediately
notify the sender by reply email, delete the communication and destroy all
copies.
############################################################################
##########################

------_=_NextPart_001_01C19D69.B9F43200
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Section 9.1.4: overlapping routes states:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;If a BGP speaker chooses to aggregate, then it =
MUST add</FONT>
<BR><FONT SIZE=3D2>ATOMIC_AGGREGATE attribute</FONT>
<BR><FONT SIZE=3D2>to the route. A route that carries ATOMIC_AGGREGATE =
attribute can not be</FONT>
<BR><FONT SIZE=3D2>de-aggregated.</FONT>
<BR><FONT SIZE=3D2>That is, the NLRI of this route can not be made more =
specific.</FONT>
<BR><FONT SIZE=3D2>Forwarding along such a</FONT>
<BR><FONT SIZE=3D2>route does not guarantee that IP packets will =
actually traverse only ASs</FONT>
<BR><FONT SIZE=3D2>listed in the</FONT>
<BR><FONT SIZE=3D2>AS_PATH attribute of the route&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>I was unsure of what de-aggregation means.</FONT>
<BR><FONT SIZE=3D2>Consider an example</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; =
bgp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bgp</FONT>
<BR><FONT SIZE=3D2>&nbsp; RTRA---------RTRB----------RTRC</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;RTRA sends 5/8 with ATOMIC_AGGREGATE set to =
RTRB.</FONT>
<BR><FONT SIZE=3D2>&nbsp;RTRB has a 5/16 route (via static).</FONT>
</P>

<P><FONT SIZE=3D2>Is the draft indicating that RTRB should only</FONT>
<BR><FONT SIZE=3D2>advertise 5/8 to RTRC and not advertise 5/16.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>&nbsp;Babu</FONT>
</P>

<P><FONT =
SIZE=3D2>###############################################################=
####################################### This email communication may =
contain CONFIDENTIAL INFORMATION and is intended only for the use of =
the intended recipients identified above.&nbsp; If you are not the =
intended recipient of this communication, you must not use, disclose, =
distribute, copy or print this email. If you have received this =
communication in error, please immediately notify the sender by reply =
email, delete the communication and destroy all copies. =
########################################################################=
##############################</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C19D69.B9F43200--

Date: Mon, 14 Jan 2002 20:13:20 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: Susan Hares <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Enke:

The draft (and RFC) states:

This document defines the following values for the Subsequent Address 
Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI 
attributes: 1 - Network Layer Reachability Information used for unicast 
forwarding
2 - Network Layer Reachability Information used for multicast forwarding
3 - Network Layer Reachability Information used for both unicast
     and multicast forwarding

Is the specification unclear?  If so, please let us know so
the final call can clarify the specifications.

Now as to why/how/when.. I've given my best effort
to answer your query.

          Why, because the operation person configures
                 unicast and multicast topologies are the same.

           How, because the mp-bgp software causes it to go that direction.
                the pim-sm and other multicast protocol utilize the
                 MP bgp routes for SPF.

           When, once upon a router the bgp converges and then
                 the ribs

SAFI 3 ;-)...

Sue Hares

At 02:12 PM 1/14/2002 -0800, Enke Chen wrote:
>Sue:
>In order for me to make sense out of your example, I need to be educated
>on how/why/when one would use "SAFI 3", especially in the context of
>Multi-protocol BGP.
>
>By the "same <AFI, AFI>, I really meant the same <AFI, SAFI>, i.e.,
>identical values.
>
>  -- Enke
>
> > Date: Fri, 11 Jan 2002 18:42:10 -0500
> > To: Enke Chen <[email-masked]>
> > From: Susan Hares <[email-masked]>
> > Subject: Re: IDR WG Last Call
> > Cc: Susan Hares <[email-masked]>, Yakov Rekhter <[email-masked]>,
> >       [email-masked], [email-masked]
> > In-Reply-To: <[email-masked]>
> > References: <Message from Susan Hares <[email-masked]>
> >  <[email-masked]>
> >
> > Enke:
> >
> > It appears I was just too fuzzy in my last email and
> > I assumed something about your last message (oops!!)...
> > We may even be in violent agreement.
> >
> >
> > Let's drop to specifics...
> >
> > Problem 1 in base specification:
> >
> >          1) no ordering of Withdraws and NRLI
> >
> > draft-17 fix:
> >
> >          1) Last ordering (NLRI works) -- good idea
> >
> > Problem 2
> >
> > Order in the packet (by number)
> >          Withdrawl
> >          MP announce
> >          MP release
> >          announce
> >
> > Your solution - last announcement works for an (AFI,SAFI) pair
> >
> > Desired packet information:
> >
> > Previous announcement left us with 128.2/16 with SAFI 2 nexthop 
> 192.168.10.2
> >
> >
> >          ASPATH + community green + next hop 192.168.10.15
> >
> >          Withdraw - nothing
> >          MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2
> >          MPUNREACH - 128.2/16 with SAFI 2
> >          REACH - 128.2 (SAFI = 1 by default)
> >
> > This scenario passes your test.   All things are processed.
> > However, we have a order problem:
> >
> >          1)  If you process the sections as:
> >                  Withdraw,
> >                  MPReach,
> >                  MPUNREACH ,
> >                  Reach
> >
> >                  You get 128.2 (SAFI = 1) with next hop 192.168.10.15.
> >
> >          2) If you process:
> >                  Withdrawa,
> >                  MPUNREACH,
> >                  MPREACH,
> >                  NLRI
> >
> >                  You get 128.2 SAFI 1 next hop 192.168.10.15,
> >                          128.2 SAFI 2 next hop 192.168.10.2
> >
> >
> >
> > Can we set the order with additions of the additions within your
> > text:
> >
> >          MPBGP unreachables before MPBGP reachables.
> >
> > If we have your text plus, the MPUNREACH before MPREACH - we have specific
> > ordering.    If you like these 2 additions, we are done
> >
> >
> > If you implied that SAFI 3 = SAFI 1 + 2, your text does not
> > state it.   The scenario I listed would be illegal.
> >
> > Two summaries:
> >
> > 1) Do you want Your text + ordering of MPBGP unreachables before MP 
> reachables?
> >          If so, let's get yakov to swipe text from the bgp-4 draft 17 
> for this
> >          note.
> >
> >
> > 2) Could you please confirm that you mean SAFI 3, SAFI 2, and SAFI 1
> >      can all be listed in the same PDU.
> >
> >
> > you've hit the mark with the need to settle this for the MPBGP protocols.
> >
> > Sue Hares
> >
> >
> >
> >
> >
> > > >
> > > >
> > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
> > > > >Hi, Yakov:
> > > > >How about we add the following clarification (similar to the one in
> > > the base
> > > > >BGP spec):
> > > > >
> > > > >    An UPDATE message should not include the same address prefix (of
> > > the same
> > > > >    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN
> > > ROUTES
> > > > >    field, Network Reachability Information fields, MP_REACH_NLRI
> > > field, and
> > > > >    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to 
> process
> > > > > UPDATE
> > > > >    messages in this form. A BGP speaker should treat an UPDATE
> > > message of
> > > > > this
> > > > >    form as if that the address prefix were included only in the last
> > > field of
> > > > >    the message.
> > > > >
> > > > >Thanks. -- Enke
> > > > >
> > > > > > Message-Id: <[email-masked]>
> > > > > > To: [email-masked]
> > > > > > Subject: IDR WG Last Call
> > > > > > MIME-Version: 1.0
> > > > > > Content-Type: text/plain; charset="us-ascii"
> > > > > > Content-ID: <[email-masked]>
> > > > > > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > > > > > From: Yakov Rekhter <[email-masked]>
> > > > > > Sender: [email-masked]
> > > > > > Precedence: bulk
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > This is to begin the WG Last Call on advancing Multiprotocol
> > > > > > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > > > > > Jan 23, 2002.
> > > > > >
> > > > > > Yakov.
> > > > > > ------- Forwarded Message
> > > > > >
> > > > > > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > > > > > From:    [email-masked]
> > > > > > To:      IETF-Announce: ;
> > > > > > cc:      [email-masked]
> > > > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> > > > > >
> > > > > > - --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           : Multiprotocol Extensions for BGP-4
> > > > > >       Author(s)       : T. Bates et al.
> > > > > >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> > > > > >       Pages           : 10
> > > > > >       Date            : 08-Jan-02
> > > > > >
> > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > > > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > > > > > enable it to carry routing information for multiple Network Layer
> > > > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > > > > > compatible - a router that supports the extensions can interoperate
> > > > > > with a router that doesn't support the extensions.
> > > > > >
> > > > > > A URL for this Internet-Draft is:
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> > > > > >
> > > > > > To remove yourself from the IETF Announcement list, send a 
> message to
> > > > > > ietf-announce-request with the word unsubscribe in the body of the
> > > message.
> > > > > >
> > > > > > Internet-Drafts are also 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-rfc2858bis-00.txt".
> > > > > >
> > > > > > A list of Internet-Drafts directories can be found in
> > > > > > http://www.ietf.org/shadow.html
> > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > > >
> > > >
> > > >
> >
> >

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Mon, 14 Jan 2002 16:04:24 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Jeff,
Thanks for the pointer - I totally missed that part of the spec..

It seems that the "SAFI 3" certainly makes the issue at hand much more
complicated. As Yakov and Sue pointed out, it is a good idea to discourage
having one prefix in multiple fields of an update message. How about the
following text:

   An UPDATE message should not include the same address prefix in more than
   one of the following fields: WITHDRAWN ROUTES field, Network Reachability
   Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The
   processing of an UPDATE message in this form is un-defined.

-- Enke

> Date: Mon, 14 Jan 2002 18:12:57 -0500
> From: Jeffrey Haas <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: IDR WG Last Call
> Message-ID: <[email-masked]>
> References: <[email-masked]> <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> In-Reply-To: <[email-masked]>; from [email-masked] on Mon, Jan 14, 2002 at 02:12:12PM -0800
> X-NextHop-MailScanner: Found to be clean
> 
> On Mon, Jan 14, 2002 at 02:12:12PM -0800, Enke Chen wrote:
> > In order for me to make sense out of your example, I need to be educated
> > on how/why/when one would use "SAFI 3", especially in the context of
> > Multi-protocol BGP.
> 
> 3 - Network Layer Reachability Information used for both unicast
>     and multicast forwarding
> 
> In other words, where you would otherwise send a SAFI 1 and then a SAFI 2
> announcement for the same prefix and same path attributes, you could
> otherwise send a SAFI 3 advertisement.
> 
> >  -- Enke
> 
> -- 
> Jeff Haas 
> NextHop Technologies

Date: Mon, 14 Jan 2002 18:12:57 -0500
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: IDR WG Last Call
Sender: [email-masked]

On Mon, Jan 14, 2002 at 02:12:12PM -0800, Enke Chen wrote:
> In order for me to make sense out of your example, I need to be educated
> on how/why/when one would use "SAFI 3", especially in the context of
> Multi-protocol BGP.

3 - Network Layer Reachability Information used for both unicast
    and multicast forwarding

In other words, where you would otherwise send a SAFI 1 and then a SAFI 2
announcement for the same prefix and same path attributes, you could
otherwise send a SAFI 3 advertisement.

>  -- Enke

-- 
Jeff Haas 
NextHop Technologies

To: Susan Hares <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Mon, 14 Jan 2002 14:12:12 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue:
In order for me to make sense out of your example, I need to be educated
on how/why/when one would use "SAFI 3", especially in the context of
Multi-protocol BGP.

By the "same <AFI, AFI>, I really meant the same <AFI, SAFI>, i.e.,
identical values.

 -- Enke

> Date: Fri, 11 Jan 2002 18:42:10 -0500
> To: Enke Chen <[email-masked]>
> From: Susan Hares <[email-masked]>
> Subject: Re: IDR WG Last Call 
> Cc: Susan Hares <[email-masked]>, Yakov Rekhter <[email-masked]>,
> 	[email-masked], [email-masked]
> In-Reply-To: <[email-masked]>
> References: <Message from Susan Hares <[email-masked]>
>  <[email-masked]>
> 
> Enke:
> 
> It appears I was just too fuzzy in my last email and
> I assumed something about your last message (oops!!)...
> We may even be in violent agreement.
> 
> 
> Let's drop to specifics...
> 
> Problem 1 in base specification:
> 
>          1) no ordering of Withdraws and NRLI
> 
> draft-17 fix:
> 
>          1) Last ordering (NLRI works) -- good idea
> 
> Problem 2
> 
> Order in the packet (by number)
>          Withdrawl
>          MP announce
>          MP release
>          announce
> 
> Your solution - last announcement works for an (AFI,SAFI) pair
> 
> Desired packet information:
> 
> Previous announcement left us with 128.2/16 with SAFI 2 nexthop 192.168.10.2
> 
> 
>          ASPATH + community green + next hop 192.168.10.15
> 
>          Withdraw - nothing
>          MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2
>          MPUNREACH - 128.2/16 with SAFI 2
>          REACH - 128.2 (SAFI = 1 by default)
> 
> This scenario passes your test.   All things are processed.
> However, we have a order problem:
> 
>          1)  If you process the sections as:
>                  Withdraw,
>                  MPReach,
>                  MPUNREACH ,
>                  Reach
> 
>                  You get 128.2 (SAFI = 1) with next hop 192.168.10.15.
> 
>          2) If you process:
>                  Withdrawa,
>                  MPUNREACH,
>                  MPREACH,
>                  NLRI
> 
>                  You get 128.2 SAFI 1 next hop 192.168.10.15,
>                          128.2 SAFI 2 next hop 192.168.10.2
> 
> 
> 
> Can we set the order with additions of the additions within your
> text:
> 
>          MPBGP unreachables before MPBGP reachables.
> 
> If we have your text plus, the MPUNREACH before MPREACH - we have specific
> ordering.    If you like these 2 additions, we are done
> 
> 
> If you implied that SAFI 3 = SAFI 1 + 2, your text does not
> state it.   The scenario I listed would be illegal.
> 
> Two summaries:
> 
> 1) Do you want Your text + ordering of MPBGP unreachables before MP reachables?
>          If so, let's get yakov to swipe text from the bgp-4 draft 17 for this
>          note.
> 
> 
> 2) Could you please confirm that you mean SAFI 3, SAFI 2, and SAFI 1
>      can all be listed in the same PDU.
> 
> 
> you've hit the mark with the need to settle this for the MPBGP protocols.
> 
> Sue Hares
> 
> 
> 
> 
> 
> > >
> > >
> > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
> > > >Hi, Yakov:
> > > >How about we add the following clarification (similar to the one in 
> > the base
> > > >BGP spec):
> > > >
> > > >    An UPDATE message should not include the same address prefix (of 
> > the same
> > > >    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN 
> > ROUTES
> > > >    field, Network Reachability Information fields, MP_REACH_NLRI 
> > field, and
> > > >    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process
> > > > UPDATE
> > > >    messages in this form. A BGP speaker should treat an UPDATE 
> > message of
> > > > this
> > > >    form as if that the address prefix were included only in the last 
> > field of
> > > >    the message.
> > > >
> > > >Thanks. -- Enke
> > > >
> > > > > Message-Id: <[email-masked]>
> > > > > To: [email-masked]
> > > > > Subject: IDR WG Last Call
> > > > > MIME-Version: 1.0
> > > > > Content-Type: text/plain; charset="us-ascii"
> > > > > Content-ID: <[email-masked]>
> > > > > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > > > > From: Yakov Rekhter <[email-masked]>
> > > > > Sender: [email-masked]
> > > > > Precedence: bulk
> > > > >
> > > > > Folks,
> > > > >
> > > > > This is to begin the WG Last Call on advancing Multiprotocol
> > > > > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > > > > Jan 23, 2002.
> > > > >
> > > > > Yakov.
> > > > > ------- Forwarded Message
> > > > >
> > > > > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > > > > From:    [email-masked]
> > > > > To:      IETF-Announce: ;
> > > > > cc:      [email-masked]
> > > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> > > > >
> > > > > - --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           : Multiprotocol Extensions for BGP-4
> > > > >       Author(s)       : T. Bates et al.
> > > > >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> > > > >       Pages           : 10
> > > > >       Date            : 08-Jan-02
> > > > >
> > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > > > > enable it to carry routing information for multiple Network Layer
> > > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > > > > compatible - a router that supports the extensions can interoperate
> > > > > with a router that doesn't support the extensions.
> > > > >
> > > > > A URL for this Internet-Draft is:
> > > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> > > > >
> > > > > To remove yourself from the IETF Announcement list, send a message to
> > > > > ietf-announce-request with the word unsubscribe in the body of the 
> > message.
> > > > >
> > > > > Internet-Drafts are also 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-rfc2858bis-00.txt".
> > > > >
> > > > > A list of Internet-Drafts directories can be found in
> > > > > http://www.ietf.org/shadow.html
> > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >
> > >
> > >
> 
> 

Date: Mon, 14 Jan 2002 16:31:26 -0500
To: Yakov Rekhter <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: [email-masked]
Sender: [email-masked]

Yakov:

Inter-operability is the basis for IETF specifications.
I suspect that indicating in the specification what
is a stupid thing to stop is a good idea.
Then, someone doesn't find a stupid thing in a network.

Sue

At 09:26 AM 1/14/2002 -0800, you wrote:
>Sue,
>
> > Enke:
> >
> > It appears I was just too fuzzy in my last email and
> > I assumed something about your last message (oops!!)...
> > We may even be in violent agreement.
> >
> >
> > Let's drop to specifics...
> >
> > Problem 1 in base specification:
> >
> >          1) no ordering of Withdraws and NRLI
> >
> > draft-17 fix:
> >
> >          1) Last ordering (NLRI works) -- good idea
> >
> > Problem 2
> >
> > Order in the packet (by number)
> >          Withdrawl
> >          MP announce
> >          MP release
> >          announce
> >
> > Your solution - last announcement works for an (AFI,SAFI) pair
> >
> > Desired packet information:
> >
> > Previous announcement left us with 128.2/16 with SAFI 2 nexthop 
> 192.168.10.2
> >
> >
> >          ASPATH + community green + next hop 192.168.10.15
> >
> >          Withdraw - nothing
> >          MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2
> >          MPUNREACH - 128.2/16 with SAFI 2
> >          REACH - 128.2 (SAFI = 1 by default)
> >
> > This scenario passes your test.   All things are processed.
> > However, we have a order problem:
> >
> >          1)  If you process the sections as:
> >                  Withdraw,
> >                  MPReach,
> >                  MPUNREACH ,
> >                  Reach
> >
> >                  You get 128.2 (SAFI = 1) with next hop 192.168.10.15.
> >
> >          2) If you process:
> >                  Withdrawa,
> >                  MPUNREACH,
> >                  MPREACH,
> >                  NLRI
> >
> >                  You get 128.2 SAFI 1 next hop 192.168.10.15,
> >                          128.2 SAFI 2 next hop 192.168.10.2
>
>Please note that the whole idea of carrying the same NLRI in
>Withdrawn, MPUNREACH, MPREACH, and NLRI of the same UPDATE message
>is kind of stupid. Enke alluded this in his proposed text:
>
>    An UPDATE message should not include the same address prefix (of the same
>    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES
>    field, Network Reachability Information fields, MP_REACH_NLRI field, and
>    MP_UNREACH_NLRI field.
>
>Thus I don't think the spec should be that much concerned with the
>outcome of folks doing stupid things.
>
>Yakov.

To: Alex Zinin <[email-masked]>
Cc: "Tom Petch" <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 Section 9 
Date: Mon, 14 Jan 2002 13:11:40 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> Tom,
> 
> > 9.1.2 Route selection now allows for the best route in
> > Loc-RIB not to be placed in the Routing table; how does this
> > impact on the principle (2 Introduction) that a BGP Speaker
> > should only advertise routes it itself uses?  Is it enough
> > for the route to be in Loc-RIB and not in the Routing Table?
> 
> The principle implies that the route is both in Loc-RIB and
> in the routing table, i.e., it needs to be both selected as
> the best and used by the router.
> However, we can only specify so much about the routing table,
> as it is (strictly speaking) outside of the scope of the BGP
> protocol and administrator do have the "filter" rope in
> their hands. Section 3.2 also talks about this.
> 
> > I believe the paragraph on immediate next hop should
> > cross-reference the one in 5.1.3; and the latter allows
> > route lookup to resolve to a subnet and not an immediate
> > next hop address, a possibility 9.1.2 appears not to cater
> > for.
> 
> Fine with me.
> 
> > Perhaps the information on immediate next hop in 5.1.3 and 9
> > should be combined in one place; 5.1.3 would be my
> > preference.
> 
> Fine with me.
> 
> > 9.1.2.1 Intermediate network address throws me each time as
> > I start thinking of networks; I assume that this is the
> > immediate next hop of Rte1; if so, would not that be
> > clearer?
> 
> The address in Rte1 can be either a direct next-hop or
> a third party next-hop (not really a next hop from the RT
> perspective). "Intermediate" should account for both cases.
> 
> > Resolvability talks of routing table entries for IGP and
> > directly connected networks; for consistency with 3.2, I
> > would like to see static in there as well.
> 
> I actually thought about it when writing this text, but
> it fell out of my head. How about this:
> 
>    BGP routes do not refer to interfaces, but can be resolved through
>    the routes in the Routing Table that can be of both types. IGP routes
>    and routes to directly connected networks are expected to specify the
>    outbound interface. Static routes can specify the outbound
>    interface, or the intermediate address, or both.

done.

> 
> > 9.1.2.2e  Again 5.1.3 impacts on this;should this be
> > 'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!)
> > and what happens with a recursive lookup?  Which of the
> > metrics in the various Routing Table entries gets used?
> > Perhaps 'The interior cost of a route is the metric in the
> > routing table for the immediate next hop (see 5.1.3)'
> 
> In fact, "next hop" should read as NEXT_HOP. The metric
> is the IGP cost found in the route resolving the NEXT_HOP.

done.

Yakov.

To: Alex Zinin <[email-masked]>
Cc: "Tom Petch" <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 5.1.3 NEXT_HOP attribute determination 
Date: Mon, 14 Jan 2002 13:12:38 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> Tom,
> 
> > I think that there is a problem with logic and terminology
> > in the determination of NEXT_HOP.  There are four cases
> > listed,
> > - a form of "third party" NEXT_HOP attribute
> > - a second form of "third party" NEXT_HOP attribute
> > - "first party" NEXT_HOP attribute
> > - by default
> > and respectively the BGP speaker
> > - can use
> > - can use
> > - may use
> > - should use
> > which seems inconsistent; I would prefer SHOULD.
> 
> Since use of third party next hops is an optimization
> by nature and does not *have* to be implemented,
> and given that "should" is used for the default,
> I think "may/can" is ok. If we change the optional
> cases to "should" to increase the level on insistence,
> we should do the same to the default case and make
> it a must.
> If you ask me, I think we're all right now.
> 
> 
> > But logically, the first party (common subnet) overlaps the
> > two third parties (common subnet with IBGP or locally
> > originated and common subnet with EBGP) which obviates
> > SHOULD.
> 
> We know how to deal with overlapping cases already---
> the more specific one wins. Same here---third party
> cases are more specific in their description.
> I guess it might be clearer if we changed "-if -if"
> to "-if -otherwise if".

done.

Yakov.

Date: Mon, 14 Jan 2002 15:19:58 -0500
To: Jeffrey Haas <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-17 Cease subcode
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

Jeff:

The backoff was in the original FSM.  Your question
still stands, is it in the implementations.

Sue

At 12:37 PM 1/14/2002 -0500, Jeffrey Haas wrote:
>On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > Please remember that the goal of the draft is to document
> > what is *currently* implemented and deployed, *not* what
> > *could* be implemented and deployed.
>
>Is the expoential backoff in the FSM in current implementations?
>
>Note that this change (IdleHold) to the FSM is going to result in
>an alteration to the MIB.  This is one of the reasons I've held
>off completion of the RFC 1657 update - to accomodate for this fact
>to converge.
>
> > Therefore, the draft
> > should not list these new subcodes.
> >
> > Yakov.
>
>--
>Jeff Haas
>NextHop Technologies

To: "Tom Petch" <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Section 9 
Date: Mon, 14 Jan 2002 12:16:50 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

> 
> 9.1.2 Route selection now allows for the best route in
> Loc-RIB not to be placed in the Routing table; how does this
> impact on the principle (2 Introduction) that a BGP Speaker
> should only advertise routes it itself uses?  Is it enough
> for the route to be in Loc-RIB and not in the Routing Table?
> 
> I believe the paragraph on immediate next hop should
> cross-reference the one in 5.1.3; and the latter allows
> route lookup to resolve to a subnet and not an immediate
> next hop address, a possibility 9.1.2 appears not to cater
> for.
> 
> Perhaps the information on immediate next hop in 5.1.3 and 9
> should be combined in one place; 5.1.3 would be my
> preference.

Please propose the specific changes.

Yakov.

To: Alex Zinin <[email-masked]>
Cc: "Tom Petch" <[email-masked]>, [email-masked]
Subject: Re: bgp4-17 LOCAL_PREF 
Date: Mon, 14 Jan 2002 12:08:58 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> 
>  A "see section 5.1.5" instead of "disallowed" in
>  the table before 5.1 should do the trick.

fixed.

Yakov.

>  
> -- 
> Alex Zinin
> 
> Saturday, January 11, 2003, 4:56:35 AM, Tom Petch wrote:
> 
> > Section 5 states that LOCAL_PREF is disallowed for EBGP;
> > section 5.1.5 allows it for external peers as part of BGP
> > Confederations.
> 
> > I think that Section 5 needs qualifying
> 
> > Tom Petch, Network Consultant
> > [email-masked]
> 
> 

To: Bill Fenner <[email-masked]>
Cc: [email-masked]
Subject: Re: 2842 to Draft Standard 
Date: Mon, 14 Jan 2002 10:48:50 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Bill

> IDR WG,
> 
>   In order to progress to Draft Standard, an implementation report
> is required (see section 4.1.2 of RFC 2026).  In particular:
> 
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.
> 
> RFC 2842 has several optional portions (e.g. sending Notifications
> and whether to include the capability in question in the Notification),
> which the implementation report that you included in the original
> request did not mention.
>
>   I'd like to see a more complete implementation report.  For
> example, if vendors don't mind being named:
> http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt
> or if they don't want to be named:
> http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION

See below.
  
>   Also, the process would go much more smoothly if there was an
> Internet-Draft containing the revision, even though it's so small.
> The RFC-Editor can supply the nroff of RFC 2842 if the authors 
> don't still have their source.

Done (see draft-ietf-idr-rfc2842bis-00.txt)

Yakov.
----------------------------------------------------------------------
The following is the list of some of the implementations of rfc2842:

Ericsson:
Interoperates with: Cisco, Juniper

Juniper Networks
Interoperates with: Cisco

Laurel Networks:
Interoperates with: Cisco, Juniper

NetPlane Systems Inc.
Interoperates with: Cisco, Juniper

Redback
Interoperates with: Cisco, Juniper

Riverstone:
Interoperates with: Cisco, Juniper, Zebra, Foundry

Unisphere Networks:
Interoperates with: Cisco, Juniper 

If a BGP speaker that supports a certain capability determines that
its peer doesn't support this capability, 2 implementations never
send a NOTIFICATION message to the peer, and 4 implementations
sometimes send a NOTIFICATION message to the peer.

Out of the 4 implementations that send the NOTIFICATION message
(when the peer doesn't support a particular capability), 2
implementations never include the Capability in question in the
message, and 2 implementations always include the Capability in
question in the message.

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Cease subcode 
Date: Mon, 14 Jan 2002 09:50:03 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> > Please remember that the goal of the draft is to document
> > what is *currently* implemented and deployed, *not* what
> > *could* be implemented and deployed.
> 
> Is the expoential backoff in the FSM in current implementations?

I guess we are going to find this out as part of the implementation
report. And if it is not in (at least two) current implementations,
we'll take it out of the text.

> Note that this change (IdleHold) to the FSM is going to result in
> an alteration to the MIB.  This is one of the reasons I've held
> off completion of the RFC 1657 update - to accomodate for this fact
> to converge.

Understood.

Yakov.

Date: Mon, 14 Jan 2002 12:37:00 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Cease subcode
Sender: [email-masked]

On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote:
> Please remember that the goal of the draft is to document
> what is *currently* implemented and deployed, *not* what
> *could* be implemented and deployed.

Is the expoential backoff in the FSM in current implementations?

Note that this change (IdleHold) to the FSM is going to result in
an alteration to the MIB.  This is one of the reasons I've held
off completion of the RFC 1657 update - to accomodate for this fact
to converge.

> Therefore, the draft
> should not list these new subcodes.
> 
> Yakov.

-- 
Jeff Haas 
NextHop Technologies

To: "Tom Petch" <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Cease subcode 
Date: Mon, 14 Jan 2002 09:28:53 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Tom,

> Ouch; I had forgotten reading that I-D.
> 
> But I am still uncomfortable with last call on this
> capabillity in bgp4-17 with the prospect of a subcode
> appearing, or possibly not, at some point in the future in a
> separate RFC.

Please remember that the goal of the draft is to document
what is *currently* implemented and deployed, *not* what
*could* be implemented and deployed. Therefore, the draft
should not list these new subcodes.

Yakov.

Date: Fri, 11 Jan 2002 18:42:10 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: Susan Hares <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Enke:

It appears I was just too fuzzy in my last email and
I assumed something about your last message (oops!!)...
We may even be in violent agreement.

Let's drop to specifics...

Problem 1 in base specification:

         1) no ordering of Withdraws and NRLI

draft-17 fix:

         1) Last ordering (NLRI works) -- good idea

Problem 2

Order in the packet (by number)
         Withdrawl
         MP announce
         MP release
         announce

Your solution - last announcement works for an (AFI,SAFI) pair

Desired packet information:

Previous announcement left us with 128.2/16 with SAFI 2 nexthop 192.168.10.2

         ASPATH + community green + next hop 192.168.10.15

         Withdraw - nothing
         MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2
         MPUNREACH - 128.2/16 with SAFI 2
         REACH - 128.2 (SAFI = 1 by default)

This scenario passes your test.   All things are processed.
However, we have a order problem:

         1)  If you process the sections as:
                 Withdraw,
                 MPReach,
                 MPUNREACH ,
                 Reach

                 You get 128.2 (SAFI = 1) with next hop 192.168.10.15.

         2) If you process:
                 Withdrawa,
                 MPUNREACH,
                 MPREACH,
                 NLRI

                 You get 128.2 SAFI 1 next hop 192.168.10.15,
                         128.2 SAFI 2 next hop 192.168.10.2

Can we set the order with additions of the additions within your
text:

         MPBGP unreachables before MPBGP reachables.

If we have your text plus, the MPUNREACH before MPREACH - we have specific
ordering.    If you like these 2 additions, we are done

If you implied that SAFI 3 = SAFI 1 + 2, your text does not
state it.   The scenario I listed would be illegal.

Two summaries:

1) Do you want Your text + ordering of MPBGP unreachables before MP reachables?
         If so, let's get yakov to swipe text from the bgp-4 draft 17 for this
         note.

2) Could you please confirm that you mean SAFI 3, SAFI 2, and SAFI 1
     can all be listed in the same PDU.

you've hit the mark with the need to settle this for the MPBGP protocols.

Sue Hares

> >
> >
> > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
> > >Hi, Yakov:
> > >How about we add the following clarification (similar to the one in 
> the base
> > >BGP spec):
> > >
> > >    An UPDATE message should not include the same address prefix (of 
> the same
> > >    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN 
> ROUTES
> > >    field, Network Reachability Information fields, MP_REACH_NLRI 
> field, and
> > >    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process
> > > UPDATE
> > >    messages in this form. A BGP speaker should treat an UPDATE 
> message of
> > > this
> > >    form as if that the address prefix were included only in the last 
> field of
> > >    the message.
> > >
> > >Thanks. -- Enke
> > >
> > > > Message-Id: <[email-masked]>
> > > > To: [email-masked]
> > > > Subject: IDR WG Last Call
> > > > MIME-Version: 1.0
> > > > Content-Type: text/plain; charset="us-ascii"
> > > > Content-ID: <[email-masked]>
> > > > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > > > From: Yakov Rekhter <[email-masked]>
> > > > Sender: [email-masked]
> > > > Precedence: bulk
> > > >
> > > > Folks,
> > > >
> > > > This is to begin the WG Last Call on advancing Multiprotocol
> > > > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > > > Jan 23, 2002.
> > > >
> > > > Yakov.
> > > > ------- Forwarded Message
> > > >
> > > > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > > > From:    [email-masked]
> > > > To:      IETF-Announce: ;
> > > > cc:      [email-masked]
> > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> > > >
> > > > - --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           : Multiprotocol Extensions for BGP-4
> > > >       Author(s)       : T. Bates et al.
> > > >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> > > >       Pages           : 10
> > > >       Date            : 08-Jan-02
> > > >
> > > > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > > > enable it to carry routing information for multiple Network Layer
> > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > > > compatible - a router that supports the extensions can interoperate
> > > > with a router that doesn't support the extensions.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> > > >
> > > > To remove yourself from the IETF Announcement list, send a message to
> > > > ietf-announce-request with the word unsubscribe in the body of the 
> message.
> > > >
> > > > Internet-Drafts are also 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-rfc2858bis-00.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> >
> >

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: bgp4-17 Cease subcode 
Date: Sat, 11 Jan 2003 21:41:20 -0000
Sender: [email-masked]

Ouch; I had forgotten reading that I-D.

But I am still uncomfortable with last call on this
capabillity in bgp4-17 with the prospect of a subcode
appearing, or possibly not, at some point in the future in a
separate RFC.

Tom Petch, Network Consultant
[email-masked]
+(44) 192 575 3018

To: "Tom Petch" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: bgp4-17 Cease subcode 
Date: Fri, 11 Jan 2002 12:48:08 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Tom,

> I believe there should be a Cease sub-code to differentiate
> the case where the upper bound on the number of acceptable
> address prefixes is exceeded.  If not, then the recipient of
> the Cease could assume this is due to some other transient,
> re-establish the connection and repeat the process ad
> infinitum.

See draft-ietf-idr-cease-subcode-00.txt for more details.

Yakov.

Date: Fri, 11 Jan 2002 14:10:48 -0500
To: "Tom Petch" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: bgp4-16 ATOMIC_AGGREGATE
Cc: <[email-masked]>
Sender: [email-masked]

Tom:

Tom:

Do you mean, "Excludes at least some of the AS numbers"?

Sue Hares

At 08:33 PM 1/9/2003 +0000, Tom Petch wrote:

>In 5.1.6, ATOMIC_AGGREGATE MUST be included if the AS_PATH
>of the aggregated route excludes at least some of the AS
>numbers present in the AS_PATHs of the routes that are
>aggregated.
>
>In 9.1.4, if a BGP speaker chooses to aggregate, then it
>MUST add ATOMIC_AGGREGATE attribute to the route ie
>ATOMIC_AGGREGATE will be present in every aggregate
>regardless of whether or not an AS number is no longer in
>the AS-PATH.
>
>Is this really what is meant?
>
>
>Tom Petch, Network Consultant
>[email-masked]
>+(44) 192 575 3018

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: Fw: bgp4-17 Section 9
Date: Sat, 11 Jan 2003 19:02:22 -0000
Sender: [email-masked]

----Original Message-----
From: Alex Zinin <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 11 January 2002 17:17
Subject: Re: bgp4-17 Section 9

[edited]
>>
>> Resolvability talks of routing table entries for IGP and
>> directly connected networks; for consistency with 3.2, I
>> would like to see static in there as well.
>
>I actually thought about it when writing this text, but
>it fell out of my head. How about this:
>
>   BGP routes do not refer to interfaces, but can be
resolved through
>   the routes in the Routing Table that can be of both
types. IGP routes
>   and routes to directly connected networks are expected
to specify the
>   outbound interface. Static routes can specify the
outbound
>   interface, or the intermediate address, or both.

Yes I like the additional sentence.

One final tweak could be to amend

> the routes in the Routing Table that can be of both types
to
the routes in the Routing Table which can be of either type

>
>> 9.1.2.2e  Again 5.1.3 impacts on this;should this be
>> 'immediate next hop' as opposed to 'next hop' (or
NEXT_HOP!)
>> and what happens with a recursive lookup?  Which of the
>> metrics in the various Routing Table entries gets used?
>> Perhaps 'The interior cost of a route is the metric in
the
>> routing table for the immediate next hop (see 5.1.3)'
>
>In fact, "next hop" should read as NEXT_HOP. The metric
>is the IGP cost found in the route resolving the NEXT_HOP.
>
>Alex.

I think recursive lookup - great concept - does make it hard
to specify these things in English without getting clumsy.
Perhaps we need terminology to differentiate the first from
the subsequent from the last entry to be used from the
routing table.  I think the last is intended here or is it
intended to be ambiguous?

Tom Petch, Network Consultant
[email-masked]

Date: Fri, 11 Jan 2002 13:57:18 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: Susan Hares <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 10:04 AM 1/11/2002 -0800, Enke Chen wrote:
>Sue:
>As the processing of a UPDATE message (with the same prefix in multiple
>fields) is un-specified in the MP spec., there is really nothing to "change"
>from.
>
>-- Enke
>
> > Message-Id: <[email-masked]>
> > Date: Fri, 11 Jan 2002 11:20:02 -0500
> > To: Enke Chen <[email-masked]>
> > From: Susan Hares <[email-masked]>
> > Subject: Re: IDR WG Last Call
> > Cc: Yakov Rekhter <[email-masked]>, [email-masked],
> >       [email-masked]
> > In-Reply-To: <[email-masked]>
> >
> >
> > Enke:
> >
> > I don't think this is a clarification, I think this is a change in the
> > specification.   The original idea was to allow:
> >
> > Withdraw and announce to withdraw the SAFI: uni,multi in the 
> MP_UNREACH_NLRI
> > filed and to announce it in the NLRI field.
> >
> > Can you site a technical reason for this change or common practice
> > regarding this text?
> >
> > Sue Hares
> >
> >
> >
> > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
> > >Hi, Yakov:
> > >How about we add the following clarification (similar to the one in 
> the base
> > >BGP spec):
> > >
> > >    An UPDATE message should not include the same address prefix (of 
> the same
> > >    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN 
> ROUTES
> > >    field, Network Reachability Information fields, MP_REACH_NLRI 
> field, and
> > >    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process
> > > UPDATE
> > >    messages in this form. A BGP speaker should treat an UPDATE 
> message of
> > > this
> > >    form as if that the address prefix were included only in the last 
> field of
> > >    the message.
> > >
> > >Thanks. -- Enke
> > >
> > > > Message-Id: <[email-masked]>
> > > > To: [email-masked]
> > > > Subject: IDR WG Last Call
> > > > MIME-Version: 1.0
> > > > Content-Type: text/plain; charset="us-ascii"
> > > > Content-ID: <[email-masked]>
> > > > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > > > From: Yakov Rekhter <[email-masked]>
> > > > Sender: [email-masked]
> > > > Precedence: bulk
> > > >
> > > > Folks,
> > > >
> > > > This is to begin the WG Last Call on advancing Multiprotocol
> > > > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > > > Jan 23, 2002.
> > > >
> > > > Yakov.
> > > > ------- Forwarded Message
> > > >
> > > > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > > > From:    [email-masked]
> > > > To:      IETF-Announce: ;
> > > > cc:      [email-masked]
> > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> > > >
> > > > - --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           : Multiprotocol Extensions for BGP-4
> > > >       Author(s)       : T. Bates et al.
> > > >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> > > >       Pages           : 10
> > > >       Date            : 08-Jan-02
> > > >
> > > > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > > > enable it to carry routing information for multiple Network Layer
> > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > > > compatible - a router that supports the extensions can interoperate
> > > > with a router that doesn't support the extensions.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> > > >
> > > > To remove yourself from the IETF Announcement list, send a message to
> > > > ietf-announce-request with the word unsubscribe in the body of the 
> message.
> > > >
> > > > Internet-Drafts are also 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-rfc2858bis-00.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> >
> >

To: Susan Hares <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Fri, 11 Jan 2002 10:04:39 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue:
As the processing of a UPDATE message (with the same prefix in multiple
fields) is un-specified in the MP spec., there is really nothing to "change"
from.

-- Enke

> Message-Id: <[email-masked]>
> Date: Fri, 11 Jan 2002 11:20:02 -0500
> To: Enke Chen <[email-masked]>
> From: Susan Hares <[email-masked]>
> Subject: Re: IDR WG Last Call 
> Cc: Yakov Rekhter <[email-masked]>, [email-masked],
> 	[email-masked]
> In-Reply-To: <[email-masked]>
> 
> 
> Enke:
> 
> I don't think this is a clarification, I think this is a change in the
> specification.   The original idea was to allow:
> 
> Withdraw and announce to withdraw the SAFI: uni,multi in the MP_UNREACH_NLRI
> filed and to announce it in the NLRI field.
> 
> Can you site a technical reason for this change or common practice
> regarding this text?
> 
> Sue Hares
> 
> 
> 
> At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
> >Hi, Yakov:
> >How about we add the following clarification (similar to the one in the base
> >BGP spec):
> >
> >    An UPDATE message should not include the same address prefix (of the same
> >    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES
> >    field, Network Reachability Information fields, MP_REACH_NLRI field, and
> >    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process 
> > UPDATE
> >    messages in this form. A BGP speaker should treat an UPDATE message of 
> > this
> >    form as if that the address prefix were included only in the last field of
> >    the message.
> >
> >Thanks. -- Enke
> >
> > > Message-Id: <[email-masked]>
> > > To: [email-masked]
> > > Subject: IDR WG Last Call
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset="us-ascii"
> > > Content-ID: <[email-masked]>
> > > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > > From: Yakov Rekhter <[email-masked]>
> > > Sender: [email-masked]
> > > Precedence: bulk
> > >
> > > Folks,
> > >
> > > This is to begin the WG Last Call on advancing Multiprotocol
> > > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > > Jan 23, 2002.
> > >
> > > Yakov.
> > > ------- Forwarded Message
> > >
> > > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > > From:    [email-masked]
> > > To:      IETF-Announce: ;
> > > cc:      [email-masked]
> > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> > >
> > > - --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           : Multiprotocol Extensions for BGP-4
> > >       Author(s)       : T. Bates et al.
> > >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> > >       Pages           : 10
> > >       Date            : 08-Jan-02
> > >
> > > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > > enable it to carry routing information for multiple Network Layer
> > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > > compatible - a router that supports the extensions can interoperate
> > > with a router that doesn't support the extensions.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> > >
> > > To remove yourself from the IETF Announcement list, send a message to
> > > ietf-announce-request with the word unsubscribe in the body of the message.
> > >
> > > Internet-Drafts are also 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-rfc2858bis-00.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> 
> 

Date: Fri, 11 Jan 2002 13:00:48 -0500
From: Jeffrey Haas <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-16 ATOMIC_AGGREGATE
Sender: [email-masked]

On Thu, Jan 09, 2003 at 08:33:25PM -0000, Tom Petch wrote:
> In 5.1.6, ATOMIC_AGGREGATE MUST be included if the AS_PATH
> of the aggregated route excludes at least some of the AS
> numbers present in the AS_PATHs of the routes that are
> aggregated.

Yes.  Especially when the path is truncated as is default in
certain router vendors.

> In 9.1.4, if a BGP speaker chooses to aggregate, then it
> MUST add ATOMIC_AGGREGATE attribute to the route ie
> ATOMIC_AGGREGATE will be present in every aggregate
> regardless of whether or not an AS number is no longer in
> the AS-PATH.
> 
> Is this really what is meant?

Arguably, it is not necessary to append atomic aggregate if the
paths and nexthop are identical.

However, there are a lot of other circumstances where appending
AA would make sense, but they're messy since they require a
great amount of additional overhead.

Generally, I consider AA to be not very useful in its current form.

> Tom Petch, Network Consultant
> [email-masked]
> +(44) 192 575 3018

-- 
Jeff Haas 
NextHop Technologies

To: Susan Hares <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Fri, 11 Jan 2002 09:43:48 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Sue, 

> Message-Id: <[email-masked]>
> Date: Fri, 11 Jan 2002 11:20:02 -0500
> To: Enke Chen <[email-masked]>
> From: Susan Hares <[email-masked]>
> Subject: Re: IDR WG Last Call 
> Cc: Yakov Rekhter <[email-masked]>, [email-masked],
> 	[email-masked]
> In-Reply-To: <[email-masked]>
> References: <Message from Yakov Rekhter <[email-masked]>
>  <[email-masked]>
> Mime-Version: 1.0
> 
> Enke:
> 
> I don't think this is a clarification, I think this is a change in the
> specification.   The original idea was to allow:
> 
> Withdraw and announce to withdraw the SAFI: uni,multi in the MP_UNREACH_NLRI
> filed and to announce it in the NLRI field.

Could not find it in the spec..

> 
> Can you site a technical reason for this change or common practice
> regarding this text?

That is what the widely deployed code does. -- Enke

> 
> Sue Hares
> 
> 
> 
> At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
> >Hi, Yakov:
> >How about we add the following clarification (similar to the one in the base
> >BGP spec):
> >
> >    An UPDATE message should not include the same address prefix (of the same
> >    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES
> >    field, Network Reachability Information fields, MP_REACH_NLRI field, and
> >    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process 
> > UPDATE
> >    messages in this form. A BGP speaker should treat an UPDATE message of 
> > this
> >    form as if that the address prefix were included only in the last field of
> >    the message.
> >
> >Thanks. -- Enke
> >
> > > Message-Id: <[email-masked]>
> > > To: [email-masked]
> > > Subject: IDR WG Last Call
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset="us-ascii"
> > > Content-ID: <[email-masked]>
> > > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > > From: Yakov Rekhter <[email-masked]>
> > > Sender: [email-masked]
> > > Precedence: bulk
> > >
> > > Folks,
> > >
> > > This is to begin the WG Last Call on advancing Multiprotocol
> > > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > > Jan 23, 2002.
> > >
> > > Yakov.
> > > ------- Forwarded Message
> > >
> > > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > > From:    [email-masked]
> > > To:      IETF-Announce: ;
> > > cc:      [email-masked]
> > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> > >
> > > - --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           : Multiprotocol Extensions for BGP-4
> > >       Author(s)       : T. Bates et al.
> > >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> > >       Pages           : 10
> > >       Date            : 08-Jan-02
> > >
> > > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > > enable it to carry routing information for multiple Network Layer
> > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > > compatible - a router that supports the extensions can interoperate
> > > with a router that doesn't support the extensions.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> > >
> > > To remove yourself from the IETF Announcement list, send a message to
> > > ietf-announce-request with the word unsubscribe in the body of the message.
> > >
> > > Internet-Drafts are also 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-rfc2858bis-00.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> 
> 

Date: Fri, 11 Jan 2002 09:16:54 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Tom Petch" <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 Section 9
Sender: [email-masked]

Tom,

> 9.1.2 Route selection now allows for the best route in
> Loc-RIB not to be placed in the Routing table; how does this
> impact on the principle (2 Introduction) that a BGP Speaker
> should only advertise routes it itself uses?  Is it enough
> for the route to be in Loc-RIB and not in the Routing Table?

The principle implies that the route is both in Loc-RIB and
in the routing table, i.e., it needs to be both selected as
the best and used by the router.
However, we can only specify so much about the routing table,
as it is (strictly speaking) outside of the scope of the BGP
protocol and administrator do have the "filter" rope in
their hands. Section 3.2 also talks about this.

> I believe the paragraph on immediate next hop should
> cross-reference the one in 5.1.3; and the latter allows
> route lookup to resolve to a subnet and not an immediate
> next hop address, a possibility 9.1.2 appears not to cater
> for.

Fine with me.

> Perhaps the information on immediate next hop in 5.1.3 and 9
> should be combined in one place; 5.1.3 would be my
> preference.

Fine with me.

> 9.1.2.1 Intermediate network address throws me each time as
> I start thinking of networks; I assume that this is the
> immediate next hop of Rte1; if so, would not that be
> clearer?

The address in Rte1 can be either a direct next-hop or
a third party next-hop (not really a next hop from the RT
perspective). "Intermediate" should account for both cases.

> Resolvability talks of routing table entries for IGP and
> directly connected networks; for consistency with 3.2, I
> would like to see static in there as well.

I actually thought about it when writing this text, but
it fell out of my head. How about this:

   BGP routes do not refer to interfaces, but can be resolved through
   the routes in the Routing Table that can be of both types. IGP routes
   and routes to directly connected networks are expected to specify the
   outbound interface. Static routes can specify the outbound
   interface, or the intermediate address, or both.

> 9.1.2.2e  Again 5.1.3 impacts on this;should this be
> 'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!)
> and what happens with a recursive lookup?  Which of the
> metrics in the various Routing Table entries gets used?
> Perhaps 'The interior cost of a route is the metric in the
> routing table for the immediate next hop (see 5.1.3)'

In fact, "next hop" should read as NEXT_HOP. The metric
is the IGP cost found in the route resolving the NEXT_HOP.

Alex.

Date: Fri, 11 Jan 2002 11:52:47 -0500
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Agenda Items
Sender: [email-masked]

It's time to send agenda items for the March IETF.
If you have something you wish to add to the
agenda, please let me know.

Our agenda is:

	1) BGP MIBs
	2) Security Document
	3) Standardization report for BGP-4

Sue Hares

Date: Fri, 11 Jan 2002 11:42:41 -0500
To: Bill Fenner <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Resending: Re: 2842 to Draft Standard
Cc: [email-masked]
Sender: [email-masked]

IDR working group:

I will be sending out a questionnaire that you can fill out
to the working group.   As I did prior to the the -17 draft,
I will also create a web site.

I, Yakov and Bill really encourage you to report your BGP
implementations, and any deployment experience on
these forms.

Sue Hares

At 10:16 AM 1/10/2002 -0800, Bill Fenner wrote:

>I am re-sending this message to the IDR mailing list since I didn't
>see it come through either on the list or in the archives.
>
>Subject: Re: 2842 to Draft Standard
>Date: Tue, 8 Jan 2002 12:01:37 -0800
>To: [email-masked]
>Cc: [email-masked]
>
>IDR WG,
>
>   In order to progress to Draft Standard, an implementation report
>is required (see section 4.1.2 of RFC 2026).  In particular:
>
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.
>
>RFC 2842 has several optional portions (e.g. sending Notifications
>and whether to include the capability in question in the Notification),
>which the implementation report that you included in the original
>request did not mention.
>
>   I'd like to see a more complete implementation report.  For
>example, if vendors don't mind being named:
>http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt
>or if they don't want to be named:
>http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION
>
>   Also, the process would go much more smoothly if there was an
>Internet-Draft containing the revision, even though it's so small.
>The RFC-Editor can supply the nroff of RFC 2842 if the authors
>don't still have their source.
>
>   Bill

Date: Wed, 28 Nov 2001 14:18:50 -0500
To: "Manav Bhatia" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: draft-ietf-idr-bgp-dpa-04.txt 
Cc: <[email-masked]>
Sender: [email-masked]

Historical

At 08:32 AM 11/28/2001 +0530, Manav Bhatia wrote:
>Hi,
>Can anybody please tell me as to what is the current status of
>draft-ietf-idr-bgp-dpa-04.txt ?
>
>Regards,
>Manav
>
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com

Date: Fri, 11 Jan 2002 08:39:32 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Tom Petch" <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 5.1.3 immediate next hop
Sender: [email-masked]

Tom,

 I think you might have gotten confused with terms, i.e., what
 resolves something and what gets resolved.

 We resolve an address (specifically the address in the NEXT_HOP
 attribute) to a direct next-hop address. We do this by performing
 a routing table look up for the address to be resolved.
 The route that gives us the result is the resolving route.

-- 
Alex Zinin

Saturday, January 11, 2003, 6:22:02 AM, Tom Petch wrote:

> Each time I read this paragraph I am left wondering if I
> really understand it!  The use of 'resolving' conveys to me
> something on-going and incomplete, surely the opposite of
> what is intended.  Might I suggest

>   The NEXT_HOP attribute is used by the BGP speaker to
> determine the
>    actual outbound interface and immediate next-hop address
> that should
>    be used to forward transit packets to the associated
> destinations.
>    The immediate next-hop address is determined by
> performing a
>    recursive route lookup operation for the IP address in
> the NEXT_HOP
>    attribute using the contents of the Routing Table (see
> Section
>    9.1.2.2). The

> *** result of this operation will always will always resolve
> the outbound interface and may resolve either the next-hop
> address or an attached subnet to be used. If the operation
> resolves the next-hop address, this address should be used
> as the immediate next-hop address for packet forwarding. If
> the operation does not resolve the next-hop address but does
> resolve the attached subnet to be used, then the address in
> the NEXT_HOP attribute should be used as the immediate
> next-hop address. ***

> Tom Petch, Network Consultant
> [email-masked]
> +(44) 192 575 3018

Date: Fri, 11 Jan 2002 11:20:02 -0500
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: IDR WG Last Call 
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Enke:

I don't think this is a clarification, I think this is a change in the
specification.   The original idea was to allow:

Withdraw and announce to withdraw the SAFI: uni,multi in the MP_UNREACH_NLRI
filed and to announce it in the NLRI field.

Can you site a technical reason for this change or common practice
regarding this text?

Sue Hares

At 10:13 AM 1/10/2002 -0800, Enke Chen wrote:
>Hi, Yakov:
>How about we add the following clarification (similar to the one in the base
>BGP spec):
>
>    An UPDATE message should not include the same address prefix (of the same
>    <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES
>    field, Network Reachability Information fields, MP_REACH_NLRI field, and
>    MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process 
> UPDATE
>    messages in this form. A BGP speaker should treat an UPDATE message of 
> this
>    form as if that the address prefix were included only in the last field of
>    the message.
>
>Thanks. -- Enke
>
> > Message-Id: <[email-masked]>
> > To: [email-masked]
> > Subject: IDR WG Last Call
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset="us-ascii"
> > Content-ID: <[email-masked]>
> > Date: Wed, 09 Jan 2002 17:31:49 -0800
> > From: Yakov Rekhter <[email-masked]>
> > Sender: [email-masked]
> > Precedence: bulk
> >
> > Folks,
> >
> > This is to begin the WG Last Call on advancing Multiprotocol
> > Extensions for BGP-4 to Draft Standard. The Last Call ends
> > Jan 23, 2002.
> >
> > Yakov.
> > ------- Forwarded Message
> >
> > Date:    Wed, 09 Jan 2002 16:06:30 -0500
> > From:    [email-masked]
> > To:      IETF-Announce: ;
> > cc:      [email-masked]
> > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> >
> > - --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           : Multiprotocol Extensions for BGP-4
> >       Author(s)       : T. Bates et al.
> >       Filename        : draft-ietf-idr-rfc2858bis-00.txt
> >       Pages           : 10
> >       Date            : 08-Jan-02
> >
> > Currently BGP-4 [BGP-4] is capable of carrying routing information
> > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> > enable it to carry routing information for multiple Network Layer
> > protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> > compatible - a router that supports the extensions can interoperate
> > with a router that doesn't support the extensions.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the message.
> >
> > Internet-Drafts are also 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-rfc2858bis-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

Date: Fri, 11 Jan 2002 09:47:19 -0500
To: Bill Fenner <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Resending: Re: 2842 to Draft Standard
Cc: [email-masked]
Sender: [email-masked]

IDR working group:

I will be sending out a questionnaire that you can fill out
to the working group.   As I did prior to the the -17 draft,
I will also create a web site.

I, Yakov and Bill really encourage you to report your BGP
implementations, and any deployment experience on
these forms.

Sue Hares

At 10:16 AM 1/10/2002 -0800, Bill Fenner wrote:

>I am re-sending this message to the IDR mailing list since I didn't
>see it come through either on the list or in the archives.
>
>Subject: Re: 2842 to Draft Standard
>Date: Tue, 8 Jan 2002 12:01:37 -0800
>To: [email-masked]
>Cc: [email-masked]
>
>IDR WG,
>
>   In order to progress to Draft Standard, an implementation report
>is required (see section 4.1.2 of RFC 2026).  In particular:
>
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.
>
>RFC 2842 has several optional portions (e.g. sending Notifications
>and whether to include the capability in question in the Notification),
>which the implementation report that you included in the original
>request did not mention.
>
>   I'd like to see a more complete implementation report.  For
>example, if vendors don't mind being named:
>http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt
>or if they don't want to be named:
>http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION
>
>   Also, the process would go much more smoothly if there was an
>Internet-Draft containing the revision, even though it's so small.
>The RFC-Editor can supply the nroff of RFC 2842 if the authors
>don't still have their source.
>
>   Bill

Date: Fri, 11 Jan 2002 08:29:04 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Tom Petch" <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 5.1.3 NEXT_HOP attribute determination
Sender: [email-masked]

Tom,

> I think that there is a problem with logic and terminology
> in the determination of NEXT_HOP.  There are four cases
> listed,
> - a form of "third party" NEXT_HOP attribute
> - a second form of "third party" NEXT_HOP attribute
> - "first party" NEXT_HOP attribute
> - by default
> and respectively the BGP speaker
> - can use
> - can use
> - may use
> - should use
> which seems inconsistent; I would prefer SHOULD.

Since use of third party next hops is an optimization
by nature and does not *have* to be implemented,
and given that "should" is used for the default,
I think "may/can" is ok. If we change the optional
cases to "should" to increase the level on insistence,
we should do the same to the default case and make
it a must.
If you ask me, I think we're all right now.

> But logically, the first party (common subnet) overlaps the
> two third parties (common subnet with IBGP or locally
> originated and common subnet with EBGP) which obviates
> SHOULD.

We know how to deal with overlapping cases already---
the more specific one wins. Same here---third party
cases are more specific in their description.
I guess it might be clearer if we changed "-if -if"
to "-if -otherwise if".

> And what does locally originated actually mean?

It means that the route was not received from another
BGP peer and was created by the guy we're talking about.

> Presumably IGP and static except that the subsequent use of
> internal router does not quite match that.

> I wonder if it would be clearer if the focus was on the
> common subnet rather than where the route came from.  Can eg
> the third party cases be combined as

> 'if the external peer X shares a common subnet with the
> immediate next hop that the BGP speaker itself has installed
> in its routing table for this route, then the speaker SHOULD
> use this immediate next hop in the NEXT_HOP attribute'

When I changed this text to what it is now, I tried to preserve
the spirit of the old one, and keep some "educational" info.
I think both ways are fine and functionally equivalent, it is
more a question of preference.
So, I guess my vote is to stet it :)

Alex.

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bgp4-17 5.1.3 immediate next hop
Date: Sat, 11 Jan 2003 14:22:02 -0000
Sender: [email-masked]

Each time I read this paragraph I am left wondering if I
really understand it!  The use of 'resolving' conveys to me
something on-going and incomplete, surely the opposite of
what is intended.  Might I suggest

  The NEXT_HOP attribute is used by the BGP speaker to
determine the
   actual outbound interface and immediate next-hop address
that should
   be used to forward transit packets to the associated
destinations.
   The immediate next-hop address is determined by
performing a
   recursive route lookup operation for the IP address in
the NEXT_HOP
   attribute using the contents of the Routing Table (see
Section
   9.1.2.2). The

*** result of this operation will always will always resolve
the outbound interface and may resolve either the next-hop
address or an attached subnet to be used. If the operation
resolves the next-hop address, this address should be used
as the immediate next-hop address for packet forwarding. If
the operation does not resolve the next-hop address but does
resolve the attached subnet to be used, then the address in
the NEXT_HOP attribute should be used as the immediate
next-hop address. ***

Tom Petch, Network Consultant
[email-masked]
+(44) 192 575 3018

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: AS4bytes old and new
Date: Sat, 11 Jan 2003 14:10:35 -0000
Sender: [email-masked]

Near me is a town called Newtown; reasonable as it is only
700 years old :-) but it does confuse people even after all
these years.
I think the use of Old and New in the 4byte AS draft will
cause similar confusion in the not too distant future and we
should come up with an absolute term to differentiate them
rather than a relative term that may soon be obsolete.  If
you want to see an example of how not to do it, look at SCSI
terminology; narrow, wide, ultra-wide, ultra2, really wide,
ultra160, ...

Tom Petch, Network Consultant
[email-masked]

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bgp4-17 Section 9
Date: Sat, 11 Jan 2003 15:53:01 -0000
Sender: [email-masked]

9.1.2 Route selection now allows for the best route in
Loc-RIB not to be placed in the Routing table; how does this
impact on the principle (2 Introduction) that a BGP Speaker
should only advertise routes it itself uses?  Is it enough
for the route to be in Loc-RIB and not in the Routing Table?

I believe the paragraph on immediate next hop should
cross-reference the one in 5.1.3; and the latter allows
route lookup to resolve to a subnet and not an immediate
next hop address, a possibility 9.1.2 appears not to cater
for.

Perhaps the information on immediate next hop in 5.1.3 and 9
should be combined in one place; 5.1.3 would be my
preference.

9.1.2.1 Intermediate network address throws me each time as
I start thinking of networks; I assume that this is the
immediate next hop of Rte1; if so, would not that be
clearer?

Resolvability talks of routing table entries for IGP and
directly connected networks; for consistency with 3.2, I
would like to see static in there as well.

9.1.2.2e  Again 5.1.3 impacts on this;should this be
'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!)
and what happens with a recursive lookup?  Which of the
metrics in the various Routing Table entries gets used?
Perhaps 'The interior cost of a route is the metric in the
routing table for the immediate next hop (see 5.1.3)'

Tom Petch, Network Consultant
[email-masked]

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bgp4-17 Cease subcode
Date: Sat, 11 Jan 2003 15:48:06 -0000
Sender: [email-masked]

I believe there should be a Cease sub-code to differentiate
the case where the upper bound on the number of acceptable
address prefixes is exceeded.  If not, then the recipient of
the Cease could assume this is due to some other transient,
re-establish the connection and repeat the process ad
infinitum.

Tom Petch, Network Consultant
[email-masked]

Date: Fri, 11 Jan 2002 07:29:36 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Tom Petch" <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-17 LOCAL_PREF
Sender: [email-masked]

 A "see section 5.1.5" instead of "disallowed" in
 the table before 5.1 should do the trick.
 
-- 
Alex Zinin

Saturday, January 11, 2003, 4:56:35 AM, Tom Petch wrote:

> Section 5 states that LOCAL_PREF is disallowed for EBGP;
> section 5.1.5 allows it for external peers as part of BGP
> Confederations.

> I think that Section 5 needs qualifying

> Tom Petch, Network Consultant
> [email-masked]

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bgp4-17 5.1.3 NEXT_HOP attribute determination
Date: Sat, 11 Jan 2003 13:48:10 -0000
Sender: [email-masked]

I think that there is a problem with logic and terminology
in the determination of NEXT_HOP.  There are four cases
listed,
- a form of "third party" NEXT_HOP attribute
- a second form of "third party" NEXT_HOP attribute
- "first party" NEXT_HOP attribute
- by default
and respectively the BGP speaker
- can use
- can use
- may use
- should use
which seems inconsistent; I would prefer SHOULD.

But logically, the first party (common subnet) overlaps the
two third parties (common subnet with IBGP or locally
originated and common subnet with EBGP) which obviates
SHOULD.  And what does locally originated actually mean?
Presumably IGP and static except that the subsequent use of
internal router does not quite match that.

I wonder if it would be clearer if the focus was on the
common subnet rather than where the route came from.  Can eg
the third party cases be combined as

'if the external peer X shares a common subnet with the
immediate next hop that the BGP speaker itself has installed
in its routing table for this route, then the speaker SHOULD
use this immediate next hop in the NEXT_HOP attribute'

Tom Petch, Network Consultant
[email-masked]

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bgp4-17 LOCAL_PREF
Date: Sat, 11 Jan 2003 12:56:35 -0000
Sender: [email-masked]

Section 5 states that LOCAL_PREF is disallowed for EBGP;
section 5.1.5 allows it for external peers as part of BGP
Confederations.

I think that Section 5 needs qualifying

Tom Petch, Network Consultant
[email-masked]

Date: Thu, 10 Jan 2002 22:12:08 -0500
To: Bill Fenner <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Resending: Re: 2842 to Draft Standard
Cc: [email-masked]
Sender: [email-masked]

Bill:

You need to be a part of [email-masked] to send to the list.
This cuts out spam.

Sue

At 10:16 AM 1/10/2002 -0800, Bill Fenner wrote:

>I am re-sending this message to the IDR mailing list since I didn't
>see it come through either on the list or in the archives.
>
>Subject: Re: 2842 to Draft Standard
>Date: Tue, 8 Jan 2002 12:01:37 -0800
>To: [email-masked]
>Cc: [email-masked]
>
>IDR WG,
>
>   In order to progress to Draft Standard, an implementation report
>is required (see section 4.1.2 of RFC 2026).  In particular:
>
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.
>
>RFC 2842 has several optional portions (e.g. sending Notifications
>and whether to include the capability in question in the Notification),
>which the implementation report that you included in the original
>request did not mention.
>
>   I'd like to see a more complete implementation report.  For
>example, if vendors don't mind being named:
>http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt
>or if they don't want to be named:
>http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION
>
>   Also, the process would go much more smoothly if there was an
>Internet-Draft containing the revision, even though it's so small.
>The RFC-Editor can supply the nroff of RFC 2842 if the authors
>don't still have their source.
>
>   Bill

From: Bill Fenner <[email-masked]>
To: [email-masked]
Subject: Resending: Re: 2842 to Draft Standard
Date: Thu, 10 Jan 2002 10:16:23 -0800
Versions: dmail (solaris) 2.2j/makemail 2.9b
Sender: [email-masked]

I am re-sending this message to the IDR mailing list since I didn't
see it come through either on the list or in the archives.

Subject: Re: 2842 to Draft Standard
Date: Tue, 8 Jan 2002 12:01:37 -0800
To: [email-masked]
Cc: [email-masked]

IDR WG,

  In order to progress to Draft Standard, an implementation report
is required (see section 4.1.2 of RFC 2026).  In particular:

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.

RFC 2842 has several optional portions (e.g. sending Notifications
and whether to include the capability in question in the Notification),
which the implementation report that you included in the original
request did not mention.

  I'd like to see a more complete implementation report.  For
example, if vendors don't mind being named:
http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt
or if they don't want to be named:
http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION

  Also, the process would go much more smoothly if there was an
Internet-Draft containing the revision, even though it's so small.
The RFC-Editor can supply the nroff of RFC 2842 if the authors 
don't still have their source.

  Bill

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: IDR WG Last Call 
Date: Thu, 10 Jan 2002 10:13:21 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Yakov:
How about we add the following clarification (similar to the one in the base
BGP spec):

   An UPDATE message should not include the same address prefix (of the same
   <AFI, SAFI>) in more than one of the following fields: WITHDRAWN ROUTES
   field, Network Reachability Information fields, MP_REACH_NLRI field, and
   MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process UPDATE
   messages in this form. A BGP speaker should treat an UPDATE message of this
   form as if that the address prefix were included only in the last field of
   the message.

Thanks. -- Enke

> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: IDR WG Last Call
> MIME-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <[email-masked]>
> Date: Wed, 09 Jan 2002 17:31:49 -0800
> From: Yakov Rekhter <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
> Folks,
> 
> This is to begin the WG Last Call on advancing Multiprotocol
> Extensions for BGP-4 to Draft Standard. The Last Call ends
> Jan 23, 2002.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Wed, 09 Jan 2002 16:06:30 -0500
> From:    [email-masked]
> To:      IETF-Announce: ;
> cc:      [email-masked]
> Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt
> 
> - --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		: Multiprotocol Extensions for BGP-4
> 	Author(s)	: T. Bates et al.
> 	Filename	: draft-ietf-idr-rfc2858bis-00.txt
> 	Pages		: 10
> 	Date		: 08-Jan-02
> 	
> Currently BGP-4 [BGP-4] is capable of carrying routing information
> only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
> enable it to carry routing information for multiple Network Layer
> protocols (e.g., IPv6, IPX, etc...). The extensions are backward
> compatible - a router that supports the extensions can interoperate
> with a router that doesn't support the extensions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also 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-rfc2858bis-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

To: [email-masked]
Subject: BGP with FSM
Date: Wed, 09 Jan 2002 17:37:51 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start WG Last Call on the -17 version of the document.
The Last Call ends Jan 23, 2002.

Yakov.

P.S. As was agree before, we added the FSM description to the document
(Many thanks to Sue Hares for providing the text).

------- Forwarded Message

Date:    Wed, 09 Jan 2002 16:06:18 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-17.txt

- --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)	: Y. Rekhter, T. Li
	Filename	: draft-ietf-idr-bgp4-17.txt
	Pages		: 66
	Date		: 08-Jan-02
	
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].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-17.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-17.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

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

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: [email-masked]
Subject: IDR WG Last Call
Date: Wed, 09 Jan 2002 17:31:49 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to begin the WG Last Call on advancing Multiprotocol
Extensions for BGP-4 to Draft Standard. The Last Call ends
Jan 23, 2002.

Yakov.
------- Forwarded Message

Date:    Wed, 09 Jan 2002 16:06:30 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt

- --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		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates et al.
	Filename	: draft-ietf-idr-rfc2858bis-00.txt
	Pages		: 10
	Date		: 08-Jan-02
	
Currently BGP-4 [BGP-4] is capable of carrying routing information
only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
enable it to carry routing information for multiple Network Layer
protocols (e.g., IPv6, IPX, etc...). The extensions are backward
compatible - a router that supports the extensions can interoperate
with a router that doesn't support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-rfc2858bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc2858bis-00.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Date: Wed, 9 Jan 2002 16:33:11 -0800 (PST)
From: Edward Crabbe <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-16 'it is critical that'
Sender: [email-masked]

> 9.1.2 Phase 2: Route Selection says
> 
> 'It is critical that routers within an AS do not make
> conflicting
>    decisions regarding route selection that would cause
> forwarding loops
>    to occur.'
> 
> Well yes but how does 'it is critical that' stand in the
> customary pantheon of MUST, SHALL, MAY etc etc ?
> 

unless you want to remove the ability to apply policy 
to ibgp sessions, you will end up with the possibility 
of inconsistant forwarding across;  ibgp policy is often used
as a traffic engineering tool, and it's removal may irritate
some backbone engineers.

Date: Wed, 9 Jan 2002 17:08:37 -0500
From: Jeffrey Haas <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked]
Subject: Re: bgp4-16 'it is critical that'
Sender: [email-masked]

I read this as a "may", but only in the sense of "You may mount
a loaded shotgun and rig up a trigger mechanism so you can shoot
yourself, but it is recommended highly that you don't do this."

On Thu, Jan 09, 2003 at 09:04:41PM -0000, Tom Petch wrote:
> 9.1.2 Phase 2: Route Selection says
> 
> 'It is critical that routers within an AS do not make
> conflicting
>    decisions regarding route selection that would cause
> forwarding loops
>    to occur.'
> 
> Well yes but how does 'it is critical that' stand in the
> customary pantheon of MUST, SHALL, MAY etc etc ?
> 
> Tom Petch, Network Consultant
> [email-masked]
> +(44) 192 575 3018
> 
> 

-- 
Jeff Haas 
NextHop Technologies

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bgp4-16 'it is critical that'
Date: Thu, 9 Jan 2003 21:04:41 -0000
Sender: [email-masked]

9.1.2 Phase 2: Route Selection says

'It is critical that routers within an AS do not make
conflicting
   decisions regarding route selection that would cause
forwarding loops
   to occur.'

Well yes but how does 'it is critical that' stand in the
customary pantheon of MUST, SHALL, MAY etc etc ?

Tom Petch, Network Consultant
[email-masked]
+(44) 192 575 3018

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: bgp4-16 ATOMIC_AGGREGATE
Date: Thu, 9 Jan 2003 20:33:25 -0000
Sender: [email-masked]

In 5.1.6, ATOMIC_AGGREGATE MUST be included if the AS_PATH
of the aggregated route excludes at least some of the AS
numbers present in the AS_PATHs of the routes that are
aggregated.

In 9.1.4, if a BGP speaker chooses to aggregate, then it
MUST add ATOMIC_AGGREGATE attribute to the route ie
ATOMIC_AGGREGATE will be present in every aggregate
regardless of whether or not an AS number is no longer in
the AS-PATH.

Is this really what is meant?

Tom Petch, Network Consultant
[email-masked]
+(44) 192 575 3018

Date: Wed, 9 Jan 2002 13:43:15 -0500
From: Jeffrey Haas <[email-masked]>
To: Raghavendran Gururajan <[email-masked]>
Cc: [email-masked]
Subject: Re: Clarifications reg.  draft-ietf-idr-as4bytes-04.txt
Sender: [email-masked]

On Wed, Jan 09, 2002 at 05:38:51AM -0000, Raghavendran  Gururajan wrote:
> But what happens now to the policies based on AS_PATH, 
> that are configured in the old BGP speaker ? The OLD speakers cannot exactly determine which route has traversed which AS for routes propagated by the NEW BGP speakers. 

No reasonable policy is possible.  The 4-byte space that isn't covered
by the 2-byte space is a "black box".  If you are a 4-byte speaker,
policy on the NEW_AS_PATH will work.

As I see more data from groups like CAIDA and previously from IPMA,
I think AS adjacency policy is less and less a good idea, especially
when it comes to completely excluding routes from eligibility.

> Raghavendran. 

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 9 Jan 2002 13:39:30 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: question
Sender: [email-masked]

On Wed, Jan 09, 2002 at 09:23:53AM -0600, [email-masked] wrote:
> The route reflector is not 
> involved in data forwarding so that even if the BGP session to another 
> router fails, that does not mean that the routes advertised by the route 
> reflector are not valid any more. Therefore it might make sense to keep 
> the BGP routes learned by the router from the route reflector even if 
> the BGP session between both breaks down. 
> Any comments ? Has there been any related work ?

There are similar issues for any element in a reflection mechanism.
Route Servers had similar issues.

BGP does not propagate the reason why a given route has been withdrawn,
only that it has.  Even if you passed along that the, for example,
transport session has been torn down between the advertising
router and the reflector you can't tell why it was done.  It could
be as simple as it getting shutoff, configuration change, etc.

In the cases where loss of a peering session is expected, there
are proposed mechanisms such as Graceful Restart that would allow
the forwarding path to remain good while the sessions came back up.

> Dr. Claus Bauer

-- 
Jeff Haas 
NextHop Technologies

Date: 9 Jan 2002 05:38:51 -0000
From: "Raghavendran  Gururajan" <[email-masked]>
Reply-To: "Raghavendran  Gururajan" <[email-masked]>
To: [email-masked]
Subject: Clarifications reg.  draft-ietf-idr-as4bytes-04.txt
Sender: [email-masked]

Hi, 

Some clarifications regarding "draft-ietf-idr-as4bytes-04.txt". 

About AS_TRANS: The draft talks about AS_TRANS, 
reserved 2-octet AS number assigned by IANA. 
The draft even mentions a scenario where a old BGP 
speaker is peering with two or more AS that 
have NEW BGP speakers (section 6). The scenario 
considers only the route selection based on MED. 

But what happens now to the policies based on AS_PATH, 
that are configured in the old BGP speaker ? The OLD speakers cannot exactly determine which route has traversed which AS for routes propagated by the NEW BGP speakers. 

Also, are there already any implementation (vendor & public domain) of the same to interop with ? 

Any pointers to the above areas will be helpful and will be appreciated. 

Regards, 
Raghavendran. 

Date: Tue, 8 Jan 2002 08:44:39 -0500 (EST)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Dong Ha <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: what is a different BGP route?
Sender: [email-masked]

These are different, and will not be aggregated unless the bgp
speaker is configured to do so.

Russ

On Mon, 7 Jan 2002, Dong Ha wrote:

> Hello everyone,
> 
> My name is Dong and I'm working on a BGP conformance
> test suite. I'm wondering if anyone can tell me if the
> two BGP routes below are different from each other.
> This information is taken from two different BGP
> Update messages from the same source. I only show the
> different values. Everything else is the same. Aslo,
> when a router receives these two routes, would it
> aggregate the route or not? 
> 
> Route 1: Community attribute value: 888:4369; NLRI
> field value: 192.168.0.0/16
> 
> Route 2: Community attribute value: 888:8738; NLRI
> field value: 192.168.120.0/24 
> 
> Thanks.
> 
> -dong
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Mon, 7 Jan 2002 12:14:59 -0800 (PST)
From: Dong Ha <[email-masked]>
Subject: what is a different BGP route?
To: [email-masked], [email-masked]
Sender: [email-masked]

Hello everyone,

My name is Dong and I'm working on a BGP conformance
test suite. I'm wondering if anyone can tell me if the
two BGP routes below are different from each other.
This information is taken from two different BGP
Update messages from the same source. I only show the
different values. Everything else is the same. Aslo,
when a router receives these two routes, would it
aggregate the route or not? 

Route 1: Community attribute value: 888:4369; NLRI
field value: 192.168.0.0/16

Route 2: Community attribute value: 888:8738; NLRI
field value: 192.168.120.0/24 

Thanks.

-dong

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

To: [email-masked]
Cc: [email-masked]
Subject: AS_TRAN in draft-ietf-idr-as4bytes-04.txt
Date: Mon, 07 Jan 2002 10:49:53 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
I have received several messages asking about the value of
AS_TRAN as described in the draft. IANA has allocated 23456
for AS_TRAN, though it has not shown up on their web page.

-- Enke

Reply-To: "Manav Bhatia" <[email-masked]>
From: "Manav Bhatia" <[email-masked]>
To: "Katia Linker" <[email-masked]>, <[email-masked]>
Subject: Re: Capabilities advertisement in BGP
Date: Mon, 7 Jan 2002 16:20:21 +0530
Sender: [email-masked]

Before 2858 came out CISCO was using a value of 128 for route refresh
messages. So the additional 80 00 is for the CISCO specific routers. They
are still using this value for the backward compatibility (my guess!).

Manav

----- Original Message -----
From: "Katia Linker" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, January 07, 2002 3:09 PM
Subject: Capabilities advertisement in BGP

| Hi,
| I need your help regards capabilities advertisement as
| an Optional parameters in BGP Open message.
| When I receives Cisco Open message, I can see in
| optional parameters 2 capabilities:
| 1) 01 04 00 01 00 01 which describes multiprotocol
|    extension (RFC 2858)
| 2) 80 00 - what does this capability means ???
|    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| The whole optonal parameter field looks like this:
| 02 06 01 04 00 01 00 01 02 02 80 00
| Please help me !!!!!!!!!!!!!!!
|      Thanks in advance.
|          Katya

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Mon, 07 Jan 2002 01:00:36 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Katia Linker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [zebra 11779] Capabilities advertisement in BGP
Sender: [email-masked]

>I need your help regards capabilities advertisement as
>an Optional parameters in BGP Open message.
>When I receives Cisco Open message, I can see in
>optional parameters 2 capabilities:
>1) 01 04 00 01 00 01 which describes multiprotocol
>   extension (RFC 2858)
>2) 80 00 - what does this capability means ???
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>The whole optonal parameter field looks like this:
>02 06 01 04 00 01 00 01 02 02 80 00 
>Please help me !!!!!!!!!!!!!!!

It is simple.  Cisco was using 128 value (and still is using with RFC
value 2) for capability code refresh.  In Zebra code we defined like
this.

/* Route refresh capabilities. */
#define CAPABILITY_CODE_REFRESH         2
#define CAPABILITY_CODE_REFRESH_OLD   128
#define CAPABILITY_CODE_REFRESH_LEN     0

So "80 00"

Means capability code refresh (old non RFC value) with length 0.  I
don't recommend to announce it.  But for backward compatibility reason
Zebra accept it.
-- 
Kunihiro Ishiguro

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Capabilities advertisement in BGP
Date: Mon, 7 Jan 2002 11:39:00 +0200 
Sender: [email-masked]

Hi,
I need your help regards capabilities advertisement as
an Optional parameters in BGP Open message.
When I receives Cisco Open message, I can see in
optional parameters 2 capabilities:
1) 01 04 00 01 00 01 which describes multiprotocol
   extension (RFC 2858)
2) 80 00 - what does this capability means ???
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The whole optonal parameter field looks like this:
02 06 01 04 00 01 00 01 02 02 80 00 
Please help me !!!!!!!!!!!!!!!
     Thanks in advance.
         Katya

Date: Fri, 4 Jan 2002 14:25:18 -0500
From: Jeffrey Haas <[email-masked]>
To: "Chang, Ellen" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Need clarification on BGP4 specifications
Sender: [email-masked]

On Fri, Jan 04, 2002 at 08:28:55AM -1000, Chang, Ellen wrote:
> ***** What if the AFI indicate IPv6 address in MP Reachable NLRI?  Would the
> system B advertise to the system C or not?

RFC 2858, section 7.

> Ellen

-- 
Jeff Haas 
NextHop Technologies

From: "Chang, Ellen" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Need clarification on BGP4 specifications
Date: Fri, 4 Jan 2002 08:28:55 -1000 
Sender: [email-masked]

On Fri, Jan 04, 2002 at 06:20:36AM -1000, Chang, Ellen wrote:
> ***** Assume system A, B and C have the MP capabilities, and they are
> external peers.
> If the system A sends MP Reachable NLRI (AFI indicate IPv4 address) to the
> system B, would the system B put MP Reachable NLRI (AFI indicate IPv4
> address) in the regular NLRI field and advertise to the system C? Also, If
> the system A sends MP Unreachable NLRI (AFI indicate IPv4 address) to the
> system B, would the system B put MP Unreachable NLRI (AFI indicate IPv4
> address) in the regular withdrawn routes field and advertise to the system
> C?  

For IPv4/unicast, putting the information in the non-MP NLRI fields
is certainly acceptable.

The MPE spec itself is somewhat vague about what happens if you have
the same reachability with differing nexthops in the same packet,
i.e. reachable NLRI and MP-reachable NLRI that are identical but
with different nexthops.

***** What if the AFI indicate IPv6 address in MP Reachable NLRI?  Would the
system B advertise to the system C or not?

Thank you
Ellen

Date: Fri, 4 Jan 2002 11:27:06 -0500
From: Jeffrey Haas <[email-masked]>
To: "Chang, Ellen" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Need clarification on BGP4 specifications
Sender: [email-masked]

On Fri, Jan 04, 2002 at 06:20:36AM -1000, Chang, Ellen wrote:
> ***** Assume system A, B and C have the MP capabilities, and they are
> external peers.
> If the system A sends MP Reachable NLRI (AFI indicate IPv4 address) to the
> system B, would the system B put MP Reachable NLRI (AFI indicate IPv4
> address) in the regular NLRI field and advertise to the system C? Also, If
> the system A sends MP Unreachable NLRI (AFI indicate IPv4 address) to the
> system B, would the system B put MP Unreachable NLRI (AFI indicate IPv4
> address) in the regular withdrawn routes field and advertise to the system
> C?  

For IPv4/unicast, putting the information in the non-MP NLRI fields
is certainly acceptable.

The MPE spec itself is somewhat vague about what happens if you have
the same reachability with differing nexthops in the same packet,
i.e. reachable NLRI and MP-reachable NLRI that are identical but
with different nexthops.

> ****** The FSM indicates that if the system A is in OpenSent state, it is
> only allow to receive an Open message, all the other messages will cause it
> to close TCP.  Also the system A will not transition to Openconfirm state
> until it sends a KeepAlive message. The system A just received Open message
> from the system B, and haven't process the Open message yet, then it
> received KeepAlive message from the system B. So from the system A point of
> view, the system B's action violates the FSM.  

A: Sends Open, State now OpenSent
B: Sends Open, State now OpenSent
B: Receives A's Open. 
B: Sends Keepalive. State now OpenConfirm
A*: on queue: one open PDU, one keepalive PDU.
A: Receives packet, its open.  
A: Sends keepalive.  State now OpenConfirm.
A: Receives packet, its keepalive.  State now Established.

So, keeping in mind *, the only way it knows that it has received
a packet is to pull it off the transport stream and look at it.

> > Ellen

-- 
Jeff Haas 
NextHop Technologies

From: "Chang, Ellen" <[email-masked]>
To: "'Jeffrey Haas'" <[email-masked]>, "Chang, Ellen" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Need clarification on BGP4 specifications
Date: Fri, 4 Jan 2002 06:20:36 -1000 
Sender: [email-masked]

On Fri, Jan 04, 2002 at 05:15:32AM -1000, Chang, Ellen wrote:
> 1. If two Update message are received back to back,  the first Update
> message includes 2 IP address prefixes in the NLRI field, the second
Update
> message withdrawn one of the IP address prefix, how would a BGP speaker
> advertise the route to it's external peers?  Would the BGP speaker only
> advertise the route with the IP address prefix that's not withdrawed?  Or,
> would the BGP speaker advertise the first Update message first, then
> withdraw a route with the second Update message (same as the receiving
order
> of the Update msgs)?

This is implementation dependant.  One would hope your implementation,
where it can, will minimize churn.  So, if you have not, for whatever
reason, advertised the prefix that is withdrawn, you shouldn't send it
in the first place.  This limits the flap to you and doesn't propagate
it to your downstream.

> 2. The spec indicates ' An UPDATE message that contains correct path
> attributes, but no NLRI,
>    shall be treated as a valid UPDATE message.'  
> Does it mean that the receiver of this message should advertise to its
> peers, because a valid Update message should be advertise to its peers?

Implementation dependant.  Why would someone do something like this?
In the case BGP-MPE, its because NLRI isn't in the traditional fields.
Its also possible that just normal path attributes are being passed
around to provide additional information, but thats outside the
scope of the protocol.

> 3. If a system receives a UPDATE message with MP Reachable or Unreachable
> NLRI (AFI indicate IPv4 address), would the system propagates/advertises
or
> withdrawn the MP Reachable or Unreachable NLRI to its peers? 

The attributes are non-transitive.
Additonally, they should only be exchanged if the capabilities are
exchanged for them.

***** Assume system A, B and C have the MP capabilities, and they are
external peers.
If the system A sends MP Reachable NLRI (AFI indicate IPv4 address) to the
system B, would the system B put MP Reachable NLRI (AFI indicate IPv4
address) in the regular NLRI field and advertise to the system C? Also, If
the system A sends MP Unreachable NLRI (AFI indicate IPv4 address) to the
system B, would the system B put MP Unreachable NLRI (AFI indicate IPv4
address) in the regular withdrawn routes field and advertise to the system
C?  

> 4.If system A and B are connected.  The system A initiates TCP connection
to
> system B, then the system A transmits an Open message and waits for an
Open
> message from the system B.  The system B transmits an Open message and a
> Keepalive message back to back.  Is the system A allow to receive a
> Keepalive message when it's still in the OpenSent state, because the
system
> A has not send KeepAlive message to system B yet for it transition to
> OpenConfirm state?  But from the system B point of view, it received Open
> message from system A and it can send KeepAlive message.  Is there a
> conflict?  

There is no conflict.  If you examine things from a packet by packet
standpoint, the ordering is correct.  Considering that BGP is a stream
based protocol, this makes sense. :-)

****** The FSM indicates that if the system A is in OpenSent state, it is
only allow to receive an Open message, all the other messages will cause it
to close TCP.  Also the system A will not transition to Openconfirm state
until it sends a KeepAlive message. The system A just received Open message
from the system B, and haven't process the Open message yet, then it
received KeepAlive message from the system B. So from the system A point of
view, the system B's action violates the FSM.  

> Ellen

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 4 Jan 2002 10:46:34 -0500
From: Jeffrey Haas <[email-masked]>
To: "Chang, Ellen" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Need clarification on BGP4 specifications
Sender: [email-masked]

On Fri, Jan 04, 2002 at 05:15:32AM -1000, Chang, Ellen wrote:
> 1. If two Update message are received back to back,  the first Update
> message includes 2 IP address prefixes in the NLRI field, the second Update
> message withdrawn one of the IP address prefix, how would a BGP speaker
> advertise the route to it's external peers?  Would the BGP speaker only
> advertise the route with the IP address prefix that's not withdrawed?  Or,
> would the BGP speaker advertise the first Update message first, then
> withdraw a route with the second Update message (same as the receiving order
> of the Update msgs)?

This is implementation dependant.  One would hope your implementation,
where it can, will minimize churn.  So, if you have not, for whatever
reason, advertised the prefix that is withdrawn, you shouldn't send it
in the first place.  This limits the flap to you and doesn't propagate
it to your downstream.

> 2. The spec indicates ' An UPDATE message that contains correct path
> attributes, but no NLRI,
>    shall be treated as a valid UPDATE message.'  
> Does it mean that the receiver of this message should advertise to its
> peers, because a valid Update message should be advertise to its peers?

Implementation dependant.  Why would someone do something like this?
In the case BGP-MPE, its because NLRI isn't in the traditional fields.
Its also possible that just normal path attributes are being passed
around to provide additional information, but thats outside the
scope of the protocol.

> 3. If a system receives a UPDATE message with MP Reachable or Unreachable
> NLRI (AFI indicate IPv4 address), would the system propagates/advertises or
> withdrawn the MP Reachable or Unreachable NLRI to its peers? 

The attributes are non-transitive.
Additonally, they should only be exchanged if the capabilities are
exchanged for them.

> 4.If system A and B are connected.  The system A initiates TCP connection to
> system B, then the system A transmits an Open message and waits for an Open
> message from the system B.  The system B transmits an Open message and a
> Keepalive message back to back.  Is the system A allow to receive a
> Keepalive message when it's still in the OpenSent state, because the system
> A has not send KeepAlive message to system B yet for it transition to
> OpenConfirm state?  But from the system B point of view, it received Open
> message from system A and it can send KeepAlive message.  Is there a
> conflict?  

There is no conflict.  If you examine things from a packet by packet
standpoint, the ordering is correct.  Considering that BGP is a stream
based protocol, this makes sense. :-)

> Ellen

-- 
Jeff Haas 
NextHop Technologies

From: "Chang, Ellen" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Need clarification on BGP4 specifications
Date: Fri, 4 Jan 2002 05:15:32 -1000 
Sender: [email-masked]

Hello:

I am resending few questions on BGP4.  Can anyone clarify them for me?

1. If two Update message are received back to back,  the first Update
message includes 2 IP address prefixes in the NLRI field, the second Update
message withdrawn one of the IP address prefix, how would a BGP speaker
advertise the route to it's external peers?  Would the BGP speaker only
advertise the route with the IP address prefix that's not withdrawed?  Or,
would the BGP speaker advertise the first Update message first, then
withdraw a route with the second Update message (same as the receiving order
of the Update msgs)?

2. The spec indicates ' An UPDATE message that contains correct path
attributes, but no NLRI,
   shall be treated as a valid UPDATE message.'  
Does it mean that the receiver of this message should advertise to its
peers, because a valid Update message should be advertise to its peers?

3. If a system receives a UPDATE message with MP Reachable or Unreachable
NLRI (AFI indicate IPv4 address), would the system propagates/advertises or
withdrawn the MP Reachable or Unreachable NLRI to its peers? 

4.If system A and B are connected.  The system A initiates TCP connection to
system B, then the system A transmits an Open message and waits for an Open
message from the system B.  The system B transmits an Open message and a
Keepalive message back to back.  Is the system A allow to receive a
Keepalive message when it's still in the OpenSent state, because the system
A has not send KeepAlive message to system B yet for it transition to
OpenConfirm state?  But from the system B point of view, it received Open
message from system A and it can send KeepAlive message.  Is there a
conflict?  

Thank you very much
Ellen

Date: Thu, 3 Jan 2002 11:20:24 -0500
From: Jeffrey Haas <[email-masked]>
To: Anand Kumar Goenka <[email-masked]>
Cc: [email-masked]
Subject: Re: ATOMIC AGGREGATE Doubts
Sender: [email-masked]

On Mon, Dec 24, 2001 at 11:35:21PM +0530, Anand Kumar Goenka wrote:
> I have some basic doubts regarding "ATOMIC AGGREGATE" attribute of BGP
> as
> mentioned in RFC1771.
> 
> Consider a case where a BGP speaker receives following overlapping
> routes from one of
> it's peers as follows.
> 150.1.0.0/16 - Path A
> 150.1.1.0/24 - Path B
> Local BGP speaker selects the less specific route (150.1.0.0/16) and
> advertises it to it's
> Peers with ATOMIC AGGREGATE attribute.
> 
> - Does the local BGP speaker adds the ATOMIC AGGREGATE in the Path
>   Attribute of  the less specific route (150.1.0.0/16) and then store
> that route in it's
>   local-RIB or it does so only while advertising the route to it's peers
> ??

That's an implementation decision.

> - What happens when the less specific routes (150.1.0.0/16)
>    is withdrawn by the BGP peer  which had earlier advertised that route
> to local BGP
>    speaker ?? Does the local BGP speaker need to re-install the more
> specific route
>    (150.1.1.0/24) in the  local-RIB and advertised to it's peers ??
> (this is assuming the
>    local  BGP speaker maintains the both less & more specific route in
> corresponding
>    Adj-RIB-In)

No.  BGP route selection shouldn't be use the presence or absence of
other routes as a selection criteria.

> - What happens when the more specific routes (150.1.1.0/24)
>    is withdrawn by the BGP peer  which had earlier advertised that route
> to local BGP
>    speaker ?? Does the local BGP speaker need to re-advertise the less
> specific route
>    (150.1.0.0/16) to it's peers without the ATOMIC ATTRIBUTE attribute
> ??

Yes, it should.

> Thanks,
> Anand Goenka.

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 2 Jan 2002 14:08:31 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: RJ Atkinson <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group notes from 12/13/01 meeting
Sender: [email-masked]

Wednesday, January 02, 2002, 1:44:52 PM, RJ Atkinson wrote:

>         It means I am on vacation.  An odd thing for me to do
> this time of year, I know, but nonetheless there it is.

I found myself having done the same odd thing recently.
Must be an infection or something :)

Alex.
P.S. Sorry for an off-topic.

Date: Wed, 02 Jan 2002 16:44:52 -0500
To: Alex Zinin <[email-masked]>
From: RJ Atkinson <[email-masked]>
Subject: Re: Working Group notes from 12/13/01 meeting
Cc: [email-masked]
Sender: [email-masked]

At 13:14 02/01/02, Alex Zinin wrote:

>Ran,
>
> I don't think I've seen you follow up on this.
> Does this mean a silent agreement with Sandy?

        It means I am on vacation.  An odd thing for me to do 
this time of year, I know, but nonetheless there it is.  For
my part, silence NEVER implies anything other than silence.

Ran

Date: Wed, 2 Jan 2002 10:14:10 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Working Group notes from 12/13/01 meeting
Sender: [email-masked]

Ran,

 I don't think I've seen you follow up on this.
 Does this mean a silent agreement with Sandy?
 Just like Sue, I'd love to see your analysis.

-- 
Alex Zinin

Thursday, December 20, 2001, 6:36:35 AM, [email-masked] wrote:

> According to the crypto folk down the hall, here are some sites that
> talk about the general vulnerability of prefix (hash[key,message]),
> suffix (hash[message,key]) and even envelope (hash[key1,message,key2])
> techniques, particularly compared to nested keyed crypto-hash
> techniques (twistycombination[hash,key,message]).

> Rogaway's talk at the 96 RSA Data Security Conference:  
> http://www.cs.ucdavis.edu/~rogaway/talks/mac-survey-19jan96.ps

> Gene Tsudik's paper on Keyed-MD4/5:

> http://citeseer.nj.nec.com/tsudik92message.html

> Bert Preneel and Paul Van Oorschot's evaluation of Tsudik's approach,
> demonstrating the weaknesses of keyed-MD4/5 for the prefix, suffix, and
> envelope methods:

> http://citeseer.nj.nec.com/preneel95mdxmac.html

> and more about the envelope method:

> http://citeseer.nj.nec.com/16659.html

> Bellare/Canetti/Krawczyk HMAC paper that references Preneel/Oorschot, but
> goes beyond by inventing NMACs and HMACs:

> http://citeseer.nj.nec.com/bellare96keying.html

> Hope this helps :-) (you'll see why the smiley when you look at the papers).

> --Sandy

> P.S.  Slide 22 of the Rogaway talk gives a summary table.