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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 30 October 2018 15:15 UTC

Return-Path: <ginsberg@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 435961293FB; Tue, 30 Oct 2018 08:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 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, 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 hZPoVbcmyhyj; Tue, 30 Oct 2018 08:15:10 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB770128CFD; Tue, 30 Oct 2018 08:15:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2580; q=dns/txt; s=iport; t=1540912509; x=1542122109; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zeCtAIItdNmHfs8ET2H47jfVmYQVGUeegnbhNSYQP2c=; b=CGM293VMlhYrjwwwmmA2gW88joejR4yT7Pvs/fYByoFu0+CLuw0FGva0 b5L+6Lj2aWRSaw7rrxiwQbyAPJNQHXMUCBJ2f0vtTem76KpNYDghhtmX5 W0ydmppDIKCnERHvy/vMdicuLnNv6hqeq10047lF12F6m7wRSak7rbvq/ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AzAABbdNhb/5RdJa1jGwEBAQEDAQEBBwMBAQGBUQYBAQELAYFVL4FlMoNsiBiMGIINg0CTYIF6CwEBhGwCF4MNIjQNDQEDAQECAQECbSiFOgEBAQMBIxFFEAIBCBoCJgICAjAVEAIEAQ0NE4UACKh6gS6KJYELilwXgUE/gRGDEogCglcCnxAJApB9IIFSjnaJOY1GAhEUgSYdOIFVcBWDKIIlFxKOCItIgR8BAQ
X-IronPort-AV: E=Sophos;i="5.54,444,1534809600"; d="scan'208";a="193846913"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 15:15:08 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9UFF6Mx028065 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 15:15:07 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Oct 2018 10:15:05 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Tue, 30 Oct 2018 10:15:05 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Joe Clarke (jclarke)" <jclarke@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "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>
Thread-Topic: Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Thread-Index: AQHUcF+wsD4GjSoZrUaivTD2hLwl5qU35DIg
Date: Tue, 30 Oct 2018 15:15:05 +0000
Message-ID: <dbd0c3902f5c4e978284cff3313f334f@XCH-ALN-001.cisco.com>
References: <154058293310.8782.9766839380541329981@ietfa.amsl.com> <5BD848FF.7060400@cisco.com> <D05B905E-F9D4-42A4-A14C-9281CBC572FC@cisco.com>
In-Reply-To: <D05B905E-F9D4-42A4-A14C-9281CBC572FC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.131.57]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/wAyPH_3CiTuXE_m1IixgPstwZrc>
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: Tue, 30 Oct 2018 15:15:11 -0000

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.

   Les