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

["Vishwas Manral" <vishwas.ietf at gmail.com>]

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?

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