From: Keith McCloghrie Subject: Re: ["Robin Tasker": Priority in 802.1p] To: Peter_Wang@3mail.3Com.COM Date: Thu, 11 Apr 1996 01:20:18 -0700 (PDT) Cc: nfinn@cisco.com, P8021@nic.hep.net > >>That's more-or-less exactly what ATM Forum is attempting to do with the > >>MPOA (Multi-Procotol Over ATM) group; its trying to make IETF's NHRP and > >>Mars work with IEEE VLANs and ATM Forum LAN Emulation. > > Is IETF reciprocating? Attempting to work with other standards body is > certainly desirable. Depending on working the whole solution out by > coordinating multiple standards is not something I think I'd want to > count on. The IETF is indeed reciprocating. For example, changes to NHRP requested by MPOA were incorporated into the NHRP spec by the IETF's ROLC working-group, and there is current work to align the IETF's proposal for a Server Cache Synchronization Protocol for NHRP/ATM-ATP/ MARS with LAN Emulation's LNNI, the idea being that each body provide complementary parts of the solution. Most vendors need to implement the standards from both bodies, and as you suggest, everyone wins when there are shared mechanisms. > >>There is another problem, of course, with registering priorities with > >>unicast MAC addresses -- the registration of those addresses. The > >>thought of propagating 8 * (the number of endstations) worth of unicast > >>MAC address registrations in order to establish the infrastructure > >>required for QoS packet delivery is obviously absurd. > > I believe the current draft recommended using two priority levels as default. Even with only two levels, propogating two addresses for every endsystem to every bridge in the layer-2 network doesn't scale. (Even propogating one address for each endsystem is questionable; sounds like a layer-2 routing protocol). > What 802.3's action might alleviate is the need to specify priority within GARP. > However, using the source MAC I/G bit is source driven. RSVP is very much > destination driven, i.e. destination sending the request towards the source. > Personally, the source driven approach seems just fine for unicast deliveries. > It may be OK for the majority of the multicast delivery scenarios, though I'm > not totally convinced that it is. Hence, the question is whether we should > allow for both source-driven and destination driven approaches? It's the RSVP reservation-request which is sent by the destination; the actual data is sent by the source (by definition :-). So, I submit that 802.1p does not need to consider a destination-driven approach unless it were to use reservations, which gets us back to Robin's original comment. Keith.