Re: Routing WG Minutes - RIPE 27, Dublin

[Carol Orange <]

Hi Anne, Joachim,

Anne Lord writes:

>> Below are the draft minutes for the Routing WG Meeting in Dublin as compiled
>> and agreed by Joachim and myself.  Any comments, questins etc are gratefully
>> recieved and should be sent to the list.

What great notes! I've finally had a chance to review them. I've 
inserted a few comments/adjustments.  My memory may of course be 
faulty, so forgive any errors please.

Greetings, 

Carol
 
>> RIPE 27    : Routing WG Draft Minutes
>> Chair      : Joachim Schmitz (JS395-RIPE)
>> Scribe     : Anne Lord (AL12-RIPE)
>> Attenders  : 57
>> 
>> 1. Preliminaries
>> 
>>    Joachim Schmitz opened the working group and asked for a volunteer
>>    scribe. Anne Lord volunteered as scribe.
>> 
>>    Review of RIPE 26 minutes 
>> 
>>    The minutes of the last working group had been previously circulated 
>>    to the mailing list.  These minutes were agreed as final and closed.
>> 
>>    Review of actions RIPE 26 
>> 
>>    Action 22.10 : J. Schmitz 
>>      Future tool development project -  closed.
>>      (was discussed during the working group meeting itself)
>> 
>>    Action 25.R1 : D.Karrenberg 
>>      Route aggregation analysis - open.  
>> 
>>      Due to lack of time this has not been progressed. Volunteers to run
>>      scripts or do further development were asked for - they should
>>      contact Daniel Karrenberg. The present tool does slightly more than
>>      Tony Bates' aggregation report which looks at announcements being
>>      made. Daniel's tool actually emails originators with a "how to fix"
>>      mail.
>> 
>>    Action 26.R1 : RIPE NCC
>>      Add link to CIDR FAQ on RIPE web server - done.
>> 
>>    Action 26.R2 : J. Schmitz 
>>      Trigger implementation of first elements of hierarchical authorisation
>>      for route objects - done.
>> 
>>    Action 26.R3 : J. Schmitz
>>      Finalise hierarchical authorisation for route objects - ongoing.
>> 
>>    Action 26.R4 : E.J. Bos
>>      Circulate URL of his analysis of routing table size - done.
>>      (ftp://ftp.surfnet.nl/surfnet/net-management/ip/nets.ps)
>> 
>>    Action 26.R5 : C. Panigl
>>      Collect reasonable route flap dampening parameter values - done. 
>>      (was discussed during the working group meeting itself)
>> 
>>    Current developments
>>    
>>    Joachim reported briefly 2 working groups within the IETF that
>>    are relevant to the work of the Routing WG.
>> 
>>    * RPS  - Routing Policy Systems
>> 
>>      Chairs are : Daniel Karrenberg and Cengiz Alaettinoglu
>>      http://www.ietf.org/html.charters/rps-charter.html
>> 
>>      The RPS working group wants to develop and propagate tools and
>>      methods to analyse and describe routing policies. One major project
>>      is RPSL "routing policy specification language". This is relevant
>>      for the Routing WG because they plan to switch from ripe-181 format
>>      for the routing registry to RPSL this year. The second version of
>>      an Internet draft on RPSL is already available.
>> 
>>    * RIDE - Registry Information Data Exchange
>> 
>>      Chairs are : David Kessens and Dhaval Shah
>> 
>>      This group is looking at ways of exchanging information between 
>>      registries of all sorts in a unified "language". See URL for more
>>      information: http://www.isi.edu/~davidk/ride
>> 
>> 2. Hierarchical Authorisation / Cross Notification of Route Objects
>>    in the IRR (Carol Orange)
>> 
>> 2.1 Cross Notification
>> 
>>    A draft proposal was sent to the Database and Routing WG mailing lists
>>    in May. The proposal is essentially to make network operators aware of
>>    overlapping route announcements in the IRR.  
>> 
>>    Implementation is by a new attribute in the route object called
>>    "x-notify". Using this attribute you will get notified if you submit
>>    a route object which overlaps an existing route object in the IRR or
>>    if another route object is submitted which overlaps your route object.
>>    Note - this will be an *optional* attribute.  
>> 
>>    The exact syntax is documented in the draft sent to the mailing list
>>    and can be found in the mailing list archives at:
>>    ftp://ftp.ripe.net/ripe/archives/routing-wg/current. There were also
>>    some additions from the Database WG. An overview of the current state
>>    is given in the Working Documents section of the Routing WG on the RIPE
>>    web server: http://www.ripe.net/wg/routing/rwg-docs.html
>> 
>>    Discussion
>> 
>>    It was envisaged that given the way that the current IRR is mirrored
>>    (once every 24 hours), there will be delay in notification.  Real
>>    time mirroring would be ideal and the software exists.  However this
>>    has not yet been fully implemented as this still requires input from
>>    other RR's.  Gerald Winters from Merit (representing the RADB)
>>    commented that the current mirroring has been changed to mirror more
>>    frequently. 
>> 
>>    It was asked if there was a way to differentiate between exact matches 
>>    and overlaps? It was commented that this could be built in to the 
>>    software notification.
>> 
>>    A question was then raised as to the exact notification that takes
>>    place when an overlap/exact match occurs and as to the timing of the
>>    possibilites for notifcation and to whom. Do you for example,
>>    also notify the originator of the overlap? Should the software return 
>>    a warning to the originator of overlap even without the "x-notify"
>>    attribute ? 
>> 
>>    After a fairly lengthy and interesting discussion, it was agreed to go
>>    ahead with implementing the draft proposal given the following
   modifications which were agreed:
>> 
>>    - the submitter of the route will always be notified as to whether the
>>      object submitted was successful. Notification of overlaps can be built
>>      into the acceptance/feedback message returned to the submitter.
>> 
>>    - for deleting a conflicting object, it was agreed to notify the 
>>      submitter of the conflicting object that there was no longer a
>>      conflict in the database
>> 
>>    - notifications on overlap - either for newly submitted route objects,
>>      or for deletions - will only be done for *existing* route objects if
>>      explicitly requested by the "x-notify" attribute

I've reworded the above adjustments as I understood them, and have
incorporated them in the newest version (to be submitted on the list).
You can keep whichever version you find clearer. They say the same
thing.

- Whenever a route object is submitted in the RR, a notification
should be generated to the submitter if the address space overlaps
with any other route object in the RR. This is regardless of whether
the new attribute for cross notification is used.

- If the address space covered in the route object matched the
address space in another route object, be sure this is clear in the
notification message.

- Notifications should be sent to the appropriate contact not only if
an overlap is introduce, but also when an overlap is eliminated. 

>>    Action 27.R1: Carol Orange, RIPE NCC 
>>      To implement cross notification in the RR with modifications as
>>      agreed at the meeting of the 27th RIPE Routing WG.
>> 
>> 2.2 Hierarchical authorisation in the RR (Carole Orange)
>>     (or "aut-num authorisation for route objects in the RR")
>> 
>>    The proposal is documented in a draft document which was previously 
>>    circulated to the Database WG and Routing WG mailing lists. Agreement
>>    on this proposal is now sought so that it can be implemented. 
>> 
>>    The goal of the proposal is to allow network operators who announce a 
>>    route in their AS to delegate this authority to others. 

No, the goal is to allow network operators who maintain an aut-num
object to determine who can submit a route object with their AS number
as origin. 

>>    There has been 
>>    much discussion on the mailing lists and a specific "non-goal" of the
>>    proposal is to produce an optimal hierarchical authorisation scheme 
>>    for the RR. This proposal is not CIDR based; hence the change of name
>>    for the draft to avoid any confusion about CIDR based hierarchy in the
>>    proposal to "Aut-num authorisation for route objects in the RR". 
>> 
>>    The proposal works briefly by the following mechanism:
>> 
>>    A "mnt-route" attribute (in former drafts called "mnt-lower") is added
>>    to the aut-num object. Currently the "mntner" object referenced
>>    determines who can add/update/delete an object associated with that
>>    aut-num (for more details see the draft which can be found at the
>>    reference above in the archives of the mailing list, or look at the
>>    Working Documents section of the Routing WG at the RIPE web server).

No, this is not the case. There are currently no restrictions on who
can add/update/delete a route object specifying a given aut-num in the
origin. The proposal is intended address this authorization gap, by 
allowing network operators to specify these restrictions, and as you 
state above, by also allowing them to delegate this authority if they 
so desire.

>>    The "mnt-route" attribute is optional and can be multiple per aut-num
>>    object. Each mnt-route attribute references it's own "mntner" object.
>>    This allows different people to maintain own routes announced.  
>> 
>>    Action 27.R2: Carole Orange, RIPE NCC
>>      To implement aut-num authorisation in the RR 
>> 
>>    There was some discussion over the notification mechanisms when customers
>>    change their announcements in their AS - so as to enable notification to 
>>    their upstream provider. This is actually a different issue and the
>>    discussion was deferred to the mailing list due to time constraints.
>> 
>> 3. A future tool development project (Joachim Schmitz)
>>    ftp://ftp.ripe.net/ripe/presentations/ripe-m27-jschmitz-ftdp.html
>> 
>>    Joachim briefly described some of the existing tool sets in place to
>>    help network operators with their network operations and asked whether
>>    there was a need for such a new development effort in this area to 
>>    be carried out under the auspices of RIPE and if so, where would it
>>    fit into the RIPE activity plan. Possibly, such a project could fit
>>    into the slot for "new activities" taken from the 1997 expenditures
>>    budget.
>> 
>>    As background to this Joachim gave a description of the history (ish) 
>>    and the functioning of the existing tools as well as the interaction 
>>    with the relevant entities. ie. routers.. ISPs, IRR.... etc.  Some of
>>    the tools he made mention of were the PRIDE tools eg. prtraceroute,
>>    prcheck, or the RATools eg. roe, aoe, peval, CIDR advisor.. 
>> 
>>    The question was then asked: Is a new tool or software project needed ?
>>    What gaps exist in the existing toolsets? 
>> 
>>    It was felt generally by the audience that the orientation should be 
>>    more towards actual integrity of the data in the RIPE database, quality 
>>    and consistency of the DB rather than towards new tools.
>> 
>>    Therefore, this action could be closed.
>> 
>> 4. Report from the RIPE NCC
>> 
>>    Time contraints prevented NCC from doing CIDR report and route aggregatio
>> n
>>    analysis that had previously been started. However new technical projects
>>    are ongoing and they are going to hire more people to do technical
>>    projects.
>> 
>>    The RIPE NCC welcomes any volunteers who wish to take over the production
>>    of the route aggregation analysis reports. Currently the reports are
>>    rather manually produced - mostly so in the generation of the "how to 
>>    fix" emails which go out to the originators of "problems". Daniel 
>>    repeated that he was quite willing to hand over the scripts if anyone 
>>    wished to work on this since there are currently no spare human resources
>>  
>>    at the NCC at this point in time. There were no volunteers immediately.
>> 
>>    It was agreed however that these reports were very useful and perhaps it
>>    would be possible to at least publish a summarised report and not send th
>> e
>>    "how to fix" emails.  Reports will be sent out to the RIPE working group 
>>    mailing list. Since Tony Bates' report on route aggregation also contains
>>    information on European ASs it was agreed to ask him whether a copy of hi
>> s
>>    report is also distributed to the general RIPE mailing list.
>> 
>>    Action 27.R3: RIPE NCC
>>      To ask Tony Bates to send a copy of his regular CIDR report to the
>>      general RIPE mailing list as well.
>> 
>> 5. Route Flap Dampening Parameters (Christian Panigl)
>> 
>>    C. Panigl started with a summary of the BOF at the last RIPE meeting.
>>    Consensus was that we needed route flap dampening, but there was no
>>    consensus on dampening parameters: 2 camps had previously emerged:
>> 
>>    - Those in favour of "progressive" dampening with the exclusion of
>>      "golden" networks ie. root name servers..
>> 
>>    - or "flat and gentle" where all prefixes are treated equally a la
>>      Cisco default dampening.
>> 
>>    As an action from the previous Routing WG meeting, Christian Panigl
>>    presented information he had collected about dampening parameters. As
>>    a basis for his studies, he took information about dampening parameters
>>    from the following sources:  
>> 
>>    - discussions by Randy Bush a la SPRINT/ICM parameters 
>>    - Tony Barbers presentation on progressive route flap dampening at 
>>      UUNET UK. 
>> 
>>    Christian reported on the work by Sean Donelan sean@localhost who 
>>    made investigations.. comparing /24 prefixes and /16 prefixes:
>> 
>>    /24: 65% of Routing Table accounts for 65% of all route flaps
>>    /16: 12% of Routing Table accounts for 10% of all route flaps
>> 
>>    Both groups tend to flap ~2% of the routes within the group.
>> 
>>    What is the goal of flap dampening: stable routes or shorter prefixes?
>>    It was suggested that softer "punishment" of shorter prefixes might 
>>    lead to future waste of address space.
>> 
>>    Some router cpu offload has happened with progressive dampening.
>>    Excessive BGP withdrawal problem seems to be fixed in IOS 11.1(8)
>>    for Cisco routers.
>> 
>>    The assumption that the /24 is more unstable is not necessarily true
>>    given the following situation:
>> 
>>    example: reload after s/w uprade - 1x flap
>>             new s/w crashes         - 1x flap
>>             reload with old s/w     - 1x flap = 3x flaps within 10 minutes
>> 
>>    Then according to Randy's parameters /24 prefixes were blocked for
>>    3.5 hours.., /22 45 minutes, /19 45 minutes, /16 less than 30 minutes.
>>    According to Tony's paramters /24 prefixes were blocked for 2hrs 45mins, 
>>    /22 55 minutes, /19 55 minutes /16 less than 30 minutes.
>> 
>>    It was suggested that suppression should not start until the 4th flap in
>>    a row which corresponds to parameter value suppress = 3000 and that the
>>    maximum suppression should not last longer than 1hour (max supress <60).
>> 
>>    It was agreed that a recommendation from RIPE would be desirable.
>>    Given that the current allocation policies are expected to hold for 
>>    the foreseeable future, it was suggested that all /19's or shorter
>>    prefixes are not penalised outside of the Cisco default dampening.

What I miss in this summary is that there seemed to be consensus at
the meeting that "it is beneficial if everyone adopts the same
parameters, because it allows problems to be detected and addressed on
the home front."  (but perhaps that was obvious, and I'm being picky.)

>> 
>>    Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg 
>>               and Christian Panigl).
>>    To write proposal document and circulate to the RIPE rounting working
>>    group mailing list for discussion as soon as possible.
>> 
>> 6. Reports from other WGs
>> 
   There was no current input from other WGs.
>> 
>> 7. AOB
>> 
>>    Since there was no AOB the meeting was closed.
>> 
>> 
>> Agenda
>> ------
>> 
>>  R I P E    2 7    D U B L I N
>>  Routing Working Group Session
>>  21-May-97        Draft Agenda
>> 
>>  A. Preliminaries
>>     - introduction
>>     - participants' list
>>     - volunteering of scribe
>>     - agenda bashing
>>     - RIPE 26 minutes
>>     - actions from earlier meetings
>>     - current developments
>> 
>>  B. Hierarchical Authorisation/Notification of Route Objects
>>     - first implementation issues (Carol Orange)
>>     - further developments (Joachim Schmitz)
>>     - discussion
>> 
>>  C. A Future Tool Development Project (Joachim Schmitz)
>>     - an overview
>>     - discussion
>> 
>>  D. Report from the RIPE NCC (Daniel Karrenberg)
>> 
>>  E. Route Flap Dampening Parameters (Christian Panigl)
>>     - overview
>>     - suggested parameters
>> 
>>  Y. General Input from Other WGs
>> 
>>  Z. AOB
>> 
>> 
>> Summary of Actions:
>> -------------------
>> 
>>    Action 25.R1: D.Karrenberg 
>>      To report on the results from the route aggregation analysis on
>>      the next RIPE meeting
>> 
>>    Action 26.R3: J. Schmitz
>>      To finalize the hierarchical authorization for route objects
>>      together with the Routing WG
>> 
>>    Action 27.R1: Carol Orange, RIPE NCC 
>>      To implement cross notification in the RR with modifications as
>>      agreed at the meeting of the 27th RIPE Routing WG.
>> 
>>    Action 27.R2: Carole Orange, RIPE NCC
>>      To implement aut-num authorisation in the RR 
>> 
>>    Action 27.R3: RIPE NCC
>>      To ask Tony Bates to send a copy of his regular CIDR report to the
>>      general RIPE mailing list as well.
>> 
>>    Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg 
>>               and Christian Panigl).
>>      To write proposal document and circulate to the RIPE Routing WG
>>      mailing list for discussion as soon as possible.
>> 
>> Anne Lord, Joachim Schmitz, 6 June 1997.
>> 
>> 
>>