Subject: Notes for IDR working group

From: Susan Hares <[email-masked]>
Date: Thu, 02 Apr 1998 14:38:20 -0500

Rough and ready notes

1) Agenda Bashing
2) Aggregations I-Ds
        - draft-ietf-idr-aggregation-framework-02.txt
        - draft-ietf-idr-aggregation-tutorial-01.txt

3) BGP-4 over ATM and Proxy PAR
4) DNS-based NLRI origin AS verification in BGP
5) DNS-based NLRI origin AS verification in BGP 
6) RR RFC status
7) Confederation

----------
1)Aggregation Framework

  Presentation:
   draft-ietf-idr-aggregation-framework-01.txt

        Successful proxy aggregation requires coordination on
        a very large scale (i.e., between

   draft-ietf-idr-aggregation-framework-02.txt

       Proxy aggregation may be appropriate on a small scale where
       the necessary coordination is tractable.  However, on a large
       scale, experience has shown that proxy aggregation is problematic
       because the coordination is tractable.

  Discussion

        Coordination is possible.  [Curtis V.]
        Coordination is done, but unfeasbile. [Tony Li]
        Discussion will continue on the mailing list.

2) Proxy par
        (draft-droz-proxypar-arch-00.txt)

        Draft was explained.  Slides are available at:

        Automatic detection of peers across ATM clouds.
        Depends on the PNNI flooding within the ATM cloud.

        BGP work entails:
        Each BGP peer registers with its ATM cloud
           - ATM address,
           - IP instance
           - IP address,
           - IP mask,
           - BGP Identifier,
        - Route reflector type as one of:
         - Reflector of a certain cluster or
           - client of a certain cluster or
           - non-client

        Each BGP queries for
           - BGP peers in different ASes to form E-BGP adjacencies
           - BGP Peers in the same AS to form i_BGP adjacencies to
                (works with route reflectors)

        Misc - Security issues,
             - Implict address resolution for ATM

  Discussion:

      Discussion of OSPF LSAs or ISIS TLVs to do auto-configuration
      for BGP peers.

      Questions if auto-configuration is necessary   
      in the ISP/NSP environment.  [Curtis, Enke Chen]  The trust level of the
      NSP/ISPs does not extend to Autoconfiguration.  [Peter Lothberg]
      The "plug-in" auto-configuration feature is unwise
      for external BGP peers.  [Yakov Rekhter]

      Problem that you are trying to solve is the discovery of
      of ATM edge devices.  [Dino F.]  The scope of
      ATM PAR may not be Jay Hawkinson [GTE networking].
    
      Autoconfiguration in this draft has not address the "shared"
      secret provided by TCP MD5 draft.  [Sandy Murphy]

3) Route Reflector

     Move Route Reflector to Proposed Standard.

4) Confederation

     Suggestion that the changes are folded into
     the draft.  The changed BGP confederation
     draft will be forwarded into the mailing group.

5) Deployed code versus I-D  for BGP

    No MED, treat at 2**32.  One vendor's implementation
    will treat missing MED as zero.  Routing loops might be
    created in networks if the missing MED interpretation
    occurs.

    Like to see a clear example of the MED being zero
    causing loops.  [Andrew Partan]

    We are going to leave the draft at 2**32 for missing
    MED.

    Rich Woundy loaded a draft was that proposed this
    change.  We agreed to this change in Montreal and
    mail archive.  Curtis recommends we stand on the draft.
    Clear consensus on the draft.

6) Draft Standard on MIB

   MIB caught in 

7) Origin Authentication for BGP 

    slides: http://psg.com/~randy/980402.idr/

    This can be obviated by a IRR fast and scalable IRR.
    Randy needs a problem solution now.  Discussion
    ensued.  It is a non-goal for this proposal to 
    protect from malcious attack.
   
    Jay Hawkinson -  Please do not overload the AS syntax
    in the DNS.  Other suggestions were given to randy and
    the other authors on implementation or clarification of
    the draft.

    This does not replace the registry?

    No it is intended to solve the problem that
    filter lists do not scale the list.  No router vendors
    can put full access list into box.

    It is important to have both the allocation 
    hierarchy and the routing prefix hierarchy.

    Email on this topic can be sent to authors 
    or the mailing group.

8) Suggestion from the floor - no more IDR meetings
    in the morning.

Notes are ***rough***.  No authors have been
consulted.  Please send flames and comments
to [email-masked].

I'll fix the notes.

Sue Hares