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

["Vishwas Manral" <[e-mail]>]

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.

Thanks,
Vishwas

On Jan 24, 2008 11:43 AM, Acee Lindem <[e-mail]> 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 <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf