WG minutes

[Yakov Rekhter <[e-mail]>]

Folks,

Attached are the WG minutes. Please review for correctness.
The deadline for review is next Monday.

Yakov.
----------------------------------------------------------

1. IDR Documents status update
   Y. Rekhter
   =======================
   See slides

   IDR Charter Update
   Y. Rekhter
   ===========================
   See Slides

2. draft-chavali-bgp-prefixlimit-00
   Sue Hares
   ================================

   The intent of this proposal is to provide a mechanism by which both
   peers can become aware of a prefix limit.  If the number of prefixes
   approaches the known limit, both peers can provide warning to their
   respective operators, and even if the limit is reached, both devices
   can behave in a manner to preserve network stability until the
   operators can address the cause of the excessive prefix condition.
   In addition, the option to terminate the session is retained in order
   to protect the BGP receiver, if the BGP sender ignores the limit.


   The basic function proposed here is for a BGP receiver which
   implements a limit on the number of prefixes which it will accept (a
   "maximum prefix limit") to send an advertisement of that limit to its
   peer BGP sender, at the time the peering session is initiated.  That
   is, a BGP receiver configured with a maximum-prefix limit notifies
   its peer BGP sender of the limit, so that the sender should
   automatically restrict the number of prefixes it announces, in order
   to comply with the limit.

   Three level response:
      90% generates warning
      at 100%, BGP speaker stops sending
      at 110%, BGP listener drops session


John Scudder: Three functions could support this feature now. These are:
remote logging, ORF, inform. You might want to collapse these functions into
existing proposals (ORF, inform).

Hares: Inform is not widely deployed.

Binam(?): I am surprised that providers do not maintain explicit import
policies that prevent them from accepting every route that a customer might
advertise.

Hares: VPN providers may not maintain such policies. (Note that a service
provider is among the authors.)

Enke Chen: Dropping after prefix limit is exceeded is a bad idea. It is
better to disable AFI. Current implementations only have warning and action
level. Draft should also have 2 levels.

Scudder: You only need one number. A limit.

Ash: We need this.

Bonica: We need three numbers; warning, speaker stops sending and listener
drops session.

3. draft-chen-bgp-avoid-collision-00
   Enke Chen
   ===================================

   To simplify the BGP session bringup logic, in this document we
   propose a revision that allows a BGP speaker to play only the active
   or the passive role in establishing a BGP connection with another BGP
   speaker.  A BGP speaker determines whether it will play the active or
   passive role based on the AS numbers and/or the peering addresses
   involved.

   Backward compatiblility required.
   Gracefull restart required.

Yakov: According to the spec, you must send an notification if you close due
to collision

Enke: All implementations don't do that

Rajeesh Kumar: If server detects connection is gone, it has to wait for
client to re-establish.

Hares: could be misconfigured?

Enke: No, larger AS number is active

Gargi: Proabability of connection collision first time is high.

Hakkivori: ?????

Jeff Pickering: problem with tie breaker using remote access. you may not
know your source address

Enke: disagress

pickering: you don't know that peers source will be what you send

Alex Zinin: we will have to support the old code for years

Enke: do randomn backoff

Alex Zinin: are you assuming that you won't have to support the old code?

Dan Indrieden: Active passive decision should be configured, not determined

Raj: does this make a difference, since there are only a few implementations
of BGP

Scudder: this is backward compatible.

4. draft-py-idr-redisfilter-00
   Michel Py
   =========

   What this draft is:

   A mechanism to distribute filtering information. Bogon filtering is only
one example of filtering
   information. The objective is to standardize the mechanism.

   Idea: re-use ORF mechanisms. The ORF specifications are not modified;
what is required is a syntax
   enhancement that is mostly a matter of implementation.


Scudder: 1)maye you want to publish this and do it. There isn't any new
protocol to standardize. 2) Have you looked at Pedro Marques flowspec
document? 3) Is the single server a single point of failure, target for
malicious attack

