Routing WG minutes 9401

Here are the draft minutes of the Routing WG meeting in Amsterdam.
Comments welcome,
-- 
Jean-Michel

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

RIPE Routing-WG Draft Minutes
Amsterdam, Tuesday January 25th

Minutes: Jean-Michel Jouanigot, Gilles Farrache (scribe)

0. Previous minutes, agenda.

        The previous minutes and the agenda were approved.  Gilles
        Farrache volunteers as a scribe.


1. Ripe-81 
	1.1 Introduction; AS registration statistics (NCC)

        Tony Bates presented briefly some  statistics  about  the
        Ripe-81  objects registration in the RIPE database during
        the plenary session.  Almost 70% of the  ASes  in  Europe
        are now registered.  This ongoing effort should continue,
        and AS guardians  are  encouraged  to  check  that  their
        routing policies are well registered and kept up-to-date.
        Ripe-81  seem  now  to  be  well  accepted   within   the
        community.

	1.2 Guarded attributes (NCC)
		1.2.1 Implementation (discussion, hopefully agreement)

                Marten Terpstra presented the  implementation  of
                the Guarded attributes in the RIPE database.  The
                implementation was agreed.  For more details, see
                "Support   of  Guarded  fields  within  the  RIPE
                Database", Final  Draft.  This  document  can  be
                obtained  from  the  RIPE  NCC,  and will soon be
                registered as a RIPE document.

                AS  objects  cannot  be  registered   using   the
                'auto-dbm@localhost  automatic  update procedure.
                These   objects    have    to    be    sent    to
                'ripe-dbm@localhost. 

                When  'inetnum'  object  is  deleted,  and   this
                network  is  tagged  with  an AS, the guardian of
                this AS receives a notification.

                This  new  procedures   should   be   operational
                beginning of February.

		1.2.2 Block splitting (Marten), discussion

                At the last Working Group meeting,  an  agreement
                was  reached  concerning  'block splitting': when
                one network within a block is tagged with  an  AS
                or  a  community,  the block has to be split, and
                the  owner  of  this  object   notified.   Daniel
                Karrenberg  expressed  some  concerns about this,
                arguing that the Database should  not  modify  an
                object  since  the  users  of the database (Local
                Registries) may have problem to follow  up  these
                modifications.   Since  no  better  solution  was
                found, it was agreed to  confirm  this  decision,
                unless a better solution is found by the Database
                Working group.

	1.3 Use of Ripe-81; conversion of Ripe-60 (reminder, brief)

                The action on Jean-Michel Jouanigot to coordinate
                this migration is kept  open:  the  migration  is
                postponed  to  February,  when  all the necessary
                tools in the  RIPE  database  concerning  guarded
                objects are implemented.

	1.4 Ripe-81 enhancements

                A new version of the Ripe-81 document,  including
                some  extensions,  was  sent  out  on the working
                group list, titled 'RIPE-81++'.

                1.4.1 DMZ (Description of  Inter-AS  Networks  in
                the  RIPE  Routing Registry" (ptraceroute issue).
                Status (brief)

                This extension,  proposed  by  Daniel  Karrenberg
                some   time   ago,   is   already  integrated  in
                RIPE-81++, and implemented in the  RIPE  database
                by the PRIDE Project.  It is now commonly used.

		1.4.2 Colouring, proposal, discussion

                Jean-Michel  Jouanigot  presented  a  few  slides
                explaining  this  new  extension.  Details  about
                colouring  can  be  found   in   Ripe-81++;   the
                principles are:

                o  Currently:  1  policy  per  AS;  Variations  =
		Communities

                o Colours : small variations within one AS; hints
                for CIDR aggregation; avoid network based lists

                o Implementation:  Path attribute (BGP); local to
                an AS; associated with communities.

                This new idea was  discussed,  and  a  series  of
                clarifications were made:

                o There is some kind of overlap  between  colours
                and  communities, but a colour is local to an AS,
                and the colour information is set at  the  source
                of  the  network  announcement,  and  not  in the
                receiver of this route (network based lists based
                on communities).

                o Someone using colours for routing  should  trust
                the  remote AS for colouring his networks properly
                when they leave its AS.

                o  One  can  use  both  mechanisms  (colours  and
                communities)  to express routing policies.  It is
                therefore proposed to extent Ripe-81 so  that  it
                can support:

		as-in: AS1234 10 COM1, where COM1 is a community.

                o It is proposed to limit the number  of  colours
                to 16 per AS, since it is the number of bits used
                in the BGP path attribute today.  It was observed
                that  the  latest  draft  of BGP4 dropped the BGP
                path attribute.  The attendees of the coming IETF
                from RIPE should propose to restore it.

		
		o A network can be marked with several colours.


	1.5 Ripe-81 limitations and pending issues

                1.5.1 AS  macros  (Ripe-81  proposal),  examples,
		discussion

                The idea of AS macro was already described in the
                Ripe-81  original  document.  It  was  agreed  to
                accept the AS macros  principle,  include  it  in
                Ripe-81++ and ask the Ripe NCC to implement it.

		Action: RIPE NCC, to implement the AS macros

                1.5.2 Default route representation (Blasco), what
                      can't we represent ?
		
                Antonio Blaco Bonito presented his concerns about
                default   route  expression  in  Ripe-81  format.
                Jean-Michel    Jouanigot    presented     several
                configurations were the routing policies can't be
                expressed in RIPE-81 format, since  Ripe-81  does
                not  understand the notion of AS Path.  There was
                a long and well debated discussion about the idea
                of   AS   Path  in  Ripe-81.   This  is  a  known
                limitation of the syntax, and  network  operators
                are  sometime  not  able  to express the policies
                they  are   implementing.   Such   a   limitation
                prevents  Ripe-81  to  be used to generate Router
                configurations.  Two  different  approaches  were
                proposed:

                a) Daniel Karrenberg:  Add an 'advice' in the  AS
                object,  something  which  could express "I don't
                want to cross AS X".

                b)  Laurent  Joncheray:   Include  the  AS   Path
                concept in Ripe-81.

                Solution (a) goes along with RIPE-81  principles:
                keep it simple.  But up to what point can  we  go
                in  this  direction  ?   What's  the  purpose  of
                RIPE-81  if  we   can't   generate   the   router
                configurations out of the database ?

                Solution (b) implies that  the  network  topology
                would  tied  with  the  policies,  and  it may be
                difficult to keep the Routing  policies  coherent
                inside the database.  Macros could possibly help.

		Since no consensus was reached, it was decided to
		investigate further in both directions:

                Action  on  Daniel  Karrenberg:   Write  down   a
                proposal for solution (a)

                Action  on  Laurent  Joncheray:   Write  down   a
                proposal for solution (b)

		1.5.3 Inter-AS Local Information, discussion

                This extension, as well as the action attached to
                it (Peter Lothberg), was dropped.

2. Closing, AOB

        A FAQ on CIDR by Daniele Vannozzi was sent to the Working
        Group  mailing  list.   This  document  was   unanimously
        recognized  as  good and it was advised to be proposed as
        an RFC.  Comments on this documents  should  be  sent  to
        Daniele  Vannozzi,  with  copy to the list.  The RIPE NCC
        will make the document available.

        Since RIPE is studying a possible reorganization  of  its
        working groups, the chairman asked  the  participants  if
        new  topics  should be dealt with or if the scope/charter
        of  the  group  should  be  changed.  The  following  was
        suggested:

        o CIDR and Aggregation should become a high  priority  of
	the group

	o BGP4/IDPR follow on

        o  The  group  should  avoid,  as   much   as   possible,
        overlapping  interest  with  other  RIPE working groups,
        especially with the Database working group and the EEPG.

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