Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

Peter Psenak <ppsenak@cisco.com> Wed, 31 October 2018 07:38 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85114130DD2; Wed, 31 Oct 2018 00:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 QHTUApCv3yOq; Wed, 31 Oct 2018 00:38:32 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D89128C65; Wed, 31 Oct 2018 00:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3024; q=dns/txt; s=iport; t=1540971512; x=1542181112; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1UFBNQQhzTFdxFFO805uzwDACkujcxczrb1JTgeJK9w=; b=GjyPG18u8oBI9GhbpSYdXpgtk57JwcCCdIAGLOtWT9jJtx5Q5ql6tyhQ Ny/mzAfwaoRNhc9NaEQ1whGGwujlVnzxrxbgBO1zkIun56jWhD+wK8Joi eragcOkiqCKxcbUzJXBgLEG3XCVdCBnemd4yIj6r7Wg/g+mcsYvuccXHO s=;
X-IronPort-AV: E=Sophos;i="5.54,447,1534809600"; d="scan'208";a="7667873"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2018 07:38:29 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9V7cSY6004844; Wed, 31 Oct 2018 07:38:29 GMT
Message-ID: <5BD95BF5.7060807@cisco.com>
Date: Wed, 31 Oct 2018 08:38:29 +0100
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Benjamin Kaduk <kaduk@mit.edu>, "Acee Lindem (acee)" <acee@cisco.com>
CC: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org" <draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org>
References: <154058293310.8782.9766839380541329981@ietfa.amsl.com> <5BD848FF.7060400@cisco.com> <D05B905E-F9D4-42A4-A14C-9281CBC572FC@cisco.com> <dbd0c3902f5c4e978284cff3313f334f@XCH-ALN-001.cisco.com> <3C579F25-20C3-4FFA-B3E2-C3977F311DA4@cisco.com> <20181031011631.GB45914@kduck.kaduk.org>
In-Reply-To: <20181031011631.GB45914@kduck.kaduk.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/sYAGnf4A5OAHPEf3DpiG4ccr3Z4>
Subject: Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2018 07:38:34 -0000

Hi Ben, Acee,

On 31/10/18 02:16 , Benjamin Kaduk wrote:
> On Tue, Oct 30, 2018 at 03:33:21PM +0000, Acee Lindem (acee) wrote:
>> Hi Les,
>>
>> On 10/30/18, 11:15 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com> wrote:
>>
>>      Acee -
>>
>>      >     > Section 3.2
>>      >     >
>>      >     > "When a router receives multiple overlapping ranges, it MUST
>>      >     >        conform to the procedures defined in
>>      >     >        [I-D.ietf-spring-segment-routing-mpls]."
>>      >     >
>>      >     > It would be useful to include a section pointer here.  I think your referring
>>      >     > to Section 2.3 where the router ignores the range?   Is it likely that will
>>      >     > change to something other than "ignore?"  If not, maybe it's just worth
>>      >     > mentioning that here.
>>      >
>>      >     ##PP
>>      >     I don't think it is good to specify the behavior which is described
>>      >     somewhere else. Regarding the section, the
>>      >     ietf-spring-segment-routing-mpls is still being worked on and the
>>      >     section may changes. We used the same text in OSPFv2 and ISIS SR drafts.
>>      >     I would like to be consistent here.
>>      >
>>      > Given that this is a normative reference, I don't think it would create too
>>      > much of a dependency to include the section in the reference. We've had a
>>      > protracted discussion (1-2 years) on the whole SID overlap topic in SPRING
>>      > and I believe we've finally come up with behavior and the specification of
>>      > such behavior with which everyone agree (or at least doesn't strongly
>>      > disagree).
>>      >
>>      [Les:] I strongly agree with Peter (and disagree with you).
>>      Why would we want to risk having an incorrect section reference to a document which is still being revised? This needlessly introduces a dependency such that if the section numbering changes in the SR-MPLS draft we would then have to update the dependent document(s).
>>      Note this has nothing to do with the SID overlap discussion itself. The compelling reason to NOT discuss this in the IGP documents but simply refer to the document that defines the solution is so that whatever the outcome in SPRING the IGP documents do not also have to be changed.
>>
>> While I don't feel as strongly as either of you, this could improve the readability. For example, if you read RFC 8362 you'll see that I have referred extensively to sections in RFC 5340. I may be overoptimistic but I'm hoping we are finally done with the SR-MPLS draft as it is blocking all our LSR SR documents.
>
> I also agree that specific section references can (in general) aid
> readability.  And there's always "[RFC Editor: please check with authors
> during AUTH48 that the section reference remains correct]"; we've done
> essentially that on a document I was shepherding in the past.

ok, added the section reference.

thanks,
Peter
>
> -Benjamin
> .
>