Subject: RE: RE: Re: suggestions for draft-ietf-idr-restart-01
From: "Srihari R. Sangli" <[email-masked]>
To: "Waters, Stephen" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Thu, 26 Jul 2001 15:05:09 -0700 (PDT)

> 
> When a peer does not send the Graceful restart capability, does that mean
> that there is no point saving state?

To extend the life of the box as a 'forwarding device' when BGP has crashed,
in some topologies it may be useful to keep the state. See the Deployment 
section of the draft for some insight.

> For example,
> 
> If peer A sends the Graceful Restart capability to preserve IP IV to peer B,
> but peer B does not send the GR cap, and then peer A restarts, is there any
> point peer A doing the GR 'Restarting side' stuff, since it would appear
> that peer B will not merely mark A's routes as stale, but will delete them
> on detecting a failure or restart?

Like I said above, there may be benefit in A doing the 'Restarting side' 
stuff which is going to be useful if B has not detected failure yet. Once 
A learns that B is not GR capable - this is equivalent to B being 
capable but was also restarted (see simulataneous restart case in the 
draft). I would do treat them similarly.

> If peer B knows nothing about GR, then if peer A 'guessed' that it did, that
> would cause delay in routes know to A being re-learnt by B since it may wait
> for an End-Of-RIB from B and B would have no 'old' routes to work with.

No. 

You may want to classify the peers as GR-capable and non-GR-capable/
restarted and hence do not wait for End-of-RIB from the second group of peers.
So the 'guess work' is not needed.

This section has been updated in the draft based on recent email discussion.

srihari...

Date: Thu, 26 Jul 2001 14:30:28 -0700 (PDT)
From: "Srihari R. Sangli" <[email-masked]>
To: "Waters, Stephen" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: suggestions for draft-ietf-idr-restart-01
Sender: [email-masked]

> And in the case where AFIs are present, but the restart timer value is zero?
> Unless otherwise stated, this would be read to mean that the peer intends to
> recover instantly, 

Yes.

> which is going to difficult given the TCP/BGP opening
> game..

Yes, most of the time.

> I am assuming the Restart Timer will be started when a TCP or BGP failure is
> spotted (TCP error or HOLD TIME timer). If the Restart Timer expires, then
> the non-restarting peer gives up on the peer flushes all routes learnt.  

True. But exceptions are when a BGP peer is using MD5 like 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.

> When would the Restart timer be 'stopped'?  When a new TCP
> connection/OPEN-message arrives from the failed peer?

TCP connection establishment. We can clarify this in the draft.

> A value of zero would seem to be useless, and should either have a special
> meaning (as originally suggested), or be illegal. 
> 

Making it illegal will not buy us anything IMO. It may add a mimimum 
delay in convergence when you know you should have come up instantly, but 
could not (in the multi-RP case we talked about before).

> It does make me think that most sane implementations should impose a
> lower-limit on this value - a value that will presumably need to be
> system/model specific to allow for various architectures and their recovery
> rate.

Yes. Its completely optional.

srihari...

Date: Fri, 20 Jul 2001 13:52:14 -0700 (PDT)
From: "Srihari R. Sangli" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: RE: Re: suggestions for draft-ietf-idr-restart-01
Sender: [email-masked]

> But the switch-over from the primary controller to the secondary
> controller could also be planned. For example, you could have put a new
> release of software on the secondary controller and they you might type
> some "switch now" command to switch over to the secondary controller. In
> this scenario, it is very plausible that the primary controller might try
> to gracefully close the BGP sessions by sending a CEASE NOTIFICATION.

The problem can be solved w/o sending the CEASE notification here and 
rely on the mechanims specified in the draft.

CEASE notification are useful if one wants to override the behaviour 
specified in the draft. (i.e. to get rid of the routes when a router is 
being taken out of service)

> According to this draft it MUST not do that (because if it would, the
> other side would not keep the routes and mark them as stale). We might
> introduce a "I-am-going-to-switch-over-now" NOTIFICATION specifically for
> this purpose. 

I don't see the need. See above.

srihari...

Date: Fri, 20 Jul 2001 16:16:44 -0400
From: [email-masked]
To: "Srihari R. Sangli" <[email-masked]>
Cc: [email-masked]
Subject: RE: RE: Re: suggestions for draft-ietf-idr-restart-01
Sender: [email-masked]

