[Lsr] [Technical Errata Reported] RFC5185 (6506)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Lsr] [Technical Errata Reported] RFC5185 (6506)

rfc-editor
The following errata report has been submitted for RFC5185,
"OSPF Multi-Area Adjacency".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6506

--------------------------------------
Type: Technical
Reported by: Ketan Talaulikar <[hidden email]>

Section: 2.7

Original Text
-------------
   Multi-area adjacencies are announced as point-to-point links.  Once
   the router's multi-area adjacency reaches the FULL state, it will be
   added as a link type 1 to the Router Link State Advertisement (LSA)
   with:

      Link ID = Remote's Router ID

      Link Data = Neighbor's IP Address or IfIndex (if the underlying
      interface is unnumbered).

   Unlike numbered point-to-point links, no type 3 link is advertised
   for multi-area adjacencies.


Corrected Text
--------------
   Multi-area adjacencies are announced as point-to-point links.  Once
   the router's multi-area adjacency reaches the FULL state, it will be
   added as a link type 1 to the Router Link State Advertisement (LSA)
   with:

      Link ID = Remote's Router ID

      Link Data = Router interface's IP Address or IfIndex (if the underlying
      interface is unnumbered).

   Unlike numbered point-to-point links, no type 3 link is advertised
   for multi-area adjacencies.


Notes
-----
The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues.

More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510.

This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5185 (draft-ietf-ospf-multi-area-adj-09)
--------------------------------------
Title               : OSPF Multi-Area Adjacency
Publication Date    : May 2008
Author(s)           : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal
Category            : PROPOSED STANDARD
Source              : Open Shortest Path First IGP
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
Lsr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/lsr
Reply | Threaded
Open this post in threaded view
|

Re: [Lsr] [Technical Errata Reported] RFC5185 (6506)

John Scudder
Hi All,

I took a look at the list thread Ketan references at the bottom of the proposed erratum. It seems pretty clear this would be a technical change vs. the WG consensus when the document was progressed, and should be rejected (see https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ #7). The appropriate way to pursue this looks to be an update or bis.

If there’s any disagreement, please let me know (and let me know why you think it’s appropriate as an erratum).

Thanks,

—John

> On Apr 2, 2021, at 8:29 AM, RFC Errata System <[hidden email]> wrote:
>
> [External Email. Be cautious of content]
>
>
> The following errata report has been submitted for RFC5185,
> "OSPF Multi-Area Adjacency".
>
> --------------------------------------
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6506__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hadu8NhQ$
>
> --------------------------------------
> Type: Technical
> Reported by: Ketan Talaulikar <[hidden email]>
>
> Section: 2.7
>
> Original Text
> -------------
>   Multi-area adjacencies are announced as point-to-point links.  Once
>   the router's multi-area adjacency reaches the FULL state, it will be
>   added as a link type 1 to the Router Link State Advertisement (LSA)
>   with:
>
>      Link ID = Remote's Router ID
>
>      Link Data = Neighbor's IP Address or IfIndex (if the underlying
>      interface is unnumbered).
>
>   Unlike numbered point-to-point links, no type 3 link is advertised
>   for multi-area adjacencies.
>
>
> Corrected Text
> --------------
>   Multi-area adjacencies are announced as point-to-point links.  Once
>   the router's multi-area adjacency reaches the FULL state, it will be
>   added as a link type 1 to the Router Link State Advertisement (LSA)
>   with:
>
>      Link ID = Remote's Router ID
>
>      Link Data = Router interface's IP Address or IfIndex (if the underlying
>      interface is unnumbered).
>
>   Unlike numbered point-to-point links, no type 3 link is advertised
>   for multi-area adjacencies.
>
>
> Notes
> -----
> The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues.
>
> More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510.
>
> This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hYBp-ZDA$
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5185 (draft-ietf-ospf-multi-area-adj-09)
> --------------------------------------
> Title               : OSPF Multi-Area Adjacency
> Publication Date    : May 2008
> Author(s)           : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal
> Category            : PROPOSED STANDARD
> Source              : Open Shortest Path First IGP
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG

_______________________________________________
Lsr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/lsr
Reply | Threaded
Open this post in threaded view
|

Re: [Lsr] [Technical Errata Reported] RFC5185 (6506)

Acee Lindem (acee)
I agree. This is probably similar to the situation of https://datatracker.ietf.org/doc/rfc8950/ where implementations did it differently than the specification.

Thanks,
Acee

