[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OSPF] Re: draft-acee-ospf-multi-instance-00


On Jan 24, 2008, at 3:09 PM, Vishwas Manral wrote:

Hi Acee,

I agree. The behavior of what needs to be done if one supports
instances and the other does not - retry without the instance field
set or not have adjacencies at all in such a case.


Hi Vishwas,

I hope the draft isn't this confusing. We don't want routers that don't support the draft to do anything. They just happen to get OSPF packets multicast on broadcast interfaces sent to 224.0.0.5/224.0.0.6. These OSPF router will still be able to use the standard instance (i.e., 0). For non-zero instances, these routers will drop the packets due to authentication failures. Unfortunately, some routers will also fill their logs with errors.

Thanks,
Acee





Thanks,
Vishwas

On Jan 24, 2008 11:43 AM, Acee Lindem <acee at redback.com> wrote: 
Hi Vishwas,

On Jan 24, 2008, at 2:28 PM, Vishwas Manral wrote:

Hi Acee,

Thanks a lot for the reply. The backward compatibility issue would
come unless there would be the case that the draft would not use
instance ID 0 (when working with a router not supporting the
functionality - where it would be treated as no instance - rather than
a particular instance). May be that could be clarified.

I understand what you mean - but would using LLS (which is now a part
of standards track now) be of any more help? 

LLS is only for hello and DD packets. This is required for all OSPF
packets. Also, I'd rather keep the solutions aligned with what we
have today with OSPFv3. Furthermore, if there are implementations
that gratuitously log authentication failures, there may be
implementations that do the same for unrecognized LLS TLVs.

Thanks,
Acee



Thanks again,
Vishwas

On Jan 24, 2008 10:56 AM, Acee Lindem <acee at redback.com> wrote: 
 Hi Vishwas,

From a protocol standpoint, it is completely backward compatible.
OSPF
routers not supporting the draft but receiving a multicast OSPF
packet with
a non-zero instance ID will simply treat it as an unknown AuType
and fail
authentication.

With this respect, RFC 2328 simply states:


8.2. Receiving protocol packets
o
o
o
o The packet must be authenticated. The authentication
procedure is indicated by the setting of AuType (see
Appendix D). The authentication procedure may use one or
more Authentication keys, which can be configured on a per-
interface basis. The authentication procedure may also
verify the checksum field in the OSPF packet header (which,
when used, is set to the standard IP 16-bit one's complement
checksum of the OSPF packet's contents after excluding the
64-bit authentication field). If the authentication
procedure fails, the packet should be discarded.


And:


    D.5 Message verification

        When an OSPF packet has been received on an interface, it
must
        be authenticated. The authentication procedure is
indicated by
        the setting of Autype in the standard OSPF packet header,
which
        matches the setting of Autype for the receiving OSPF
interface.

If an OSPF protocol packet is accepted as authentic,
processing
of the packet continues as specified in Section 8.2. Packets
which fail authentication are discarded.

Speaking as a draft author (not OSPF WG Co-chair):

Unfortunately, some well-deployed implementations make a bigger
fuss than is
necessary when an authentication failure occurs. IMHO, now would
be a good
time to rectify this to lesses the impact should this draft be
accepted as a
standards track document. Of course, there are manual ways of
segregating
the multi-access networks to avoid down-level routers from receiving
multicast packets for non-zero instances. Perhaps, we should
discuss these
in the draft and dispense with the more radical discussions of
requesting
new multicast addresses or other IANA code points.

Thanks,
Acee




On Jan 24, 2008, at 12:49 PM, Vishwas Manral wrote:

Hi Acee,

I wanted to know if this draft was backward compatible with current
implementation. If its not, I was also eager to know, if we have a
way
for incremental deployment.

Thanks,
Vishwas





_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www1.ietf.org/mailman/listinfo/ospf