Subject: RE: iBGP route oscillation drafts
From: Dimitry Haskin <[email-masked]>
To: "'Enke Chen'" <[email-masked]>, Dimitry Haskin <[email-masked]>
Cc: [email-masked]
Date: Fri, 31 May 2002 17:14:38 -0400

Correct, it becomes a matter of route reflecting policy with all resulting
consequences.

> -----Original Message-----
> From: Enke Chen [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 4:54 PM
> To: Dimitry Haskin
> Cc: [email-masked]; [email-masked]
> Subject: Re: iBGP route oscillation drafts 
> 
> 
> Hi, Dimitry:
> Just one comment: once we have a mechanism in BGP to 
> advertise multiple paths,
> it would be possible for a RR to support multiple operating 
> modes, advertising
> a subset or fullset depending on the customer need. For example:
> 
>     L0 - advertise bestpath
>     L1 - advertise best in each neighbor AS
>     L2 - advertise all paths
> 
> It seems that the approach of RR (at L2) would converge with 
> the RS approach
> described in RFC 1863.
> 
> -- Enke
>       
> > Message-ID: 
> <[email-masked]>
> > From: Dimitry Haskin <[email-masked]>
> > To: [email-masked]
> > Subject: RE: iBGP route oscillation drafts
> > Date: Fri, 31 May 2002 14:12:33 -0400
> > 
> > Falks,
> > 
> > FWIW, I attempt to give a brief historical and 
> implementation perspective on
> > the subject at hand.
> > 
> > The concepts that both draft-walton and draft-wilfong put 
> forward have been
> > presented in rfc-1863 in much greater details (intellectual 
> property claims
> > in draft-wilfong are simply ridicules). This rfc has been actually
> > implemented and deployed in a large enterprise network. In 
> this particular
> > deployment use of RRs that pass only a single route to 
> their clients was not
> > an option since border routers needed to know all exit points to a
> > particular destination for the load sharing purpose.  Use 
> of a full iBGP
> > mesh was not an option either since there was many hundreds 
> if not thousand
> > border routers involved.
> > 
> > To summarize, rfc-1863 offered all benefits of the full 
> mesh iBGP, including
> > equal cost multipath support, without administrative burden 
> of the full mesh
> > peering.  On other hand, RR, as currently widely 
> implemented (rfc-2796),
> > offers better scalability as far as amount of routing 
> information passed
> > around at the expense of reduced functionality and 
> potential instability due
> > to the reduction of routing information.
> > 
> > It also should be mentioned that rfc-2796 is somewhat 
> easier to implement
> > than rfc-1863. Going back to draft-walton and 
> draft-wilfong, they are
> > seriously flawed or insufficient as far as the description 
> of mechanisms
> > that need to be implemented at reflecting routers and their 
> clients.  For
> > instance, it is not sufficient for a reflecting router to 
> simply include a
> > withdrawn route in the unreachable prefix list (as can be done with
> > rfc-2796) since a client would not be able to determine 
> which of multiple
> > routes advertised by RR to the withdrawn prefix is to be 
> actually withdrawn.
> > A correct mechanism is in rfc-1863 as other important 
> details. So indeed,
> > contrarily to some claims on the mailing list, to implement proposed
> > extensions would require procedural changes to both 
> reflecting routers and
> > their clients.
> > 
> > Regards,
> >   Dimitry
> 

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'Enke Chen'" <[email-masked]>, Dimitry Haskin <[email-masked]>
Cc: [email-masked]
Subject: Testing
Date: Fri, 31 May 2002 17:04:01 -0400
Sender: [email-masked]

Testing:
  Does this list work?

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Friday, May 31, 2002 4:54 PM
To: Dimitry Haskin
Cc: [email-masked]; [email-masked]
Subject: Re: iBGP route oscillation drafts 

Hi, Dimitry:
Just one comment: once we have a mechanism in BGP to advertise multiple
paths,
it would be possible for a RR to support multiple operating modes,
advertising
a subset or fullset depending on the customer need. For example:

    L0 - advertise bestpath
    L1 - advertise best in each neighbor AS
    L2 - advertise all paths

It seems that the approach of RR (at L2) would converge with the RS approach
described in RFC 1863.

-- Enke
      
> Message-ID: <[email-masked]>
> From: Dimitry Haskin <[email-masked]>
> To: [email-masked]
> Subject: RE: iBGP route oscillation drafts
> Date: Fri, 31 May 2002 14:12:33 -0400
> 
> Falks,
> 
> FWIW, I attempt to give a brief historical and implementation perspective
on
> the subject at hand.
> 
> The concepts that both draft-walton and draft-wilfong put forward have
been
> presented in rfc-1863 in much greater details (intellectual property
claims
> in draft-wilfong are simply ridicules). This rfc has been actually
> implemented and deployed in a large enterprise network. In this particular
> deployment use of RRs that pass only a single route to their clients was
not
> an option since border routers needed to know all exit points to a
> particular destination for the load sharing purpose.  Use of a full iBGP
> mesh was not an option either since there was many hundreds if not
thousand
> border routers involved.
> 
> To summarize, rfc-1863 offered all benefits of the full mesh iBGP,
including
> equal cost multipath support, without administrative burden of the full
mesh
> peering.  On other hand, RR, as currently widely implemented (rfc-2796),
> offers better scalability as far as amount of routing information passed
> around at the expense of reduced functionality and potential instability
due
> to the reduction of routing information.
> 
> It also should be mentioned that rfc-2796 is somewhat easier to implement
> than rfc-1863. Going back to draft-walton and draft-wilfong, they are
> seriously flawed or insufficient as far as the description of mechanisms
> that need to be implemented at reflecting routers and their clients.  For
> instance, it is not sufficient for a reflecting router to simply include a
> withdrawn route in the unreachable prefix list (as can be done with
> rfc-2796) since a client would not be able to determine which of multiple
> routes advertised by RR to the withdrawn prefix is to be actually
withdrawn.
> A correct mechanism is in rfc-1863 as other important details. So indeed,
> contrarily to some claims on the mailing list, to implement proposed
> extensions would require procedural changes to both reflecting routers and
> their clients.
> 
> Regards,
>   Dimitry

To: Dimitry Haskin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: iBGP route oscillation drafts 
Date: Fri, 31 May 2002 13:54:12 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Dimitry:
Just one comment: once we have a mechanism in BGP to advertise multiple paths,
it would be possible for a RR to support multiple operating modes, advertising
a subset or fullset depending on the customer need. For example:

    L0 - advertise bestpath
    L1 - advertise best in each neighbor AS
    L2 - advertise all paths

It seems that the approach of RR (at L2) would converge with the RS approach
described in RFC 1863.

-- Enke
      
> Message-ID: <[email-masked]>
> From: Dimitry Haskin <[email-masked]>
> To: [email-masked]
> Subject: RE: iBGP route oscillation drafts
> Date: Fri, 31 May 2002 14:12:33 -0400
> 
> Falks,
> 
> FWIW, I attempt to give a brief historical and implementation perspective on
> the subject at hand.
> 
> The concepts that both draft-walton and draft-wilfong put forward have been
> presented in rfc-1863 in much greater details (intellectual property claims
> in draft-wilfong are simply ridicules). This rfc has been actually
> implemented and deployed in a large enterprise network. In this particular
> deployment use of RRs that pass only a single route to their clients was not
> an option since border routers needed to know all exit points to a
> particular destination for the load sharing purpose.  Use of a full iBGP
> mesh was not an option either since there was many hundreds if not thousand
> border routers involved.
> 
> To summarize, rfc-1863 offered all benefits of the full mesh iBGP, including
> equal cost multipath support, without administrative burden of the full mesh
> peering.  On other hand, RR, as currently widely implemented (rfc-2796),
> offers better scalability as far as amount of routing information passed
> around at the expense of reduced functionality and potential instability due
> to the reduction of routing information.
> 
> It also should be mentioned that rfc-2796 is somewhat easier to implement
> than rfc-1863. Going back to draft-walton and draft-wilfong, they are
> seriously flawed or insufficient as far as the description of mechanisms
> that need to be implemented at reflecting routers and their clients.  For
> instance, it is not sufficient for a reflecting router to simply include a
> withdrawn route in the unreachable prefix list (as can be done with
> rfc-2796) since a client would not be able to determine which of multiple
> routes advertised by RR to the withdrawn prefix is to be actually withdrawn.
> A correct mechanism is in rfc-1863 as other important details. So indeed,
> contrarily to some claims on the mailing list, to implement proposed
> extensions would require procedural changes to both reflecting routers and
> their clients.
> 
> Regards,
>   Dimitry

To: Dimitry Haskin <[email-masked]>
Cc: "'John G. Scudder'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: iBGP route oscillation drafts 
Date: Fri, 31 May 2002 13:49:20 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Message-ID: <[email-masked]>
> From: Dimitry Haskin <[email-masked]>
> To: "'John G. Scudder'" <[email-masked]>,
> 	Dimitry Haskin <[email-masked]>
> Cc: [email-masked]
> Subject: RE: iBGP route oscillation drafts
> Date: Fri, 31 May 2002 15:57:22 -0400
> 
> I see.. Still, what draft-walton-bgp-route-oscillation-stop-00 tries to
> achieve can be done without introducing a path identifier or any
> modifications to existing attributes.

True - please see my suggested revision in an earlier post that would
avoid introducing the path identifier.

-- Enke

> 
> Dimitry
> 
> 
> > -----Original Message-----
> > From: John G. Scudder [mailto:[email-masked]]
> > Sent: Friday, May 31, 2002 3:21 PM
> > To: Dimitry Haskin
> > Cc: [email-masked]
> > Subject: RE: iBGP route oscillation drafts
> > 
> > 
> > At 2:12 PM -0400 5/31/02, Dimitry Haskin wrote:
> > >Going back to draft-walton and draft-wilfong, they are
> > >seriously flawed or insufficient as far as the description 
> > of mechanisms
> > >that need to be implemented at reflecting routers and their 
> > clients.  For
> > >instance, it is not sufficient for a reflecting router to 
> > simply include a
> > >withdrawn route in the unreachable prefix list (as can be done with
> > >rfc-2796) since a client would not be able to determine 
> > which of multiple
> > >routes advertised by RR to the withdrawn prefix is to be 
> > actually withdrawn.
> > 
> > One quick correction (or clarification). 
> > draft-walton-bgp-add-paths-00 quite explicitly addresses the "how to 
> > withdraw a path" issue.  This is done by including a path identifier. 
> > One does not even need to read the whole draft to understand this, 
> > it's made sufficiently clear in the abstract.
> > 
> > --John
> > 

From: Dimitry Haskin <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>, Dimitry Haskin <[email-masked]>
Cc: [email-masked]
Subject: RE: iBGP route oscillation drafts
Date: Fri, 31 May 2002 15:57:22 -0400
Sender: [email-masked]

I see.. Still, what draft-walton-bgp-route-oscillation-stop-00 tries to
achieve can be done without introducing a path identifier or any
modifications to existing attributes.

Dimitry

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 3:21 PM
> To: Dimitry Haskin
> Cc: [email-masked]
> Subject: RE: iBGP route oscillation drafts
> 
> 
> At 2:12 PM -0400 5/31/02, Dimitry Haskin wrote:
> >Going back to draft-walton and draft-wilfong, they are
> >seriously flawed or insufficient as far as the description 
> of mechanisms
> >that need to be implemented at reflecting routers and their 
> clients.  For
> >instance, it is not sufficient for a reflecting router to 
> simply include a
> >withdrawn route in the unreachable prefix list (as can be done with
> >rfc-2796) since a client would not be able to determine 
> which of multiple
> >routes advertised by RR to the withdrawn prefix is to be 
> actually withdrawn.
> 
> One quick correction (or clarification). 
> draft-walton-bgp-add-paths-00 quite explicitly addresses the "how to 
> withdraw a path" issue.  This is done by including a path identifier. 
> One does not even need to read the whole draft to understand this, 
> it's made sufficiently clear in the abstract.
> 
> --John
> 

Date: Fri, 31 May 2002 15:21:14 -0400
To: Dimitry Haskin <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: RE: iBGP route oscillation drafts
Cc: [email-masked]
Sender: [email-masked]

At 2:12 PM -0400 5/31/02, Dimitry Haskin wrote:
>Going back to draft-walton and draft-wilfong, they are
>seriously flawed or insufficient as far as the description of mechanisms
>that need to be implemented at reflecting routers and their clients.  For
>instance, it is not sufficient for a reflecting router to simply include a
>withdrawn route in the unreachable prefix list (as can be done with
>rfc-2796) since a client would not be able to determine which of multiple
>routes advertised by RR to the withdrawn prefix is to be actually withdrawn.

One quick correction (or clarification). 
draft-walton-bgp-add-paths-00 quite explicitly addresses the "how to 
withdraw a path" issue.  This is done by including a path identifier. 
One does not even need to read the whole draft to understand this, 
it's made sufficiently clear in the abstract.

--John

To: Alvaro Retana <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Comments on draft-walton-bgp-add-paths-00.txt
Date: Fri, 31 May 2002 11:35:58 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:

> Date: Tue, 28 May 2002 14:15:52 -0400 (EDT)
> From: Alvaro Retana <[email-masked]>
> To: Pedro Roque Marques <[email-masked]>
> Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>

[snip]

> 
> Both -walton- drafts have now been published:
> 
> http://www.ietf.org/internet-drafts/draft-walton-bgp-add-paths-00.txt
> http://www.ietf.org/internet-drafts/draft-walton-bgp-route-oscillation-stop-00.txt
> 
> -> The working group was asked to comment on a draft (the one quoted in
> -> the topic), however it is not clear to me on which proposals exactly
> -> are we supposed to comment upon.
> 
> Comments on those are welcome. ;-)
> 
> Alvaro.
> 

Here are some comments on draft-walton-bgp-add-paths-00.txt (some of the comments
have been communicated to the authors privately):

The draft specifies a way to advertise and withdraw a path for a prefix. IMO
per-path based update would require significant additional state (i.e., per-path
instead of per prefix) and memory in order to avoid spurious withdraws that we
experienced in the past.

We could avoid the additional state and simplify implementation if we treat
all the paths of a prefix as one unit in advertisement and withdraw. By "one
Unit" I mean that all paths are advertised (could be in multiple messages)
together, and are withdrawn by the NLRI.

This can be accomplished by introducing two additional bit flags for the
reachable NLRIs:

  o First Path Bit: When set, this indicates this is the first path for
                    the prefix, and any existing paths should be removed.
                    (This is similar to the current implicit replacement.)
                    When clear, there is no implicit replacement.

  o Last Path Bit:  When set, this indicates this is the last path, and
                    bestpath selection should be done immediately. When
                    clear, the bestpath selection may be deferred.
                    This would help avoid FIB churn.

Please note that with this approach there is no need to change the encoding
of unreachable NLRIs, and the path "Identifier" field in the draft is no
longer needed.

Comments?   -- Enke

From: Dimitry Haskin <[email-masked]>
To: [email-masked]
Subject: RE: iBGP route oscillation drafts
Date: Fri, 31 May 2002 14:12:33 -0400
Sender: [email-masked]

Falks,

FWIW, I attempt to give a brief historical and implementation perspective on
the subject at hand.

The concepts that both draft-walton and draft-wilfong put forward have been
presented in rfc-1863 in much greater details (intellectual property claims
in draft-wilfong are simply ridicules). This rfc has been actually
implemented and deployed in a large enterprise network. In this particular
deployment use of RRs that pass only a single route to their clients was not
an option since border routers needed to know all exit points to a
particular destination for the load sharing purpose.  Use of a full iBGP
mesh was not an option either since there was many hundreds if not thousand
border routers involved.

To summarize, rfc-1863 offered all benefits of the full mesh iBGP, including
equal cost multipath support, without administrative burden of the full mesh
peering.  On other hand, RR, as currently widely implemented (rfc-2796),
offers better scalability as far as amount of routing information passed
around at the expense of reduced functionality and potential instability due
to the reduction of routing information.

It also should be mentioned that rfc-2796 is somewhat easier to implement
than rfc-1863. Going back to draft-walton and draft-wilfong, they are
seriously flawed or insufficient as far as the description of mechanisms
that need to be implemented at reflecting routers and their clients.  For
instance, it is not sufficient for a reflecting router to simply include a
withdrawn route in the unreachable prefix list (as can be done with
rfc-2796) since a client would not be able to determine which of multiple
routes advertised by RR to the withdrawn prefix is to be actually withdrawn.
A correct mechanism is in rfc-1863 as other important details. So indeed,
contrarily to some claims on the mailing list, to implement proposed
extensions would require procedural changes to both reflecting routers and
their clients.

Regards,
  Dimitry

Date: Fri, 31 May 2002 10:47:38 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Idle hold/Active state in draft-ietf-idr-bgp4-17
Sender: [email-masked]

On Fri, May 31, 2002 at 06:01:10PM +0530, [email-masked] wrote:
> 2. What is the main difference between Active and Connect state? Is it that in
> Active it accepts connections from other BGP peers and in Connect it just
> connects to other BGP peers?

In the connect state, the bgp speaker also listens for incoming
connections.

-- 
Jeff Haas 
NextHop Technologies

From: [email-masked]
To: [email-masked]
Date: Fri, 31 May 2002 18:01:10 +0530
Subject: Idle hold/Active state in draft-ietf-idr-bgp4-17
Sender: [email-masked]

Hi
   I have a few queries/doubts regarding Idle hold and Active states

1. As per the draft,

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

   And also "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."

Here what is meant by IdleHoldTimer exceeds the local limit? Does it mean that
its value exceeds a certain configured limit or is it that when it expires. If
the later is true then the second quote does not seem much relevant.

And if the first is true then it is mentioned that if keep idle is set the state
remains in idle hold. In this situation do we restart the idlehold timer or just
wait for manual intervention only?

2. What is the main difference between Active and Connect state? Is it that in
Active it accepts connections from other BGP peers and in Connect it just
connects to other BGP peers?

Please let me know your response on this.

Thanks
Sarika

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

Date: Thu, 30 May 2002 14:33:21 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

Jeffrey Haas writes:

> On Thu, May 30, 2002 at 12:12:45PM -0700, Pedro Roque Marques wrote:
>> I believe the main question is which routers need to advertise
>> what. I've mentioned in previous e-mails, i beilieve that the
>> behaviour changes need to affect all the iBGP speakers of a mesh to
>> be effective.

> Not all iBGP speakers - only the reflecting agents, whether they be
> route reflectors or confederation routers.  Your EBGP speakers don't
> need the additional route instances.

I disagree.

There are 2 questions...

1) Do non reflecting ibgp speakers needs behaviour changes...
2) Do non reflecting ibgp speakers need to have availiable all best
per group paths in order to make a non-oscilating/stable decision.

I believe the answer to both questions is yes.

I think that 1) is very easy to prove... take an AS with a single RR
in the top level mesh. If non of the other speakers has any behaviour
change then your are left with the exact same end result that you have
today as ibgp mesh speakers withrawn their previous best routes.

2) is a question of if you believe that oscilation requires
reflection/confed to occur or not. Or of how complete the 'fix' to the
problem should be.

  Pedro.

Date: Thu, 30 May 2002 15:19:06 -0400
From: Jeffrey Haas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

On Thu, May 30, 2002 at 12:12:45PM -0700, Pedro Roque Marques wrote:
> I believe the main question is which routers need to advertise
> what. I've mentioned in previous e-mails, i beilieve that the
> behaviour changes need to affect all the iBGP speakers of a mesh to be
> effective.

Not all iBGP speakers - only the reflecting agents, whether they be
route reflectors or confederation routers.  Your EBGP speakers don't
need the additional route instances.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 30 May 2002 12:12:45 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>, [email-masked]
Subject: Re: iBGP route oscillation drafts 
Sender: [email-masked]

Enke Chen writes:

> Agreed. IMO, if we were to tackle this issue, we should try to find
> a complete solution (possibly with multiple deployment mode).

> As has been pointed out before, the original BGP spec (RFC 1771) has
> a solution, that is, advertising all external routes to IBGP peers
> although it does not specify the necessary protocol to do so. The RR
> and confed introduce abstraction/summarization. It seems that the
> probability of route oscillation increases as the level of this
> abstraction increases.

It sounds right.

> It is certtainly true that scalability is a major concern as more
> paths are advertised. However, not all networks are of the same size
> and not all netowrks have the route oscillation problem (or the same
> problem).  Once there is a mechanism (such as the one proposed) in
> BGP to advertise and withdraw multiple paths, I imagine there could
> be different levels of advertisement by the RR, depending on
> customer needs and controlled by configuration:

>     Level 0: Advertise only the best path (the default behavior)
   
>     Level 1: Level 0 + Advertise the best of each external neighbor
> AS.

>     Level 2: Level 1 + Advertise all eligible paths.

I don't think you ever need to advertise all eligible paths... only
the best of each neighbor AS.

I believe the main question is which routers need to advertise
what. I've mentioned in previous e-mails, i beilieve that the
behaviour changes need to affect all the iBGP speakers of a mesh to be
effective.

i.e. withing a ibgp cloud (a set of peers meshed together) all routers
need to know the best of all neighbor AS paths for path seletion to be
deterministic.

> Does this makes sense?

A gradual aproach seems to make sense.

  Pedro.

To: Pedro Roque Marques <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: iBGP route oscillation drafts 
Date: Thu, 30 May 2002 12:02:27 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:

> Date: Thu, 30 May 2002 11:01:20 -0700 (PDT)
> Message-Id: <[email-masked]>
> From: Pedro Roque Marques <[email-masked]>
> To: "John G. Scudder" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: iBGP route oscillation drafts
> In-Reply-To: <p05111a15b91be5c0027c@[171.69.182.155]>
> References: <[email-masked]>
> 	<[email-masked]>
> 	<p05111a15b91be5c0027c@[171.69.182.155]>
> 
> John G Scudder writes:
> 
> > My take on the subject is that while theoretical protocol
> > correctness is an admirable goal, it's not more important than
> > scalability.  Protocol scalability plus _practical_ protocol
> > correctness is more important, IMO.
> 
> Yes, but the problem of the 'pratical'/'realistic' criteria is that it
> is not static... it may change has applications do change or just
> because a given scenario was not considered.

Agreed. IMO, if we were to tackle this issue, we should try to find a
complete solution (possibly with multiple deployment mode).

As has been pointed out before, the original BGP spec (RFC 1771) has a
solution, that is, advertising all external routes to IBGP peers although
it does not specify the necessary protocol to do so. The RR and confed
introduce abstraction/summarization. It seems that the probability of route
oscillation increases as the level of this abstraction increases.

It is certtainly true that scalability is a major concern as more paths
are advertised. However, not all networks are of the same size and not
all netowrks have the route oscillation problem (or the same problem).
Once there is a mechanism (such as the one proposed) in BGP to advertise
and withdraw multiple paths, I imagine there could be different levels of
advertisement by the RR, depending on customer needs and controlled by
configuration:

    Level 0: Advertise only the best path (the default behavior)
   
    Level 1: Level 0 + Advertise the best of each external neighbor AS.

    Level 2: Level 1 + Advertise all eligible paths.