On 5/10/21, 2:34 PM, "John Scudder" <[hidden email]> wrote:

    Hi All,

    I took a look at the list thread Ketan references at the bottom of the proposed erratum. It seems pretty clear this would be a technical change vs. the WG consensus when the document was progressed, and should be rejected (see https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ #7). The appropriate way to pursue this looks to be an update or bis.

    If there’s any disagreement, please let me know (and let me know why you think it’s appropriate as an erratum).

    Thanks,

    —John

    > On Apr 2, 2021, at 8:29 AM, RFC Errata System <[hidden email]> wrote:
    >
    > [External Email. Be cautious of content]
    >
    >
    > The following errata report has been submitted for RFC5185,
    > "OSPF Multi-Area Adjacency".
    >
    > --------------------------------------
    > You may review the report below and at:
    > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6506__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hadu8NhQ$
    >
    > --------------------------------------
    > Type: Technical
    > Reported by: Ketan Talaulikar <[hidden email]>
    >
    > Section: 2.7
    >
    > Original Text
    > -------------
    >   Multi-area adjacencies are announced as point-to-point links.  Once
    >   the router's multi-area adjacency reaches the FULL state, it will be
    >   added as a link type 1 to the Router Link State Advertisement (LSA)
    >   with:
    >
    >      Link ID = Remote's Router ID
    >
    >      Link Data = Neighbor's IP Address or IfIndex (if the underlying
    >      interface is unnumbered).
    >
    >   Unlike numbered point-to-point links, no type 3 link is advertised
    >   for multi-area adjacencies.
    >
    >
    > Corrected Text
    > --------------
    >   Multi-area adjacencies are announced as point-to-point links.  Once
    >   the router's multi-area adjacency reaches the FULL state, it will be
    >   added as a link type 1 to the Router Link State Advertisement (LSA)
    >   with:
    >
    >      Link ID = Remote's Router ID
    >
    >      Link Data = Router interface's IP Address or IfIndex (if the underlying
    >      interface is unnumbered).
    >
    >   Unlike numbered point-to-point links, no type 3 link is advertised
    >   for multi-area adjacencies.
    >
    >
    > Notes
    > -----
    > The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues.
    >
    > More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510.
    >
    > This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hYBp-ZDA$
    >
    > Instructions:
    > -------------
    > This erratum is currently posted as "Reported". If necessary, please
    > use "Reply All" to discuss whether it should be verified or
    > rejected. When a decision is reached, the verifying party
    > can log in to change the status and edit the report, if necessary.
    >
    > --------------------------------------
    > RFC5185 (draft-ietf-ospf-multi-area-adj-09)
    > --------------------------------------
    > Title               : OSPF Multi-Area Adjacency
    > Publication Date    : May 2008
    > Author(s)           : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal
    > Category            : PROPOSED STANDARD
    > Source              : Open Shortest Path First IGP
    > Area                : Routing
    > Stream              : IETF
    > Verifying Party     : IESG


_______________________________________________
Lsr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/lsr
Reply | Threaded
Open this post in threaded view
|

Re: [Lsr] [Technical Errata Reported] RFC5185 (6506)

Peter Psenak
In reply to this post by John Scudder
Hi Jonh,

On 10/05/2021 20:34, John Scudder wrote:
> Hi All,
>
> I took a look at the list thread Ketan references at the bottom of the proposed erratum. It seems pretty clear this would be a technical change vs. the WG consensus when the document was progressed, and should be rejected (see https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ #7). The appropriate way to pursue this looks to be an update or bis.
>
> If there’s any disagreement, please let me know (and let me know why you think it’s appropriate as an erratum).

no disagreement on my side.

thanks,
Peter


>
> Thanks,
>
> —John
>
>> On Apr 2, 2021, at 8:29 AM, RFC Errata System <[hidden email]> wrote:
>>
>> [External Email. Be cautious of content]
>>
>>
>> The following errata report has been submitted for RFC5185,
>> "OSPF Multi-Area Adjacency".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6506__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hadu8NhQ$
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Ketan Talaulikar <[hidden email]>
>>
>> Section: 2.7
>>
>> Original Text
>> -------------
>>    Multi-area adjacencies are announced as point-to-point links.  Once
>>    the router's multi-area adjacency reaches the FULL state, it will be
>>    added as a link type 1 to the Router Link State Advertisement (LSA)
>>    with:
>>
>>       Link ID = Remote's Router ID
>>
>>       Link Data = Neighbor's IP Address or IfIndex (if the underlying
>>       interface is unnumbered).
>>
>>    Unlike numbered point-to-point links, no type 3 link is advertised
>>    for multi-area adjacencies.
>>
>>
>> Corrected Text
>> --------------
>>    Multi-area adjacencies are announced as point-to-point links.  Once
>>    the router's multi-area adjacency reaches the FULL state, it will be
>>    added as a link type 1 to the Router Link State Advertisement (LSA)
>>    with:
>>
>>       Link ID = Remote's Router ID
>>
>>       Link Data = Router interface's IP Address or IfIndex (if the underlying
>>       interface is unnumbered).
>>
>>    Unlike numbered point-to-point links, no type 3 link is advertised
>>    for multi-area adjacencies.
>>
>>
>> Notes
>> -----
>> The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues.
>>
>> More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510.
>>
>> This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hYBp-ZDA$
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5185 (draft-ietf-ospf-multi-area-adj-09)
>> --------------------------------------
>> Title               : OSPF Multi-Area Adjacency
>> Publication Date    : May 2008
>> Author(s)           : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal
>> Category            : PROPOSED STANDARD
>> Source              : Open Shortest Path First IGP
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG
>
>
>

