Hi Carlos, On Nov 15, 2011, at 12:10 PM, Carlos Pignataro wrote:
> Hi Acee, > > On 11/14/2011 10:11 PM, Acee Lindem wrote: >> >> On Nov 14, 2011, at 9:46 PM, Lorenzo Colitti wrote: >> >>> On Tue, Nov 15, 2011 at 10:25, Acee Lindem <acee.lin...@ericsson.com >>> <mailto:acee.lin...@ericsson.com>> wrote: >>> >>>> 1. I think the OSPFv3 router ID should not be based on the MAC >>> address because that will encourage people to assume it's unique >>> "most of the time". I think we should just make it a pseudo-random >>> number so it's clear that uniqueness is only guaranteed by >>> collision detection and that collision detection needs to be robust. >>> >>> The draft requires duplicate Router-ID detection and resolution. I >>> don't think that the fact that a portion of the MAC address is >>> used as a first try is reason for this detection/resolution not to >>> be implemented or tested. >>> >>> >>> In my experience, giving people something that works "most of the >>> time" will cause the cases where it doesn't work to break. I think >>> it's better to explicitly provide no guarantees of uniqueness to make >>> it clear that collision detection needs to be robust. >> >> In the OSPF WG, the fact that a mechanism is specified implies that it >> is required to be robust. >> >>> Also, if we rely on collision detection, then what's the advantage of >>> using the MAC address? We might as well as make it random all the time >>> - that probably has a lower chance of collision anyway. >> >> I can't disagree with this argument and think we could go with a >> psuedo-random number seeded with a hash on the hardware fingerprint as >> the first try for router-id. >> > > As a side note, what's your opinion on citing and suggesting/requiring > <http://tools.ietf.org/html/rfc5642#section-4> for manageability? I think the dynamic host-name is less applicable in an auto-configured routing domain than other domains. In the auto-configured routing domain, you hope that little monitoring, debugging, or interaction is required. Thanks, Acee > > Thanks, > > -- Carlos. > >>> >>> I think you mean virtual links. They are definitely not needed in >>> the auto-configured environment as they are for providing a >>> backbone path through a transit area and the OSPFv3 >>> auto-configured routing domain assumes only a backbone area. >>> >>> >>> Yes, virtual links. Do we need to state explicitly that they cannot >>> exist and are not supported? >> >> Since the auto-configured routing domain is area 0 only, it is explicit. >> >>> >>> >>>> 3. Can we use normal LSAs to detect collisions? One idea would >>> be "if you see your own router ID in the list of neighbours of a >>> network LSA or router LSA, then there is a collision". Will that >>> work? If so we wouldn't need the hardware fingerprint at all. >>> >>> No. In an arbitrary topology, A router with a duplicate router-id >>> can be multiple hops away. >>> >>> >>> Yes, but router and network LSAs are flooded, so you'll hear them >>> regardless of whether your duplicate is multiple hops away, no? >> >> Both OSPFv3 and OSPFv2 would consider an unrecognized self-originated >> LSA, i.e. having our Route-ID, as a stale LSA and purge it. This is a >> very basic mechanism of OSPF. I'd rather use a separate mechanism for >> duplicate Router-ID detection. I considered techniques involving the >> encoding some additional information in the Router-LSA but these all >> seemed to be hacked. >> >> >>> >>> >>> If the pre-shared key is hard-coded, it is no better than the >>> OSPFv3 Interface Instance ID that is specified to prevent >>> inadvertent adjacencies with routers not supporting the >>> auto-configuration. If configuration of a pre-shared key is >>> required, you no longer have auto-configuration. >>> >>> >>> Sorry, that wasn't clear. What I meant to say is that we should pick >>> one scheme (e.g., HMAC-SHA) and stick to it; we shouldn't support >>> multiple schemes as that will lead to interoperability issues for >>> devices that use one scheme and devices that use another scheme. >> >> The OSPFv3 Instance ID is part of the base OSPFv3 specification and I >> think it is a very good mechanism to prevent inadvertent adjacencies. If >> we need real authentication, we'll need a pre-shared key. I don't see >> any advantage of authentication with a well-known pre-shared key to >> prevent inadvertent adjacencies. >> >> Thanks for the comments, >> Acee >> >> >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