A non-RR could also be in Level 0, or Level 1 for advertising its external
routes to IBGP.

The proposed solution in draft-walton-etc seems to fit the Level 1
advertisement (for both RR and non-RR).

It seems that the scenario described in draft-wilfong-etc can be
addressed by Level 2 on RR and Level 1 on non-RR.

Does this makes sense?

-- Enke

Date: Thu, 30 May 2002 14:55:24 -0400
From: Gordon Wilfong <[email-masked]>
To: Anindya Basu <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>, Brijesh Kumar <[email-masked]>, [email-masked], anindyabasu <[email-masked]>, [email-masked], [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

Anindya,

I apologize, but I think I might have 
mislead you somewhat.  The example we have is of 
a system that suffers from persistent route
oscillations when MEDs are compared, but that converges
when MEDs are ignored.  Thus in my terminology, this system
has a MED induced oscillation problem.  I'm not sure however
if this is what others mean by the MED induced
oscillation problem.

- Gordon

Anindya Basu wrote:
> 
> John, in addition to Bruce's comments, here are my $0.02.
> -Anindya
> 
> "John G. Scudder" wrote:
> > The MED problem is real enough.  However, as we've been discussing in
> > a different thread, your proposal is more far-reaching than just
> > addressing [3].  Specifically:
> >
> > At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
> > >However, our aim was to address the elimination of any possible kind
> > >of oscillation in I-BGP, MED-induced or not, persistent or not.
> >
> > That's laudable in the abstract but inevitably leads to the
> > requirement that you advertise more additional routes than required
> > to fix specifically [3].
> 
> The comment you refer to here was made in the context of Alvaro's
> comment that their solution was designed only to eliminate MED-induced
> oscillations. We now have an example where the oscillations are
> MED-induced, which our solution fixes but the solution proposed by
> Alvaro
> et. al. does not. In that sense, sending around the extra routes is
> *necessary* to eliminate even MED-induced oscillations alone.
> 
> > My take on the subject is that while theoretical protocol correctness
> > is an admirable goal, it's not more important than scalability.
> > Protocol scalability plus _practical_ protocol correctness is more
> > important, IMO.
> >
> > As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
> > >Admittedly, the configuration in Figure 1 is not likely in a
> > >reasonable network.
> >
> > I think the IDR working group should be primarily concerned with
> > reasonable networks.  Fixing problems for unreasonable (or
> > hypothetical) networks seems fine as long as it doesn't conflict with
> > the operation and scaling of reasonable ones.
> >
> > Do you disagree?
> 
> In principle, I do agree with what you say. However, the question is
> what we mean by _practical_ protocol correctness, as you call it.
> Moreover, I think we pointed out in an earlier mail (and I quote):
> 
> "We feel that our example is no less real than the one outlined in the
> McPherson I-D since that example also critically relies on a route
> reflector preferring a route through the client of a different route
> reflector (due to IGP metrics)."
> 
> Also, there may be some danger in equating "real" configurations with
> configurations that are "safe" (i.e., that do not produce oscillations).
> We cannot say for sure that a "real" configuration (produced by using
> heuristics or rules of thumb) will never produce MED-induced (or any
> other kinds of) oscillations. Finally, detecting configurations that are
> safe is NP-hard, as we have shown in the SIGCOMM paper (reference [5],
> soon to be available from the ACM SIGCOMM website).

From: "Abarbanel, Benjamin" <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>, Anindya Basu <[email-masked]>
Cc: Brijesh Kumar <[email-masked]>, [email-masked], anindyabasu <[email-masked]>, [email-masked], [email-masked]
Subject: RE: iBGP route oscillation drafts
Date: Thu, 30 May 2002 14:28:40 -0400
Sender: [email-masked]

I have been following this thread on iBGP route oscillation drafts and 
one fundamental thought comes to mind. Each solution in its use will/might
work and solve the problem but the problem in a general sense is still
there. What I mean, if the route reflectors or Confederation topology is 
configured slightly off the expected "realistic" case route oscillation will
return. So the question whether we should consider hypothetical or realistic
network topologies is a false one. Why, the minute an operator
mis-configures
his network he ends up with the "hypothetical network" and during the time
it takes him/her to figure out what happened his routers are
oscillating/churning their routes.

I dont think these solutions will scale or affort an answer that will solve
this rather crucial issue. Network meltdown will commense assuming the 
oscillation condition is not repaired in a timely manner. I propose another
approach to the problem. 

Dont try to fix the problem, try to control it in software.

I have some ideas in mind on how to better control route oscillations. I
dont
know if a draft is a way to go or just casual discussions on the list. Any
suggestions are welcomed?

Regards,
Ben

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 12:54 PM
To: Anindya Basu
Cc: Brijesh Kumar; [email-masked]; anindyabasu; [email-masked];
[email-masked]
Subject: Re: iBGP route oscillation drafts

At 12:32 PM -0400 5/30/02, Anindya Basu wrote:
>The comment you refer to here was made in the context of Alvaro's
>comment that their solution was designed only to eliminate MED-induced
>oscillations. We now have an example where the oscillations are
>MED-induced, which our solution fixes but the solution proposed by
>Alvaro
>et. al. does not. In that sense, sending around the extra routes is
>*necessary* to eliminate even MED-induced oscillations alone.

OK, can you share your example?

(It would be more interesting if it corresponds to a somewhat 
realistic network configuration.)

>In principle, I do agree with what you say. However, the question is
>what we mean by _practical_ protocol correctness, as you call it.

Fair enough.  I mean correctness of the protocol when the problem 
domain is constrained to networks designed according to various 
well-known guidelines (heuristics, rules of thumb, etc).  One such 
guideline can be found in RFC 2796:

    In general, the route reflection topology should congruent
    with the network topology

Clearly the example in your draft doesn't conform to this guideline.

>Moreover, I think we pointed out in an earlier mail (and I quote):
>
>"We feel that our example is no less real than the one outlined in the
>McPherson I-D since that example also critically relies on a route
>reflector preferring a route through the client of a different route
>reflector (due to IGP metrics)."

You think it's "no less real".  Others (me included, according to the 
criteria stated above) do think it's "less real".  Shall we agree to 
disagree?

--John

Date: Thu, 30 May 2002 11:01:20 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

John G Scudder writes:

> My take on the subject is that while theoretical protocol
> correctness is an admirable goal, it's not more important than
> scalability.  Protocol scalability plus _practical_ protocol
> correctness is more important, IMO.

Yes, but the problem of the 'pratical'/'realistic' criteria is that it
is not static... it may change has applications do change or just
because a given scenario was not considered.

I might be wrong of course and it may be that the only pratical
scenarios we will ever find of this problem are the ones documented in
the McPherson draft... still it would be nice to have stronger
guarantees than what we have currently.

If we where talking about an operational change or a small change that
is simple to implement (in both code and networks), dealing with the
known corner cases, would probably be a consensual thing to do.

However since we are talking about pretty significant changes being
proposed i expect there would be a bit more of controversy in the WG
concerning the cost/impact of the proposed fix vs theoretical/pratical
aspects... i.e. if the cost of deploying a solution is high it would
be really nice if it could fix the root cause of the problem instead
of the known symptoms.

  Pedro.

Date: Thu, 30 May 2002 12:54:16 -0400
To: Anindya Basu <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: iBGP route oscillation drafts
Cc: Brijesh Kumar <[email-masked]>, [email-masked], anindyabasu <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 12:32 PM -0400 5/30/02, Anindya Basu wrote:
>The comment you refer to here was made in the context of Alvaro's
>comment that their solution was designed only to eliminate MED-induced
>oscillations. We now have an example where the oscillations are
>MED-induced, which our solution fixes but the solution proposed by
>Alvaro
>et. al. does not. In that sense, sending around the extra routes is
>*necessary* to eliminate even MED-induced oscillations alone.

OK, can you share your example?

(It would be more interesting if it corresponds to a somewhat 
realistic network configuration.)

>In principle, I do agree with what you say. However, the question is
>what we mean by _practical_ protocol correctness, as you call it.

Fair enough.  I mean correctness of the protocol when the problem 
domain is constrained to networks designed according to various 
well-known guidelines (heuristics, rules of thumb, etc).  One such 
guideline can be found in RFC 2796:

    In general, the route reflection topology should congruent
    with the network topology

Clearly the example in your draft doesn't conform to this guideline.

>Moreover, I think we pointed out in an earlier mail (and I quote):
>
>"We feel that our example is no less real than the one outlined in the
>McPherson I-D since that example also critically relies on a route
>reflector preferring a route through the client of a different route
>reflector (due to IGP metrics)."

You think it's "no less real".  Others (me included, according to the 
criteria stated above) do think it's "less real".  Shall we agree to 
disagree?

--John

Date: Thu, 30 May 2002 12:32:25 -0400
From: Anindya Basu <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: Brijesh Kumar <[email-masked]>, [email-masked], anindyabasu <[email-masked]>, [email-masked], [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

John, in addition to Bruce's comments, here are my $0.02.
-Anindya

"John G. Scudder" wrote:
> The MED problem is real enough.  However, as we've been discussing in
> a different thread, your proposal is more far-reaching than just
> addressing [3].  Specifically:
> 
> At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
> >However, our aim was to address the elimination of any possible kind
> >of oscillation in I-BGP, MED-induced or not, persistent or not.
> 
> That's laudable in the abstract but inevitably leads to the
> requirement that you advertise more additional routes than required
> to fix specifically [3].

The comment you refer to here was made in the context of Alvaro's 
comment that their solution was designed only to eliminate MED-induced
oscillations. We now have an example where the oscillations are 
MED-induced, which our solution fixes but the solution proposed by
Alvaro
et. al. does not. In that sense, sending around the extra routes is 
*necessary* to eliminate even MED-induced oscillations alone. 

> My take on the subject is that while theoretical protocol correctness
> is an admirable goal, it's not more important than scalability.
> Protocol scalability plus _practical_ protocol correctness is more
> important, IMO.
> 
> As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
> >Admittedly, the configuration in Figure 1 is not likely in a
> >reasonable network.
> 
> I think the IDR working group should be primarily concerned with
> reasonable networks.  Fixing problems for unreasonable (or
> hypothetical) networks seems fine as long as it doesn't conflict with
> the operation and scaling of reasonable ones.
> 
> Do you disagree?

In principle, I do agree with what you say. However, the question is
what we mean by _practical_ protocol correctness, as you call it.
Moreover, I think we pointed out in an earlier mail (and I quote):

"We feel that our example is no less real than the one outlined in the
McPherson I-D since that example also critically relies on a route
reflector preferring a route through the client of a different route
reflector (due to IGP metrics)."

Also, there may be some danger in equating "real" configurations with
configurations that are "safe" (i.e., that do not produce oscillations).
We cannot say for sure that a "real" configuration (produced by using
heuristics or rules of thumb) will never produce MED-induced (or any
other kinds of) oscillations. Finally, detecting configurations that are
safe is NP-hard, as we have shown in the SIGCOMM paper (reference [5],
soon to be available from the ACM SIGCOMM website).

Date: Thu, 30 May 2002 12:24:32 -0400
To: "Natale, Jonathan" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: RE:
Cc: "'f b shepherd'" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:20 PM -0400 5/30/02, Natale, Jonathan wrote:
>If this is caused by not having the deterministic med command

It's not.

--John

From: "Natale, Jonathan" <[email-masked]>
To: "'f b shepherd'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: 
Date: Thu, 30 May 2002 12:20:37 -0400
Sender: [email-masked]

If this is caused by not having the deterministic med command, then why not
roll the command's functionality into the new bgp draft?  I consider this
command to be a bug fix--where does RFC1771 say that non-deterministic med
behavior is ok anyway?  I think it does not, but obviously it (like many bgp
behaviors) needs to be clarified.  Why invent a new command and tell
everyone that they should always turn it on, instead of just putting it on
by default or just on always?

-----Original Message-----
From: f b shepherd [mailto:[email-masked]] 
Sent: Thursday, May 30, 2002 11:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: 

Dear John,

Personally I agree with you. 
It is not my (I think our) view that protocol correctness
a priori outweighs any (including scalability) of the
important properties that a protocol should possess in practice.
One can take the view that our I-D and paper is meant
to help analyze the tradeoffs in achieving the different goals.

At the same time, BGP and inter-domain routing has taken on
an importance in traffic engineering (and network design) where it is
a reasonable and worthwhile endeavour to put in place
some fundamentals which would be important in understanding 
better its behaviour.  I feel such models will prove important
especially in an effort to understand the cause-and-effect of
certain 1-time events or  policy changes in a network.
For instance, my view is that similar ``fundamentals'' were already 
well-established in the 50's
and 60's  for circuit-switched and OSPF-like networks
by Ford, Bellman, Fulkerson, and even Dantzig etc.

In  this sense, it is useful to think of our work
as an exploration of the route oscillation
problem. IMO this problem  is already more complex than 
it appears on the surface. Dismissing examples as unrealistic is
fair enough although it does also beg for an understanding of the line
between real and not (Im sure the people on this
mailing list are infinitely more aware of this than I).
Also, as Anindya pointed out, our own aims were to explore possible
solutions
for all  configurations.

Regards,
Bruce

----
At 9:39 AM -0400 5/30/02, Anindya Basu wrote:
...
>Brijesh Kumar wrote:
>>2. I am curious to know if the problem is existent in real networks 
>>beyond pathological scenario depicted in the draft as to merit 
>>announcements and storage of multiple routes at the routers. I find 
>>it too drastic a proposal for a problem whose existence/severity 
>>seems to be based on a simple paper scenario (unless I see 
>>reference 5). After all, it proposes to do away the most 
>>stabilizing BGP/distance vector protocol rule that a peer will 
>>advertise only its best route to its neighbour.
>
>in case you have completely missed it (though it is in the references),
>the original problem was outlined in an ID (reference [3]) by McPherson
>et. al. and actually stems from a cisco field report called "Endless BGP
>Convergence Problem in Cisco IOS Software Releases", October 10, 2000.
>is that real enough?

The MED problem is real enough.  However, as we've been discussing in 
a different thread, your proposal is more far-reaching than just 
addressing [3].  Specifically:

At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
>However, our aim was to address the elimination of any possible kind 
>of oscillation in I-BGP, MED-induced or not, persistent or not.

That's laudable in the abstract but inevitably leads to the 
requirement that you advertise more additional routes than required 
to fix specifically [3].

My take on the subject is that while theoretical protocol correctness 
is an admirable goal, it's not more important than scalability. 
Protocol scalability plus _practical_ protocol correctness is more 
important, IMO.

As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
>Admittedly, the configuration in Figure 1 is not likely in a 
>reasonable network.

I think the IDR working group should be primarily concerned with 
reasonable networks.  Fixing problems for unreasonable (or 
hypothetical) networks seems fine as long as it doesn't conflict with 
the operation and scaling of reasonable ones.

Do you disagree?

Regards,

- --John

------- End of Forwarded Message

To: [email-masked]
Cc: [email-masked]
Subject: 
Date: Thu, 30 May 2002 11:44:35 -0400
From: f b shepherd <[email-masked]>
Sender: [email-masked]

Dear John,

Personally I agree with you. 
It is not my (I think our) view that protocol correctness
a priori outweighs any (including scalability) of the
important properties that a protocol should possess in practice.
One can take the view that our I-D and paper is meant
to help analyze the tradeoffs in achieving the different goals.

At the same time, BGP and inter-domain routing has taken on
an importance in traffic engineering (and network design) where it is
a reasonable and worthwhile endeavour to put in place
some fundamentals which would be important in understanding 
better its behaviour.  I feel such models will prove important
especially in an effort to understand the cause-and-effect of
certain 1-time events or  policy changes in a network.
For instance, my view is that similar ``fundamentals'' were already 
well-established in the 50's
and 60's  for circuit-switched and OSPF-like networks
by Ford, Bellman, Fulkerson, and even Dantzig etc.

In  this sense, it is useful to think of our work
as an exploration of the route oscillation
problem. IMO this problem  is already more complex than 
it appears on the surface. Dismissing examples as unrealistic is
fair enough although it does also beg for an understanding of the line
between real and not (Im sure the people on this
mailing list are infinitely more aware of this than I).
Also, as Anindya pointed out, our own aims were to explore possible solutions
for all  configurations.

Regards,
Bruce

----
At 9:39 AM -0400 5/30/02, Anindya Basu wrote:
...
>Brijesh Kumar wrote:
>>2. I am curious to know if the problem is existent in real networks 
>>beyond pathological scenario depicted in the draft as to merit 
>>announcements and storage of multiple routes at the routers. I find 
>>it too drastic a proposal for a problem whose existence/severity 
>>seems to be based on a simple paper scenario (unless I see 
>>reference 5). After all, it proposes to do away the most 
>>stabilizing BGP/distance vector protocol rule that a peer will 
>>advertise only its best route to its neighbour.
>
>in case you have completely missed it (though it is in the references),
>the original problem was outlined in an ID (reference [3]) by McPherson
>et. al. and actually stems from a cisco field report called "Endless BGP
>Convergence Problem in Cisco IOS Software Releases", October 10, 2000.
>is that real enough?

The MED problem is real enough.  However, as we've been discussing in 
a different thread, your proposal is more far-reaching than just 
addressing [3].  Specifically:

At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
>However, our aim was to address the elimination of any possible kind 
>of oscillation in I-BGP, MED-induced or not, persistent or not.

That's laudable in the abstract but inevitably leads to the 
requirement that you advertise more additional routes than required 
to fix specifically [3].

My take on the subject is that while theoretical protocol correctness 
is an admirable goal, it's not more important than scalability. 
Protocol scalability plus _practical_ protocol correctness is more 
important, IMO.

As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
>Admittedly, the configuration in Figure 1 is not likely in a 
>reasonable network.

I think the IDR working group should be primarily concerned with 
reasonable networks.  Fixing problems for unreasonable (or 
hypothetical) networks seems fine as long as it doesn't conflict with 
the operation and scaling of reasonable ones.

Do you disagree?

Regards,

- --John

------- End of Forwarded Message

Date: Thu, 30 May 2002 10:37:10 -0400
To: Anindya Basu <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: iBGP route oscillation drafts
Cc: Brijesh Kumar <[email-masked]>, [email-masked], anindyabasu <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 9:39 AM -0400 5/30/02, Anindya Basu wrote:
...
>Brijesh Kumar wrote:
>>2. I am curious to know if the problem is existent in real networks 
>>beyond pathological scenario depicted in the draft as to merit 
>>announcements and storage of multiple routes at the routers. I find 
>>it too drastic a proposal for a problem whose existence/severity 
>>seems to be based on a simple paper scenario (unless I see 
>>reference 5). After all, it proposes to do away the most 
>>stabilizing BGP/distance vector protocol rule that a peer will 
>>advertise only its best route to its neighbour.
>
>in case you have completely missed it (though it is in the references),
>the original problem was outlined in an ID (reference [3]) by McPherson
>et. al. and actually stems from a cisco field report called "Endless BGP
>Convergence Problem in Cisco IOS Software Releases", October 10, 2000.
>is that real enough?

The MED problem is real enough.  However, as we've been discussing in 
a different thread, your proposal is more far-reaching than just 
addressing [3].  Specifically:

At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
>However, our aim was to address the elimination of any possible kind 
>of oscillation in I-BGP, MED-induced or not, persistent or not.

That's laudable in the abstract but inevitably leads to the 
requirement that you advertise more additional routes than required 
to fix specifically [3].

My take on the subject is that while theoretical protocol correctness 
is an admirable goal, it's not more important than scalability. 
Protocol scalability plus _practical_ protocol correctness is more 
important, IMO.

As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
>Admittedly, the configuration in Figure 1 is not likely in a 
>reasonable network.

I think the IDR working group should be primarily concerned with 
reasonable networks.  Fixing problems for unreasonable (or 
hypothetical) networks seems fine as long as it doesn't conflict with 
the operation and scaling of reasonable ones.

Do you disagree?

Regards,

--John

Date: Thu, 30 May 2002 09:39:06 -0400
From: Anindya Basu <[email-masked]>
To: Brijesh Kumar <[email-masked]>
Cc: [email-masked], anindyabasu <[email-masked]>, [email-masked], [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

answers inline.

Brijesh Kumar wrote:
> 
> I have a few questions about this draft. As I haven't caught up with all mails, it may be possible these
> have been discussed earlier.
> 
> 1. It quotes two references [4] and [5] as Sigcomm 2002 submitted papers as a proof that the use of route
> reflectors alone in the absence of MEDs can lead to persistent or transient route oscillations (proof in 4)
> and whether or not route reflectors are used, configurations using the MED attribute can lead to transient 
> route oscillations (proof in 5). Also, most of the assertions in this draft are based on proof in [5]. Since 
> SIGCOMM 2002 is in August, I would like to know if these referenced drafts are in some public places, and 
> also if they have been accepted for publication.

both the references quoted have been accepted for publication in sigcomm
2002 (which is exactly what the references say). they will hopefully be
available from the sigcomm website after we turn in the final versions
on june 21.

> 2. I am curious to know if the problem is existent in real networks beyond pathological scenario depicted in
> the draft as to merit announcements and storage of multiple routes at the routers. I find it too drastic a 
> proposal for a problem whose existence/severity seems to be based on a simple paper scenario (unless I
> see reference 5). After all, it proposes to do away the most stabilizing BGP/distance vector protocol rule
> that a peer will advertise only its best route to its neighbour.

in case you have completely missed it (though it is in the references),
the original problem was outlined in an ID (reference [3]) by McPherson
et. al. and actually stems from a cisco field report called "Endless BGP
Convergence Problem in Cisco IOS Software Releases", October 10, 2000.
is that real enough?

cheers,
-anindya

p.s. and next time, please do put in line breaks in your emails, it
makes parsing so much easier :-)

> 
> cheers,
> 
> --brijesh
> 
> -----------------------
> disclaimer: The views expressed do not necessarily represent the views of my organization.
>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-restart-05.txt
Date: Thu, 30 May 2002 07:27:42 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Graceful Restart Mechanism for BGP
	Author(s)	: S. Sangli, Y. Rekhter, R. Fernando, 
                          J. Scudder, E. Chen
	Filename	: draft-ietf-idr-restart-05.txt
	Pages		: 10
	Date		: 29-May-02
	
This document proposes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence
information.  A new BGP capability, termed 'Graceful Restart
Capability', is defined which would allow a BGP speaker to express
its ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information
across a TCP transport reset.
The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state
during BGP restart and those without (although the latter need to
implement only a subset of the mechanisms described in this
document).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-05.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-restart-05.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-restart-05.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-restart-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 29 May 2002 18:04:17 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Anindya Basu <[email-masked]>, Alvaro Retana <[email-masked]>, Gordon Wilfong <[email-masked]>, "John G. Scudder" <[email-masked]>, Pramod Koppol <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], anindyabasu <[email-masked]>, [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

Jeffrey Haas writes:

> In addition to your comments about *which* routes to distribute,
> namely only those that get to the point of the MED comparison
> portion of route selection (i.e. it has passed Local_Pref and
> AS_PATH length comparisons) it is only necessary to distribute your
> best MEDs, not all of them.

Jeff,

Yes but... i believe there is an important point that Anindya (et al)
make with the draft/discussion...

In the route oscilation document, the problems apear characterized as
being trigered by RR and confed usage however this isn't strictly the
cause. If you take a look at the 'Route Reflection and Type I Churn'
for instance that is depicted in the oscilation draft, the oscilation
occurs between two iBGP peers.

The fact that they are RR servers isn't really the main factor
here... it just makes for a 'realistic'/understandable scenario where
this can happen. But the fact is that the problem is caused because
you can have paths such that router A makes a selection based on the
presence path that it receives from an ibgp neighbor which then is
withrawn as a result of this selection.

It is easy to reproduce the problem just with ibgp if you use a policy
that tweaks local-pref (as an example) on a route received through
ibgp.

One may argue that this isn't 'realistic' and thus irrelevant...
However a counter argument may be made that the RR and confed problems
that are documented in the route oscilation draft are not guaranteed
to be the only ones existing in real networks.

While it may be possible to solve this problem by just advertising
routes that are the 'best in group' i.e. best from the same AS (as
Alvaro suggest) it seems necessary to address it whenever RR/confed is
present or not (as Anindya points out).

That said, the problem is in the details...
I'm fairly sceptic that the current -walton drafts describe the full
set of mechanisms necessary. Plus one would need to access the cost of
that from an operational point of view.

Comparing vs always-compare-med and/or vs 'ibgp dampening' or any
other sort of mechanism that slows down the speed of the transitions.

  Pedro.

Date: Wed, 29 May 2002 12:14:40 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Comments on ibgp oscilation draft(s).
Sender: [email-masked]

Alvaro et all,

In the 'route-oscillation-stop' draft your proposal specifies that a
    "route reflector [4] or
     a sub-AS border router in a BGP confederation [5] MUST advertise the
     following to its IBGP or confederation peers"

You do not specify any changes to the behaviour of other BGP speakers
in the ibgp domain. As such one could assume that there are no
modifications to their behaviour however i don't really understand how
can that be the case.

Currently, implementations send a withrawn of any previously
advertised path to an iBGP speaker when the best path changes so that
the best path is now the path received from the neighbor in question.

If R1 is iBGP neighbor of RR1, when receiving a path from RR1 that RC1
considers best that any previously know path it will withdraw it's
advertised path.

- I assume, but this needs to be specified, that you propose to change
this behaviour so that R1 will now advertise via the new ADD_PATH
extensions it's previous path (you need to specify which
paths/conditions apply here).

