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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 29 June 2016 19:24 UTC

Return-Path: <acee@cisco.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 8348312D563; Wed, 29 Jun 2016 12:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 RfsuSyqwQmD0; Wed, 29 Jun 2016 12:24:33 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F333512D558; Wed, 29 Jun 2016 12:24:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8446; q=dns/txt; s=iport; t=1467228273; x=1468437873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jiwII0zb0DK82Em1SCPaQCar8YxpZDa2DeJICNiEjH0=; b=EUxhTfLTrVCUCC2TKpY4dd4Ta4bN06sayZJoseYY/zG+ydc0derp/rsk Bs5u4PcYiEMpsLN2IaZgCYueCV6sjKiyLh4K/92GA5xEv940RBqgzHev5 6roocgqYiTlaDP5k6x4ExPb91eLjxN1zh+w8XB6TTdF3ES8AafdvJ3FLR k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBzH3RX/4oNJK1bgz5WfQa3NYIPg?= =?us-ascii?q?XsihXYCHIEWOBQBAQEBAQEBZSeETQEBBCMRQAUQAgEIGAICHwcCAgIwFRACBAE?= =?us-ascii?q?NBYgwDrNekCQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBiXSEEhEBHBeCaoJaB?= =?us-ascii?q?YgWkG8BhgeINoFphFSIaIZUiS4BHjaCO4E1bgGHew0XBxh/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,548,1459814400"; d="scan'208";a="124013271"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2016 19:24:31 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u5TJOVrH002447 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 19:24:31 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 15:24:30 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 15:24:30 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.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: AQHR0bgcH1JJhVjnJkCZhri87TpVs6AA1EWA
Date: Wed, 29 Jun 2016 19:24:30 +0000
Message-ID: <D399988F.674B0%acee@cisco.com>
References: <20160629034122.22589.47318.idtracker@ietfa.amsl.com> <D3993A03.67315%acee@cisco.com> <E87B771635882B4BA20096B589152EF643D46C7B@eusaamb107.ericsson.se>
In-Reply-To: <E87B771635882B4BA20096B589152EF643D46C7B@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <63B93BC3FB387C4CA284A6EF54F092CD@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/Ct0c72e5KOtT3ENQ5P30kob_-_Y>
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 19:24:35 -0000

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
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>
>>
>