>> ***> I was looking for some more specific statement of what it was that
>> you are *not* supposed to do when you receive a notification (e.g. keep
>> routes and mark them as stale). But if that is obvious to everyone, I
>> guess it is not needed. 
>
>I think its obvious. NOTIFICATIONs are sent when errors are encountered.
>That quite explains it.

Except the CEASE NOTIFICATION which is not sent as a result of an error. 

If a primary controller crashes and you switch over to a secondary controller as a result of that, the (crashed) primary controller is obviously not going to send any NOTIFICATION.

But the switch-over from the primary controller to the secondary controller could also be planned. For example, you could have put a new release of software on the secondary controller and they you might type some "switch now" command to switch over to the secondary controller. In this scenario, it is very plausible that the primary controller might try to gracefully close the BGP sessions by sending a CEASE NOTIFICATION. According to this draft it MUST not do that (because if it would, the other side would not keep the routes and mark them as stale). We might introduce a "I-am-going-to-switch-over-now" NOTIFICATION specifically for this purpose.

R.

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Date: Fri, 20 Jul 2001 12:32:18 -0700 (PDT)
From: "Srihari R. Sangli" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: Re: suggestions for draft-ietf-idr-restart-01
Sender: [email-masked]

> ***> Ah! I missed that part. So, just to make sure we're on the same
> page: If I send the capability without any AFI/SAFI I am indicating that
> I will send an End-of-RIB marker for all address families but I am not
> capable of preserving forwarding state for any address family. And, if I
> send the capability with only AFI=ipv4 SAFI=unicast I am saying that I
> will send the end-of-rib marker for all (!) address families but I can
> only preserve forwarding state for the ipv4-unicast address family (but
> not for ipv4 multicast or ipv6 unicast). 

Yes.

I can see the why its confusing. May be we should add "will generate 
End-of-RIB marker for all address familiy(s) exchanged". Will update the 
draft.

> ***> I was looking for some more specific statement of what it was that
> you are *not* supposed to do when you receive a notification (e.g. keep
> routes and mark them as stale). But if that is obvious to everyone, I
> guess it is not needed. 

I think its obvious. NOTIFICATIONs are sent when errors are encountered.
That quite explains it.

srihari...

Date: Fri, 20 Jul 2001 15:02:03 -0400
From: [email-masked]
To: "Srihari R. Sangli" <[email-masked]>
Cc: [email-masked]
Subject: RE: Re: suggestions for draft-ietf-idr-restart-01
Sender: [email-masked]

"Srihari R. Sangli" <[email-masked]> wrote:

See inline comments ***> below

Thanks for your clarifications -- R.

>
>
>> Would it make sense to make the following changes to draft-ietf-idr-restart-01?
>> 
>> < CHANGE 1 >
>> 
>> OLD:
>> 
>>     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.
>> 
>> NEW:
>> 
>>     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. A restart time of 
>>       zero indicates that the BGP speaker will generate an End-Of-RIB
>>       marker but is not able to preserve its forwarding state during
>>       a BGP restart.
>
>I don't think the above is necessary because its already taken care of in 
>the draft like below:
>
>    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.
>
>and
>
>    The advertisement of this capability by a BGP speaker also implies
>   that it will generate the End-of-RIB marker 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>.

***> Ah! I missed that part. So, just to make sure we're on the same page:
If I send the capability without any AFI/SAFI I am indicating that I will send an End-of-RIB marker for all address families but I am not capable of preserving forwarding state for any address family. And, if I send the capability with only AFI=ipv4 SAFI=unicast I am saying that I will send the end-of-rib marker for all (!) address families but I can only preserve forwarding state for the ipv4-unicast address family (but not for ipv4 multicast or ipv6 unicast).

>
>
>
>> 
>> < CHANGE 2 >
>> 
>> OLD:
>> 
>>   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). 
>> 
>> NEW:
>> 
>>   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 did not advertise the graceful restart capability). 
>
>Can be done. Will update the draft.

***> Thanks

>
>> 
>> < CHANGE 3 >
>> 
>> OLD:
>> 
>>   When the TCP reset is detected by the Receiving Speaker, it shall
>>   retain the routes received from the Restarting Speaker for all the
>>   address families that were previously received in the Graceful
>>   Restart Capability, and shall mark them as stale routing information.
>> 
>> NEW:
>> 
>>   When the TCP reset is detected by the Receiving Speaker, it shall
>>   retain the routes received from the Restarting Speaker for all the
>>   address families that were previously received in the Graceful
>>   Restart Capability, and shall mark them as stale routing information.
>> 
>>   However, if the peer advertised a restart time of zero (indicating
>>   that the peer is not able to preserve the forwarding state) it shall 
>>   not retain the  routes received from the Restarting Speaker and any
>>   routes from that peer previously marked as stale shall be deleted.
>
>I take the above is not needed. See above.