If this doesn't happen then all rr clients will withrawn their
paths... and you get back into having the same information that you
had before the ADD_PATH extension, correct ?

- The proposed extensions advertise not-best paths between iBGP
  peers. However iBGP does not have a loop avoidance mechanism. i.e. a
  peer can't know it is listening back to an advertisement that it
  sourced (in iBGP you don't advertise iBGP routes so the problem
  couldn't occur).

  I believe that you need to address this issue... it would help to
  understand how a path that is not best gets withrawn out of the
  iBGP.

Date: Wed, 29 May 2002 14:39:22 -0400
From: Jeffrey Haas <[email-masked]>
To: Anindya Basu <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, Gordon Wilfong <[email-masked]>, "John G. Scudder" <[email-masked]>, Pramod Koppol <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], anindyabasu <[email-masked]>, [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

On Wed, May 29, 2002 at 01:26:10PM -0400, Anindya Basu wrote:
> However, our aim was
> to address the elimination of any possible kind of oscillation
> in I-BGP, MED-induced or not, persistent or not.

Gentlemen,

Its worth pointing out that the solution in your ID has been discussed
a few times and is pretty much understood to be "a right answer",
just one that scales poorly.  Besides the ID's that Alvaro published
to distribute multiple paths, RFC 1863 originally documented a method
meant for Route Servers to exchange multiple route instances.  This
RFC also had other things which weren't necessarily useful.  Obviously,
this hasn't been implemented.

In addition to your comments about *which* routes to distribute,
namely only those that get to the point of the MED comparison
portion of route selection (i.e. it has passed Local_Pref and
AS_PATH length comparisons) it is only necessary to distribute your
best MEDs, not all of them.

> -Anindya, Gordon and Bruce

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 29 May 2002 13:26:10 -0400
From: Anindya Basu <[email-masked]>
To: Alvaro Retana <[email-masked]>
Cc: Gordon Wilfong <[email-masked]>, "John G. Scudder" <[email-masked]>, Pramod Koppol <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], anindyabasu <[email-masked]>, [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

Alvaro,

You indicate that the cluster-list selection rule is an existing
solution to the oscillation problem in our example. Reading the
references that you provided us, it is our understanding that the
cluster-list selection rule is applied *after* the IGP metric rule
(assuming the rules are applied in the order listed). If so, the
example we have continues to oscillate since the IGP metric rule
breaks the tie and the cluster-list selection rule is never applied.

If, on the other hand, the cluster-list selection rule is applied
before the IGP metric rule, the original example in McPherson
et. al. does not undergo persistent oscillations. Thus, there is no
churn problem at all. If  these interpretations are correct, then the
claim from your email: "(2) a solution already exists to this problem"
is not clear to us.

Next, you say that the example we have "is not real". While we
recognize your experience in this area, we feel that our example is no
less real than the one outlined in the McPherson I-D since that
example also critically relies on a route reflector preferring a route
through the client of a different route reflector (due to IGP
metrics). 

Finally, you say that your solution was addressing "the MED churn
issue". We do not doubt that for some appropriate definition of
the MED churn problem, your solution works. However, our aim was
to address the elimination of any possible kind of oscillation
in I-BGP, MED-induced or not, persistent or not.

Thanks,
-Anindya, Gordon and Bruce

Alvaro Retana wrote:
> 
> On Tue, 28 May 2002, Gordon Wilfong wrote:
> 
> Gordon:
> 
> -> In looking over the approach in draft-walton-etc, it seems that there
> -> is a problem.  For instance, if you look at the example in
> -> draft-wilfong-etc, you'll notice that the method in draft-walton-etc
> -> fails to stop the persistent route oscillations in that example.
> 
> The only example I found in your document is:
> 
>              ********************          ***********************
>               *                  *          *                     *
>               *                  *          *                     *
>             [RR1]****[RR2]*****[RR3]        * [RR1]    [RR2]    [RR3]
>               *        *         *          *   * *      * *      *
>               *        *         *          *   *   *1   *   *1   *
>               *        *         *          *   *5    *  *5   *   *5
>               *        *         *          *   *      * *      * *
>             [C1]     [C2]      [C3]         **[C1]     [C2]     [C3]
>               *        *         *
>               *        *         *
>               ********[R]*********
> 
>                  BGP sessions                Physical links
> 
> You wrote: "It is straightforward to check for example that RR1 will
> constantly switch between choosing the route to R through its client C1
> and through the client C2 depending on which route RR2 announces to RR1."
> 
> If you look at the picture, things *may* oscillate because of the IGP
> metrics you chose...  BUT you missed the already deployed solution:
> choosing the path with the shortest cluster-list.  It doesn't matter what
> the other RRs say, RR1 will always chose the path through its client (no
> cluster-list = length of 0).
> 
> To be honest, I don't know why this extension hasn't been documented (as
> in a draft) before...I'll write something up and send it out in the next
> couple of days.  However, the solution has been deployed for years...just
> as a sample, take a look at:
> 
> http://www.cisco.com/warp/public/459/25.shtml
> http://www.juniper.net/techpubs/software/junos53/swconfig53-routing/html/protocols-overview4.html
> 
> You go further to say: "Admittedly, the configuration in Figure 1 is not
> likely in a reasonable network.  The point though is that such behavior is
> possible with route reflectors..."
> 
> So...it doens't matter that we don't cover this case because (1) it's not
> real, (2) a solution already exists and (3) that's not the problem we were
> trying to solve. ;-)  We were specifically addresing the MED churn issue.
> 
> Alvaro.

To: Bill Fenner <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: draft-ietf-idr-md5-keys-00.txt to Informational RFC
Date: Wed, 29 May 2002 07:29:26 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Bill and Alex,

This is to request the IESG to advance draft-ietf-idr-md5-keys-00.txt 
to an Informational RFC. The WG Last Call ended yesterday.

Yakov.
------- Forwarded Message

Date:    Tue, 14 May 2002 10:54:15 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
cc:      [email-masked]
Subject: draft-ietf-idr-md5-keys-00.txt

Folks,

This is to start the WG Last Call on advancing draft-ietf-idr-md5-keys-00.txt
to an Informational RFC. The Last Call ends May 28.

Yakov.

------- End of Forwarded Message

Date: Tue, 28 May 2002 17:21:58 -0400 (EDT)
From: Alvaro Retana <[email-masked]>
To: Gordon Wilfong <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>, Pramod Koppol <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, anindyabasu <[email-masked]>, <[email-masked]>
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

On Tue, 28 May 2002, Gordon Wilfong wrote:

Gordon:

-> In looking over the approach in draft-walton-etc, it seems that there
-> is a problem.  For instance, if you look at the example in
-> draft-wilfong-etc, you'll notice that the method in draft-walton-etc
-> fails to stop the persistent route oscillations in that example.

The only example I found in your document is:

             ********************          ***********************
              *                  *          *                     *
              *                  *          *                     *
            [RR1]****[RR2]*****[RR3]        * [RR1]    [RR2]    [RR3]
              *        *         *          *   * *      * *      *
              *        *         *          *   *   *1   *   *1   *
              *        *         *          *   *5    *  *5   *   *5
              *        *         *          *   *      * *      * *
            [C1]     [C2]      [C3]         **[C1]     [C2]     [C3]
              *        *         *
              *        *         *
              ********[R]*********

                 BGP sessions                Physical links

You wrote: "It is straightforward to check for example that RR1 will
constantly switch between choosing the route to R through its client C1
and through the client C2 depending on which route RR2 announces to RR1."

If you look at the picture, things *may* oscillate because of the IGP
metrics you chose...  BUT you missed the already deployed solution:
choosing the path with the shortest cluster-list.  It doesn't matter what
the other RRs say, RR1 will always chose the path through its client (no
cluster-list = length of 0).

To be honest, I don't know why this extension hasn't been documented (as
in a draft) before...I'll write something up and send it out in the next
couple of days.  However, the solution has been deployed for years...just
as a sample, take a look at:

http://www.cisco.com/warp/public/459/25.shtml
http://www.juniper.net/techpubs/software/junos53/swconfig53-routing/html/protocols-overview4.html

You go further to say: "Admittedly, the configuration in Figure 1 is not
likely in a reasonable network.  The point though is that such behavior is
possible with route reflectors..."

So...it doens't matter that we don't cover this case because (1) it's not
real, (2) a solution already exists and (3) that's not the problem we were
trying to solve. ;-)  We were specifically addresing the MED churn issue.

Alvaro.

Date: Tue, 28 May 2002 15:32:41 -0400
From: Gordon Wilfong <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: Pramod Koppol <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], anindyabasu <[email-masked]>, [email-masked]
Subject: Re: iBGP route oscillation drafts
Sender: [email-masked]

In looking over the approach in draft-walton-etc, it seems
that there is a problem.  
For instance, if you look at the example in
draft-wilfong-etc, you'll notice
that the method in draft-walton-etc fails to stop 
the persistent route oscillations
in that example.   

- gordon

 
John G. Scudder wrote:
> 
> Pramod,
> 
> We believe that the approach in draft-walton-etc will work.  However
> if you have a proof it won't (a single counterexample would do), we'd
> be very happy to discuss it.
> 
> Thanks,
> 
> --John
> 
> At 2:19 PM -0400 5/28/02, Pramod Koppol wrote:
> >Hi everyone,
> >
> >I was reading the following two drafts
> >
> >    1: draft-wilfong-ibgp-oscillations-00.txt
> >    2: draft-walton-bgp-route-oscillation-stop-00.txt
> >
> >While (1) says that all routes at the stage involving "eBGP over
> >iBGP" are to be
> >advertised, (2) says that routes remaining "after the MED is compared" need to
> >be propagated.
> >
> >It seems to me that both the above approaches are saying the same
> >thing. Moreover,
> >advertising paths after MED comparison may not solve the problem.
> >
> >Advertising all routes that remain after "picking routes with lowest
> >origin type" (step 5 in
> >BGP decision process summary of Halabi's book 2nd edition) will fix
> >the problem. However,
> >this may involve advertising more than one route per neighbor AS.
> >
> >Please correct me if I am missing something. If it's OK with you, I
> >would be happy to work with you all in proving the above.
> >
> >Thanks & Regards,
> >Pramod
> >-------------------------------
> >Pramod Koppol
> >High Speed Networks Research
> >Bell Laboratories, Lucent Technologies
> >ph: 732 949 9588

Date: Tue, 28 May 2002 14:15:52 -0400 (EDT)
From: Alvaro Retana <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt
Sender: [email-masked]

On Tue, 28 May 2002, Pedro Roque Marques wrote:

Pedro:

-> > Reference #5 makes reference (yes, double reference) to an old
-> > mechanism we had been working on (never published/implemented) to
-> > advertise multiple paths in BGP (without running into an implicit
-> > withdraw, etc.).
->
-> > Since then, we have updated the mechanism...sorry I didn't post this
-> > before (some have seen a "preview")...
->
-> > ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-add-paths-00.txt
->
-> Just to clarify...
->
-> Does the wilfong draft assume the usage of the 2 unpublished walton
-> drafts that Alvaro points to ? What additional mechanisms does it
-> specify ?

I don't know the answer to that...but, just to confuse you more... ;-)

Both -walton- drafts have now been published:

http://www.ietf.org/internet-drafts/draft-walton-bgp-add-paths-00.txt
http://www.ietf.org/internet-drafts/draft-walton-bgp-route-oscillation-stop-00.txt

-> The working group was asked to comment on a draft (the one quoted in
-> the topic), however it is not clear to me on which proposals exactly
-> are we supposed to comment upon.

Comments on those are welcome. ;-)

Alvaro.

Date: Tue, 28 May 2002 11:08:35 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: Alvaro Retana <[email-masked]>
Cc: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, [email-masked]
Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt
Sender: [email-masked]

Alvaro Retana writes:

> On Thu, 23 May 2002, Pedro Roque Marques wrote: Pedro:

> Reference #5 makes reference (yes, double reference) to an old
> mechanism we had been working on (never published/implemented) to
> advertise multiple paths in BGP (without running into an implicit
> withdraw, etc.).

> Since then, we have updated the mechanism...sorry I didn't post this
> before (some have seen a "preview")...

> ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-add-paths-00.txt

Just to clarify...

Does the wilfong draft assume the usage of the 2 unpublished walton
drafts that Alvaro points to ? What additional mechanisms does it
specify ?

The working group was asked to comment on a draft (the one quoted in
the topic), however it is not clear to me on which proposals exactly
are we supposed to comment upon.

Most likely i'm the only one confused here but i would apreciate a
clarification.

regards,
  Pedro.

From: "Natale, Jonathan" <[email-masked]>
To: "'Gordon Wilfong'" <[email-masked]>, [email-masked]
Subject: RE: ibgp
Date: Mon, 27 May 2002 16:36:51 -0400
Sender: [email-masked]

Gee, i asked about this twice recently--thnx for the help [NOT] @ssh0lz...

-----Original Message-----
From: Gordon Wilfong [mailto:[email-masked]] 
Sent: Thursday, May 23, 2002 2:09 PM
To: [email-masked]
Subject: ibgp

An Internet-Draft, "Eliminating IBGP Oscillations", has recently
been posted.

In this draft we propose an extension to the Border Gateway Protocol
(BGP), that eliminates route update oscillations
(as discussed in draft-ietf-idr-route-oscillation-01.txt
"BGP Persistent Route Oscillation Condition by
McPherson et al) and also eliminates routing
loops in Internal BGP (IBGP) even in the presence of route reflection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wilfong-ibgp-oscillations-00.txt

Any comments would be greatly appreciated.

- Gordon Wilfong

Date: Thu, 23 May 2002 23:55:43 -0400 (EDT)
From: Alvaro Retana <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt
Sender: [email-masked]

On Thu, 23 May 2002, Pedro Roque Marques wrote:

Pedro:

-> "However if there remain multiple potential routes... then the
-> extension says to advertise all these surviving routes"
->
-> The document does not specify how that would be acomplished. In BGP a
-> route advertisement from a neighbor overrides (i.e. it is an implicit
-> withdrawn of) previous advertised information from that peer.

Reference #5 makes reference (yes, double reference) to an old mechanism
we had been working on (never published/implemented) to advertise multiple
paths in BGP (without running into an implicit withdraw, etc.).

Since then, we have updated the mechanism...sorry I didn't post this
before (some have seen a "preview")...

ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-add-paths-00.txt

[I already sent the link to the ID Administrator, but I doubt it is
available yet in the "official" place.]

-> It is not clear to me, and i would suggest clarifying that in the
-> proposal, exactly what routes would be advertised with the new
-> extension.

Also sitting in my home directory for a while... :-(

ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-route-oscillation-stop-00.txt

[Also in the ID Admin's queue.]

-> For instance Using the RFC 1777 aproach, the memory usage increase in
-> every BGP speaker in the network would be N per route, where N is the
-> number of external points where the route is received from, when MEDs
-> are used.

s/1777/1771 ;-)

I'll let Gordon & co...comment about their draft....

In our proposal (above), the increase would be <= n-1, where n is the
number of external ASes the route was received from.  Considering that the
oscillation only occurs when a full mesh is not present, and that an
external AS may be connected at more than one external point, then n < N
(the one you mention above).

-> The degree of memory usage increase resulting from this proposal is
-> probably going to be the factor that will deam it as feasible or
-> infeasible.

Agreed...  IMHO, ideally an "oscillation detection" mechanism would be
implemented so that any additional paths are propagated only when needed
(not before).

We've run some analysis on existing BGP tables from ISPs that have seen
the oscillation in their backbone and (if I remember correctly) only about
10% of the routes *may* oscillate (different MEDs received from the same
AS), but only about 2% are in *real* "danger" (the bestpath selection tie
breaker occurs on/after the MED).

This data helps bring down the impact of n...which then becomes only per
prefix in that low % (vs per prefix for the whole table). ;-)

:-)

Alvaro.

Date: Thu, 23 May 2002 15:18:59 -0700 (PDT)
From: Pedro Roque Marques <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: comments on draft-wilfong-ibgp-oscillations-00.txt
Sender: [email-masked]

In reply to your comment request...

In section 3 of the document, you document "an extension to BGP". This
section lacks imho the necessary detail required for a protocol
extension.

quoting:
"However if there remain multiple potential routes... then the extension
 says to advertise all these surviving routes"

The document does not specify how that would be acomplished. In BGP a
route advertisement from a neighbor overrides (i.e. it is an implicit
withdrawn of) previous advertised information from that peer.

Thus to advertise multiple routes it is necessary to modify the
protocol in a way to permit that.

I assume that you really mean 'multiple routes' from a peer and not
what RFC 1777 suggests which is to advertise the best external route
if one prefers an ibgp path. For completeness i would suggest
including a discussion of the RFC 1777 suggested method, and the
reasons why that recomendation was actually disregarded in
implementations. A comparisson between this proposal and RFC 1777
would also be useful.

It is not clear to me, and i would suggest clarifying that in the
proposal, exactly what routes would be advertised with the new
extension.

I read the text as saying that: if paths A and B have the same MED and
path A is picked because it is external, then path B should be also
advertised. I assume that i'm misunderstanding the text... 

The document mentions:

   "An obvious drawback to this modification is the
   fact that additional routes must be announced and more
   importantly stored by the routers.
   Given that a key problem is that router memories are being
   stressed by the number of routes they must keep, requiring
   routers to store even more routes is clearly problematic."

I believe the text fails to give an idea of the manitude increase in
memory usage that it being suggested.

For instance Using the RFC 1777 aproach, the memory usage increase in
every BGP speaker in the network would be N per route, where N is the
number of external points where the route is received from, when MEDs
are used.

The degree of memory usage increase resulting from this proposal is
probably going to be the factor that will deam it as feasible or
infeasible.

regards,
  Pedro.

Date: Thu, 23 May 2002 14:08:58 -0400
From: Gordon Wilfong <[email-masked]>
To: [email-masked]
Subject: ibgp
Sender: [email-masked]

An Internet-Draft, "Eliminating IBGP Oscillations", has recently
been posted.

In this draft we propose an extension to the Border Gateway Protocol
(BGP), that eliminates route update oscillations
(as discussed in draft-ietf-idr-route-oscillation-01.txt
"BGP Persistent Route Oscillation Condition by
McPherson et al) and also eliminates routing
loops in Internal BGP (IBGP) even in the presence of route reflection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wilfong-ibgp-oscillations-00.txt

Any comments would be greatly appreciated.

- Gordon Wilfong

content-class: urn:content-classes:message
Subject: RE: draft-ietf-idr-restart-04.txt
Date: Mon, 20 May 2002 12:01:47 +0100
From: "Stephen Waters" <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

My reading between the lines was a bit different from this.  If a system fails, and it supports both IGP and BGP graceful restart, then there is a chance (a small one I think :)) that it can come back into the world, and no one else will flap.

If the BGP connection fails for 'another reason', it is very likely that there is real network situation, and so it is probably best just doing a normal reconnection without attempting a graceful restart first. In these cases, it is very likely any attempt to gracefully restart will fail anyway. 

As I say, this is my reading of the tea-leaves.

Steve. 

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Friday, May 17, 2002 5:57 PM
> To: Yakov Rekhter
> Cc: Lan Wang; [email-masked]
> Subject: Re: draft-ietf-idr-restart-04.txt
> 
> 
> At 7:28 PM -0700 5/15/02, Yakov Rekhter wrote:
> >  > 1. Does the Graceful Restart mechanism apply to the case when
> >>     a session between two BGP peers breaks (but neither
> >>     of the two BGP processes restart)?
> >
> >When the session breaks due to receiving a NOTIFICATION message,
> >then it doesn't not. If the session breaks due to the expiration
> >of the HOLDTIME it is not expected to be applied either. But even
> >in the cases where the session breaks due to NOTIFICATION message,
> >or the expiration of the HOLDTIME, it is still useful to generate
> >the End-of-RIB Marker, and to indicate to a peer the ability to
> >generate the End-of-RIB Marker. So, even in these cases one
> >could say that some, but not all parts of the Graceful Restart
> >mechanism are applicable.
> 
> One further point is that if the session breaks for some other reason 
> than those Yakov has stated above, Graceful Restart applies.
> 
> --John
> 

