home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
- Reported by Dave O'Leary/cisco Systems
-
- Minutes of the Inter-Domain Routing Working Group (IDR)
-
- The IDR Working Group held two sessions on Thursday, 8 December.
-
-
- Agenda Bashing
-
- o Guidelines for the use of autonomous system numbers
- o CIDR to a Draft Standard
- o BGP-4 to a Draft Standard
- o IDRP for IPv6
-
-
- In addition to the above items the following topics were added:
-
-
- o AS# -- RD mapping
- o BGP-4 --> IDRP interaction
- o OSPF --> IDRP interaction
-
-
- Guidelines For the Use of AS Numbers - Tony Bates
-
- References are slides and the Internet-Draft, ``Guidelines for creation,
- selection, and registration of an Autonomous System (AS)''
- (draft-ietf-idr-autosys-guide-00.txt). The draft is intended as an
- advisory document only, to clear up confusion rather than state policy.
-
- The document addresses those singly-homed sites whose policy is the same
- as their provider, intent is to reduce AS number utilization and AS path
- lengths. Currently there is no choice other than BGP (requiring a legal
- AS number) or a classless IGP between providers and customers (which is
- considered non-optimal by many). Classless static also solves this and
- is used in many cases but does not help in cases of transition from one
- provider to another or for those who anticipate future multiple homing.
-
- This document will probably need to be updated sometime to reflect the
- existence of BGP communities.
-
- Jessica Yu will write some text on how the existence of someone else's
- policy should not necessarily affect the requirement for using an AS,
- and why this is a fuzzy area driven by the choice of the originating AS
- and how their policy is defined.
-
- Concern was expressed relative to this document and its lack of text on
- where AS numbers should be used, so that less knowledgeable service
- providers do not read this draft the wrong way and try to stop using AS
- numbers in their networks. Peter Lothberg will write some text.
-
- The goal is to have a new version of this document by 14 January 1995.
- The consensus of the working group was to advance it as a Proposed
- Standard.
-
-
-
- CIDR to Draft Standard - Peter Ford
-
- There was clear consensus of the working group that the CIDR
- architecture should move forward as a Draft Standard. The working group
- agreed to ask the IESG on 15 January 1995 to advance RFC 1518 and
- RFC 1519 to a Draft Standard. Any comments on these documents should be
- posted to the mailing list as soon as possible (prior to 15 January).
-
- Peter Ford has a rough draft of the CIDR experience document. He is
- looking for writers and reviewers for this document.
-
-
-
- BGP-4 to Draft Standard - Paul Traina
-
- Known implementations are: cisco, Wellfleet/Bay Networks, gated, 3Com,
- Rob Coltun's, and European Telebit.
-
- There was clear consensus of the working group that BGP-4 should move
- forward as a Draft Standard.
-
- Recent changes in the BGP documents were cleanup of the text relative to
- the use of the terms ``network,'' ``prefix,'' etc.
-
- There was discussion on the use of ``open'' message for use by route
- reflectors/servers. The change will be editorial; relabel the
- authentication field as the ``open parameters'' field since it is an
- extensible field that can still be used for authentication. Its use
- will be detecting misconfiguration at other layers in the hierarchy.
-
- The editors agreed to prepare revised text of BGP-4 (both the protocol
- specifications and the usage document) within two weeks.
-
- The working group agreed to ask the IESG on 15 January 1995 to advance
- BGP-4 to a Draft Standard. Any comments on the revised text of BGP-4
- (protocol specifications or usage document) should be posted to the
- mailing list as soon as possible (prior to 15 January).
-
-
-
- Use of Colors
-
- Paul Traina proposed to add a new optional transitive attribute to BGP-4
- -- ``route color.''
-
- The attribute is defined as a list of long words (four octets) to use
- for policy control in addition to AS path.
-
- Possible examples of application:
-
-
- o do not leave this router
- o do not leave this AS
- o others locally significant between peers
-
-
- Sean Doran and Paul Traina will work on a usage document addressing how
- this will affect aggregation, local color versus global color, scope
- limitation versus AS path length (some concern/offense was expressed
- regarding the use of this mechanism).
-
-
-
- IDRP Transport Over IPv6 - Paul Traina
-
- Paul Traina presented a brief overview of the Internet-Draft,
- draft-ietf-idr-idrp-v6-00.txt.
-
- A recent change (clarification) is that one message contains multiple
- attributes, and changes for consistency with BGP.
-
- There was discussion of possible changes to IDRP - sending fewer bits
- versus complexity of implementation. Yakov will remove text re:
- routeID (explicit withdrawals) and replace it with advertising just
- unreachable address prefixes.
-
- The group discussed the use of Multi-Exit Discriminator (MED) --
- flexibility on a per RD peer basis which is not currently accommodated.
- This will remain unspecified at this point.
-
- A revised version of the Internet-Draft is expected before the next
- IETF.
-
- The Route Server implementation by IBM and ISI (as part of the Routing
- Arbiter project) will support IDRP for IPv6.
-
-
-
- AS Number to RDCI/RDI Mapping
-
- Since BGP-4 operates in terms of AS numbers, and IDRP operates in terms
- Routing Domain Identifiers (RDI) or Routing Domain Confederation
- Identifiers (RDCI), there is a need to define how AS numbers could be
- mapped into RDI or RDCI.
-
- IPv4 mapping is dropped into mapping for IPv6.
-
-
-
- Connection of IPv4 and IPv6 Domains
-
- For transition to IPv6 it will be important to leak IPv4 routing
- information into IPv6 routing system. Dimitry Haskin agreed to write a
- document that specifies how this leakage should be done.
-
-
- OSPF --> IDRP for IPv6 Interaction
-
- Yakov Rekhter agreed to make the necessary editorial changes to the
- OSPF/IDRP for IPv4 interaction document to deal with IDRP for IPv6.
-
-