***> Agreed.

>> 
>> < CHANGE 4 >
>> 
>> Could some additional language be added to clarify the following statement?
>> 
>>   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.
>> 
>
>What needs to be clarified here. The draft does not change the 
>interpretation of existing NOTIFICATION message.

***> I was looking for some more specific statement of what it was that you are *not* supposed to do when you receive a notification (e.g. keep routes and mark them as stale). But if that is obvious to everyone, I guess it is not needed.

>srihari...
>
>> 
>> 
>> 
>> __________________________________________________________________
>> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
>> 
>> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
>> 
>> _______________________________________________
>> Idr-external mailing list
>> [email-masked]
>> http://mailist.procket.com/mailman/listinfo/idr-external
>> 
>

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Date: Fri, 20 Jul 2001 11:57:28 -0700 (PDT)
From: "Srihari R. Sangli" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: suggestions for draft-ietf-idr-restart-01
Sender: [email-masked]

> Would it make sense to make the following changes to draft-ietf-idr-restart-01?
> 
> < CHANGE 1 >
> 
> OLD:
> 
>     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.
> 
> NEW:
> 
>     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. A restart time of 
>       zero indicates that the BGP speaker will generate an End-Of-RIB
>       marker but is not able to preserve its forwarding state during
>       a BGP restart.

I don't think the above is necessary because its already taken care of in
the draft like below:

        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.

and

        The advertisement of this capability by a BGP speaker also implies
   that it will generate the End-of-RIB marker 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>.

> 
> < CHANGE 2 >
> 
> OLD:
> 
>   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). 
> 
> NEW:
> 
>   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 did not advertise the graceful restart capability). 

Can be done. Will update the draft.

> 
> < CHANGE 3 >
> 
> OLD:
> 
>   When the TCP reset is detected by the Receiving Speaker, it shall
>   retain the routes received from the Restarting Speaker for all the
>   address families that were previously received in the Graceful
>   Restart Capability, and shall mark them as stale routing information.
> 
> NEW:
> 
>   When the TCP reset is detected by the Receiving Speaker, it shall
>   retain the routes received from the Restarting Speaker for all the
>   address families that were previously received in the Graceful
>   Restart Capability, and shall mark them as stale routing information.
> 
>   However, if the peer advertised a restart time of zero (indicating
>   that the peer is not able to preserve the forwarding state) it shall 
>   not retain the  routes received from the Restarting Speaker and any
>   routes from that peer previously marked as stale shall be deleted.

I take the above is not needed. See above.

> 
> < CHANGE 4 >
> 
> Could some additional language be added to clarify the following statement?
> 
>   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.

What needs to be clarified here. The draft does not change the existing
interpretation of any message.

srihari...

> 
> 
> 
> 
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
> 
> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
> 
> _______________________________________________
> Idr-external mailing list
> [email-masked]
> http://mailist.procket.com/mailman/listinfo/idr-external
> 

Date: Fri, 20 Jul 2001 08:35:12 -0400
From: [email-masked]
To: [email-masked], [email-masked]
Subject: IPv6 RIB size?
Sender: [email-masked]

Does anyone have any experience with the number of and distribution of prefixes in an IPv6 network?

Imagine that we change every existing IPv4 host in the world to an IPv6 host. 

- Would we have more or less than the current 100K distinct prefixes in the BGP local-RIB? What about the number of paths (multi-homing is done differently)?

- What would the distribution of prefix lengths look like? For example, would we ever expect to see a prefix more specific than a /64 in the default-free zone?

Would these assumptions change if IPv6 has different kinds of hosts than IPv4 (e.g. cell phones and toasters instead of PCs)?

R.

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 19 Jul 2001 16:10:45 -0700 (PDT)
To: "Li, Eve" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: IPV4 NLRI & MP_REACH NLRI
Sender: [email-masked]

