APCCIRN-040
APCCIRN-040
Geoff Huston
IEPG Meeting
23 August 1993
Bodega Bay, Ca, U.S.A.
As noted at the meeting the following is not structured as minutes of
the meeting per se - the intent of these notes is to outline the
topics covered and the relevant outcomes and actions that may be taken
up.
1. Who Attended
The list of attended who owned up to being in the room were as follows
Geoff Huston gih@aarnet.edu.au AARNet
Elise Gerich epg@merit.edu Merit
Bernhard Stockman boss@ebone.net EBONE
Che-Hoo Cheng chehoocheng@cuhk.hk UPCC / HARNET
Kin Fung mingfung@cuhk.hk UPCC/ HARNET
Bob Coggeshall coggs@hk.super.net Hong Kong Supernet
Joe Burrescia burrescia@es.net ESnet
Tim Dixon dixon@rare.nl RARE
Weiping Zhao zhao@nacsis.ac.jp NACSIS
Jun Matsukata jm@eng.isas.ac.jp ISAS / SINET
Bill Manning bmanning@rice.edu Sesquinet
Jack Waters waters@sura.net SURAnet
Richard Colella colella@nist.gov NIST
Akiko Aizawa akiko@nacsis.ac.jp NACSIS
Masaya Nakayama nakayama@nic.ad.jp JPNIC
Daniel Karrenberg daniel@ripe.net RIPE NCC
Farooq Hussain farooq@icm1.icp.net Sprint
Peter Ford peter@goshawk.lanl.gov LANL
Claudio Topolcic topolcic@cnri.reston.va.us FEPG/CNRI
Peter Dawe peter@pipex.net Pipex
Peter Lothberg roll@stupi.se EBONE
Keith Mitchell keith@pipex.net Pipex
Joo Song jysong@ring.kotel.co.kr Hananet
Sun-Young Ko - KT
Milton Cho milton@solomon.technet.sg Technet
John Houlker j.houlker@waikato.ac.nz Tuia
JunMurai jun@wide.ad.jp WIDE
Guy Almes almes@ans.net ANS
Hans-Werner Braun hwb@sdsc.edu SDSC
Torben Neilsen torben@hawaii.edu PACCOM
2. GIX Report - Report by Peter Lothberg
The MAE-EAST Exchange pilot activity is operating in the Washington DC area,
providing a first resort for routing exchanges and a last resort for data for
the participants. Work is continuing on the use of an EBONE Route Server
deployed on this exchange. The Exchange is self-funded by the participants.
Discussion included the scalability of the exchange, noting that route flaps
are causing a high level of route recalculation on the part of the exchange
routers. Discussion also included various models which could extend the GIX,
using either an extension of the Address Bus using Layer 2 extension, or using
replicated exchanges with connections provided only by transit providers.
It is noted that in the global context this structure addresses a routing
scaling issue. It does introduce issues of single points of potential failure,
and does not address the global transit issue per se.
Two actions were taken on this item:
1. Document the current configuration of MAE-EAST and the operational
environment.
(Andrew Partan, Peter Ford & Peter Lothberg)
2. Document how this facility can be extended, including a number of
scenarios of both increased levels of participants, geographical extension
of the current exchange structure and issues involved in replication of
the structure without direct routing linkages.
(Peter Lothberg, Claudio Topolcic, Peter Ford & Geoff Huston)
3. Registries Report - Report by Daniel Karrenberg and Jun Murai
Daniel presented the role of the RIPE NCC. Copies of his overheads are on
ftp.ripe.net, and the RIPE-81 document also contains a description of this
effort. The RIPE NCC is both a number registry and a routing / policy registry
(using preferred AS Path registration). A number of tools to both check the
routing database for consistency and to generate router configurations are in
development by the RIPE NCC.
Jun Murai presented the establishment of JPNIC in Japan and the extension of
this to a regional registry with the APNIC experiment - the regional work is
intended to be distributed with JPNIC undertaking net number registration and
KRNIC undertaking routing registry activities.
The potential relationships of the European route server work and the routing
registries with the current NSF Solicitation for the NAP architecture were
noted.
Routing Registries are seen as playing an integral role in the maintenance of
policy integrity, and the registries are therefore undertaking the role of the
major support vehicle for external routing in the Internet.
The work of the routing registry should be further disseminated in the Internet
community, and the RIPE-81 paper is seen as being an important paper to further
this dissemination.
4. EBONE, Europanet and Connectivity to Europe - Report by Bernhard Stockman
The organisational structure of Europanet was described, outlining the roles of
Dante Inc, the Unisource provider, the X.25 and IP Unidata service and the EMPB
service which is being offered in a CUG configuration within Europe to national
academic and research providers. Production turnover of the trial service is
anticipated to occur in September 1993.
EBONE is still undertaking the role of a pan-European IP backbone, providing a
policy-free European service and providing operational support and coordination
services to a number of connecting trans-Atlantic T1 IP links.
Potential connectivity issues between Europanet and EBONE were discussed and
the overall operational coordination with respect to routing was highlighted.
Specification of European interconnection is a prerequisite for further
activity relating to coordinated European routing and coordinated global
Internet routing.
5. CIDR - BGP4 Deployment - Report by Guy Almes
The status of BGP deployment on the NSFNET by ANS was reported. ANS will be
deploying CIDR routing tables with GateD routing in October. (Slide summary is
attached).
The basic message to providers is "CIDR, Default or Die". Other issues
highlighted include the difficulty in attempting dis-aggregation of aggregated
routes (which implies that providers not using Default to implicitly collect
aggregated routes should deploy CIDR in synchronisation with each other), the
increased operational costs associated with partial CIDR deployment, and the
role of the registry to generate accurate aggregation routing configurations.
BGP4 issues will be further examined within the scope of the IETF, and the
deployment issues will be examined at the forthcoming US Regional Techs meeting
6. Multicast and the MBONE - Report by Steve Deering
Steve Deering was invited to attend the meeting to report on the MBONE and
associated issues. (Slide summary is attached).
The nature of the use of the infrastructure by high bandwidth UDP audio and
video flows on both a local and global scale were discussed, and recent
problems with uncontrolled signal generators were highlighted. Some solution
directions were highlighted with refinement of the routing tools (tree pruning
within DVMRP) and token-based control of signal generation. Overall global low
control is controlled by a single TTL control structure, which is a somewhat
crude tool to use to exercise resource control. Development of more specific
control protocols for multicast is being developed within the IETF.
The potential efficiencies of multicast for data transfer were highlighted, and
applications which implement reliable data transfer within a multicast
environment were discussed
Further discussion of these issues is being undertaken within the mbone@isi.edu
mailing list.
7. CLNP Routing Coordination - Report by Richard Colella
Richard highlighted a lack of coordination activities within the internet-
deployed NSAP space, an issue which has become more visible with the growth of
the TUBA pilot deployment project.
Richard noted the need for Internet Registries to register and maintain
registered NSAP addresses which can assist in both the current techniques of
static routing of CLNP traffic and the generation of router configuration
tables to underlie future intentions to move to dynamic routing within this
area.
The NSAP structuring was also discussed, with noting that the country-based
NSAP prefixes and potential Internet NSAP prefixes will probably require
coordination within the CLNP routing space.
The role of Internet Registries within the area of NSAP registration was noted,
and Richard Colella, Daniel Karrenberg and Elise Gerich indicated they would
followup in this area with a review of the role of the registry in this area.
8. CIDR ISSUES
The question was posed as to the extent of the "win" in address entities being
routed with CIDR in the early stage of CIDR deployment (October 1993). The long
term expectation was of a 30 - 40 % "win" within the environment currently
served by the NSFNET, but the short term expectation was of no immediate gains
in the routing domain. Disaggregation is also an issue here, and there is an
issue of ensuring that providers are fully aware of the impacts of
disaggregation on their operational environment.
The use of CIDR to trawl the unused address space was also discussed, noting
that the knowledge base on this issue is weak and the issue of whether host
software requires CIDR awareness in order to function correctly is not well
explored. Existing tools also require refinement, both operational tools and
registry tools.
It was also noted that the registries are the only point were CIDR information
can be generated cleanly, and furthermore it was noted that in order to do so
the registry must have a complete knowledge base regarding the local domain of
responsibility.
Further investigation is required in this area is evidently required, and the
role of the registry in the generation of the CIDR routing domain requires
documentation.
9. Quality of Service and Standards of Service - Report by Peter Dawe
The IEPG discussed whether there was a role within the Internet for an
organisation to function with operational authority to ensure that end to end
service was maintained within defined parameters of quality of service by the
service provider community.
The discussion highlighted the difficulties in establishing such authority
within the Internet community and the consequent issues of liabilities and the
potential for cartel formation. The conclusions drawn from this discussion is
that it is not possible within the Internet environment to mandate authority.
The IEPG saw itself as a forum where operational issues can be discussed within
a provider environment, but the conclusions of such discussions from the IEPG
perspective are simply phrased at most as recommendations which individual
providers may find useful to implement in some form or other in a coordinated
fashion.
The RIPE NCC effort at a Generic Internet Service Description was noted. The
document is intended to describe the "state of the art" in the provision of
specific elements of an Internet service, and while the overall structure of
the document is complete the document is seen as a edited effort where input
within each service description element is solicited from IEPG members.
10. The IEPG itself
Discussion of the role of the IEPG and the future requirements for operators to
meet and work within an appropriately synchronised environment in order to
ensure the interoperability capabilities of the network. A secondary objective
is to advocate operational practices and advocate engineering developments
which can ensure cost effectiveness of operation within the global Internet
provider environment.
The issue of the hierarchical relationship with the CCIRN was discussed, and
the IEPG was of the view that there is a requirement to take the current broad
participation structure and assert a role within the Internet as a whole. This
would not preclude the CCIRN requesting the IEPG to examine specific areas of
operational coordination, but additionally input would be anticipated from
other areas of Internet activity. The area of support for the IEPG activity is
an open issue, and further investigation of this is required by the co-chairs.
The co-chairs were tasked to develop this further and to report back to the
IEPG on potential organisational structures for the IEPG within the Internet
domain.
11. Next Meeting
It is intended to convene the next meting of the IEPG immediately preceding the
March 1994 IETF meeting, as a one day meeting.
------------------------------------------------------
SLIDES OF IEPG MEETING
A. IEPG SUMMARY SLIDES
Geoff Huston
GIX REPORT
MAE-EAST Exchange
Routing Scaling
Extensions to MAE-EAST
Document current status
Document proposed pilot extensions
REGISTRY FUNCTION
Registry as integral component of policy integrity
Registry as the major support vehicle for external routing
Wider dissemination of the role of registry functions within the
provider domain
UPDATE ON EUROPEAN ACTIVITIES
Europanet / EBONE interaction issues highlighted
Consequent requirement for routing coordination across the Internet
BGP4 and AGGREGATION
CIDR, DEFAULT or DIE
and all together (dis-aggregation issues)
and not without some degree of difficulty
Registry information and tools to support CIDR deployment by the
providers
MULTICAST and the MBONE
Growth of the MBONE
Managing the MBONE
Examination of the problems in Multicast management
CLNP COORDINATION
Registry support required
NSAP issues
IANA
Country NSAP Prefixes
Static -> Dynamic CLNP routing
CIDR ISSUES
Registry role
DisAggregation costs
Tools for Operational Support
Reclamation and Renumbering
QUALITY of SERVICE DEFINITION
Issue of Authority to specify Service Provider roles rejected
IEPG Role to promote quality service provision
Generic Internet Service Description document
NEXT STEPS
The IEPG is already functioning as an Internet Operations
activity
Assertion of a role within the Internet as a whole
Details to be developed
B. Status Report on ANS CIDR Deployment
Guy Almes, ANS
IEPG Meeting, August 1993
Outline of the talk:
Summary of CIDR Functionality
Schedule of Deployment
Issues
CIDR Summary
BGP4 Essentials
Generalized Network Number
Two ways to Aggregate
Control over Aggregation Policy
Difficulty of dis-aggregation
Implications
BGP4: Generalized Network Number
EGP and BGP 1-3: IPv4 Network Number
BGP4: IPv4 Address Prefix
BitCount = 0; Default route
BitCount = 1..31; Network number
BitCount = 32; Host Address
BGP4: Support for Aggregation
Aggregator Field: Last AS that Aggregated
Atomic Aggregator: Caution on dis-aggregation
AS_Sequence vs AS_Set within AS_Paths
Two Ways to Aggregate
Use Atomic_Aggregate
Current AS is now the Origin
No dis-aggregation is now allowed
Use AS_set to merge multiple AS_Paths
Results in Complex AS_Paths
Dis-aggregation allowed, but no simplification of complex
AS_Paths
Examples of Aggregation
AS#e received 128.100.2 from <a, b, c> IGP
AS#e receives 128.100.3 from <a, d, c> IGP
With Atomic_Aggregate:
Advertise 128.100 from <e, a> Incomplete
Otherwise
Advertise 128.100 from <e, a, (b,d), c> IGP
Control over Aggregation Policy
Aggregation is best done near the origin
A Backbone can aggregate, but later dis-aggregation not likely
Policy that controls this will be explicit
Difficulty of dis-Aggregation
With Atomic_Aggregate, the AS_Path is truncated
With AS_Set, there is still insufficient information to
resimplify the AS_Paths
Therefore, dont expect dis-aggregation with BGP4
Implications
Once routes are aggregated, they can be shared only:
With other CIDR-capable networks
(Implicitly) with other nets using default
Once CIDR is deployed, 'full routing tables' may be easier
But when CIDR is partially deployed, 'full routing tables' may be
harder
Schedule of ANS Deployment
24 Aug: Build to support 25,000 routes and CIDR Routing Tables
24 Sep: GateD (coexisting with rcp_routed) deployed
SLSP, EGP, BGP2-4, and IBGP2, but no aggregation possible
Early October: rcp_routed RIP
IBGP4 used, so aggregation becomes possible
Later: IS-IS replaces SLSP, then IBGP can go away
Merit role should be stressed
Databases must reflect which aggregation should occur
GateD config files must be generated
Other nets of the CIDR Core are also key
Interim: Self-conscious distinction between:
CIDR-capable networks that can accept non-classed nets
Others that can use Default
C. State of the MBone
Steve Deering
IEPG Meeting, August 1993
MBONE: The Multicast Backbone
a virtual network, overlaid on the Internet, to carry IP
multicast packets
multicast router connected by physical links or "tunnels"
[tunnel diagram]
to become "less virtual" over time (we hope!)
Growth of the MBone
Mar 1992 40 subnets 4 countries
July 1992 90 subnets 10 countries
Nov 1992 190 subnets 12 countries
Mar 1993 295 subnets ? countries
June 1993 370 subnets ? countries
Aug 1993 505 subnets ? countries
Problems with the MBone
(in rough order of urgency)
* high degree of tunnel fan-out on some routers
-> CPU saturation -> packet losses & routing instability
* large number of tunnels over single links
-> bandwidth saturation
solutions:
(1) better tunnel "engineering"
(2) get multicast routing into the "real" routers
* delivery is broadcast, not multicast
-> excessive bandwidth usage
(somewhat alleviated by "TTL hack")
solution
finish implementation of intended multicast routing
algorithm
(ie add tree pruning)
* no flow control in audio/video applications
-> unfair bandwidth usage, saturation of some links
(somewhat alleviated by "TTL hack")
solution:
Bandwidth Limiting & Smart Dropping
[token bucket diagram]
manually configured token rate (= long-term max BW)
other parameters: bucket size (=max burst size)
queue bound (=max delay)
on queue overflow, toss lowest priority packet(s)
* tight limit on path lengths ("infinity" = 32 hops)
-> difficult to engineer back-up paths
* routing is insensitive to available bandwidth
-> packets follow shortest, not highest capacity, paths
solution: straightforward changes to implementation;
challenge is backward-compatibility
* lack of scalability of flat, distance-vector routing
-> bandwidth, CPU, and memory demands are growing
solutions: - more efficient routing algorithm (MOSPF)
- hierarchical multicast routing
* lack of scalability of reverse-path multicast routing
-> multicast routing overhead grows faster than unicast
solution: new multicast routing algorithms (a research
problem) -
several efforts are underway
* no bandwidth reservations (a unicast problem too)
-> as load goes up, everyone suffers (the "IP Way")
solution: Clark-Shenker-Zhang resource reservation and
management
architecture and SIP