5. draft-nalawade-bgp-soft-notify-00
   Gargi Nalawade, Keyur Patel, John Scudder, David Ward
   ======================================================

   Currently there is no mechanism available for two BGP Speakers to
   communicate the occurrence of an error-condition other than through a
   BGP NOTIFICATION Message. The problem is that a NOTIFICATION message
   resets the peering session and terminates the connection. If a peer
   wants to gracefully recover from an error or wants to warn its peer
   about the occurrence of a BGP-related event, there is no mechanism
   currently available to do that.

   The proposed BGP SOFT-NOTIFICATION message is a mechanism to notify a
   remote peer of an error-condition or an event without resetting or
   terminating the BGP session. The purpose of this message is to
   provide the ability to soft-reset a particular AFI/SAFI without
   disrupting other BGP AFI/SAFIs or sections.

   - New Soft noticication message and soft notification ACK

   - Inform is for logging only; soft notification can also take an action

6. draft-nalawade-bgp-update-v2-00
   Gargi Nalawade, Himanshu Shah
   ============
   The current version of the BGP UPDATE Message has evolved from its
   original definition for IPv4 Unicast AFI/SAFI. The use of new
   AFI/SAFIs in BGP has caused the MP_REACH and MP_UNREACH attributes to
   be defined. But the attributes such as NEXTHOP still continued to
   apply only to IPv4 Unicast. It is only defined to carry an IPv4
   address. This has forced several workarounds over the years such as
   carrying the Nexthop corresponding to the AFI/SAFI inside the
   MP_REACH/MP_UNREACH attribute.

   Carrying non-IPv4 NLRIs in the MP_REACH/MP_UNREACH attribute itself
   is a workaround to the fact that the NLRI section only applies to
   IPv4 Unicast routes.

   Also, the current BGP UPDATE Message starts out as being generic such
   that it could apply to any AFI/SAFI - until an MP_REACH/MP_UNREACH
   section is encountered. Only then can it be decided whether to use
   the NEXTHOP attribute or the NEXTHOP encoded in the MP_REACH
   attribute as the applicable NEXTHOP.

   The MP_REACH/MP_UNREACH attribute needs to be successfully parsed to
   identify the AFI/SAFI to which the UPDATE Message applies. Thus, if
   there is an error in the section preceding the MP_REACH attribute,
   the whole BGP session and other AFI/SAFIs running on the same
   saession are impacted. This does not protect one AFI/SAFI from being
   impacted by the other AFI/SAFIs on the same session - in case of
   AFI/SAFI specific errors that make it impossible to parse the
   MP_REACH/ MP_UNREACH section.


   The proposed BGP UPDATE-v2 message proposes solving all of the
   above-mentioned problems. BGP UPDATE-v2 will enable separation of
   updates belonging to different AFI/SAFI and an error in attribute can
   be isolated to a particular AFI/SAFI.

7. draft-scudder-bgp-multisession
   John Scudder
   =============
   This specification augments "Multiprotocol Extensions for BGP-4"
   by proposing a mechanism to allow multiple sessions to be used
   between a given pair of BGP speakers.  Each session is used to
   transport routes for one or more AFI/SAFI.  This provides an
   alternative to the current MP-BGP approach of multiplexing routes
   for all AFI/SAFI onto a single connection.

   Use of this approach is expected to increase the robustness of the
   BGP protocol as it is used to support more and more diverse AFI/SAFI.


Discussion on (5), (6), and (7).
================================

Parantap: frightened by multiple afi/safis. frightened by amountof change 
to BGP.

Parantap: perhaps we could use reliable UDP, instead of making all
these changes to BGP.

Yakov: Would you be frightened by reliable UDP ?

Parantap: Then perhaps we could use unreliable UDP.

Yakov: Would you be frightened to use unreliable transport for
delivering incremental updates ?

Yakov: If folks are frightened by changes in BGP then
we should immediately stop the WG meeting, close the WG, and go
to the bar. That was greeted by a round of applause.

Scudder: design goal is to minimize number of changes to BGP

Gargi: ???/

Rahul: please compare and contrast the drafts? 2) Would like to see
discussion on percieved problem with multiple loopbacks. Why not?

Chavali: Confusion about deprication of existing notification messages.

Acee: Too many ways to group. Do we really need all of this flexibility?

Alex: if the length field is incorrect, can you trust the next PDU?

Yakov: if the legth field is incorrect, then Gargi's proposal
results in terminating BGP session for all the AFI/SAFI carried in the
session, thus failing to provide isolation among multiple AFI/SAFIs,
and therefore failing to provide isolation among different applications
that use BGP. In contrast, Scudder proposal does not have this problem as
different AFI/SAFI need not share the same BGP session.

Andrew Lang: ????

Enke: Passive active simplfies multiple session

Scudder: already simple, but wouldn make it worse