>>>>> "Eve" == Li, Eve <[email-masked]> writes:

    Eve> After looking through RFC 2858, it is not clear to me if a
    Eve> BGP4 packet can carry both MP_REACH_NLRI and regular IPv4
    Eve> NLRI. Can anyone clarify this issue?

    Eve> on page 16 of draft-ietf-idr-bgp4-12, it says: " All path
    Eve> attributes contained in a given UPDATE messages apply to the
    Eve> destinations carried in the Network Layer Reachability
    Eve> Information field of the UPDATE message. "

    Eve> This implies that there should never be both MP_REACH_NLRI
    Eve> and IPv4 NLRI in one packet.

If you have an update msgs that includes n attributes + an
MP_REACH_NLRI for an af other than ipv4 + NEXTHOP attr + nlri that msg
would apear to be consistent to all the rules.

    Eve> However, on page 5 of RFC2858, it says:

    Eve>    An UPDATE message that carries no NLRI, other than the one
    Eve> encoded in the MP_REACH_NLRI attribute, should not carry the
    Eve> NEXT_HOP attribute.  If such a message contains the NEXT_HOP
    Eve> attribute, the BGP speaker that receives the message should
    Eve> ignore this attribute.

    Eve> This seems to imply that it is OK to carry both MP_REACH_NLRI
    Eve> & IPv4 NLRI.

    Eve> If a BGP packet can carry both MP_REACH_NLRI attribute and
    Eve> regular IPv4 NLRI. How does the path attribute apply to both
    Eve> NLRIs? For example, suppose the path attribute contains
    Eve> extended community with Route Target Community as type
    Eve> field. Does this path attribute applies to both MP_reach_nlri
    Eve> and Ipv4 unicast nlri? Also, does MP_REACH_NLRI apply to the
    Eve> IPV4 NLRI.

The MP_REACH_NLRI is not an attribute per se... it is encoded as such
because attributes are the extensible encoding mechanism in update
msgs. But one should look at it as encoding extension to encode non
ipv4 unicast NLRI.

All attributes of an update apply to nlri and mp_reach_nlri except:

- mp_reach_nlri isn't really an attribute and as such doesn't apply to
  nlri.

- nexthop doesn't apply to mp_reach_nlri's as it is superceeded by the
  nexthop included in mp_reach (which would tend to be for a different
  address family anyway).

regards,
  Pedro.

Date: Thu, 19 Jul 2001 18:49:02 -0400
From: [email-masked]
To: [email-masked]
Subject: suggestions for draft-ietf-idr-restart-01
Sender: [email-masked]

Would it make sense to make the following changes to draft-ietf-idr-restart-01?

< CHANGE 1 >

OLD:

    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.

NEW:

    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. A restart time of 
      zero indicates that the BGP speaker will generate an End-Of-RIB
      marker but is not able to preserve its forwarding state during
      a BGP restart.

< CHANGE 2 >

OLD:

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

NEW:

  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 did not advertise the graceful restart capability). 

< CHANGE 3 >

OLD:

  When the TCP reset is detected by the Receiving Speaker, it shall
  retain the routes received from the Restarting Speaker for all the
  address families that were previously received in the Graceful
  Restart Capability, and shall mark them as stale routing information.

NEW:

  When the TCP reset is detected by the Receiving Speaker, it shall
  retain the routes received from the Restarting Speaker for all the
  address families that were previously received in the Graceful
  Restart Capability, and shall mark them as stale routing information.

  However, if the peer advertised a restart time of zero (indicating
  that the peer is not able to preserve the forwarding state) it shall 
  not retain the  routes received from the Restarting Speaker and any
  routes from that peer previously marked as stale shall be deleted.

< CHANGE 4 >

Could some additional language be added to clarify the following statement?

  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.

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

From: "Li, Eve" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: IPV4 NLRI & MP_REACH NLRI
Date: Thu, 19 Jul 2001 18:38:44 -0400
Sender: [email-masked]

-----Original Message-----
From: Li, Eve 
Sent: Wednesday, July 18, 2001 11:45 AM
To: [email-masked]
Subject: IPV4 NLRI & MP_REACH NLRI

After looking through RFC 2858, it is not clear to me if a BGP4 packet can
carry both MP_REACH_NLRI and regular IPv4 NLRI. Can anyone clarify this
issue? 

on page 16 of draft-ietf-idr-bgp4-12, it says: 
  " All path attributes contained
   in a given UPDATE messages apply to the destinations carried in the
   Network Layer Reachability Information field of the UPDATE message. "

This implies that there should never be both MP_REACH_NLRI and IPv4 NLRI in
one packet. 

