August 24, 1998 Chicago ION met for a single session on Monday afternoon. 1. Workgroup Status We opened with Andy Malis reporting on the current status of the working groups documents. Since the previous meeting 10 new RFCs have been published, and a number of others are in the final stages of completion. New RFCs - RFC 2225, Classical IP and ARP over ATM, M. Laubach, J. Halpern, Proposed Standard - RFC 2320, Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB), M. Greene, J. Luciani, K. White, T. Kuo, Proposed Standard - RFC 2331, ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update, M. Maher, Proposed Standard - RFC 2332, NBMA Next Hop Resolution Protocol (NHRP), J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy, Proposed Standard - RFC 2333, NHRP Protocol Applicability Statement, D. Cansever, Proposed Standard - RFC 2334, Server Cache Synchronization Protocol (SCSP), J. Luciani, G. Armitage, J. Halpern, N. Doraswamy, Proposed Standard (will be reissued) - RFC 2335, A Distributed NHRP Service Using SCSP, J. Luciani, Proposed Standard - RFC 2336, Classical IP to NHRP Transition, J. Luciani, Informational - RFC 2337, Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM, D. Farinacci, D. Meyer, Y. Rekhter, Experimental - RFC 2366, Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks, C. Chung, M. Greene, Proposed Standard Awaiting RFC publication - draft-ietf-ion-inarp-update-03.txt, Inverse Address Resolution Protocol, approved by IESG 8/18/98 (Draft Standard) Drafts in IESG Review - draft-ietf-ion-scsp-mars-01.txt, A Distributed MARS Service Using SCSP, 3/25/98, Proposed Standard - draft-ietf-ion-nhrp-mobile-nhc-00.txt, NHRP with Mobile NHCs, 5/1/98, Proposed Standard - draft-ietf-ion-nhrp-mib-04.txt, Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP), 5/22/98, Proposed Standard - draft-ietf-ion-fr-update-05.txt, Multiprotocol Interconnect over Frame Relay, 6/27/98, Standard - draft-ietf-ion-ipv6-01.txt, IPv6 over Non-Broadcast Multiple Access (NBMA) networks, 8/11/98, Proposed Standard - draft-ietf-ion-ipv6-atm-02.txt, IPv6 over ATM Networks, 8/11/98, Proposed Standard - draft-ietf-ion-ipv6-fr-00.txt, Transmission of IPv6 Packets over Frame Relay Networks, 8/11/98, Proposed Standard - draft-ietf-ion-ipv6-ind-00.txt, Extensions to IPv6 Neighbor Discovery for Inverse Discovery, 8/11/98, Proposed Standard Other Drafts in Progress - draft-armitage-ion-mars-scsp-03.txt, Redundant MARS architectures and SCSP, 7/7/97, G. Armitage - draft-armitage-ion-sec-arp-00.txt, Security Issues for the ATMARP Protocol, 10/13/97 , G. Armitage - draft-armitage-ion-security-01.txt, Security Issues for ION Protocols, 10/13/97, G. Armitage - draft-carlson-nhrp-01.txt, Guidelines for Next Hop Client (NHC) Developers, 3/19/98, R. Carlson, L. Winkler - draft-ietf-ion-discov-atmarp-01.txt, ILMI-Based Server Discovery for ATMARP, 5/11/98, M. Davison - draft-ietf-ion-discov-mars-01.txt, ILMI-Based Server Discovery for MARS, 5/11/98, M. Davison - draft-ietf-ion-discov-nhrp-01.txt, ILMI-Based Server Discovery for NHRP, 5/11/98, M. Davison - draft-ietf-ion-intra-area-unicast-01.txt, Intra-area IP unicast among routers over legacy ATM, 11/21/97, J. Heinanen - draft-ietf-ion-proxypar-arch-00.txt, Proxy PAR, 3/13/98, P. Droz, T. Przygienda - draft-ietf-ion-scsp-atmarp-00.txt, A Distributed ATMARP Service Using SCSP, 4/16/97, B. Fox, J. Luciani - draft-wang-ion-scsp-mib-00.txt, Definitions of Managed Objects for SCSP Using SMIv2, 11/24/97, J. Luciani, C. Verrilli, C. Wang - draft-wang-ion-sec-scsp-00.txt, Security Analysis to Server Cache Synchronization Protocol, 3/9/98, C. Wang, S. Wu Grenville Armitage reports that he is no longer in a position to progress the drafts which he has authored. The wg is soliciting someone to take on this effort. 2. Router to Router NHRP - Joel Halpern draft-halpern-ion-rtr-nhrp-00.txt As defined, at least one end of a NHRP query must be stable. That is, the binding between either the source IP and NBMA addresses or the binding between the destination IP and NBMA addresses must be stable. However, NHRP is being used between router. This is subject to loops. The purpose of this draft is to define how to use NHRP safely/correctly between routers. It is based on work done by Yakov Rekhter Two general issues are addressed: prefix handling and routing protocol boundaries. The approach to prefix handling is to send the complete destination IP address and to set the prefix lenght to one. (Optimally this should be zero, however the current coding does not allow one to express zero. This deficiency is so minor as to not be considered worth fixing.) Each router which processes the query must increase the length to the lenght of the prefix it uses to this destination. If however, there are prefixes contained within the range of that prefix, then the lenght must be increase to the longest of these prefixes. In no case does a router shorted the prefix length. To avoid loops, and avoid excessive maintenance it is necessary to keep state. Specifically, keep state at each routing protocol border. Due to the possibility of running multiple IGPs, it may not be possible to implicitly determine the IGP/IGP border. Thus a mechanism is added to note the IGP from which this query was routed at the previous hop. Routing Stability Routing sometimes changes. Shortcuts based on transitory state are a waste of effort, or worse So, we should avoid this. Should we avoid using routing entries in holddown? Any other ways to tell when things are stable? BGP Mostly, we just need to know when we enter BGP. However, we can not exit the NBMA inside an AS. The exit device will not be in a position to monitor topology. How do we detect this case? Can we just have the BGP Border do monitoring rather than termination? Additional Issues What happens if a "state maintaining router" other than the NBMA ingress or egress loses its state? Can we detect this? Can we recover? Are there scaling implications which limit the applicability and need to be spelled out? Do we need a formal proof of correctness? This latter issue was discussed. It was decided that good engineering and field experience would suffice. Joel requested the help of the working group on the open issues. The draft moved to a wg draft. 3. Setting up shortcuts without NHRP, K. K. Ramakrishnan, Tony Lauck Tony Lauck presented a scheme for setting up ATM shortcuts using information carried in OSPF. This scheme as Rob Coltun pointed out is very similar to the ARA proposal. Jim Luciani questioned the actual latency reduction. This lead the authors to note another item that they are working on is a fast ATM call setup. Jim also pointed out that this scheme bypasses some of the policy and security mechanisms which exist in NHRP. The presentation was informational; the work group was not asked to take any action. K.K. plans to work with Rob and Juha to incorporate his ideas into the ARA proposal. 4. Lou Berger NHRP Flow Extension draft-ietf-ion-nhrp-flowext-00.txt This draft provides a finer granularity NHRP resolution. Resolution based on destination addresses may not be adequate for all cases. The case addressed by this document is when the NBMA next hop is dependent on the contents of a data packet, i.e. its type of traffic. The extension presented in this document provides the ability to resolve NBMA next hops based on destination and additional data packet information. Possible uses of this extention are selecting among multiple parallel links, filtering, and use with other extensions, i.e. the in progress CoS/QoS Extension. Although the current draft concerns itself largely with policy, the real objective is CoS/QoS although that section is weak due to time constraints. Basic Operation Requesting NHC includes Flow Extension in NHRP request message The extention describes the flow and initializes the Policy Area. Intermediate and serving NHSs update the extention based on local policy they are only allowed to describe in MORE restrictive fashion. The serving NHS includes extension in corresponding Resolution Reply message. The are no changes to transit NHS processing. The source NHC acts based on information in reply. The source NHC may: 1. Use the indicated next hop(s) following information in Reply (normal case), forwarding matching data traffic and NOT forwarding non matching traffic. 2. Use the Routed path (in the case where the shortcut resources are unavailable or other error 3. Drop matching traffic when indicated by extension. The source NHC MUST NOT forward non-matching data traffic based on reply information Lou would like feedback from working group. He will be issuing an updated draft prior to Orlando. Related to this draft is a CoS/QoS Extension. This is in progress - and a draft will be issued soon. NHRP Requests will include capabilities. Replies will provide the desired CoS/QoS. Support for multiple semantics is planned including IntServ, ATM, and rewriting the ToS field in support of DifServ. 4. IPv6 over NBMA networks - Markus Jork Markus reported that ION WG last call had ended for draft-ietf-ion-ipv6-01.txt, draft-ietf-ion-ipv6-atm-02.txt, draft-ietf-ion-ipv6-fr-00.txt, draft-ietf-ion-ipv6-ind-00.txt. Issues around IPv6 over ATM in PVC mode raised by the WIDE project have been resolved one week after the last IETF. New ND option number in draft-ietf-ion-ipv6 needs to be registered with the IANA. 5. RFC 1483 update - Dan Grossman RFC 1483 has been a proposed standard since July 1993. Since then there has been much progress, implementation experience since then. The current effort is to update the document and to advance it to a Draft Standard. In that vein, Dan has endeavored to lean up anachronism and improve English. The references have been updated. AAL5 options which did not exist at the time of the original draft have been addressed. Some notes on how things were expected to evolve were dropped. Dan added a lot of Must & Must nots and requested that wg participants please check. The section on LLC vs VC mux selection was removed as this is mostly historical. Clarified applicability of the NLPID encapsulation - this is now required for certain Frame Relay interworking scenarios. A reference to RFC 2364 was added for the PPP case. AAL5 reference was updated to point to Recommendation I.363.5. The text on AAL5 now specifically excludes assured mode, streaming mode, and the corrupted delivery option. The reassembly timer option is specifically allowed. A reference to CCITT work-in-progress was replace by a reference to RFC 1755. The draft will be updated and re-issued as a workgroup draft. Juha Heinanen will be added as an author, as this remains largely his original work.