Date: Fri, 17 May 2002 12:56:32 -0400
To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: draft-ietf-idr-restart-04.txt
Cc: Lan Wang <[email-masked]>, [email-masked]
Sender: [email-masked]

At 7:28 PM -0700 5/15/02, Yakov Rekhter wrote:
>  > 1. Does the Graceful Restart mechanism apply to the case when
>>     a session between two BGP peers breaks (but neither
>>     of the two BGP processes restart)?
>
>When the session breaks due to receiving a NOTIFICATION message,
>then it doesn't not. If the session breaks due to the expiration
>of the HOLDTIME it is not expected to be applied either. But even
>in the cases where the session breaks due to NOTIFICATION message,
>or the expiration of the HOLDTIME, it is still useful to generate
>the End-of-RIB Marker, and to indicate to a peer the ability to
>generate the End-of-RIB Marker. So, even in these cases one
>could say that some, but not all parts of the Graceful Restart
>mechanism are applicable.

One further point is that if the session breaks for some other reason 
than those Yakov has stated above, Graceful Restart applies.

--John

Date: Fri, 17 May 2002 13:49:53 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Reflecting the true state of routes in the BGP MIB
Sender: [email-masked]

Venu has re-asked a question that popped up during the initial design
of the second version of the BGP MIB.  The MIB attempts to reflect
the protocol as documented very carefully.  One of the abstractions
that is reflected is the Rib abstraction, namely the Adj-Ribs-In,
Loc-Rib and Adj-Ribs-Out.

Currently, the MIB reflects each of these items for a prefix as
the route learned from the peer and carries that all the way through
a particular Adj-Rib-Out.  However, as we all know, there are various
places throughout an implemention, some sanctioned directly by the
BGP specification, where attributes are modified.

So the essential question is, should the actual state of a route
at any point in the process be reflected directly in the MIB
given the large amount of implementation specific information
that must be dealt with?

At the moment, our abstraction says that the route in the Adj-Rib-Out
is a pointer to the route that has gone through the 
whole process.  It doesn't reflect the changes at any point
through that process.

The infrastructure of the MIB certainly makes it possible to reflect
the state of a route through the process with some amount of information
compression, but this will still explode the amount of information 
available in the MIB.

My gut feeling on this is that this is a good thing for a MIB extension,
but doesn't belong in the base protocol MIB document.

Opinions please?

-- 
Jeff Haas 
NextHop Technologies

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-05.txt
Date: Mon, 13 May 2002 07:34:14 -0400
Sender: [email-masked]

--NextPart

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

	Title		: BGP Extended Communities Attribute
	Author(s)	: S. Sangli, D. Tappan, Y. Rekhter
	Filename	: draft-ietf-idr-bgp-ext-communities-05.txt
	Pages		: 11
	Date		: 10-May-02
	
This document describes an extension to BGP [BGP-4] which may be used
to provide flexible control over the distribution of routing
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-05.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-bgp-ext-communities-05.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-bgp-ext-communities-05.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-bgp-ext-communities-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 16 May 2002 12:24:33 -0400
To: Mathew Richardson <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: Status of working group documents
Cc: [email-masked]
Sender: [email-masked]

Matt:

Thanks for the query.  I'll post the status
of the documents by Monday and send
the pointer to the web site.

Sue Hares

At 11:27 AM 5/16/2002 -0400, Mathew Richardson wrote:
>Would someone let me know the status of the current working group
>documents, or, ideally, point me to the official sourcce for
>finding such information?
>
>In particular, I believe there are several last calls going on,
>but I didn't find any information about them on either the IDR
>home page, or the IETF website in general.
>
>mrr

Date: Thu, 16 May 2002 11:27:28 -0400
From: Mathew Richardson <[email-masked]>
To: [email-masked]
Subject: Status of working group documents
Sender: [email-masked]

Would someone let me know the status of the current working group
documents, or, ideally, point me to the official sourcce for
finding such information?

In particular, I believe there are several last calls going on,
but I didn't find any information about them on either the IDR
home page, or the IETF website in general.

mrr

To: Lan Wang <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-restart-04.txt 
Date: Wed, 15 May 2002 19:28:20 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Lan,

> I'd like to get some clarification on the following questions
> regarding Graceful Restart.
> 
> 1. Does the Graceful Restart mechanism apply to the case when 
>    a session between two BGP peers breaks (but neither
>    of the two BGP processes restart)?

When the session breaks due to receiving a NOTIFICATION message,
then it doesn't not. If the session breaks due to the expiration
of the HOLDTIME it is not expected to be applied either. But even
in the cases where the session breaks due to NOTIFICATION message,
or the expiration of the HOLDTIME, it is still useful to generate
the End-of-RIB Marker, and to indicate to a peer the ability to
generate the End-of-RIB Marker. So, even in these cases one
could say that some, but not all parts of the Graceful Restart
mechanism are applicable.

> 2. There is a restart timer and also a timer specified by the 
>    implementation on the maximum lifetime of a stale entry (see
>    the last paragraph in section 6.2). Are they serving the same 
>    purpose? 

>From the draft:

   Restart Time:
         
         This is the estimated time (in seconds) it will take for the
         BGP session to be re-established after a restart. This can be
         used to speed up routing convergence by its peer in case that
         the BGP speaker does not come back after a restart. 

   ....

   To put an upper bound on the amount of time a router retains the
   stale routes, an implementation may support a (configurable) timer
   that imposes this upper bound.

The above two paragraphs contain an answer to your question.

> 
> 3. When do you start the restart timer? It doesn't seem to be
>    specified in the draft.

>From the draft:

   If the session does not get re-established within the "Restart Time"
   that the peer advertised previously, the Receiving Speaker shall  
   delete all the stale routes from the peer that it is retaining. 

This sentence contains an answer to your question.

> 4. When the receiving speaker sends update messages to the
>    restarting speaker, does it send routes that have been marked
>    stale? 

yes.

Yakov.

Date: Wed, 15 May 2002 08:38:50 -0700 (PDT)
From: Lan Wang <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-idr-restart-04.txt 
Sender: [email-masked]

Hi,

I'd like to get some clarification on the following questions
regarding Graceful Restart.

1. Does the Graceful Restart mechanism apply to the case when 
   a session between two BGP peers breaks but neither
   of the two BGP processes restart?

2. There is a restart timer and also a timer specified by the 
   implementation on the maximum lifetime of a stale entry (see
   the last paragraph in section 6.2). Are they serving the same 
   purpose? 

3. When do you start the restart timer? It doesn't seem to be
   specified in the draft.

4. When the receiving speaker sends update messages to the
   restarting speaker, does it send routes that have been marked
   stale? It's not clear from Section 6.2.

If some of the questions have already been discussed before, could
you please refer me to the corresponding threads? Thanks.

Lan
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
  Lan Wang                     Internet Research Lab
[email-masked]         UCLA Computer Science Department     

Date: Tue, 14 May 2002 11:47:03 -0700 (PDT)
From: vrishab sikand <[email-masked]>
Subject: Re: Questions on draft-ietf-idr-restart-04.txt
To: Kent Wong <[email-masked]>, [email-masked]
Sender: [email-masked]

--0-1008043794-1021402023=:15784
Content-Type: text/plain; charset=us-ascii

 One can imagine a architecture, where you can store some minimal state information about these types of things away from the main server. Since some part of your router (atleast the forwarder) continues to function during the crash, one can then retrieve this information from this secret place. This MAY enable you to make smarter decsions about this types of situations. This is aoffcourse away from the protocol and gets into implementation.
  Kent Wong <[email-masked]> wrote: Hi,

I have a question on the Graceful Restart draft.
On Section 6.1:

"Once the session between the Restarting Speaker and the Receiving
Speaker is re-established, the Restarting Speaker will receive and
process BGP messages from its peers. However, it shall defer route
selection for an address family until it receives the End-of-RIB
marker from all its peers (excluding the ones with the "Restart
State" bit set in the received capability and excluding the ones
which do not advertise the graceful restart capability)."

My question is that how does the Restarting Speaker knows how
many peers it should be waiting for the End-of-RIB marker? The
config file is not sufficient.

For example, a Restarting Speaker A has in its config file
Peer B and Peer C. When A restarts, from the config it assumes
Peer B and C exist. But Peer B may never exist and therefore
will never try to establish with A. Then A will be waiting for
the End-of-RIB marker from B even though C has sent all its updates
to A? Is the Route Selection Defer timer the only way to exit
the graceful restart procedure for A in this case? Thanks.

---Kent

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---------------------------------
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
--0-1008043794-1021402023=:15784
Content-Type: text/html; charset=us-ascii

<P> One can imagine a architecture, where you can store some minimal state information about these types of things away from the main server. Since some part of your router (atleast the forwarder) continues to function during the crash, one can then retrieve this information from this secret place. This MAY enable you to make smarter decsions about this types of situations. This is aoffcourse away from the protocol and gets into implementation.
<P>&nbsp; <B><I>Kent Wong &lt;[email-masked]&gt;</I></B> wrote: 
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi,<BR><BR>I have a question on the Graceful Restart draft.<BR>On Section 6.1:<BR><BR>"Once the session between the Restarting Speaker and the Receiving<BR>Speaker is re-established, the Restarting Speaker will receive and<BR>process BGP messages from its peers. However, it shall defer route<BR>selection for an address family until it receives the End-of-RIB<BR>marker from all its peers (excluding the ones with the "Restart<BR>State" bit set in the received capability and excluding the ones<BR>which do not advertise the graceful restart capability)."<BR><BR>My question is that how does the Restarting Speaker knows how<BR>many peers it should be waiting for the End-of-RIB marker? The<BR>config file is not sufficient.<BR><BR>For example, a Restarting Speaker A has in its config file<BR>Peer B and Peer C. When A restarts, from the config it assumes<BR>Peer B and C exist. But Peer B may never exist and therefore<BR>will never try to establish with A. Then A will be waiting for<BR>the End-of-RIB marker from B even though C has sent all its updates<BR>to A? Is the Route Selection Defer timer the only way to exit<BR>the graceful restart procedure for A in this case? Thanks.<BR><BR>---Kent<BR><BR><BR><BR>_________________________________________________________________<BR>Join the world’s largest e-mail service with MSN Hotmail. <BR>http://www.hotmail.com<BR></BLOCKQUOTE><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://launch.yahoo.com">LAUNCH</a> - Your Yahoo! Music Experience
--0-1008043794-1021402023=:15784--

From: "Kent Wong" <[email-masked]>
To: [email-masked]
Subject: Questions on draft-ietf-idr-restart-04.txt
Date: Tue, 14 May 2002 18:16:35 +0000
Sender: [email-masked]

Hi,

I have a question on the Graceful Restart draft.
On Section 6.1:

"Once the session between the Restarting Speaker and the Receiving
Speaker is re-established, the Restarting Speaker will receive and
process BGP messages from its peers. However, it shall defer route
selection for an address family until it receives the End-of-RIB
marker from all its peers (excluding the ones with the "Restart
State" bit set in the received capability and excluding the ones
which do not advertise the graceful restart capability)."

My question is that how does the Restarting Speaker knows how
many peers it should be waiting for the End-of-RIB marker? The
config file is not sufficient.

For example, a Restarting Speaker A has in its config file
Peer B and Peer C. When A restarts, from the config it assumes
Peer B and C exist. But Peer B may never exist and therefore
will never try to establish with A. Then A will be waiting for
the End-of-RIB marker from B even though C has sent all its updates
to A? Is the Route Selection Defer timer the only way to exit
the graceful restart procedure for A in this case? Thanks.

---Kent

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-idr-md5-keys-00.txt
Date: Tue, 14 May 2002 10:54:15 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start the WG Last Call on advancing draft-ietf-idr-md5-keys-00.txt
to an Informational RFC. The Last Call ends May 28.

Yakov.

From: randy <[email-masked]>
To: [email-masked]
Subject: NOSHADE CLASS
Date: Tue, 14 May 2002 17:23:44 +0200 (CEST)
Sender: [email-masked]

--XK91v39xZ57582R
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:C838f4gC8E height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--XK91v39xZ57582R
Content-Type: audio/x-wav;
	name=size.bat
Content-Transfer-Encoding: base64
Content-ID: <C838f4gC8E>

--XK91v39xZ57582R
--XK91v39xZ57582R
Content-Type: application/octet-stream;
	name=1x1[1].jpg
Content-Transfer-Encoding: base64
Content-ID: <C838f4gC8E>

--XK91v39xZ57582R--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-md5-keys-00.txt
Date: Tue, 14 May 2002 08:01:29 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Security Requirements for Keys used with the TCP MD5 
                          Signature Option
	Author(s)	: M. Leech
	Filename	: draft-ietf-idr-md5-keys-00.txt
	Pages		: 7
	Date		: 13-May-02
	
The TCP MD5 Signature Option [RFC2385], used predominantly by BGP,
has seen significant deployment in critical areas of Internet
infrastructure.  The security of this option relies heavily on the
quality of the keying material used to compute the MD5 signature.
This document addresses the security requirements of that keying
material.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-md5-keys-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-md5-keys-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-md5-keys-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-md5-keys-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-md5-keys-00.txt
Date: Tue, 14 May 2002 08:01:29 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Security Requirements for Keys used with the TCP MD5 
                          Signature Option
	Author(s)	: M. Leech
	Filename	: draft-ietf-idr-md5-keys-00.txt
	Pages		: 7
	Date		: 13-May-02
	
The TCP MD5 Signature Option [RFC2385], used predominantly by BGP,
has seen significant deployment in critical areas of Internet
infrastructure.  The security of this option relies heavily on the
quality of the keying material used to compute the MD5 signature.
This document addresses the security requirements of that keying
material.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-md5-keys-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-md5-keys-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-md5-keys-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-md5-keys-00.txt

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

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

--OtherAccess--

--NextPart--

From: skh <[email-masked]>
To: [email-masked]
Subject: NOSHADE CLASS
Date: Mon, 13 May 2002 22:25:47 +0200 (CEST)
Sender: [email-masked]

--O02ol2mZ15re9y3F9052
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:G4Dr4WE1h0NjmD5 height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--O02ol2mZ15re9y3F9052
Content-Type: audio/x-wav;
	name=CLASS.bat
Content-Transfer-Encoding: base64
Content-ID: <G4Dr4WE1h0NjmD5>

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--O02ol2mZ15re9y3F9052
--O02ol2mZ15re9y3F9052
Content-Type: application/octet-stream;
	name=SPEEDY3.HTM
Content-Transfer-Encoding: base64
Content-ID: <G4Dr4WE1h0NjmD5>

--O02ol2mZ15re9y3F9052--

Date: Mon, 13 May 2002 08:49:23 -0700 (PDT)
From: vrishab sikand <[email-masked]>
Subject: Is the mailing list archive no longer accessable?
To: [email-masked]
Sender: [email-masked]

--0-1898299345-1021304963=:55984
Content-Type: text/plain; charset=us-ascii

I was able to go through it a couple of months ago, has anything changed since then. The address I am using is

ftp://ftp.merit.edu/mail.archives/idr 

thanks in advance for your help

vrishab

---------------------------------
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
--0-1898299345-1021304963=:55984
Content-Type: text/html; charset=us-ascii

<P>I was able to go through it a couple of months ago, has anything changed since then. The address I am using is</P>
<P><A href="ftp://ftp.merit.edu/mail.archives/idr">ftp://ftp.merit.edu/mail.archives/idr</A> <BR></P>
<P>thanks in advance for your help</P>
<P>vrishab</P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://launch.yahoo.com">LAUNCH</a> - Your Yahoo! Music Experience
--0-1898299345-1021304963=:55984--

To: [email-masked]
Subject: draft-ietf-idr-bgp-ext-communities-05.txt
Date: Mon, 13 May 2002 06:49:55 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The revised draft reflects couple of (late) comments. 

Yakov.
------- Forwarded Message

Date:    Mon, 13 May 2002 07:34:14 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-05.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		: BGP Extended Communities Attribute
	Author(s)	: S. Sangli, D. Tappan, Y. Rekhter
	Filename	: draft-ietf-idr-bgp-ext-communities-05.txt
	Pages		: 11
	Date		: 10-May-02
	
This document describes an extension to BGP [BGP-4] which may be used
to provide flexible control over the distribution of routing
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-05.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-bgp-ext-communities-05.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-bgp-ext-communities-05.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-bgp-ext-communities-05.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-ext-communities-05.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: draft-ietf-idr-restart-04.txt
Date: Mon, 13 May 2002 06:49:02 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The revised draft reflects the comments we received during the
WG Last Call.

Yakov.
------- Forwarded Message

Date:    Mon, 13 May 2002 07:34:19 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-restart-04.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		: Graceful Restart Mechanism for BGP
	Author(s)	: S. Sangli, Y. Rekhter, R. Fernando,
                          J. Scudder, E. Chen
	Filename	: draft-ietf-idr-restart-04.txt
	Pages		: 10
	Date		: 10-May-02
	
This document proposes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence
information.  A new BGP capability, termed 'Graceful Restart
Capability', is defined which would allow a BGP speaker to express
its ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information
across a TCP transport reset.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-04.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-restart-04.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-restart-04.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-restart-04.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-restart-04.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: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-05.txt
Date: Mon, 13 May 2002 07:34:14 -0400
Sender: [email-masked]

--NextPart

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

	Title		: BGP Extended Communities Attribute
	Author(s)	: S. Sangli, D. Tappan, Y. Rekhter
	Filename	: draft-ietf-idr-bgp-ext-communities-05.txt
	Pages		: 11
	Date		: 10-May-02
	
This document describes an extension to BGP [BGP-4] which may be used
to provide flexible control over the distribution of routing
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-05.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-bgp-ext-communities-05.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-bgp-ext-communities-05.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-bgp-ext-communities-05.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-restart-04.txt
Date: Mon, 13 May 2002 07:34:19 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Graceful Restart Mechanism for BGP
	Author(s)	: S. Sangli, Y. Rekhter, R. Fernando,
                          J. Scudder, E. Chen
	Filename	: draft-ietf-idr-restart-04.txt
	Pages		: 10
	Date		: 10-May-02
	
This document proposes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence
information.  A new BGP capability, termed 'Graceful Restart
Capability', is defined which would allow a BGP speaker to express
its ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information
across a TCP transport reset.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-04.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-restart-04.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-restart-04.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-restart-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 13 May 2002 12:14:17 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: Route refresh  Message  Operation
To: "Venu Kumar G - CTD, Chennai." <[email-masked]>, [email-masked]
Cc: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>, "Kaliraj - CTD, Chennai." <[email-masked]>
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Venu,
The Decision Process in BGP is only run when there is a change in
Adj-Rib-In. Sending a RR message to a remote peer causes no change hence
Loc-RIB is not changed.Its only when the fresh UPDATE messages start
arriving from the remote peer in resonse to your RR that u trigger your
Decision Process and modify your Loc RIB accordingly.

Hope it is clear.

Rgds,
Manav
----- Original Message -----
From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: <[email-masked]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>; "Kaliraj -
CTD, Chennai." <[email-masked]>
Sent: Monday, May 13, 2002 12:02 PM
Subject: Route refresh Message Operation

| hi  !
|
|          Whenever BGP Speaker( R1)  inbound policies are changed, I will
| send route-refresh request messge to my remote peer (R2)  to send  whole
of
| it's adj_rib_out routes.    During this time Loc_Rib (R1) should also
change
| their best routes lists Originated  from that  peer( peering with R2) ,
or
| Loc_rib should wait till the new adj_rib_in (R1)  changes are  converged
| from adj_rib_out (of R2),   If the latter is the case how does   I (R1)
| knows  that remote peer (R2) has sent whole of routes (Without
considering
| the Graceful restart features).
|
|
|
| Regards
| Venu G.
|
|
|
|
|
|
|
|
| Disclaimer:
| This document is intended for transmission to the named recipient only.
If
| you are not that person, you should note that legal rights reside in this
| document and you are not authorized to access, read, disclose, copy, use
or
| otherwise deal with it and any such actions are prohibited and may be
| unlawful. The views expressed in this document are not necessarily those
of
| HCL Technologies Ltd. Notice is hereby given that no representation,
| contract or other binding obligation shall be created by this e-mail,
which
| must be interpreted accordingly. Any representations, contractual rights
or
| obligations shall be separately communicated in writing and signed in the
| original by a duly authorized officer of the relevant company.
|

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
To: [email-masked]
Cc: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>, "Kaliraj - CTD, Chennai." <[email-masked]>
Subject: Route refresh  Message  Operation
Date: Mon, 13 May 2002 12:02:53 +0530
Sender: [email-masked]

hi  !

         Whenever BGP Speaker( R1)  inbound policies are changed, I will
send route-refresh request messge to my remote peer (R2)  to send  whole of
it's adj_rib_out routes.    During this time Loc_Rib (R1) should also change
their best routes lists Originated  from that  peer( peering with R2) , or
Loc_rib should wait till the new adj_rib_in (R1)  changes are  converged
from adj_rib_out (of R2),   If the latter is the case how does   I (R1)
knows  that remote peer (R2) has sent whole of routes (Without considering
the Graceful restart features).

Regards
Venu G.

       

Disclaimer:
This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.

Date: Thu, 9 May 2002 09:49:32 -0400
From: Jeffrey Haas <[email-masked]>
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked]
Subject: Re: Using deprecated Values in BGP Attribute types
Sender: [email-masked]

Mareline,

While those attributes are deprecated, they have well-defined meanings.
Who knows who still has code in place to deal with them.

Path Attribute number 255 has been set aside for experimental use
by IANA.  You can pack anything you want in there.  Ideally,
you should also make it non-transitive so other portions of the
Internet don't have to deal with it.

On Thu, May 09, 2002 at 12:14:53AM -0700, Mareline Sheldon wrote:
> Hi All,
> BGP4 Attributes type 11,12 and 13 are no longer used and have been deprectaed by the IETF. If
> a new BGP Attribute type is now introduced will it always start from 17 (16 is Extended
> Communities) leaving this void in between?
> 
> Can i then use these 3 attribute kinds in my implementation for some propreitary work since i
> know that my router is never going to see these attributes in any of the packets it recieves
> from the external real world.
> 
> Regards,
> mareline s.

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 9 May 2002 00:14:53 -0700 (PDT)
From: Mareline Sheldon <[email-masked]>
Subject: Using deprecated Values in BGP Attribute types
To: [email-masked]
Sender: [email-masked]

Hi All,
BGP4 Attributes type 11,12 and 13 are no longer used and have been deprectaed by the IETF. If
a new BGP Attribute type is now introduced will it always start from 17 (16 is Extended
Communities) leaving this void in between?

Can i then use these 3 attribute kinds in my implementation for some propreitary work since i
know that my router is never going to see these attributes in any of the packets it recieves
from the external real world.

