Re: proposed TRILL IS-IS System ID text
Donald Eastlake <[email protected]> Sun, 30 Jan 2011 22:39:13 -0500
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
On 01/27/11 12:31, William Allen Simpson wrote: > On 1/27/11 6:03 AM, William Allen Simpson wrote: >> 3. An implementation that has only PPP links might have no previously >> configured Media Access Control (MAC) that can function as an >> IS-IS System ID. In this case, the System ID is formed by adding >> a randomly generated 14-bit leading number (in place of an OUI) to >> the link's unique LCP Magic Number. I think it is a very bad idea to mandate this method which, as far as I know, is radically different from all methods currently in use. For example, some manufacturers just allocate a 48-bit number related to their MAC address space for each switch and use that as the System ID regardless of the type of any switch interfaces or the MAC addresses of any interfaces that have MAC addresses. Why should they change their behavior just because it happens that they have all PPP interfaces? Having all PPP interface is a state that could change dynamically. I would suggest, at a minimum, the following changes: - Replace the beginning with something more like "An RBridge that has only PPP interfaces might not have a conveniently available MAC address from which a System ID that would be unique across the campus can be derived. A possible statistical source of a System ID that implementors may wish to consider would be formed by ...." - Add a reference to [RFC4086] after "randomly generated". - Add a reference to [RFC5342] after "OUI". - The reference to "the link" is obviously problematic if their are more than one. Suggest changing to "a link". Even with the above changes, I'm pretty dubious. >> The Magic Number MUST be >> unique for all links and all known link peers. My impression from other posts is that you are not just trying to change how people do IS-IS, but aspects of how they do PPP as well. >> This pseudo-MAC >> MUST have both the "locally-assigned" and "broadcast/multicast" >> (group) bits set to 1; that is, the least significant two bits of >> the most significant octet are both set to 1. > > Looking at this again, and remembering how fanatic the new RFC Editors (TM) > are about abbreviations, probably needs to expand OUI, too: > > .... In this case, the System ID is formed by appending > the link's unique 32-bit LCP Magic Number after a randomly generated > 14-bit number in place of an Organizationally Unique Identifier (OUI). Sure. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA [email protected] _______________________________________________ Pppext mailing list [email protected] https://www.ietf.org/mailman/listinfo/pppext