_______________________________________________
Lsr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/lsr
Reply | Threaded
Open this post in threaded view
|

Re: [Lsr] [Technical Errata Reported] RFC5185 (6506)

Ketan Talaulikar (ketant)
Hi John/Acee/Peter,

I was not in a position to judge for myself on this matter and hence thought prudent to first raise this as an erratum.

I have no issues with pursuing this update via a bis.

Thanks,
Ketan

-----Original Message-----
From: Peter Psenak <[hidden email]>
Sent: 12 May 2021 12:59
To: John Scudder <[hidden email]>; Ketan Talaulikar (ketant) <[hidden email]>; [hidden email]
Cc: [hidden email]; [hidden email]; Alvaro Retana <[hidden email]>; Martin Vigoureux <[hidden email]>; [hidden email]; Acee Lindem (acee) <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5185 (6506)

Hi Jonh,

On 10/05/2021 20:34, John Scudder wrote:
> Hi All,
>
> I took a look at the list thread Ketan references at the bottom of the proposed erratum. It seems pretty clear this would be a technical change vs. the WG consensus when the document was progressed, and should be rejected (see https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ #7). The appropriate way to pursue this looks to be an update or bis.
>
> If there’s any disagreement, please let me know (and let me know why you think it’s appropriate as an erratum).

no disagreement on my side.

thanks,
Peter


>
> Thanks,
>
> —John
>
>> On Apr 2, 2021, at 8:29 AM, RFC Errata System <[hidden email]> wrote:
>>
>> [External Email. Be cautious of content]
>>
>>
>> The following errata report has been submitted for RFC5185, "OSPF
>> Multi-Area Adjacency".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6506
>> __;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVt
>> Z5hadu8NhQ$
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Ketan Talaulikar <[hidden email]>
>>
>> Section: 2.7
>>
>> Original Text
>> -------------
>>    Multi-area adjacencies are announced as point-to-point links.  Once
>>    the router's multi-area adjacency reaches the FULL state, it will be
>>    added as a link type 1 to the Router Link State Advertisement (LSA)
>>    with:
>>
>>       Link ID = Remote's Router ID
>>
>>       Link Data = Neighbor's IP Address or IfIndex (if the underlying
>>       interface is unnumbered).
>>
>>    Unlike numbered point-to-point links, no type 3 link is advertised
>>    for multi-area adjacencies.
>>
>>
>> Corrected Text
>> --------------
>>    Multi-area adjacencies are announced as point-to-point links.  Once
>>    the router's multi-area adjacency reaches the FULL state, it will be
>>    added as a link type 1 to the Router Link State Advertisement (LSA)
>>    with:
>>
>>       Link ID = Remote's Router ID
>>
>>       Link Data = Router interface's IP Address or IfIndex (if the underlying
>>       interface is unnumbered).
>>
>>    Unlike numbered point-to-point links, no type 3 link is advertised
>>    for multi-area adjacencies.
>>
>>
>> Notes
>> -----
>> The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues.
>>
>> More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510.
>>
>> This topic has been discussed in the LSR WG recently and this errata
>> is being raised to track this issue :
>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr
>> /iL85WkrqhI17wUrxd-WozMQvKtE/__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMAT
>> vZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hYBp-ZDA$
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or rejected.
>> When a decision is reached, the verifying party can log in to change
>> the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5185 (draft-ietf-ospf-multi-area-adj-09)
>> --------------------------------------
>> Title               : OSPF Multi-Area Adjacency
>> Publication Date    : May 2008
>> Author(s)           : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal
>> Category            : PROPOSED STANDARD
>> Source              : Open Shortest Path First IGP
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG
>
>
>

_______________________________________________
Lsr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/lsr