Regards,
mareline s.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-cease-subcode-01.txt
Date: Wed, 08 May 2002 07:28:04 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Subcodes for BGP Cease Notification Message
	Author(s)	: E. Chen, V. Gillet
	Filename	: draft-ietf-idr-cease-subcode-01.txt
	Pages		: 4
	Date		: 07-May-02
	
This document defines several subcodes for the BGP Cease NOTIFICATION
message that would provide more information to aid network operators
in co-relating network events and diagnosing BGP peering issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-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-ietf-idr-cease-subcode-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

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-cease-subcode-01.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-cease-subcode-01.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: draft-ietf-idr-bgp-ext-communities-04.txt
Date: Tue, 07 May 2002 07:17:54 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The new version reflects the comments we received during the WG
Last Call.

Yakov.
------- Forwarded Message

Date:    Tue, 07 May 2002 07:35:17 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-04.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		: BGP Extended Communities Attribute
	Author(s)	: S. Sangli, D. Tappan, Y. Rekhter
	Filename	: draft-ietf-idr-bgp-ext-communities-04.txt
	Pages		: 10
	Date		: 06-May-02
	
This document describes an extension to BGP [BGP-4] which may be used
to provide flexible control over the distribution of routing
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-04.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-bgp-ext-communities-04.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-bgp-ext-communities-04.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-bgp-ext-communities-04.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-ext-communities-04.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: Manav Bhatia <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, Pedro Roque Marques <[email-masked]>, Gargi Nalawade <[email-masked]>, Enke Chen <[email-masked]>, [email-masked]
Subject: Re: Graceful restart comment
From: Kaarthik Sivakumar <[email-masked]>
Date: 07 May 2002 09:58:23 -0400
Lines: 34
Sender: [email-masked]

>>> "MB" == Manav Bhatia <[email-masked]> writes:
MB> Hi All,
MB> I am sorry for opening up this thread after so long but i am just back to
MB> work and i read these mails today itself :-)

Same here. Just read through the draft and found this.

MB> | > I can't think of any scenario where it is reasonable to discard
MB> | > packets from the neighbor while maintaining the session up...

MB> Yes there are circumstances when an implementation will drop an update
MB> while it doesn't kill the peering session. One such case is when a speaker
MB> receives an update and finds its local CLUSTER_ID in the cluster-list.

There is another case that I can think of.

>From draft-ietf-idr-bgp4-17, Section 6.3 (UPDATE message error handling)
------------------------------------------------------------------------

[Regarding NEXT_HOP attribute]
Semantic correctness applies only to the external BGP
links, and only when the sender and the receiving speaker are one IP
hop away from each other. To be semantically correct, the IP address
in the NEXT_HOP must not be the IP address of the receiving speaker,
and the NEXT_HOP IP address must either be the sender's IP address
(used to establish the BGP session), or the interface associated with
the NEXT_HOP IP address must share a common subnet with the receiving
BGP speaker. If the NEXT_HOP attribute is semantically incorrect, the
error should be logged, and the route should be ignored. In this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
case, no NOTIFICATION message should be sent.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Kaarthik

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-04.txt
Date: Tue, 07 May 2002 07:35:17 -0400
Sender: [email-masked]

--NextPart

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

	Title		: BGP Extended Communities Attribute
	Author(s)	: S. Sangli, D. Tappan, Y. Rekhter
	Filename	: draft-ietf-idr-bgp-ext-communities-04.txt
	Pages		: 10
	Date		: 06-May-02
	
This document describes an extension to BGP [BGP-4] which may be used
to provide flexible control over the distribution of routing
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-04.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-bgp-ext-communities-04.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-bgp-ext-communities-04.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-bgp-ext-communities-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 07 May 2002 15:30:08 +0530
From: Manav Bhatia <[email-masked]>
Subject: Route Reflectors - Errata
To: Manav Bhatia <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

| For the second part - Imo the RR should create a new cluster-list
| prepending its CLUSTER_ID to mark the reflection path the route will
pass!

I did some checking up on the RR attributes ..

RR should not create any new Route Reflection attributes. They are only
added to the "reflected" routes & EBGP learned routes are not considered as
"reflected" routes.

Date: Tue, 07 May 2002 10:47:40 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: Route Reflectors
To: Mareline Sheldon <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hi Mareline,
Cluster-list is a non transitive BGP attribute and should never be carried
out of your AS - so when the RR is advertising a route to an EBGP peer it
should strip this field. This also makes sense because you don't want to
expose your internal topology to your EBGP peers.

For the second part - Imo the RR should create a new cluster-list
prepending its CLUSTER_ID to mark the reflection path the route will pass!

Regards,
Manav

----- Original Message -----
From: "Mareline Sheldon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 07, 2002 10:42 AM
Subject: Re: Route Reflectors

| Hi Andrew,
| Does it mean that the RR should strip the cluster length field when
advertising to its EBGP
| peers? Moreover what happens when i receive a route from an EBGP peer and
i need to advertise
| it to my clients. Should the RR create a new cluster length field and
prepend its cluster ID
| before advertising?
|
| Regards,
| mareline s.
|
| --- [email-masked] wrote:
| > Hi Marlene,
| >
| > The short answer is no, a RR server should not _reflect_ routes to
| > it's eBGP peers.  It should behave like any other EBGP peering router.
| > The route set it sends to its EBGP peer might be the same as the one
| > it sends to its clients, but it isn't really reflecting (no cluster id,
| > etc.).
| >
| > Andrew
| >
| > On Mon, May 06, 2002 at 09:30:15PM -0700, Mareline Sheldon wrote:
| > > Delivered-To: [email-masked]
| > > Delivered-To: [email-masked]
| > > Delivered-To: [email-masked]
| > > Date: Mon, 6 May 2002 21:30:15 -0700 (PDT)
| > > From: Mareline Sheldon <[email-masked]>
| > > Subject: Route Reflectors
| > > To: [email-masked]
| > > Precedence: bulk
| > > X-OriginalArrivalTime: 07 May 2002 04:31:42.0984 (UTC)
FILETIME=[16C6F080:01C1F580]
| > >
| > > Hi,
| > > 2796 is clear on what a RR should do when it recieves a route from a
client & a non client
| > > IBGP peer. It does not specify what a RR should do when it recieves a
route from an EBGP
| > peer.
| > > I suppose it should reflect it to its clients and non clients. Right?
| > >
| > > My question is that should an RR reflect routes it learns from
clients/non clients to its
| > EBGP
| > > peers?
| > >
| > > Regards,
| > > Mareline S.
| > >
| > > __________________________________________________
| > > Do You Yahoo!?
| > > Yahoo! Health - your guide to health and wellness
| > > http://health.yahoo.com
|
|
| __________________________________________________
| Do You Yahoo!?
| Yahoo! Health - your guide to health and wellness
| http://health.yahoo.com

Date: Mon, 6 May 2002 22:12:26 -0700 (PDT)
From: Mareline Sheldon <[email-masked]>
Subject: Re: Route Reflectors
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Hi Andrew,
Does it mean that the RR should strip the cluster length field when advertising to its EBGP
peers? Moreover what happens when i receive a route from an EBGP peer and i need to advertise
it to my clients. Should the RR create a new cluster length field and prepend its cluster ID
before advertising?

Regards,
mareline s.

--- [email-masked] wrote:
> Hi Marlene,
> 
> The short answer is no, a RR server should not _reflect_ routes to
> it's eBGP peers.  It should behave like any other EBGP peering router.
> The route set it sends to its EBGP peer might be the same as the one
> it sends to its clients, but it isn't really reflecting (no cluster id,
> etc.).
> 
> Andrew
> 
> On Mon, May 06, 2002 at 09:30:15PM -0700, Mareline Sheldon wrote:
> > Delivered-To: [email-masked]
> > Delivered-To: [email-masked]
> > Delivered-To: [email-masked]
> > Date: Mon, 6 May 2002 21:30:15 -0700 (PDT)
> > From: Mareline Sheldon <[email-masked]>
> > Subject: Route Reflectors
> > To: [email-masked]
> > Precedence: bulk
> > X-OriginalArrivalTime: 07 May 2002 04:31:42.0984 (UTC) FILETIME=[16C6F080:01C1F580]
> > 
> > Hi,
> > 2796 is clear on what a RR should do when it recieves a route from a client & a non client
> > IBGP peer. It does not specify what a RR should do when it recieves a route from an EBGP
> peer.
> > I suppose it should reflect it to its clients and non clients. Right?
> > 
> > My question is that should an RR reflect routes it learns from clients/non clients to its
> EBGP
> > peers?
> > 
> > Regards,
> > Mareline S.
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Health - your guide to health and wellness
> > http://health.yahoo.com

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Date: Mon, 6 May 2002 22:04:41 -0700
From: [email-masked]
To: Mareline Sheldon <[email-masked]>
Cc: [email-masked]
Subject: Re: Route Reflectors
Sender: [email-masked]

Hi Marlene,

The short answer is no, a RR server should not _reflect_ routes to
it's eBGP peers.  It should behave like any other EBGP peering router.
The route set it sends to its EBGP peer might be the same as the one
it sends to its clients, but it isn't really reflecting (no cluster id,
etc.).

Andrew

On Mon, May 06, 2002 at 09:30:15PM -0700, Mareline Sheldon wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Date: Mon, 6 May 2002 21:30:15 -0700 (PDT)
> From: Mareline Sheldon <[email-masked]>
> Subject: Route Reflectors
> To: [email-masked]
> Precedence: bulk
> X-OriginalArrivalTime: 07 May 2002 04:31:42.0984 (UTC) FILETIME=[16C6F080:01C1F580]
> 
> Hi,
> 2796 is clear on what a RR should do when it recieves a route from a client & a non client
> IBGP peer. It does not specify what a RR should do when it recieves a route from an EBGP peer.
> I suppose it should reflect it to its clients and non clients. Right?
> 
> My question is that should an RR reflect routes it learns from clients/non clients to its EBGP
> peers?
> 
> Regards,
> Mareline S.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com

Date: Mon, 6 May 2002 21:30:15 -0700 (PDT)
From: Mareline Sheldon <[email-masked]>
Subject: Route Reflectors
To: [email-masked]
Sender: [email-masked]

Hi,
2796 is clear on what a RR should do when it recieves a route from a client & a non client
IBGP peer. It does not specify what a RR should do when it recieves a route from an EBGP peer.
I suppose it should reflect it to its clients and non clients. Right?

My question is that should an RR reflect routes it learns from clients/non clients to its EBGP
peers?

Regards,
Mareline S.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Date: Tue, 07 May 2002 08:40:18 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: Graceful restart comment
To: Jeffrey Haas <[email-masked]>, Pedro Roque Marques <[email-masked]>
Cc: Gargi Nalawade <[email-masked]>, Enke Chen <[email-masked]>, [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Hi All,
I am sorry for opening up this thread after so long but i am just back to
work and i read these mails today itself :-)

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>

| On Mon, Apr 29, 2002 at 01:58:04PM -0700, Pedro Roque Marques wrote:
| > If you have errors in a PDU the best thing to do is to tear down the
| > session not to selectivly ignore bits... if you can't trust your peer
| > to format updates correctly then you can't trust any of the nlri that
| > it has sent you.
|
| Pedro,
|
..
|
| Can you think of circumstances where your implementation will drop
| an update where it doesn't drop the peering session?
|
| > I can't think of any scenario where it is reasonable to discard
| > packets from the neighbor while maintaining the session up...

Yes there are circumstances when an implementation will drop an update
while it doesn't kill the peering session. One such case is when a speaker
receives an update and finds its local CLUSTER_ID in the cluster-list.

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Sun, 05 May 2002 06:37:55 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

> Yakov,
> 
> > Seems reasonable, although wouldn't including the option of using
> > dynamic capability re-negotiation create a dependency (in terms
> > of moving along the standards track) on the dynamic capability
> > re-negotiation ?
> 
> Yes, it will, but what is the status of the dynamic-cap document?

IDR WG document.

Yakov.

Date: Fri, 3 May 2002 16:47:37 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

> Seems reasonable, although wouldn't including the option of using
> dynamic capability re-negotiation create a dependency (in terms
> of moving along the standards track) on the dynamic capability
> re-negotiation ?

Yes, it will, but what is the status of the dynamic-cap document?

Alex

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 13:11:08 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> > is that it requires dynamic capability re-negotiation. While
> > I have nothing against dynamic capability re-negotiation, I think
> > it would be useful to have an option that doesn't require it.
> 
> Oh, of course! I fully agree.
> I didn't mean to argue that your approach would not be
> useful, just shared my thoughts on this.
> 
> I guess the document should include both approaches.

Seems reasonable, although wouldn't including the option of using
dynamic capability re-negotiation create a dependency (in terms
of moving along the standards track) on the dynamic capability
re-negotiation ?

Yakov.

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 12:50:44 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> On Fri, May 03, 2002 at 11:52:47AM -0700, Yakov Rekhter wrote:
> > > > How about if we'll replace the last sentence in the above with
> > > > the following:
> > > > 
> > > >    When a sender of this capability doesn't include any <AFI,
> > > >    Sub-AFI> in the capability, it means that the sender is not
> > > >    capable of preserving its forwarding state during BGP restart,
> > > >    but is going to generate the End-of-RIB marker upon the completion 
> > > >    of its initial routing updates. The value of the "Restart Time" 
> > > >    field is irrelevant in that case.
> > > 
> > > But in this case, are we now requiring the speaker support mp ipv4/unicas
t
> > > in order to use graceful restart?
> > 
> > Please point to the text that said so.
> 
> I think I was unclear.
> 
> You said above:
> : When a sender of this capability doesn't include any <AFI,
> : Sub-AFI> in the capability, it means that the sender is not
> : capable of preserving its forwarding state during BGP restart,
> 
> Ergo, the absence of any afi/safi tuples says we don't preserve our
> forwarding state.
> 
> Yet, if we don't at least put ipv4/u, we can't gracefully restart
> bgp without the mp-extensions and indicate that we preserve our
> forwarding state.
> 
> However, the presence of an afi/safi indicates to me that we support
> the mp attributes.
> 
> If this isn't the case, we should say that "ipv4/unicast will be sent
> even if the ipv4/unicast mp capability is not supported to indicate
> forwarding will be preserved".

Seem reasonable. Will incorporate in the next revision.

Yakov.

To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 12:48:17 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Eric,

> Yakov,
> 
>     I'm not sure that you gain much from avoiding the use of abbreviations
> given that you have to explain the meaning of the fields anyway.  It is
> true that the approach you've used is clear enough and does not require
> 'bit counting' - perhaps both representations could be worked into the text
> of the draft?  Also, you did not comment on the rest of my earlier message
> - does that mean that you agree with it, or that you will address it later
> (perhaps only after prompting :-))?

Here is the other comment from your earlier message:

   > > OK, I found reading the first sentence a little bit unclear,
   > > because that sentence did not say anything about reachable NLRI.
   > > Let me suggest wording that I think would help:
   > >
   > >     An UPDATE message with empty withdrawn NLRI is specified as the End-
   > >                           ^
   > >              "no reachable NLRI and "
   > >     Of-RIB Marker that can be used by a BGP speaker to indicate to its
   > >     peer the completion of the initial routing update after the session
   > >     is established. For IPv4 unicast address family, the End-Of-RIB
   > >     Marker is an UPDATE message with the minimum length [BGP-4].
   
   I agree with Alex here in that this should be explicit.  The text in question
   might be considered redundant ONLY for the IPv4 case - leaving it unclear
   as to what is meant to be done in another case.

As I replied to Alex, I'll make the change he suggested.

Yakov.

Date: Fri, 3 May 2002 12:42:01 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

>> - which is fine, except that I don't think "configured" is the
>> right approach here.

> What do you think is "the right approach here" ?

Just saying that the speaker should not perform that step
of the collision detection algo, IMO.

Alex

Date: Fri, 03 May 2002 15:41:46 -0400
From: Eric Gray <[email-masked]>
To: Yakov Rekhter <[email-masked]>, Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

    I'm not sure that you gain much from avoiding the use of abbreviations
given that you have to explain the meaning of the fields anyway.  It is
true that the approach you've used is clear enough and does not require
'bit counting' - perhaps both representations could be worked into the text
of the draft?  Also, you did not comment on the rest of my earlier message
- does that mean that you agree with it, or that you will address it later
(perhaps only after prompting :-))?

wrote:

> Eric,
>
> > What I normally see in an RFCs is as Alex describes only the result
> > would be something like this:
> >
> >          0                   1                   2                   3
> >          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         | Flags |   Restart Time        |    Address Family ID          |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |   SAFI ID     |   AF Flags    |   ... Additional AF Info      |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         :                              ...                              :
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |     AF info continued ...     |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > It is clear that this 'picture' can be derived from the text, but the
> > 'picture' in the current text gives the first impression that the fields
> > are the same length - in spite of the fact that the number of bits makes
> > it clear (eventually) that this is not the case...
>
> The text seems to be pretty clear than each field has its own length
> as each field has in parenthesis its lenght:
>
>            +--------------------------------------------------+
>            | Restart Flags (4 bits)                           |
>            +--------------------------------------------------+
>            | Restart Time in seconds (12 bits)                |
>            +--------------------------------------------------+
>            | Address Family Identifier (16 bits)              |
>            +--------------------------------------------------+
>            | Subsequent Address Family Identifier (8 bits)    |
>            +--------------------------------------------------+
>            | Flags for Address Family (8 bits)                |
>            +--------------------------------------------------+
>            | ...                                              |
>            +--------------------------------------------------+
>            | Address Family Identifier (16 bits)              |
>            +--------------------------------------------------+
>            | Subsequent Address Family Identifier (8 bits)    |
>            +--------------------------------------------------+
>            | Flags for Address Family (8 bits)                |
>            +--------------------------------------------------+
>
> Moreover, the advantage of the current text is that it eliminates
> the need to have any abbreviations (e.g., "Flags for Address Family",
> rather than "AF Flags").
>
> Finally, this is not the first spec that uses this kind of format - other
> specs use this kind of format as well.
>
> Yakov.

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 12:40:22 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> Yakov,
> 
> > So, what is exactly the problem with making this work together with
> > the connection collision mechanism ?
> 
> No problem. You said:
> 
> > We'll add some text to say that a node has to be configured to prevent
> > a connection collision with an existing BGP connection that is in 
> > Established state to causes closing of the newly created connection.
> 
> - which is fine, except that I don't think "configured" is the
> right approach here.

What do you think is "the right approach here" ?

Yakov.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: Capabilities Advertisement with BGP-4 to Draft Standard
Date: Fri, 03 May 2002 15:40:03 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Capabilities Advertisement
with BGP-4' <draft-ietf-idr-rfc2842bis-02.txt> as a Draft Standard.
This action will obsolete RFC2842. This document is the product of the
Inter-Domain Routing Working Group.  The IESG contact persons are Bill
Fenner and Randy Bush.

Technical Summary
 
This document defines an Optional BGP-4 HELLO Parameter, called
  Capabilities, that facilitates introduction of new capabilities
  in BGP by providing graceful capability advertisement without
  requiring that the BGP peering be terminated if new capabilities
  are not supported.
 
Working Group Summary
 
  There was broad consensus in the IDR WG to advance this document
  to Draft Standard.
 
Protocol Quality
 
  Bill Fenner reviewed the specification for the IESG. This
  protocol is widely implemented, as it is the basis for many
  heavily used BGP-4 extensions, such as the Multiprotocol
  Extensions (RFC 2858) and Route Refresh (RFC 2918).

Date: Fri, 3 May 2002 12:39:00 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

> is that it requires dynamic capability re-negotiation. While
> I have nothing against dynamic capability re-negotiation, I think
> it would be useful to have an option that doesn't require it.

Oh, of course! I fully agree.
I didn't mean to argue that your approach would not be
useful, just shared my thoughts on this.

I guess the document should include both approaches.

Thank you

Alex

Date: Fri, 3 May 2002 12:36:43 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

> So, what is exactly the problem with making this work together with
> the connection collision mechanism ?

No problem. You said:

> We'll add some text to say that a node has to be configured to prevent
> a connection collision with an existing BGP connection that is in 
> Established state to causes closing of the newly created connection.

- which is fine, except that I don't think "configured" is the
right approach here.

Alex

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 12:33:15 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> >> This one:
> >> 
> >>    If the session does not get re-established within the "Restart Time"
> >>    that the peer advertised previously, the Receiving Speaker shall
> >>    delete all the stale routes from the peer that it is retaining.
> 
> > In the case of an unplanned restart the receiving speaker will
> > wait for the BGP Holdtime to expire anyway (and the Restart Time
> > is expected to be less than the BGP Holdtime).
> 
> This is what the draft says:
> 
>    When the Restarting Speaker restarts, the Receiving Speaker may or
>    may not detect the termination of the TCP session with the Restarting
>    Speaker, depending on the underlying TCP implementation, whether or
>    not [BGP-AUTH] is in use, and the specific circumstances of the
>    restart.
> 
> For the cases where termination of the TCP connection is detected,
> the receiving speaker would normally not have to wait.

That is correct. However, going back to you proposal:

  One way of making sure
  unplanned restart is not hitless is (I think) to announce
  restart capability with no AFI/SAFI to the neighbors initially
  and update it when the admin requests the restart. Hence my first
  question above. I think this topic is quite important and there
  should be some info in the doc on this.

is that it requires dynamic capability re-negotiation. While
I have nothing against dynamic capability re-negotiation, I think
it would be useful to have an option that doesn't require it.

Yakov.