However, on page 5 of RFC2858, it says: 

   An UPDATE message that carries no NLRI, other than the one encoded in
   the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
   If such a message contains the NEXT_HOP attribute, the BGP speaker
   that receives the message should ignore this attribute.

This seems to imply that it is OK to carry both MP_REACH_NLRI & IPv4 NLRI.  

If a BGP packet can carry both MP_REACH_NLRI attribute and regular IPv4
NLRI. How does the path attribute apply to both NLRIs? For example, suppose
the path attribute contains extended community with Route Target Community
as type field. Does this path attribute applies to both MP_reach_nlri and
Ipv4 unicast nlri? Also, does MP_REACH_NLRI apply to the IPV4 NLRI. 

Any clarifications? 

-eve

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: WG meeting
Date: Tue, 17 Jul 2001 09:29:13 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

We'll be meeting in London. Please send the proposed agenda items
to co-chairs (Sue Hares and myself).

Yakov.

Date: Tue, 17 Jul 2001 12:24:32 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Experiments on why the routing table is growing
Sender: [email-masked]

This is a very experimental draft that still may be of interest to 
IDR people who are interested not just that the BGP table is growing, 
but why it is growing.  It's coauthored by Elwyn Davies of Nortel 
(UK) and Loa Andersson of Utfors (Sweden).

We'd like to run over it briefly in London, and may have some early 
experimental data to present.

----------

	Title		: An Experimental Methodology for Analysis of Growth in
                           the Global Routing Table
	Author(s)	: H. Berkowitz et al.
	Filename	: draft-berkowitz-tblgrow-00.txt
	Pages		: 5
	Date		: 16-Jul-01

Measurements [3,4,5] have shown that the rate of growth of routes and
route instances in the default-free table have resumed exponential
growth, which had slowed to linear growth after the introduction of
CIDR [7].  This memorandum explores some analytical methods,
admittedly heuristic in most cases, to understand why growth is
faster than the simple rate of allocation. When accelerated growth
can be attributed to operational practices or poor understanding, it
may be possible to propose approaches to reducing the rate of table
explosion without reducing the services delivered to end users.

Date: Tue, 17 Jul 2001 12:23:14 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: New drafts on BGP convergence
Sender: [email-masked]

These new Internet Drafts are now standards track in the IETF 
Benchmarking Technology Working Group. Obviously, they relate closely 
to IDR, and we'd like to give a brief briefing in London, along with 
any experimental results we may have available by then.

These were coauthored by a multivendor team, including Alvaro Retana 
of Cisco, Marianne Lepp of Juniper, Sue Hares and Padma Krisnaswamy 
of Nexthop, and myself at Nortel.  Elwyn Davies (Nortel) should have 
some early experimental data available in the next couple of weeks, 
although this is to validate the methodology rather than make any 
direct comparisons of commercial routers.

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

	Title		: Terminology for Benchmarking External Routing
                           Convergence Measurements
	Author(s)	: H. Berkowitz et al.
	Filename	: draft-ietf-bmwg-conterm-00.txt
	Pages		:
	Date		: 16-Jul-01

This draft establishes terminology to standardize the description of
benchmarking methodology for measuring eBGP convergence in the control
plane of a single router. Future documents will address iBGP
convergence, the initiation of forwarding based on converged control
plane information and internet-wide convergence.

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

-------------------
         Title		: Benchmarking Methodology for Basic BGP Convergence
	Author(s)	: H. Berkowitz et al.
	Filename	: draft-ietf-bmwg-bgpbas-00.txt
	Pages		:
	Date		: 16-Jul-01

This draft establishes standards for measuring BGP convergence
performance. Its initial emphasis is on the control plane of single
BGP routers.  We do not address forwarding plane performance.

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

Date: Tue, 3 Jul 2001 14:57:01 -0400
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: John Engelhart <[email-masked]>, [email-masked]
Subject: Re: RFC 3065, confeds..
Sender: [email-masked]

On Tue, Jul 03, 2001 at 11:54:52AM -0700, Alex Zinin wrote:
> Except that I don't believe that "silently" is a correct behavior.
> The BGP speaker need to draw the administrator's attention by (at
> least) logging a message.

Apologies.  My error.

> > Alex also made additional suggestions about rules for modification
> > of the AS_PATH.  Without a mechanism to know the configuration of
> > your peer's confederation settings, these additions wouldn't work.
> > IMO,
> 
> Do you mean not sending AS_CONF_* out to an eBGP peer outside
> the confed?

