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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 30 October 2018 14:46 UTC

Return-Path: <acee@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 A363F129C6A; Tue, 30 Oct 2018 07:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level:
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 fgb-EGX7Neyu; Tue, 30 Oct 2018 07:46:43 -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 58A39128CFD; Tue, 30 Oct 2018 07:46:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7502; q=dns/txt; s=iport; t=1540910803; x=1542120403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RqFdGzzze7zRrwuaP2h6kOXkySNu6swhgLCXe6T867U=; b=ljm1kLS7fJQ5YR/T3QK3sAvfrpywFGXSrRSgvZKOgOSjPyGzmSOdoN/k RXa2V17he9JL9Oiu45YlsOu7Bgi80iCSNX91FVdzA36NeEPSoCLn511UV NPpxnEwKMjPRvGAXr3fRfQV3DU8G08xUG/tSIhg/usfZa+mE0Gp5C55zX 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAABbbthb/51dJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggSBZSgKg2yIGIwYgg2XIIF6CwEBhGwCF4MNIjQNDQEDAQECAQECbSiFOgEBAQMBIxFFEAIBCBgCAiYCAgIwFRACBAENBYMhgXoIqGiBLoomgQuKXBeCAIERJx+CTIUVgm0xgiYCnkFPCQKRBRiBUoR3iX+WfwIRFIEmHTiBVXAVZQGCQYImFxKOCG+KWYEfAQE
X-IronPort-AV: E=Sophos;i="5.54,444,1534809600"; d="scan'208";a="463019637"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 14:46:42 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w9UEkfoZ008634 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 14:46:42 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Oct 2018 10:46:41 -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.1395.000; Tue, 30 Oct 2018 10:46:41 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "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: AQHUcEjZmKmPEynPMkOuVmLD9bmAs6U33ioA
Date: Tue, 30 Oct 2018 14:46:41 +0000
Message-ID: <D05B905E-F9D4-42A4-A14C-9281CBC572FC@cisco.com>
References: <154058293310.8782.9766839380541329981@ietfa.amsl.com> <5BD848FF.7060400@cisco.com>
In-Reply-To: <5BD848FF.7060400@cisco.com>
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.200]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1CA5B004F586A04B98CF5602F03C9144@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/w_7qmKy9SoyiCo2G2RGTrhPWgSg>
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 14:46:46 -0000

Hi Peter, Joe, et al, 

On 10/30/18, 8:05 AM, "Peter Psenak (ppsenak)" <ppsenak@cisco.com> wrote:

    Hi Joe,
    
    thanks for your review, please see inline (##PP):
    
    On 26/10/18 21:42 , Joe Clarke wrote:
    > Reviewer: Joe Clarke
    > Review result: Has Nits
    >
    > I have been assigned to review
    > draft-ietf-ospf-ospfv3-segment-routing-extensions  on behalf of the ops
    > directorate.  This document defines OSPFv3 extensions needed for segment
    > routing (SR).  And therein lies my first nit.  While the document begins to set
    > forth this overarching scope, a small paragraph in section 1 further limits it
    > to MPLS dataplanes only.  I think perhaps the abstract should be updated to
    > clarify that.
    
    ##PP
    Done
    
    
    > Other items I found are listed below.
    >
    > Overall, there are a lot of terminology used like RSVP, LDP, LSP, SID, etc.  I
    > think this document would benefit from a terminology section.
    
    ##PP
    added
    
    
    >
    > With respect to TLV types 8, 9, 14, and 15, they are defined in
    > draft-ietf-ospf-segment-routing-extensions, and it took me a while to figure
    > out where you were getting those values and why they weren't spelled out in the
    > IANA considerations.  You have a normative reference to this, which is good,
    > but you only mention it with respect to the algorithm parameters.  I think
    > another mention is required.
    >
    > I'm going to be pedantic here.  According to RFC7770, when a new OSPF Router
    > Information LSA TLV is defined, the spec needs to explicitly state if it's
    > applicable to OSPFv2, v3, or both.  While you reference the TLVs from
    > draft-ietf-ospf-segment-routing-extensions, I didn't see that either document
    > _explicitly_ states that they are applicable to both.
    
    ##PP
    added the following to each of the values:
    
    Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and 
    aplicable to OSPFv3.
    
    >
    > ===
    >
    > Section 2.1
    >
    > s/length is other then 3 or 4/length is other than 3 or 4/
    
    ##PP
    fixed
    
    >
    > ===
    >
    > Section 3.2
    >
    > s/If more then one SID/Label/If more than one SID/label/
    
    ##PP
    fixed
    
    >
    > ===
    >
    > 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). 
    
    >
    > ===
    >
    > Section 3.3
    >
    > s/If more then one SID/Label/If more than one SID/Label/
    
    ##PP
    fixed.
    
    >
    > ===
    >
    > Section 3.3
    >
    > "The originating router MUST NOT advertise overlapping ranges."
    >
    > You specify what a router should do if it receives overlapping ranges above.  I
    > think the same text should be used here, too.
    
    ##PP
    Here we say that the originating router MUST NOT advertise overlapping 
    ranges. We can not specify what it should do when it breaks the MUST.
    
    We specify what other routers should do when they receive overlapping 
    ranges and we refer it to spring-segment-routing-mpls draft. Again this 
    is the same as we used in OSPFv3 and ISIS SR extensions. I would like to 
    keep the consistency here.
    
    >
    > ===
    >
    > Section 5
    >
    > "Other bits: Reserved.  These MUST be zero when sent and are
    >           ignored when received."
    >
    > The normative language changes.  In other places you say the bits SHOULD be 0.
    > I suggest:
    
    ##PP
    Whenever we refer to "other bits" in the flag fields we use the same 
    language.
    
    >
    > Other bits: Reserved.  These SHOULD be set to 0 when sent and MUST be ignored
    > when received.
    
    ##PP
    this refers to Reserved fields in the TLV (not the bits in a flag field) 
    and again is used consistently across document.

I agree. Use "These SHOULD be set to 0 when sent and MUST be ignored when received." For all reserved bits. 

Thanks,
Acee
    
    
    >
    > ===
    >
    > Section 7.4.1
    >
    > s/state lower then 2-Way/state lower than 2-Way/
    
    ##PP
    fixed.
    
    thanks,
    Peter
    >
    > ===
    >
    >
    > .
    >