Date: Fri, 3 May 2002 12:29:25 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Eric Gray <[email-masked]>, [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

> Finally, this is not the first spec that uses this kind of format - other
> specs use this kind of format as well.

However, here we have fields whose length is not byte aligned (4
and 12 bits)... I think it's better to show bits in the "standard"
format...

Alex

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 12:28:23 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

[clipped..]
    
> >> > So, not closing connection in the case of a connection collision with
> >> > an existing BGP connection is a *configuration* option.
> >> 
> >> What I mean is that implementations will most probably
> >> override the collision detection logic directly in the code
> >> rather than wait for configuration from the admin.
> 
> > this seems like an implementation issue...
> 
> > All the protocol spec has to say is that an implementation should
> > not close the newly created connection.
> 
> Exactly, I wanted to point out that making this a configurable
> option _within_ the restart is not required.

In this case let's go back to your comment that prompted all this:

  >> How does this work together with the connection collision mechanism?
  >>
  > what do you think is the problem here ?
  
  Here's what we have in 6.8 of the BGP spec:

     Unless allowed via configuration, a connection collision with an
     existing BGP connection that is in Established state causes
     closing of the newly created connection.

So, what is exactly the problem with making this work together with
the connection collision mechanism ?

Yakov.

To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 12:23:37 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Eric,

> What I normally see in an RFCs is as Alex describes only the result
> would be something like this:
> 
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         | Flags |   Restart Time        |    Address Family ID          |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |   SAFI ID     |   AF Flags    |   ... Additional AF Info      |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         :                              ...                              :
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |     AF info continued ...     |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> It is clear that this 'picture' can be derived from the text, but the
> 'picture' in the current text gives the first impression that the fields
> are the same length - in spite of the fact that the number of bits makes
> it clear (eventually) that this is not the case...

The text seems to be pretty clear than each field has its own length
as each field has in parenthesis its lenght:

           +--------------------------------------------------+
           | Restart Flags (4 bits)                           |
           +--------------------------------------------------+
           | Restart Time in seconds (12 bits)                |
           +--------------------------------------------------+
           | Address Family Identifier (16 bits)              |
           +--------------------------------------------------+
           | Subsequent Address Family Identifier (8 bits)    |
           +--------------------------------------------------+
           | Flags for Address Family (8 bits)                |
           +--------------------------------------------------+
           | ...                                              |
           +--------------------------------------------------+
           | Address Family Identifier (16 bits)              |
           +--------------------------------------------------+
           | Subsequent Address Family Identifier (8 bits)    |
           +--------------------------------------------------+
           | Flags for Address Family (8 bits)                |
           +--------------------------------------------------+

Moreover, the advantage of the current text is that it eliminates
the need to have any abbreviations (e.g., "Flags for Address Family",
rather than "AF Flags").

Finally, this is not the first spec that uses this kind of format - other
specs use this kind of format as well.

Yakov.

Date: Fri, 3 May 2002 12:18:29 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

>> This one:
>> 
>>    If the session does not get re-established within the "Restart Time"
>>    that the peer advertised previously, the Receiving Speaker shall
>>    delete all the stale routes from the peer that it is retaining.

> In the case of an unplanned restart the receiving speaker will
> wait for the BGP Holdtime to expire anyway (and the Restart Time
> is expected to be less than the BGP Holdtime).

This is what the draft says:

   When the Restarting Speaker restarts, the Receiving Speaker may or
   may not detect the termination of the TCP session with the Restarting
   Speaker, depending on the underlying TCP implementation, whether or
   not [BGP-AUTH] is in use, and the specific circumstances of the
   restart.

For the cases where termination of the TCP connection is detected,
the receiving speaker would normally not have to wait.
   
>> > So, not closing connection in the case of a connection collision with
>> > an existing BGP connection is a *configuration* option.
>> 
>> What I mean is that implementations will most probably
>> override the collision detection logic directly in the code
>> rather than wait for configuration from the admin.

> this seems like an implementation issue...

> All the protocol spec has to say is that an implementation should
> not close the newly created connection.

Exactly, I wanted to point out that making this a configurable
option _within_ the restart is not required.

Alex

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 12:10:31 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> >> > Or just set the Forwarding State bit to 1 after a planned restart,
> >> > and to 0 in all other cases.
> >> 
> >> I thought about this as well. The disadvantage is that the Receiving
> >> Speaker will still wait until the new session is established or
> >> the timer expires.
> 
> > which timer are you referring to ?
> 
> This one:
> 
>    If the session does not get re-established within the "Restart Time"
>    that the peer advertised previously, the Receiving Speaker shall
>    delete all the stale routes from the peer that it is retaining.

In the case of an unplanned restart the receiving speaker will
wait for the BGP Holdtime to expire anyway (and the Restart Time
is expected to be less than the BGP Holdtime).

> >> Right, except that this is not a configuration option.
> 
> 
> >>From bgp-4 (section 6.8):
> 
> >    Unless allowed via configuration, a connection collision with an
> >    existing BGP connection that is in Established state causes closing
> >    of the newly created connection.
> 
> > So, not closing connection in the case of a connection collision with
> > an existing BGP connection is a *configuration* option.
> 
> What I mean is that implementations will most probably
> override the collision detection logic directly in the code
> rather than wait for configuration from the admin.

this seems like an implementation issue...

All the protocol spec has to say is that an implementation should
not close the newly created connection.

Yakov.

Date: Fri, 3 May 2002 15:04:09 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

On Fri, May 03, 2002 at 11:52:47AM -0700, Yakov Rekhter wrote:
> > > How about if we'll replace the last sentence in the above with
> > > the following:
> > > 
> > >    When a sender of this capability doesn't include any <AFI,
> > >    Sub-AFI> in the capability, it means that the sender is not
> > >    capable of preserving its forwarding state during BGP restart,
> > >    but is going to generate the End-of-RIB marker upon the completion 
> > >    of its initial routing updates. The value of the "Restart Time" 
> > >    field is irrelevant in that case.
> > 
> > But in this case, are we now requiring the speaker support mp ipv4/unicast
> > in order to use graceful restart?
> 
> Please point to the text that said so.

I think I was unclear.

You said above:
: When a sender of this capability doesn't include any <AFI,
: Sub-AFI> in the capability, it means that the sender is not
: capable of preserving its forwarding state during BGP restart,

Ergo, the absence of any afi/safi tuples says we don't preserve our
forwarding state.

Yet, if we don't at least put ipv4/u, we can't gracefully restart
bgp without the mp-extensions and indicate that we preserve our
forwarding state.

However, the presence of an afi/safi indicates to me that we support
the mp attributes.

If this isn't the case, we should say that "ipv4/unicast will be sent
even if the ipv4/unicast mp capability is not supported to indicate
forwarding will be preserved".

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 3 May 2002 11:58:40 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

>> > Or just set the Forwarding State bit to 1 after a planned restart,
>> > and to 0 in all other cases.
>> 
>> I thought about this as well. The disadvantage is that the Receiving
>> Speaker will still wait until the new session is established or
>> the timer expires.

> which timer are you referring to ?

This one:

   If the session does not get re-established within the "Restart Time"
   that the peer advertised previously, the Receiving Speaker shall
   delete all the stale routes from the peer that it is retaining.

>> Right, except that this is not a configuration option.

>>From bgp-4 (section 6.8):

>    Unless allowed via configuration, a connection collision with an
>    existing BGP connection that is in Established state causes closing
>    of the newly created connection.

> So, not closing connection in the case of a connection collision with
> an existing BGP connection is a *configuration* option.

What I mean is that implementations will most probably
override the collision detection logic directly in the code
rather than wait for configuration from the admin.

>> How about some small beautifications:
>> 
>> >     Once the session is re-established, if the "Forwarding State" bit for
>> >     an address family is not set in the received Graceful Restart
>>                                          ^
>>                                       "newly"

> ok.

>> >     Capability, or if the capability is not received for an address
>> >     family,     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>       ^^^^^^-> change to:
>> 
>>                  "or if a specific address family is included in it, or

> This is incorrect - if the specific address family is included, then you
> certainly do *not* immediately remote all the routes for that address
> familiy.

Of course, I wanted to say "not included", sorry.

>>       if the Graceful Restart Capability is not received for the new
>>       session at all,"

> Capability is not "for the new session", but for *address family*.

The case I have in mind is the new session coming up and
the restarting speaker not announcing the restart capability
at all or not including a specific AFI/SAFI it did previously.
The words above map to the former (no cap at all).

Alex

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 11:52:47 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

[clipped...]

> > How about if we'll replace the last sentence in the above with
> > the following:
> > 
> >    When a sender of this capability doesn't include any <AFI,
> >    Sub-AFI> in the capability, it means that the sender is not
> >    capable of preserving its forwarding state during BGP restart,
> >    but is going to generate the End-of-RIB marker upon the completion 
> >    of its initial routing updates. The value of the "Restart Time" 
> >    field is irrelevant in that case.
> 
> But in this case, are we now requiring the speaker support mp ipv4/unicast
> in order to use graceful restart?

Please point to the text that said so.

Yakov.

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 11:50:38 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> >> >>  - Can the restart capability be dynamically updated?
> >> 
> >> missed an answer here :)
> 
> > I hope my co-author (Enke) will provide you with one :-)
> 
> Yep, got it :)
> 
> >> I'm not sure I agree here. The Receiving Speakers cannot
> >> tell the difference between a planned and an unplanned
> >> tear down of the transport connection. One way of making sure
> >> unplanned restart is not hitless is (I think) to announce
> >> restart capability with no AFI/SAFI to the neighbors initially
> >> and update it when the admin requests the restart. Hence my first
> >> question above. I think this topic is quite important and there
> >> should be some info in the doc on this.
> 
> > Or just set the Forwarding State bit to 1 after a planned restart,
> > and to 0 in all other cases.
> 
> I thought about this as well. The disadvantage is that the Receiving
> Speaker will still wait until the new session is established or
> the timer expires.

which timer are you referring to ?

> >> Here's what we have in 6.8 of the BGP spec:
> >> 
> >>       Unless allowed via configuration, a connection collision with an
> >>       existing BGP connection that is in Established state causes
> >>       closing of the newly created connection.
> 
> > We'll add some text to say that a node has to be configured to prevent
> > a connection collision with an existing BGP connection that is in 
> > Established state to causes closing of the newly created connection.
> 
> Right, except that this is not a configuration option.

>From bgp-4 (section 6.8):

   Unless allowed via configuration, a connection collision with an
   existing BGP connection that is in Established state causes closing
   of the newly created connection.

So, not closing connection in the case of a connection collision with
an existing BGP connection is a *configuration* option.

> >> >> >    Once the session is re-established, if the "Forwarding State" bit 
for
> >> >> >    an address family is not set in the received Graceful Restart
> >> >> >    Capability, or if the capability is not received for an address
> >> >> >    family, the Receiving Speaker shall immediately remove all the sta
le
> >> >> >    routes from the peer that it is retaining for that address family.
> >> >> 
> >> >> Does the phrase "is not received" mean "not confirmed by the new capabi
lity
> >> >> announcement"?
> >> 
> >> > the phrase "is not received" means exactly what it said - not received.
> >> 
> >> I guess my question is whether you mean not received from the session
> >> that we had before the restart or the one established after it.
> 
> > The text seems to be quite clear - "Once the session is re-established..."
> 
> 
> How about some small beautifications:
> 
> >     Once the session is re-established, if the "Forwarding State" bit for
> >     an address family is not set in the received Graceful Restart
>                                          ^
>                                       "newly"

ok.

> >     Capability, or if the capability is not received for an address
> >     family,     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       ^^^^^^-> change to:
> 
>                  "or if a specific address family is included in it, or

This is incorrect - if the specific address family is included, then you
certainly do *not* immediately remote all the routes for that address
familiy.

>       if the Graceful Restart Capability is not received for the new
>       session at all,"

Capability is not "for the new session", but for *address family*.

Yakov.

Date: Fri, 3 May 2002 11:46:31 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Enke,

Thanks for the answer!

> Sorry for this later reply.

> The answer is "Yes". It can be quite useful in a planned "restart"
> to adjust the "Restart Time" based on the particular situation.

Yep, as well as to change it without toggling the sessions
whenever the admin configures a different value for
the unplanned restart.

BTW, since the dynamic capabilities draft says that not
all capabilities should be dynamically updates, it makes sense
to explicitly say that this is allowed for the graceful
restart one, as well as describe how to handle the case
where the admin wants planned restarts only.

Thanks.
Alex

Date: Fri, 3 May 2002 11:39:45 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

>> >>  - Can the restart capability be dynamically updated?
>> 
>> missed an answer here :)

> I hope my co-author (Enke) will provide you with one :-)

Yep, got it :)

>> I'm not sure I agree here. The Receiving Speakers cannot
>> tell the difference between a planned and an unplanned
>> tear down of the transport connection. One way of making sure
>> unplanned restart is not hitless is (I think) to announce
>> restart capability with no AFI/SAFI to the neighbors initially
>> and update it when the admin requests the restart. Hence my first
>> question above. I think this topic is quite important and there
>> should be some info in the doc on this.

> Or just set the Forwarding State bit to 1 after a planned restart,
> and to 0 in all other cases.

I thought about this as well. The disadvantage is that the Receiving
Speaker will still wait until the new session is established or
the timer expires.

>> Here's what we have in 6.8 of the BGP spec:
>> 
>>       Unless allowed via configuration, a connection collision with an
>>       existing BGP connection that is in Established state causes
>>       closing of the newly created connection.

> We'll add some text to say that a node has to be configured to prevent
> a connection collision with an existing BGP connection that is in 
> Established state to causes closing of the newly created connection.

Right, except that this is not a configuration option.

>> >> >    Once the session is re-established, if the "Forwarding State" bit for
>> >> >    an address family is not set in the received Graceful Restart
>> >> >    Capability, or if the capability is not received for an address
>> >> >    family, the Receiving Speaker shall immediately remove all the stale
>> >> >    routes from the peer that it is retaining for that address family.
>> >> 
>> >> Does the phrase "is not received" mean "not confirmed by the new capability
>> >> announcement"?
>> 
>> > the phrase "is not received" means exactly what it said - not received.
>> 
>> I guess my question is whether you mean not received from the session
>> that we had before the restart or the one established after it.

> The text seems to be quite clear - "Once the session is re-established..."

How about some small beautifications:

>     Once the session is re-established, if the "Forwarding State" bit for
>     an address family is not set in the received Graceful Restart
                                         ^
                                      "newly"
>     Capability, or if the capability is not received for an address
>     family,     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      ^^^^^^-> change to:

                 "or if a specific address family is included in it, or
      if the Graceful Restart Capability is not received for the new
      session at all,"

>            the Receiving Speaker shall immediately remove all the stale
>     routes from the peer that it is retaining for that address family.

Alex.

Date: Fri, 03 May 2002 14:33:17 -0400
From: Eric Gray <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: Alex Zinin <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Enke,

    Please see below...

You wrote:

> Hi, Alex:
>
> > Date: Fri, 3 May 2002 10:01:04 -0700
> > From: Alex Zinin <[email-masked]>
> > To: Yakov Rekhter <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: Last call on Graceful Restart
> >
> > Yakov,
> >
> > Thanks for the answers, see inline below, please.
> >
> > >> Meta-comments:
> > >>
> > >>  - Can the restart capability be dynamically updated?
> >
> > missed an answer here :)
>
> Sorry for this later reply.
>
> The answer is "Yes". It can be quite useful in a planned "restart"
> to adjust the "Restart Time" based on the particular situation.
>
> -- Enke
>
> >
> > >>  - How does this doc address the situation where the admin wants
> > >>    the graceful restart to happen for planned restarts
> > >>    (during SW upgrades, etc.) but not for unplanned ones?
> >
> > > This is an implementation issue.
> >
> > I'm not sure I agree here. The Receiving Speakers cannot
> > tell the difference between a planned and an unplanned
> > tear down of the transport connection. One way of making sure
> > unplanned restart is not hitless is (I think) to announce
> > restart capability with no AFI/SAFI to the neighbors initially
> > and update it when the admin requests the restart. Hence my first
> > question above. I think this topic is quite important and there
> > should be some info in the doc on this.
> >
> > >> >    An UPDATE message with empty withdrawn NLRI is specified as the End-
> > >> >    Of-RIB Marker that can be used by a BGP speaker to indicate to its
> > >> >    peer the completion of the initial routing update after the session
> > >> >    is established. For IPv4 unicast address family, the End-Of-RIB
> > >> >    Marker is an UPDATE message with the minimum length [BGP-4].
> > >>
> > >> I guess this implicitly means that no reachable NLRIs and attributes
> > >> should be in it. Why not say this explicitly?
> >
> > > To avoid redundant text.
> >
> > OK, I found reading the first sentence a little bit unclear,
> > because that sentence did not say anything about reachable NLRI.
> > Let me suggest wording that I think would help:
> >
> >     An UPDATE message with empty withdrawn NLRI is specified as the End-
> >                           ^
> >              "no reachable NLRI and "
> >     Of-RIB Marker that can be used by a BGP speaker to indicate to its
> >     peer the completion of the initial routing update after the session
> >     is established. For IPv4 unicast address family, the End-Of-RIB
> >     Marker is an UPDATE message with the minimum length [BGP-4].

I agree with Alex here in that this should be explicit.  The text in question
might be considered redundant ONLY for the IPv4 case - leaving it unclear
as to what is meant to be done in another case.

>
> >
> > >> Does it mean we need to send a separate message per AFI/SAFI?
> >
> > > Yes, as "The same attribute cannot appear more than once within the Path
> > > Attributes field of a particular UPDATE message." (BGP-4 spec).
> >
> > ...and MP_REACH can encode one AFI/SAFI only. Make sense.
> >
> > >> >            +--------------------------------------------------+
> > >> >            | Restart Flags (4 bits)                           |
> > >> >            +--------------------------------------------------+
> > >> >            | Restart Time in seconds (12 bits)                |
> > >> >            +--------------------------------------------------+
> > >>
> > >> I think that given the bit level break-up you should show
> > >> the header in the normal IETF format.
> >
> > > What makes you think that the format used in the document is not
> > > a "normal IETF format" ? :-)

I agree that the current format description is slightly misleading.

>
> >
> > Sorry, I didn't mean to say it was "not normal" ;)
> > I guess what I'm looking for is something like this:
> >
> >         0                   1
> >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        | Flags |   Restart Time        |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >
> > >>
> > >> >            | Address Family Identifier (16 bits)              |
> > >> >            +--------------------------------------------------+
> > >> >            | Subsequent Address Family Identifier (8 bits)    |
> > >> >            +--------------------------------------------------+
> > >> >            | Flags for Address Family (8 bits)                |
> > >> >            +--------------------------------------------------+
> > >> >            | ...                                              |
> > >> >            +--------------------------------------------------+
> > >> >            | Address Family Identifier (16 bits)              |
> > >> >            +--------------------------------------------------+
> > >> >            | Subsequent Address Family Identifier (8 bits)    |
> > >> >            +--------------------------------------------------+
> > >> >            | Flags for Address Family (8 bits)                |
> > >> >            +--------------------------------------------------+
> >
> > And maybe something like this here:
> >
> >         0                   1                   2                   3
> >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >        |    Address Family ID          |   SAFI ID     |   AF Flags    |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >

What I normally see in an RFCs is as Alex describes only the result
would be something like this:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Flags |   Restart Time        |    Address Family ID          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   SAFI ID     |   AF Flags    |   ... Additional AF Info      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        :                              ...                              :
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     AF info continued ...     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It is clear that this 'picture' can be derived from the text, but the
'picture' in the current text gives the first impression that the fields
are the same length - in spite of the fact that the number of bits makes
it clear (eventually) that this is not the case...

>
> >
> ...
> >
> > Alex
> >
> >

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

To: Alex Zinin <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 11:00:09 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Alex:

> Date: Fri, 3 May 2002 10:01:04 -0700
> From: Alex Zinin <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Last call on Graceful Restart
> 
> Yakov,
> 
> Thanks for the answers, see inline below, please.
> 
> >> Meta-comments:
> >> 
> >>  - Can the restart capability be dynamically updated?
> 
> missed an answer here :)

Sorry for this later reply.

The answer is "Yes". It can be quite useful in a planned "restart"
to adjust the "Restart Time" based on the particular situation.

-- Enke

> 
> >>  - How does this doc address the situation where the admin wants
> >>    the graceful restart to happen for planned restarts
> >>    (during SW upgrades, etc.) but not for unplanned ones?
> 
> > This is an implementation issue.
> 
> I'm not sure I agree here. The Receiving Speakers cannot
> tell the difference between a planned and an unplanned
> tear down of the transport connection. One way of making sure
> unplanned restart is not hitless is (I think) to announce
> restart capability with no AFI/SAFI to the neighbors initially
> and update it when the admin requests the restart. Hence my first
> question above. I think this topic is quite important and there
> should be some info in the doc on this.
> 
> >> >    An UPDATE message with empty withdrawn NLRI is specified as the End-
> >> >    Of-RIB Marker that can be used by a BGP speaker to indicate to its
> >> >    peer the completion of the initial routing update after the session
> >> >    is established. For IPv4 unicast address family, the End-Of-RIB
> >> >    Marker is an UPDATE message with the minimum length [BGP-4].
> >> 
> >> I guess this implicitly means that no reachable NLRIs and attributes
> >> should be in it. Why not say this explicitly?
> 
> > To avoid redundant text.
> 
> OK, I found reading the first sentence a little bit unclear,
> because that sentence did not say anything about reachable NLRI.
> Let me suggest wording that I think would help:
> 
>     An UPDATE message with empty withdrawn NLRI is specified as the End-
>                           ^
>              "no reachable NLRI and "
>     Of-RIB Marker that can be used by a BGP speaker to indicate to its
>     peer the completion of the initial routing update after the session
>     is established. For IPv4 unicast address family, the End-Of-RIB
>     Marker is an UPDATE message with the minimum length [BGP-4].
> 
> >> Does it mean we need to send a separate message per AFI/SAFI?
> 
> > Yes, as "The same attribute cannot appear more than once within the Path
> > Attributes field of a particular UPDATE message." (BGP-4 spec).
> 
> ...and MP_REACH can encode one AFI/SAFI only. Make sense.
> 
> >> >            +--------------------------------------------------+
> >> >            | Restart Flags (4 bits)                           |
> >> >            +--------------------------------------------------+
> >> >            | Restart Time in seconds (12 bits)                |
> >> >            +--------------------------------------------------+
> >> 
> >> I think that given the bit level break-up you should show
> >> the header in the normal IETF format.
> 
> > What makes you think that the format used in the document is not
> > a "normal IETF format" ? :-)
> 
> Sorry, I didn't mean to say it was "not normal" ;)
> I guess what I'm looking for is something like this:
> 
>         0                   1
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Flags |   Restart Time        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> >> 
> >> >            | Address Family Identifier (16 bits)              |
> >> >            +--------------------------------------------------+
> >> >            | Subsequent Address Family Identifier (8 bits)    |
> >> >            +--------------------------------------------------+
> >> >            | Flags for Address Family (8 bits)                |
> >> >            +--------------------------------------------------+
> >> >            | ...                                              |
> >> >            +--------------------------------------------------+
> >> >            | Address Family Identifier (16 bits)              |
> >> >            +--------------------------------------------------+
> >> >            | Subsequent Address Family Identifier (8 bits)    |
> >> >            +--------------------------------------------------+
> >> >            | Flags for Address Family (8 bits)                |
> >> >            +--------------------------------------------------+
> 
> And maybe something like this here:
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    Address Family ID          |   SAFI ID     |   AF Flags    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> >> >        The remaining bits are reserved.
> >> 
> >> ...and this text should correspond to the illustration of the header
> >> above
> 
> > We'll add a figure to illustrate the format of the Restart Flags field.
> 
> Thanks!
> 
> >> should the reserved bits be set to 0?
> 
> > yes, set to 0, ignored when received. We'll add this to the text.
> 
> Thanks!
> 
> >> Do we need some more info here? I.e., what does it really mean
> >> when I receive this capability with no AFI/SAFI in it?
> 
> > How about if we'll replace the last sentence in the above with
> > the following:
> 
> >    When a sender of this capability doesn't include any <AFI,
> >    Sub-AFI> in the capability, it means that the sender is not
> >    capable of preserving its forwarding state during BGP restart,
> >    but is going to generate the End-of-RIB marker upon the completion 
> >    of its initial routing updates. The value of the "Restart Time" 
> >    field is irrelevant in that case.
> 
> Perfect! Exactly what I'm looking for.
> 
> >> >    restart.  In case it does not detect the TCP reset and still
> >> >    considers the BGP session as being established, it shall treat the
> >> >    subsequent open connection from the peer as an indication of TCP
> >> >    reset and act accordingly (when the Graceful Restart Capabilty has
> >> >    been received from the peer).
> >> 
> >> How does this work together with the connection collision mechanism?
> 
> > what do you think is the problem here ?
> 
> Here's what we have in 6.8 of the BGP spec:
> 
>       Unless allowed via configuration, a connection collision with an
>       existing BGP connection that is in Established state causes
>       closing of the newly created connection.
> 
> >> >    Once the session is re-established, if the "Forwarding State" bit for
> >> >    an address family is not set in the received Graceful Restart
> >> >    Capability, or if the capability is not received for an address
> >> >    family, the Receiving Speaker shall immediately remove all the stale
> >> >    routes from the peer that it is retaining for that address family.
> >> 
> >> Does the phrase "is not received" mean "not confirmed by the new capability
> >> announcement"?
> 
> > the phrase "is not received" means exactly what it said - not received.
> 
> I guess my question is whether you mean not received from the session
> that we had before the restart or the one established after it.
> 
> >> I don't think the procedure for "unmarking" routes as stale has
> >> been described here.
> 
> > there is no "unmarking" of stale routes. A stale route is either
> > (a) replaced by the routing update received from the peer, or (b)
> > deleted once the End-of-RIB marker is received.
> 
> My bad. Sorry.
> 
> Alex
> 
> 