Yes.

Upon reviewing the message in question, I misinterpreted announcing
things outside of the confederation as implying pre-knowledge
by a protocol mechanism that a peer was part of the confederation or not.
You didn't actually say that.

> Alex.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 3 Jul 2001 11:54:52 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Jeffrey Haas <[email-masked]>
Cc: John Engelhart <[email-masked]>, [email-masked]
Subject: Re: RFC 3065, confeds..
Sender: [email-masked]

Jeffrey,

> Add:

>    A BGP speaker receiving an AS_PATH attribute containing an
>    AS_CONFED_SEQUENCE or AS_CONFED_SET from a peer which is not
>    configured to be a member of its confederation SHALL <foo>.

> Where <foo> could either be:
>    generate a
>    notification message specifying an "UPDATE Message Error" and a sub-
>    code of "Malformed AS_PATH".

> Or:
>    silently discard the BGP route.

> The first case is what I would prefer given the current design of
> the BGP protocol.  The second case would possibly please the operational
> community.  Please see the most recent discussion on RFC-1771 on
> the NANOG list if you don't know what I'm talking about.  A polite 
> summary is, IDR should consider the implications of soft-failure
> in the presence of "Bad Routing Data".  

> Alex Z. suggested similar text using the latter behavior.

Except that I don't believe that "silently" is a correct behavior.
The BGP speaker need to draw the administrator's attention by (at
least) logging a message.

> Alex also made additional suggestions about rules for modification
> of the AS_PATH.  Without a mechanism to know the configuration of
> your peer's confederation settings, these additions wouldn't work.
> IMO,

Do you mean not sending AS_CONF_* out to an eBGP peer outside
the confed?

Alex.

> with the receiver-side filtering, the current modification
> rules are probably fine.

Date: Mon, 2 Jul 2001 19:56:55 +0000
From: Andrew Lange <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: John Engelhart <[email-masked]>, [email-masked]
Subject: Re: RFC 3065, confeds..
Sender: [email-masked]

On Mon, Jul 02, 2001 at 01:08:05PM -0400, Jeffrey Haas <[email-masked]> wrote:

> On Thu, Jun 28, 2001 at 01:21:50AM -0700, John Engelhart wrote:
> > Specifically, the above quoted section from the RFC is being interpreted
> > by Cisco and Juniper to mean that even if confederations aren't enabled
> > and configured, it's still valid to accept and pass them on to other IBGP
> > peers.
> 
> As noted by others, the issue is not the AS_PATH modification rules
> when re-advertising/originating routes, its the operational behavior
> on receipt.
> 
> IMO, the AS_PATH modification rules in the current RFC are fine.
> What we probably want is something along the lines of the following
> modification:
> 
> 6. Operation
> [...]
>    A BGP speaker receiving an AS_PATH attribute containing an
>    AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS
>    Number shall treat the path in the same fashion as if it had received
>    a path containing its own AS number.
> 
> Add:
> 
>    A BGP speaker receiving an AS_PATH attribute containing an
>    AS_CONFED_SEQUENCE or AS_CONFED_SET from a peer which is not
>    configured to be a member of its confederation SHALL <foo>.
> 
> Where <foo> could either be:
>    generate a
>    notification message specifying an "UPDATE Message Error" and a sub-
>    code of "Malformed AS_PATH".
> 
> Or:
>    silently discard the BGP route.
> 
> The first case is what I would prefer given the current design of
> the BGP protocol.  The second case would possibly please the operational
> community.  Please see the most recent discussion on RFC-1771 on
> the NANOG list if you don't know what I'm talking about.  A polite 
> summary is, IDR should consider the implications of soft-failure
> in the presence of "Bad Routing Data".  

I agree that the proper behavior is to drop the BGP session.  If the
session dampening specified in RFC-1771 is implemented, the impact of
the flapping would be progressively lessened.  I would also like to see
a toggle from the vendors that says "if session has flapped n times,
errdisable the session", but that is an implementation detail.

Silently discarding the route might work to remedy the problems of this 
specific bug, but it doesn't provide a good paradigm for generic handling
of malformed AS paths.  There is the general issue of not breaking the
protocol to fix the bugs.  Then there is the troubleshooting aspect:

