Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-transition-to-ospfv3-10: (with DISCUSS and COMMENT)

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 29 June 2016 23:13 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF5412D590; Wed, 29 Jun 2016 16:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXo7CUVegcyA; Wed, 29 Jun 2016 16:13:18 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E7012D917; Wed, 29 Jun 2016 16:13:13 -0700 (PDT)
X-AuditID: c618062d-f79886d000002334-a7-57744bbb82fc
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id B6.03.09012.BBB44775; Thu, 30 Jun 2016 00:29:15 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0294.000; Wed, 29 Jun 2016 19:13:11 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, The IESG <iesg@ietf.org>
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ospf-transition-to-ospfv3-10: (with DISCUSS and COMMENT)
Thread-Index: AQHR0bgfEaJcZakKeU+i75Ki6x5aYw==
Date: Wed, 29 Jun 2016 23:13:11 +0000
Message-ID: <E87B771635882B4BA20096B589152EF643D47EE6@eusaamb107.ericsson.se>
References: <20160629034122.22589.47318.idtracker@ietfa.amsl.com> <D3993A03.67315%acee@cisco.com> <E87B771635882B4BA20096B589152EF643D46C7B@eusaamb107.ericsson.se> <D399988F.674B0%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonXHe3d0m4wYctGhaT385jtmg+e4bJ YsaficwW38/+Z7RouXeP3aL12SomBzaPKb83snrsnHWX3WPJkp9MAcxRXDYpqTmZZalF+nYJ XBlTtmxgLVhoWXF6/knWBsa/ul2MnBwSAiYSJ/dtZoWwxSQu3FvP1sXIxSEkcJRRYtqstSwQ znJGiUlr7rOBVLEBdWzY+ZkJxBYRcJbYsfgaWBGzwBNGiSMX7jOCJIQF8iWWv1sBVVQgcefb VXYIW09izcUOsBoWAVWJ5dPmgK3mFfCVeDl3PxPEtpOMEicaDrOAJBiBbvp+ag3YIGYBcYlb T+YzQdwqILFkz3lmCFtU4uXjf1A/KEnMeX2NGaLeQOL9uflQtrbEsoWvmSGWCUqcnPmEZQKj 6CwkY2chaZmFpGUWkpYFjCyrGDlKiwtyctONDDYxAqPomASb7g7G+9M9DzEKcDAq8fAu4CkJ F2JNLCuuzD3EKMHBrCTCGxkKFOJNSaysSi3Kjy8qzUktPsQozcGiJM4r9kgxXEggPbEkNTs1 tSC1CCbLxMEp1cBYmv36ca5kR7T5nX+59Y2h4nVKmhpbW30zPjz6+s31OvfcO3cur/G2b5i3 Ru1AfiNb6LS5PIVHPKYK3LpybCXzW4fVCvVTU8WuvykOdHXaWban9HareGHOw9e/3Rjvn3s3 zffialmZawdezj55IvXJ6vQW2cZbB3Y76Yn/ecvPnbF2+f7jIffZlViKMxINtZiLihMB+kFe B54CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/v8F8WhCFA32C-BZyvshm0o6zAhE>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "draft-ietf-ospf-transition-to-ospfv3@ietf.org" <draft-ietf-ospf-transition-to-ospfv3@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, "wenhu.lu@gmail.com" <wenhu.lu@gmail.com>
Subject: Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-transition-to-ospfv3-10: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2016 23:13:21 -0000

Thanks Acee. Looks good to me. I have cleared.

Regards
Suresh