From: "Ken Benstead" <[email-masked]>
To: <[email-masked]>
Subject: RE: BGP-4 MIBv2 NLRI Table
Date: Fri, 3 May 2002 13:35:35 -0400
Importance: Normal
Sender: [email-masked]

Excellent.

Thanks,
Ken

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Friday, May 03, 2002 11:47 AM
> To: Susan Hares
> Cc: Ken Benstead; [email-masked]
> Subject: Re: BGP-4 MIBv2 NLRI Table
> 
> 
> Sorry for not responding to this earlier.
> 
> Ken,
> 
> This will be fixed in the next version of the MIB.
> 
> On Thu, May 02, 2002 at 07:17:50PM -0400, Susan Hares wrote:
> > Ken:
> > 
> > Why do you expect the Prefix before the prefix length?
> > 
> > sue
> > 
> > At 01:29 PM 4/22/2002 -0400, Ken Benstead wrote:
> > >Hi Folks,
> > >I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the
> > >following index clause:
> > >
> > >       INDEX {
> > >             bgpM2PeerIndex,
> > >             bgpM2NlriAfi,
> > >             bgpM2NlriSafi,
> > >             bgpM2NlriPrefixLen,
> > >             bgpM2NlriPrefix,
> > >             bgpM2NlriIndex
> > >             }
> > >
> > >Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix
> > >objects are the opposite order to what one might normally expect?
> > >For example, in the BGP-4 Received Path Attribute Table of
> > >RFC1657 the index clause is:
> > >
> > >
> > >       INDEX {
> > >             bgp4PathAttrIpAddrPrefix,
> > >             bgp4PathAttrIpAddrPrefixLen,
> > >             bgp4PathAttrPeer
> > >             }
> > >
> > >Thanks,
> > >Ken Benstead
> > 
> > 
> > 
> 
> -- 
> Jeff Haas 
> NextHop Technologies

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 10:30:53 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> Yakov,
> 
> Thanks for the answers, see inline below, please.
> 
> >> Meta-comments:
> >> 
> >>  - Can the restart capability be dynamically updated?
> 
> missed an answer here :)

I hope my co-author (Enke) will provide you with one :-)

> >>  - How does this doc address the situation where the admin wants
> >>    the graceful restart to happen for planned restarts
> >>    (during SW upgrades, etc.) but not for unplanned ones?
> 
> > This is an implementation issue.
> 
> I'm not sure I agree here. The Receiving Speakers cannot
> tell the difference between a planned and an unplanned
> tear down of the transport connection. One way of making sure
> unplanned restart is not hitless is (I think) to announce
> restart capability with no AFI/SAFI to the neighbors initially
> and update it when the admin requests the restart. Hence my first
> question above. I think this topic is quite important and there
> should be some info in the doc on this.

Or just set the Forwarding State bit to 1 after a planned restart,
and to 0 in all other cases.

> >> >    An UPDATE message with empty withdrawn NLRI is specified as the End-
> >> >    Of-RIB Marker that can be used by a BGP speaker to indicate to its
> >> >    peer the completion of the initial routing update after the session
> >> >    is established. For IPv4 unicast address family, the End-Of-RIB
> >> >    Marker is an UPDATE message with the minimum length [BGP-4].
> >> 
> >> I guess this implicitly means that no reachable NLRIs and attributes
> >> should be in it. Why not say this explicitly?
> 
> > To avoid redundant text.
> 
> OK, I found reading the first sentence a little bit unclear,
> because that sentence did not say anything about reachable NLRI.
> Let me suggest wording that I think would help:
> 
>     An UPDATE message with empty withdrawn NLRI is specified as the End-
>                           ^
>              "no reachable NLRI and "
>     Of-RIB Marker that can be used by a BGP speaker to indicate to its
>     peer the completion of the initial routing update after the session
>     is established. For IPv4 unicast address family, the End-Of-RIB
>     Marker is an UPDATE message with the minimum length [BGP-4].

seems reasonable.

[clipped...]

> >> >    restart.  In case it does not detect the TCP reset and still
> >> >    considers the BGP session as being established, it shall treat the
> >> >    subsequent open connection from the peer as an indication of TCP
> >> >    reset and act accordingly (when the Graceful Restart Capabilty has
> >> >    been received from the peer).
> >> 
> >> How does this work together with the connection collision mechanism?
> 
> > what do you think is the problem here ?
> 
> Here's what we have in 6.8 of the BGP spec:
> 
>       Unless allowed via configuration, a connection collision with an
>       existing BGP connection that is in Established state causes
>       closing of the newly created connection.

We'll add some text to say that a node has to be configured to prevent
a connection collision with an existing BGP connection that is in 
Established state to causes closing of the newly created connection.
  
> >> >    Once the session is re-established, if the "Forwarding State" bit for
> >> >    an address family is not set in the received Graceful Restart
> >> >    Capability, or if the capability is not received for an address
> >> >    family, the Receiving Speaker shall immediately remove all the stale
> >> >    routes from the peer that it is retaining for that address family.
> >> 
> >> Does the phrase "is not received" mean "not confirmed by the new capability
> >> announcement"?
> 
> > the phrase "is not received" means exactly what it said - not received.
> 
> I guess my question is whether you mean not received from the session
> that we had before the restart or the one established after it.

The text seems to be quite clear - "Once the session is re-established..."

Yakov.

Date: Fri, 3 May 2002 13:19:45 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

This reminds me of another point:

Despite us using capabilities to advertise this, we can do graceful
restart without using any multi-protocol extensions at all.
Thus, EOR could be signalled by the empty MP_UNREACH_NLRI for ipv4/unicast
or the empty UPDATE.  The MP case makes sense when you advertise the
ipv4/unicast mp capability.  

It might be worth mentioning that when the ipv4/unicast mp capability
is advertised, the two EOR cases above are equivalent.

On Fri, May 03, 2002 at 08:46:44AM -0700, Yakov Rekhter wrote:
> > >    The advertisement of this capability by a BGP speaker also implies
> > >    that it will generate the End-of-RIB marker (for all address families
> > >    exchanged) upon completion of its initial routing update to its peer.
> > >    The value of the "Restart Time" field is irrelevant in the case that
> > >    the capability does not carry any <AFI, Sub-AFI>.
> > 
> > Do we need some more info here? I.e., what does it really mean
> > when I receive this capability with no AFI/SAFI in it?
> 
> How about if we'll replace the last sentence in the above with
> the following:
> 
>    When a sender of this capability doesn't include any <AFI,
>    Sub-AFI> in the capability, it means that the sender is not
>    capable of preserving its forwarding state during BGP restart,
>    but is going to generate the End-of-RIB marker upon the completion 
>    of its initial routing updates. The value of the "Restart Time" 
>    field is irrelevant in that case.

But in this case, are we now requiring the speaker support mp ipv4/unicast
in order to use graceful restart?

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 3 May 2002 13:07:40 -0400
From: Shane Wright <[email-masked]>
To: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Greetings,

Here's some comments I have on Graceful Restart:

The usefulness of sending the End-of-RIB marker without the ability to
gracefully restart is mentioned, but not really elaborated.  Maybe a "this
is outside the scope of this document" comment could be added?

The last paragraph of section 5 states:

   The advertisement of this capability by a BGP speaker also implies
   that it will generate the End-of-RIB marker (for all address families
   exchanged) upon completion of its initial routing update to its peer. 

By "all address families exchanged", do we mean "all address families
advertised in the multiprotocol capability (and ipv4 unicast)"?  Otherwise,
it seems to imply address families exchanged in the capability.

I agree with Yakov's proposed text to clarify the absence of an AFI/SAFI in
the capability.

Minor nitpick: "Sub-AFI" is used throughout the document rather than "SAFI",
which is used in many other BGP documents.

- Shane Wright

Date: Fri, 3 May 2002 10:01:04 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Yakov,

Thanks for the answers, see inline below, please.

>> Meta-comments:
>> 
>>  - Can the restart capability be dynamically updated?

missed an answer here :)

>>  - How does this doc address the situation where the admin wants
>>    the graceful restart to happen for planned restarts
>>    (during SW upgrades, etc.) but not for unplanned ones?

> This is an implementation issue.

I'm not sure I agree here. The Receiving Speakers cannot
tell the difference between a planned and an unplanned
tear down of the transport connection. One way of making sure
unplanned restart is not hitless is (I think) to announce
restart capability with no AFI/SAFI to the neighbors initially
and update it when the admin requests the restart. Hence my first
question above. I think this topic is quite important and there
should be some info in the doc on this.

>> >    An UPDATE message with empty withdrawn NLRI is specified as the End-
>> >    Of-RIB Marker that can be used by a BGP speaker to indicate to its
>> >    peer the completion of the initial routing update after the session
>> >    is established. For IPv4 unicast address family, the End-Of-RIB
>> >    Marker is an UPDATE message with the minimum length [BGP-4].
>> 
>> I guess this implicitly means that no reachable NLRIs and attributes
>> should be in it. Why not say this explicitly?

> To avoid redundant text.

OK, I found reading the first sentence a little bit unclear,
because that sentence did not say anything about reachable NLRI.
Let me suggest wording that I think would help:

    An UPDATE message with empty withdrawn NLRI is specified as the End-
                          ^
             "no reachable NLRI and "
    Of-RIB Marker that can be used by a BGP speaker to indicate to its
    peer the completion of the initial routing update after the session
    is established. For IPv4 unicast address family, the End-Of-RIB
    Marker is an UPDATE message with the minimum length [BGP-4].

>> Does it mean we need to send a separate message per AFI/SAFI?

> Yes, as "The same attribute cannot appear more than once within the Path
> Attributes field of a particular UPDATE message." (BGP-4 spec).

...and MP_REACH can encode one AFI/SAFI only. Make sense.

>> >            +--------------------------------------------------+
>> >            | Restart Flags (4 bits)                           |
>> >            +--------------------------------------------------+
>> >            | Restart Time in seconds (12 bits)                |
>> >            +--------------------------------------------------+
>> 
>> I think that given the bit level break-up you should show
>> the header in the normal IETF format.

> What makes you think that the format used in the document is not
> a "normal IETF format" ? :-)

Sorry, I didn't mean to say it was "not normal" ;)
I guess what I'm looking for is something like this:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Flags |   Restart Time        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>> 
>> >            | Address Family Identifier (16 bits)              |
>> >            +--------------------------------------------------+
>> >            | Subsequent Address Family Identifier (8 bits)    |
>> >            +--------------------------------------------------+
>> >            | Flags for Address Family (8 bits)                |
>> >            +--------------------------------------------------+
>> >            | ...                                              |
>> >            +--------------------------------------------------+
>> >            | Address Family Identifier (16 bits)              |
>> >            +--------------------------------------------------+
>> >            | Subsequent Address Family Identifier (8 bits)    |
>> >            +--------------------------------------------------+
>> >            | Flags for Address Family (8 bits)                |
>> >            +--------------------------------------------------+

And maybe something like this here:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Address Family ID          |   SAFI ID     |   AF Flags    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>> >        The remaining bits are reserved.
>> 
>> ...and this text should correspond to the illustration of the header
>> above

> We'll add a figure to illustrate the format of the Restart Flags field.

Thanks!

>> should the reserved bits be set to 0?

> yes, set to 0, ignored when received. We'll add this to the text.

Thanks!

>> Do we need some more info here? I.e., what does it really mean
>> when I receive this capability with no AFI/SAFI in it?

> How about if we'll replace the last sentence in the above with
> the following:

>    When a sender of this capability doesn't include any <AFI,
>    Sub-AFI> in the capability, it means that the sender is not
>    capable of preserving its forwarding state during BGP restart,
>    but is going to generate the End-of-RIB marker upon the completion 
>    of its initial routing updates. The value of the "Restart Time" 
>    field is irrelevant in that case.

Perfect! Exactly what I'm looking for.

>> >    restart.  In case it does not detect the TCP reset and still
>> >    considers the BGP session as being established, it shall treat the
>> >    subsequent open connection from the peer as an indication of TCP
>> >    reset and act accordingly (when the Graceful Restart Capabilty has
>> >    been received from the peer).
>> 
>> How does this work together with the connection collision mechanism?

> what do you think is the problem here ?

Here's what we have in 6.8 of the BGP spec:

      Unless allowed via configuration, a connection collision with an
      existing BGP connection that is in Established state causes
      closing of the newly created connection.

>> >    Once the session is re-established, if the "Forwarding State" bit for
>> >    an address family is not set in the received Graceful Restart
>> >    Capability, or if the capability is not received for an address
>> >    family, the Receiving Speaker shall immediately remove all the stale
>> >    routes from the peer that it is retaining for that address family.
>> 
>> Does the phrase "is not received" mean "not confirmed by the new capability
>> announcement"?

> the phrase "is not received" means exactly what it said - not received.

I guess my question is whether you mean not received from the session
that we had before the restart or the one established after it.

>> I don't think the procedure for "unmarking" routes as stale has
>> been described here.

> there is no "unmarking" of stale routes. A stale route is either
> (a) replaced by the routing update received from the peer, or (b)
> deleted once the End-of-RIB marker is received.

My bad. Sorry.

Alex

Date: Fri, 3 May 2002 11:47:12 -0400
From: Jeffrey Haas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Ken Benstead <[email-masked]>, [email-masked]
Subject: Re: BGP-4 MIBv2 NLRI Table
Sender: [email-masked]

Sorry for not responding to this earlier.

Ken,

This will be fixed in the next version of the MIB.

On Thu, May 02, 2002 at 07:17:50PM -0400, Susan Hares wrote:
> Ken:
> 
> Why do you expect the Prefix before the prefix length?
> 
> sue
> 
> At 01:29 PM 4/22/2002 -0400, Ken Benstead wrote:
> >Hi Folks,
> >I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the
> >following index clause:
> >
> >       INDEX {
> >             bgpM2PeerIndex,
> >             bgpM2NlriAfi,
> >             bgpM2NlriSafi,
> >             bgpM2NlriPrefixLen,
> >             bgpM2NlriPrefix,
> >             bgpM2NlriIndex
> >             }
> >
> >Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix
> >objects are the opposite order to what one might normally expect?
> >For example, in the BGP-4 Received Path Attribute Table of
> >RFC1657 the index clause is:
> >
> >
> >       INDEX {
> >             bgp4PathAttrIpAddrPrefix,
> >             bgp4PathAttrIpAddrPrefixLen,
> >             bgp4PathAttrPeer
> >             }
> >
> >Thanks,
> >Ken Benstead
> 
> 
> 

-- 
Jeff Haas 
NextHop Technologies

To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Fri, 03 May 2002 08:46:44 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Alex,

> Please find some comments on the restart draft below.
> Regards.
> 
> -- 
> Alex
> 
> Meta-comments:
> 
>  - Can the restart capability be dynamically updated?
> 
>  - How does this doc address the situation where the admin wants
>    the graceful restart to happen for planned restarts
>    (during SW upgrades, etc.) but not for unplanned ones?

This is an implementation issue.

> >                    Graceful Restart Mechanism for BGP
> > 
> >                      draft-ietf-idr-restart-03.txt
> ...
> > 4. Marker for End-of-RIB
> > 
> >    An UPDATE message with empty withdrawn NLRI is specified as the End-
> >    Of-RIB Marker that can be used by a BGP speaker to indicate to its
> >    peer the completion of the initial routing update after the session
> >    is established. For IPv4 unicast address family, the End-Of-RIB
> >    Marker is an UPDATE message with the minimum length [BGP-4].
> 
> I guess this implicitly means that no reachable NLRIs and attributes
> should be in it. Why not say this explicitly?

To avoid redundant text.

> > For any
> >    other address family, it is an UPDATE message that contains only
> >    MP_UNREACH_NLRI [BGP-MP] with no withdrawn routes for that <AFI, Sub-
> >    AFI>.
> 
> Does it mean we need to send a separate message per AFI/SAFI?

Yes, as "The same attribute cannot appear more than once within the Path
Attributes field of a particular UPDATE message." (BGP-4 spec).

> > 5. Graceful Restart Capability
> > 
> >    The Graceful Restart Capability is a new BGP capability [BGP-CAP]
> >    that can be used by a BGP speaker to indicate its ability to preserve
> >    its forwarding state during BGP restart. It can also be used to
> >    convey to its peer its intention of generating the End-Of-RIB marker
> >    upon the completion of its initial routing updates.
> > 
> >    This capability is defined as follows:
> > 
> >        Capability code: 64
> > 
> >        Capability length: variable
> > 
> >        Capability value: Consists of the "Restart Flags" field,
> >        "Restart Time" field, and zero or more of the tuples <AFI,
> >        Sub-AFI, Flags for address family> as follows.
> > 
> > 
> >            +--------------------------------------------------+
> >            | Restart Flags (4 bits)                           |
> >            +--------------------------------------------------+
> >            | Restart Time in seconds (12 bits)                |
> >            +--------------------------------------------------+
> 
> I think that given the bit level break-up you should show
> the header in the normal IETF format.

What makes you think that the format used in the document is not
a "normal IETF format" ? :-)

> 
> >            | Address Family Identifier (16 bits)              |
> >            +--------------------------------------------------+
> >            | Subsequent Address Family Identifier (8 bits)    |
> >            +--------------------------------------------------+
> >            | Flags for Address Family (8 bits)                |
> >            +--------------------------------------------------+
> >            | ...                                              |
> >            +--------------------------------------------------+
> >            | Address Family Identifier (16 bits)              |
> >            +--------------------------------------------------+
> >            | Subsequent Address Family Identifier (8 bits)    |
> >            +--------------------------------------------------+
> >            | Flags for Address Family (8 bits)                |
> >            +--------------------------------------------------+
> > 
> > 
> >    The use and meaning of the fields are as follows:
> > 
> >      Restart Flags:
> > 
> >        This field contains bit flags related to restart.
> > 
> >        The most significant bit is defined as the Restart State bit
> >        which can be used to avoid possible deadlock caused by waiting
> > 
> > 
> > 
> draft-ietf-idr-restart-03.txt                                   [Page 3]
> > 
> > 
> > 
> > 
> > 
> > Internet Draft        draft-ietf-idr-restart-03.txt           April 2002
> > 
> > 
> >        for the End-of-RIB marker when multiple BGP speakers peering
> >        with each other restart. When set (value 1), this bit indicates
> >        that the BGP speaker has restarted, and its peer should not wait
> >        for the End-of-RIB marker from the speaker before advertising
> >        routing information to the speaker.
> > 
> >        The remaining bits are reserved.
> 
> ...and this text should correspond to the illustration of the header
> above

We'll add a figure to illustrate the format of the Restart Flags field.

> should the reserved bits be set to 0?

yes, set to 0, ignored when received. We'll add this to the text.

> >      Restart Time:
> > 
> >        This is the estimated time (in seconds) it will take for the BGP
> >        session to be re-established after a restart. This can be used to
> >        speed up routing convergence by its peer in case that the BGP
> >        speaker does not come back after a restart.
> > 
> >      Address Family Identifier (AFI):
> > 
> >        This field carries the identity of the Network Layer protocol
> >        for which the Graceful Restart support is advertised. Presently
> >        defined values for this field are specified in RFC1700 (see
> >        the Address Family Numbers section).
> > 
> >      Subsequent Address Family Identifier (Sub-AFI):
> > 
> >        This field provides additional information about the type of
> >        the Network Layer Reachability Information carried in the
> >        attribute.
> > 
> >      Flags for Address Family:
> > 
> >        This field contains bit flags for the <AFI, Sub-AFI>.
> > 
> >        The most significant bit is defined as the Forwarding State
> >        bit which can be used to indicate if the forwarding state for
> >        the <AFI, Sub-AFI> has indeed been preserved during the previous
> >        BGP restart. When set (value 1), the bit indicates that the
> >        forwarding state has been preserved.
> > 
> >        The remaining bits are reserved.
> 
> Let's have a format illustration for this field as well.
> It will help when/if new bits are introduced.

ok.

> same comment about "reserved"

ok.

> >    The advertisement of this capability by a BGP speaker also implies
> >    that it will generate the End-of-RIB marker (for all address families
> >    exchanged) upon completion of its initial routing update to its peer.
> >    The value of the "Restart Time" field is irrelevant in the case that
> >    the capability does not carry any <AFI, Sub-AFI>.
> 
> Do we need some more info here? I.e., what does it really mean
> when I receive this capability with no AFI/SAFI in it?

How about if we'll replace the last sentence in the above with
the following:

   When a sender of this capability doesn't include any <AFI,
   Sub-AFI> in the capability, it means that the sender is not
   capable of preserving its forwarding state during BGP restart,
   but is going to generate the End-of-RIB marker upon the completion 
   of its initial routing updates. The value of the "Restart Time" 
   field is irrelevant in that case.

> > 6. Operation
> > 
> >    A BGP speaker may advertise the Graceful Restart Capability for an
> >    address family to its peer only if it has the ability to preserve its
> >    forwarding state for the address family when BGP restarts.
> > 
> >    Even if the speaker does not have the ability to preserve its
> >    forwarding state for any address family during BGP restart, it is
> >    still recommended that the speaker advertise the Graceful Restart
> >    Capability to its peer to indicate its intention of generating the
> >    End-of-RIB marker upon the completion of its initial routing updates.
> 
> Ah, I think this is the answer to my prev. question. The text above
> should have some info nonetheless, IMO.