Customer: "Why can't I get to www.foo.com?  It resolves to x.x.x.x/x."
NOC Engineer:  "I doesn't seem to be advertized anywhere."

With silent discard, reachiblity problems could be missed for long periods.

And, perhaps most importantly, we are already trusting our peers to an 
amazing extent (insert rant about the radb being sufficently unused to make
filtering major peers impossible), if the peer sends us one bad route, the
probablity that they are going to send us more than one goes up enough to
warrent not trusting them at all.

> Alex Z. suggested similar text using the latter behavior.
> 
> Alex also made additional suggestions about rules for modification
> of the AS_PATH.  Without a mechanism to know the configuration of
> your peer's confederation settings, these additions wouldn't work.
> IMO, with the receiver-side filtering, the current modification
> rules are probably fine.

Yes, the only viable options are dropping the session, or dropping the route.

Andrew

Date: Mon, 2 Jul 2001 13:20:10 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Previous work on TTL on bgp routes?
Sender: [email-masked]

On Mon, Jun 18, 2001 at 02:39:47PM -0400, Martin, Christian wrote:
> This is exactly what I was thinking of.  Is there interest in putting this
> in BGP?  This could significantly localize route table bloat in the
> Internet, but still allows for efficient TE in multihomed environments.

Someone has beaten us to it:

<draft-bonaventure-bgp-redistribution-00.txt>
Controlling the redistribution of BGP routes

Initial comments, already made to the author:

o The "append N-AS's by proxy" mechanism is nice, but it would be
  nicer if it was generic.
o The format of "cidr prefix/length" ebgp speakers field mechanism
  seems a little awkward, especially in the cases where the peering
  session is done over loopback interfaces or multi-hopped in some
  other fashion.

> -chris

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 2 Jul 2001 13:11:35 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: route reflection language change suggestion
Sender: [email-masked]

On Tue, Jun 26, 2001 at 12:52:02PM -0700, Alex Zinin wrote:
>   Something like the text below is what I meant. :)
>   We definitely don't want to make the spec a deployment
>   guidelines doc, but a small note is good.

Its not unreasonable to put together a deployment guidelines document
if the protocol gives you too much rope to hang yourself.
RFC 177[234] provide examples about talking about the uses of
BGP.  If we feel the need for a document on deployment of hierarchical
scaling solutions for BGP, a deployment document may be helpful.

I'd suggest coming to closure on the MED churn issue before
such a document is drafted.

> Alex Zinin

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 2 Jul 2001 13:08:05 -0400
From: Jeffrey Haas <[email-masked]>
To: John Engelhart <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC 3065, confeds..
Sender: [email-masked]

My apologies for making comments initially on this thread and not
having the time to follow up promptly.

On Thu, Jun 28, 2001 at 01:21:50AM -0700, John Engelhart wrote:
> Specifically, the above quoted section from the RFC is being interpreted
> by Cisco and Juniper to mean that even if confederations aren't enabled
> and configured, it's still valid to accept and pass them on to other IBGP
> peers.

As noted by others, the issue is not the AS_PATH modification rules
when re-advertising/originating routes, its the operational behavior
on receipt.

IMO, the AS_PATH modification rules in the current RFC are fine.
What we probably want is something along the lines of the following
modification:

6. Operation
[...]
   A BGP speaker receiving an AS_PATH attribute containing an
   AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS
   Number shall treat the path in the same fashion as if it had received
   a path containing its own AS number.

Add:

   A BGP speaker receiving an AS_PATH attribute containing an
   AS_CONFED_SEQUENCE or AS_CONFED_SET from a peer which is not
   configured to be a member of its confederation SHALL <foo>.

Where <foo> could either be:
   generate a
   notification message specifying an "UPDATE Message Error" and a sub-
   code of "Malformed AS_PATH".

Or:
   silently discard the BGP route.

The first case is what I would prefer given the current design of
the BGP protocol.  The second case would possibly please the operational
community.  Please see the most recent discussion on RFC-1771 on
the NANOG list if you don't know what I'm talking about.  A polite 
summary is, IDR should consider the implications of soft-failure
in the presence of "Bad Routing Data".  

Alex Z. suggested similar text using the latter behavior.

Alex also made additional suggestions about rules for modification
of the AS_PATH.  Without a mechanism to know the configuration of
your peer's confederation settings, these additions wouldn't work.
IMO, with the receiver-side filtering, the current modification
rules are probably fine.

-- 
Jeff Haas 
NextHop Technologies