On 06/29/2016 03:24 PM, Acee Lindem (acee) wrote:
> Hi Suresh,
>
> We’ve updated the draft.
>
> Thanks,
> Acee
>
> On 6/29/16, 11:10 AM, "Suresh Krishnan" <suresh.krishnan@ericsson.com>
> wrote:
>
>> Hi Acee,
>>    Thanks for the quick turanround. All your proposed changes look good
>> to
>> me. I will clear as soon as a new version posts. We can probably discuss
>> the
>> "Updates:" issue on the telechat but I do not have strong feelings about
>> this
>> one way or another.
>>
>> Cheers
>> Suresh
>>
>> On 06/29/2016 09:49 AM, Acee Lindem (acee) wrote:
>>> Hi Suresh,
>>>
>>> On 6/28/16, 11:41 PM, "Suresh Krishnan" <suresh.krishnan@ericsson.com>
>>> wrote:
>>>
>>>> Suresh Krishnan has entered the following ballot position for
>>>> draft-ietf-ospf-transition-to-ospfv3-10: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> I do think this is a good mechanism to transition from IPv4-only OSPFv2
>>>> to dual-stack capable OSPFv3 and I intend to switch to a Yes once my
>>>> discuss points are addressed.
>>>>
>>>> * The calculation for the checksum field in the OSPFv3 packet is not
>>>> specified in this document. The RFC5340 checksum calculation uses the
>>>> IPv6 pseudo-header mechanism for upper layer checksums as specified in
>>>> Section 8.1 of RFC2460. Since that obviously won't work here (as there
>>>> are no source and dest IPv6 addresses) some different mechanism needs
>>>> to
>>>> be specified here.
>>>
>>> Agreed. We will add this - not sure how we missed it. Many IPv4
>>> protocols
>>> (including OSPFv2 as described in RFC 2328) exclude the pseudo-header
>>> from
>>> the standard checksum calculation. Since we have it in OSPFv3 over IPv6
>>> with the RFC 2460 pseudo header, I feel we should retain it here lest we
>>> open up OSPFv3 to a documented OSPFv3 vulnerably when authentication is
>>> not used.
>>>
>>> I propose we just use a variant of the UDP pseudo header as described in
>>> RFC 768.
>>>
>>> For IPv4 transport, the pseudo-header used in the checksum calculation
>>> will
>>> contain the IPv4 source and destination addresses, the OSPFv3 protocol
>>> ID,
>>> and the OSPFv3 length from the OSPFv3 header (Appendix A.3.1 [RFC5340]).
>>> The format is similar to the UDP pseudo-header as described in [RFC768].
>>>
>>>
>>>    0                   1                   2                   3
>>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                       Source Address                          |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                    Destination Address                        |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |     0         | Protocol (89) |     OSPFv3 Packet Length      |
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>
>>>
>>>
>>>
>>>
>>>> * (based on the above) Why doesn't this document update RFC5340?
>>>
>>> It could. However, RFC 5340 solely describes OSPFv3 with IPv6 transport.
>>> Whether or not an enhancement that doesn’t change an existing
>>> specification but augments it has always been a debate. We usually err
>>> on
>>> the side of updating. What is the IESG take on this?
>>>
>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> I do have one question that I am curious about. Can this mechanism be
>>>> run
>>>> alongside OSPFv2 on the same router? If so, how does the demultiplexing
>>>> take place to dispatch the packet to either the OSPFv2 or the
>>>> OSPFv3-over-IPv4 implementation (as the endpoints are potentially the
>>>> same and the IP proto number 89 is usually dispatched to OSPFv2)? Does
>>>> it
>>>> require inserting some sort of shim in the OSPFv2 implementation to
>>>> further dispatch on the version number octet?
>>>
>>> No shim is necessary since both OSPFv2 and OSPFv3 will check the version
>>> number in the first octet of the OSPF(v3) packet header. Commercial
>>> implementations normally would normally drop the packet before this
>>> stage
>>> unless one has both OSPFv2 and OSPFv3 running on the same interface.
>>> However, I think this should be discussed in a “Management
>>> Considerations”
>>> section.
>>>
>>>    5.0 Management Considerations
>>>
>>>    5.1 Coexistence with OSPFv2
>>>
>>>    Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use
>>>    exactly the same protocol and IPv4 addresses, OSPFv2 packets may be
>>>    delivered to the OSPFv3 process and vice versa. When this occurs, the
>>>    mismatched protocol packets will be dropped due to validation of the
>>>    version in the first octet of the OSPFv2/OSPFv3 protocol header. Note
>>>    that this will not prevent the packets from being delivered to the
>>>    correct protocol process as standard socket implementations will
>>>    deliver a copy to each socket matching the selectors.
>>>
>>>    Implementations of OSPFv3 over IPv4 transport SHOULD implement
>>>    separate counters for a protocol mismatch and SHOULD provide
>>>    means to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket
>>>    SNMP notifications as described in [RFC4750] and the
>>>    ospfv3IfRxBadPacket and ospv3VirtIfRxBadPacket SNMP notifications
>>>    as described in [RFC5643] when an OSPFv2 packet is received by
>>>    the OSPFv3 process or vice versa.
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>
>>>
>>
>
>