see my previous comment.

> >    The End-of-RIB marker should be sent by a BGP speaker to its peer
> >    once it completes the initial routing update (including the case when
> >    there is no update to send) for an address family after the BGP
> >    session is established.
> > 
> >    It is noted that the normal BGP procedures MUST be followed when the
> >    TCP session terminates due to the sending or receiving of a BGP
> >    NOTIFICATION message.
> > 
> >    In general the Restart Time SHOULD NOT be greater than the HOLDTIME
> >    carried in the OPEN.
> > 
> >    In the following sections, "Restarting Speaker" refers to a router
> >    whose BGP has restarted, and "Receiving Speaker" refers to a router
> >    that peers with the restarting speaker.
> > 
> >    Consider that the Graceful Restart Capability for an address family
> >    is advertised by the Restarting Speaker, and is understood by the
> >    Receiving Speaker, and a BGP session between them is established.
> >    The following sections detail the procedures that shall be followed
> >    by the Restarting Speaker as well as the Receiving Speaker once the
> >    Restarting Speaker restarts.
> > 
> ...
> >
> > 
> > 6.2. Procedures for the Receiving Speaker
> > 
> >    When the Restarting Speaker restarts, the Receiving Speaker may or
> >    may not detect the termination of the TCP session with the Restarting
> >    Speaker, depending on the underlying TCP implementation, whether or
> >    not [BGP-AUTH] is in use, and the specific circumstances of the
> >    restart.  In case it does not detect the TCP reset and still
> >    considers the BGP session as being established, it shall treat the
> >    subsequent open connection from the peer as an indication of TCP
> >    reset and act accordingly (when the Graceful Restart Capabilty has
> >    been received from the peer).
> 
> How does this work together with the connection collision mechanism?

what do you think is the problem here ?

> >    When the Receiving Speaker detects TCP reset for a BGP session with a
> >    peer that has advertised the Graceful Restart Capability, it shall
> >    retain the routes received from the peer for all the address families
> >    that were previously received in the Graceful Restart Capability, and
> >    shall mark them as stale routing information. To deal with possible
> >    consecutive restarts, a route (from the peer) previously marked as
> >    stale shall be deleted. The router should not differentiate between
> >    stale and other routing information during forwarding.
> > 
> >    In re-establishing the session, the "Restart State" bit in the
> >    Graceful Restart Capability of the OPEN message sent by the Receiving
> >    Speaker shall not be set unless the Receiving Speaker has restarted.
> >    The presence and the setting of the "Forwarding State" bit for an
> >    address family depends upon the actual forwarding state and
> >    configuration.
> > 
> >    If the session does not get re-established within the "Restart Time"
>    that the peer advertised previously, the Receiving Speaker shall
> >    delete all the stale routes from the peer that it is retaining.
> > 
> >    Once the session is re-established, if the "Forwarding State" bit for
> >    an address family is not set in the received Graceful Restart
> >    Capability, or if the capability is not received for an address
> >    family, the Receiving Speaker shall immediately remove all the stale
> >    routes from the peer that it is retaining for that address family.
> 
> Does the phrase "is not received" mean "not confirmed by the new capability
> announcement"?

the phrase "is not received" means exactly what it said - not received.

> >    The Receiving Speaker shall send the End-of-RIB marker once it
> >    completes the initial update for an address family (including the
> >    case that it has no routes to send) to the peer.
> > 
> >    The Receiving Speaker shall replace the stale routes by the routing
> >    updates received from the peer. Once the End-of-RIB marker for an
> >    address family is received from the peer, it shall immediately remove
> >    any routes from the peer that are still marked as stale for that
> >    address family.
> 
> I don't think the procedure for "unmarking" routes as stale has
> been described here.

there is no "unmarking" of stale routes. A stale route is either
(a) replaced by the routing update received from the peer, or (b)
deleted once the End-of-RIB marker is received.

Yakov.

Date: Fri, 3 May 2002 10:37:37 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Last Call concerns (again): Extended Communities
Sender: [email-masked]

I've been asked to bring these concerns to the list again one last time.
If no one else has the conerns, I'm happy to yield on the issue.

The base BGP communities specification deals with aggregation by saying:

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

As we all know, ATOMIC_AGGREGATE isn't well defined enough to actually
do enough useful things, and isn't implemented by most of the major
distributions.

As a result, BGP communities simply end up aggregated as a union of
the elements in the community sets.

(This is another gripe with the base spec - communities are treated as
a set and thus no duplicates are needed, and implementations seem
to prune duplicates, but this isn't spelled out anywhere.)

The problem with synthesizing aggregates is that if aggregate component
R1 has some communities C1, and we have an R2, C2 that is another
contributing component, the resulting aggregate A1 will have the
union of C1 and C2.  Some elements of C1 or C2 may not be applicable
towards the various components of A1.  Taking the intersection would
have been saner IMO.

One example that immediately comes to mind is if C1 has NO_EXPORT
and C2 has NO_ADVERTISE, then A1 will have NO_EXPORT and NO_ADVERTISE.
If the contributing components are not propagated (where the communities
permit them) within the same AS, A1 will not be advertised to any other
routers whereas the component covered by R1,C1 should have been.

One might argue that this is a feature and this argues that communites
should be stripped or otherwise manipulated prior to insertion into
an aggregate.

The extended communities specification introduces similar special
communities with special properties.  In particular, Route Origin
is used by PPVPN's 2547-bis to prevent the route from being re-advertised
to a site.  From the current 2547-bis spec:

: 8. How CEs learn Routes from PEs
: 
:    back to the CE.)  We add one more restriction on the distribution of
:    routes from PE to CE: if a route's Site of Origin attribute
:    identifies a particular site, that route must never be redistributed
:    to any CE at that site.

This property is never documented in the base specification.  At
the very least, it should be mentioned that in the context of 2547
that this community will have special semantics.  It would also be
nice for operators for the aggregation issues to be explicitly documented.

Similarly, the Link Bandwidth extended community has special semantics -
namely:

:    When a router receives a route from a directly connected external
:    neighbor (the external neighbor that is one IP hop away), and
:    advertises this route (via IBGP) to internal neighbors, as part of
:    this advertisement the router may carry the bandwidth of the link
:    that connects the router with the external neighbor. The bandwidth of
:    such a link is carried in the Link Bandwidth Community. The community

I don't believe this attribute should be aggregatable.

Lastly, the extended communities document should have a section similar
to the aggregation section of the base communities document.

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Subject: draft-ietf-idr-as4bytes-05.txt
Date: Fri, 03 May 2002 07:03:51 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The only changes are (a) version number increment, (b) updates dates.

Yakov.
------- Forwarded Message

Date:    Fri, 03 May 2002 07:28:33 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-as4bytes-05.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		: BGP support for four-octet AS number space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-05.txt
	Pages		: 7
	Date		: 02-May-02
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-05.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-as4bytes-05.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-as4bytes-05.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-as4bytes-05.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-as4bytes-05.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: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-filter-06.txt
Date: Fri, 03 May 2002 07:28:42 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Cooperative Route Filtering Capability for BGP-4
	Author(s)	: E. Chen, Y. Rekhter
	Filename	: draft-ietf-idr-route-filter-06.txt
	Pages		: 11
	Date		: 02-May-02
	
This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of route filters that the peer would
use to constrain/filter its outbound routing updates to the speaker.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-06.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-route-filter-06.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-route-filter-06.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-route-filter-06.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-as4bytes-05.txt
Date: Fri, 03 May 2002 07:28:33 -0400
Sender: [email-masked]

--NextPart

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

	Title		: BGP support for four-octet AS number space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-05.txt
	Pages		: 7
	Date		: 02-May-02
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-05.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-as4bytes-05.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-as4bytes-05.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-as4bytes-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 2 May 2002 20:18:52 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

Please find some comments on the restart draft below.
Regards.

-- 
Alex

Meta-comments:

 - Can the restart capability be dynamically updated?

 - How does this doc address the situation where the admin wants
   the graceful restart to happen for planned restarts
   (during SW upgrades, etc.) but not for unplanned ones?

>                    Graceful Restart Mechanism for BGP
> 
>                      draft-ietf-idr-restart-03.txt
...
> 4. Marker for End-of-RIB
> 
>    An UPDATE message with empty withdrawn NLRI is specified as the End-
>    Of-RIB Marker that can be used by a BGP speaker to indicate to its
>    peer the completion of the initial routing update after the session
>    is established. For IPv4 unicast address family, the End-Of-RIB
>    Marker is an UPDATE message with the minimum length [BGP-4].

I guess this implicitly means that no reachable NLRIs and attributes
should be in it. Why not say this explicitly?

> For any
>    other address family, it is an UPDATE message that contains only
>    MP_UNREACH_NLRI [BGP-MP] with no withdrawn routes for that <AFI, Sub-
>    AFI>.

Does it mean we need to send a separate message per AFI/SAFI?

> 5. Graceful Restart Capability
> 
>    The Graceful Restart Capability is a new BGP capability [BGP-CAP]
>    that can be used by a BGP speaker to indicate its ability to preserve
>    its forwarding state during BGP restart. It can also be used to
>    convey to its peer its intention of generating the End-Of-RIB marker
>    upon the completion of its initial routing updates.
> 
>    This capability is defined as follows:
> 
>        Capability code: 64
> 
>        Capability length: variable
> 
>        Capability value: Consists of the "Restart Flags" field,
>        "Restart Time" field, and zero or more of the tuples <AFI,
>        Sub-AFI, Flags for address family> as follows.
> 
> 
>            +--------------------------------------------------+
>            | Restart Flags (4 bits)                           |
>            +--------------------------------------------------+
>            | Restart Time in seconds (12 bits)                |
>            +--------------------------------------------------+

I think that given the bit level break-up you should show
the header in the normal IETF format.

>            | Address Family Identifier (16 bits)              |
>            +--------------------------------------------------+
>            | Subsequent Address Family Identifier (8 bits)    |
>            +--------------------------------------------------+
>            | Flags for Address Family (8 bits)                |
>            +--------------------------------------------------+
>            | ...                                              |
>            +--------------------------------------------------+
>            | Address Family Identifier (16 bits)              |
>            +--------------------------------------------------+
>            | Subsequent Address Family Identifier (8 bits)    |
>            +--------------------------------------------------+
>            | Flags for Address Family (8 bits)                |
>            +--------------------------------------------------+
> 
> 
>    The use and meaning of the fields are as follows:
> 
>      Restart Flags:
> 
>        This field contains bit flags related to restart.
> 
>        The most significant bit is defined as the Restart State bit
>        which can be used to avoid possible deadlock caused by waiting
> 
> 
> 
> draft-ietf-idr-restart-03.txt                                   [Page 3]
> 
> 
> 
> 
> 
> Internet Draft        draft-ietf-idr-restart-03.txt           April 2002
> 
> 
>        for the End-of-RIB marker when multiple BGP speakers peering
>        with each other restart. When set (value 1), this bit indicates
>        that the BGP speaker has restarted, and its peer should not wait
>        for the End-of-RIB marker from the speaker before advertising
>        routing information to the speaker.
> 
>        The remaining bits are reserved.

...and this text should correspond to the illustration of the header
above

should the reserved bits be set to 0?

> 
>      Restart Time:
> 
>        This is the estimated time (in seconds) it will take for the BGP
>        session to be re-established after a restart. This can be used to
>        speed up routing convergence by its peer in case that the BGP
>        speaker does not come back after a restart.
> 
>      Address Family Identifier (AFI):
> 
>        This field carries the identity of the Network Layer protocol
>        for which the Graceful Restart support is advertised. Presently
>        defined values for this field are specified in RFC1700 (see
>        the Address Family Numbers section).
> 
>      Subsequent Address Family Identifier (Sub-AFI):
> 
>        This field provides additional information about the type of
>        the Network Layer Reachability Information carried in the
>        attribute.
> 
>      Flags for Address Family:
> 
>        This field contains bit flags for the <AFI, Sub-AFI>.
> 
>        The most significant bit is defined as the Forwarding State
>        bit which can be used to indicate if the forwarding state for
>        the <AFI, Sub-AFI> has indeed been preserved during the previous
>        BGP restart. When set (value 1), the bit indicates that the
>        forwarding state has been preserved.
> 
>        The remaining bits are reserved.

Let's have a format illustration for this field as well.
It will help when/if new bits are introduced.

same comment about "reserved"

>    The advertisement of this capability by a BGP speaker also implies
>    that it will generate the End-of-RIB marker (for all address families
>    exchanged) upon completion of its initial routing update to its peer.
>    The value of the "Restart Time" field is irrelevant in the case that
>    the capability does not carry any <AFI, Sub-AFI>.

Do we need some more info here? I.e., what does it really mean
when I receive this capability with no AFI/SAFI in it?

> 6. Operation
> 
>    A BGP speaker may advertise the Graceful Restart Capability for an
>    address family to its peer only if it has the ability to preserve its
>    forwarding state for the address family when BGP restarts.
> 
>    Even if the speaker does not have the ability to preserve its
>    forwarding state for any address family during BGP restart, it is
>    still recommended that the speaker advertise the Graceful Restart
>    Capability to its peer to indicate its intention of generating the
>    End-of-RIB marker upon the completion of its initial routing updates.

Ah, I think this is the answer to my prev. question. The text above
should have some info nonetheless, IMO.

>    The End-of-RIB marker should be sent by a BGP speaker to its peer
>    once it completes the initial routing update (including the case when
>    there is no update to send) for an address family after the BGP
>    session is established.
> 
>    It is noted that the normal BGP procedures MUST be followed when the
>    TCP session terminates due to the sending or receiving of a BGP
>    NOTIFICATION message.
> 
>    In general the Restart Time SHOULD NOT be greater than the HOLDTIME
>    carried in the OPEN.
> 
>    In the following sections, "Restarting Speaker" refers to a router
>    whose BGP has restarted, and "Receiving Speaker" refers to a router
>    that peers with the restarting speaker.
> 
>    Consider that the Graceful Restart Capability for an address family
>    is advertised by the Restarting Speaker, and is understood by the
>    Receiving Speaker, and a BGP session between them is established.
>    The following sections detail the procedures that shall be followed
>    by the Restarting Speaker as well as the Receiving Speaker once the
>    Restarting Speaker restarts.
> 
...
>
> 
> 6.2. Procedures for the Receiving Speaker
> 
>    When the Restarting Speaker restarts, the Receiving Speaker may or
>    may not detect the termination of the TCP session with the Restarting
>    Speaker, depending on the underlying TCP implementation, whether or
>    not [BGP-AUTH] is in use, and the specific circumstances of the
>    restart.  In case it does not detect the TCP reset and still
>    considers the BGP session as being established, it shall treat the
>    subsequent open connection from the peer as an indication of TCP
>    reset and act accordingly (when the Graceful Restart Capabilty has
>    been received from the peer).

How does this work together with the connection collision mechanism?

>    When the Receiving Speaker detects TCP reset for a BGP session with a
>    peer that has advertised the Graceful Restart Capability, it shall
>    retain the routes received from the peer for all the address families
>    that were previously received in the Graceful Restart Capability, and
>    shall mark them as stale routing information. To deal with possible
>    consecutive restarts, a route (from the peer) previously marked as
>    stale shall be deleted. The router should not differentiate between
>    stale and other routing information during forwarding.
> 
>    In re-establishing the session, the "Restart State" bit in the
>    Graceful Restart Capability of the OPEN message sent by the Receiving
>    Speaker shall not be set unless the Receiving Speaker has restarted.
>    The presence and the setting of the "Forwarding State" bit for an
>    address family depends upon the actual forwarding state and
>    configuration.
> 
>    If the session does not get re-established within the "Restart Time"
>    that the peer advertised previously, the Receiving Speaker shall
>    delete all the stale routes from the peer that it is retaining.
> 
>    Once the session is re-established, if the "Forwarding State" bit for
>    an address family is not set in the received Graceful Restart
>    Capability, or if the capability is not received for an address
>    family, the Receiving Speaker shall immediately remove all the stale
>    routes from the peer that it is retaining for that address family.

Does the phrase "is not received" mean "not confirmed by the new capability
announcement"?

>    The Receiving Speaker shall send the End-of-RIB marker once it
>    completes the initial update for an address family (including the
>    case that it has no routes to send) to the peer.
> 
>    The Receiving Speaker shall replace the stale routes by the routing
>    updates received from the peer. Once the End-of-RIB marker for an
>    address family is received from the peer, it shall immediately remove
>    any routes from the peer that are still marked as stale for that
>    address family.

I don't think the procedure for "unmarking" routes as stale has
been described here.

>    To put an upper bound on the amount of time a router retains the
>    stale routes, an implementation may support a (configurable) timer
>    that imposes this upper bound.

Date: Thu, 02 May 2002 19:17:50 -0400
To: "Ken Benstead" <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: BGP-4 MIBv2 NLRI Table
Cc: <[email-masked]>
Sender: [email-masked]

Ken:

Why do you expect the Prefix before the prefix length?

sue

At 01:29 PM 4/22/2002 -0400, Ken Benstead wrote:
>Hi Folks,
>I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the
>following index clause:
>
>       INDEX {
>             bgpM2PeerIndex,
>             bgpM2NlriAfi,
>             bgpM2NlriSafi,
>             bgpM2NlriPrefixLen,
>             bgpM2NlriPrefix,
>             bgpM2NlriIndex
>             }
>
>Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix
>objects are the opposite order to what one might normally expect?
>For example, in the BGP-4 Received Path Attribute Table of
>RFC1657 the index clause is:
>
>
>       INDEX {
>             bgp4PathAttrIpAddrPrefix,
>             bgp4PathAttrIpAddrPrefixLen,
>             bgp4PathAttrPeer
>             }
>
>Thanks,
>Ken Benstead

To: Bill Fenner <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Last call on Graceful Restart 
Date: Wed, 01 May 2002 11:56:32 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Bill:
Thanks for your comments. We will take care of them and submit a
version.

-- Enke

> From: Bill Fenner <[email-masked]>
> Received: (from fenner@localhost)
> 	by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA03963;
> 	Wed, 1 May 2002 10:21:36 -0700 (PDT)
> Message-Id: <[email-masked]>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> To: [email-masked]
> Subject: Re: Last call on Graceful Restart
> Date: Wed, 1 May 2002 10:21:35 -0700
> Versions: dmail (solaris) 2.4/makemail 2.9b
> Sender: [email-masked]
> Precedence: bulk
> 
> 
> A couple of comments on the Graceful Restart draft.
> 
> The biggest problem is that the first two paragraphs of section 6
> are contradictory: The first says that you may only advertise
> graceful restart if you can preserve forwarding state; the second
> says to advertise it anyway.  I think changing the first sentence
> to start "A BGP speaker should advertise..." and removing the word
> "only" gets rid of the contradiction.
> 
> RFC2842bis says that the document defining a capability needs to say
> what happens if multiple instances of the capability are advertised
> with different values; persumably this can happen in section 5.
> 
> The document uses the RFC2119 key words without defining them; however it
> uses them a total of twice, at the beginning of section 6; the document
> has other places where it may want to use these requirements
> terms in order to make the meaning clear.  I see two options:
> - Reference 2119 and sweep through the document converting the pieces
>   that are required for the protocol to 2119-ese.
> - Change the MUST and SHOULD NOT in section 6 to lowercase, to avoid
>   confusion
> 
> Section 5's reference for AFI shouldn't be to the obsolete rfc 1700
> (see RFC 3232); in this case the reference should be to
> http://www.iana.org/assignments/address-family-numbers .  It should
> also have a reference to http://www.iana.org/assignments/safi-namespace
> for the SAFI numbers.
> 
> The references to 2283 and 2842 could be updated to 2858 and 2842bis.
> (It's OK to reference 2842bis because it's already approved by the
> IESG and so will have an RFC number already by the time this gets
> published).
> 
>   Bill

Date: Wed, 1 May 2002 14:50:40 -0400
From: Shane Wright <[email-masked]>
To: Bill Fenner <[email-masked]>
Cc: [email-masked]
Subject: Re: Last call on Graceful Restart
Sender: [email-masked]

On Wed, May 01, 2002 at 10:21:35AM -0700, Bill Fenner wrote:
> 
> A couple of comments on the Graceful Restart draft.
> 
> The biggest problem is that the first two paragraphs of section 6
> are contradictory: The first says that you may only advertise
> graceful restart if you can preserve forwarding state; the second
> says to advertise it anyway.  I think changing the first sentence
> to start "A BGP speaker should advertise..." and removing the word
> "only" gets rid of the contradiction.

Hi Bill,

What the document is trying to say in the second paragraph is that the
graceful restart capability can be sent with no address families in the case
where you want to only send End-of-RIB messages.  Advertising the capability
with an address family implies that you are able to gracefully restart for
that family.  

- Shane Wright

From: Bill Fenner <[email-masked]>
To: [email-masked]
Subject: Re: Last call on Graceful Restart
Date: Wed, 1 May 2002 10:21:35 -0700
Versions: dmail (solaris) 2.4/makemail 2.9b
Sender: [email-masked]

A couple of comments on the Graceful Restart draft.

The biggest problem is that the first two paragraphs of section 6
are contradictory: The first says that you may only advertise
graceful restart if you can preserve forwarding state; the second
says to advertise it anyway.  I think changing the first sentence
to start "A BGP speaker should advertise..." and removing the word
"only" gets rid of the contradiction.

RFC2842bis says that the document defining a capability needs to say
what happens if multiple instances of the capability are advertised
with different values; persumably this can happen in section 5.

The document uses the RFC2119 key words without defining them; however it
uses them a total of twice, at the beginning of section 6; the document
has other places where it may want to use these requirements
terms in order to make the meaning clear.  I see two options:
- Reference 2119 and sweep through the document converting the pieces
  that are required for the protocol to 2119-ese.
- Change the MUST and SHOULD NOT in section 6 to lowercase, to avoid
  confusion

Section 5's reference for AFI shouldn't be to the obsolete rfc 1700
(see RFC 3232); in this case the reference should be to
http://www.iana.org/assignments/address-family-numbers .  It should
also have a reference to http://www.iana.org/assignments/safi-namespace
for the SAFI numbers.

The references to 2283 and 2842 could be updated to 2858 and 2842bis.
(It's OK to reference 2842bis because it's already approved by the
IESG and so will have an RFC number already by the time this gets
published).

  Bill

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-aspath-orf-02.txt
Date: Wed, 01 May 2002 07:26:06 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-02.txt
	Pages		: 
	Date		: 30-Apr-02
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-02.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-aspath-orf-02.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-aspath-orf-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-aspath-orf-02.txt

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

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

--OtherAccess--

--NextPart--