Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18

"Acee Lindem (acee)" <acee@cisco.com> Sun, 13 August 2017 23:57 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 7F5B2133CD2; Sun, 13 Aug 2017 16:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MCbkjACMNlXa; Sun, 13 Aug 2017 16:57:42 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085DF133AAB; Sun, 13 Aug 2017 16:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14959; q=dns/txt; s=iport; t=1502668662; x=1503878262; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ehppD9oK+Z6ZGR68BDdgkoaYfERlA/2WU6c9ubqZYPY=; b=EMI9+dBKDdudbvcdaBIx+2+xLFsPzeopmCTDvkRSR+ssBUa3OK4jB6Da U/NsaZ/NDKXhd20sdlYOop4onnsp1OUPYPsDpl/ZSv3AQlZj8PBNPHXo8 dJycGhw2OUtBku8X+bz0tBL+bEU4Nvc14mwDcUEuJ4l6smMXyqGU1Thib 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DlAAD45ZBZ/4oNJK1cGQEBAQEBAQEBAQEBBwEBAQEBgm9rgXgHjgqQC4FuiDeILIU1ghKFRwIahFw/GAECAQEBAQEBAWsohRgBAQEBAyNmAgEIDgMDAQIoAwICAh8RFAkIAgQBEolLTAMVrFyCJoctDYQhAQEBAQEBBAEBAQEBAQEhgyiCAoMvgyeCV4IGNoJzgmEFmA2HaDwCj0WEdYIPiVeGb4wyiWIBHziBCncVSYUXHIFndohUgQ8BAQE
X-IronPort-AV: E=Sophos;i="5.41,371,1498521600"; d="scan'208,217";a="285821310"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Aug 2017 23:57:41 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v7DNve3Y019662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 13 Aug 2017 23:57:40 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 13 Aug 2017 19:57:40 -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; Sun, 13 Aug 2017 19:57:40 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alia Atlas <akatlas@gmail.com>, OSPF List <ospf@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@ietf.org" <draft-ietf-ospf-segment-routing-extensions@ietf.org>
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18
Thread-Index: AQHTExAgVtYHriLCM06HnXNcslAzRaKC+bmA
Date: Sun, 13 Aug 2017 23:57:40 +0000
Message-ID: <D5B65E4A.C08CB%acee@cisco.com>
References: <CAG4d1reMd1rdyVb46jJgVnGJE_x8-Z1GQTsFWGSTw_8DKyy4hQ@mail.gmail.com>
In-Reply-To: <CAG4d1reMd1rdyVb46jJgVnGJE_x8-Z1GQTsFWGSTw_8DKyy4hQ@mail.gmail.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.201]
Content-Type: multipart/alternative; boundary="_000_D5B65E4AC08CBaceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/55h7ZI4bQt8Wl7IkLD5Cslp2muE>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 13 Aug 2017 23:57:44 -0000

Thanks Alia – I’ve read through the comments and I think the authors should be able to address these in this draft or the LDP interoperation draft.
Acee

From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Date: Friday, August 11, 2017 at 10:09 PM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>" <draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>>
Subject: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18

As is customary, I have done another AD review of draft-ietf-ospf-segment-routing-extensions-18. I do appreciate the improvements in the draft.

I do still see a few minor issues.  I would like to see a revised draft before IETF Last Call. I expect to progress this at an IESG telechat with the primary spring documents, when Alvaro feels they are ready.


1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router
   Information LSAs that have different flooding scopes, the SR-
   Algorithm TLV in the Router Information LSA with the narrowest
   flooding scope SHOULD be used.  "
   Given that the area-scope is REQUIRED - shouldn't this also prefer
   the area-scope?  Is there future-proofing being done?

2) In Sec 3.4: "For the purpose of the SRMS Preference TLV advertisement, AS-scoped flooding is REQUIRED.  This
   is because SRMS servers can be located in a different area then
   consumers of the SRMS advertisements.  If the SRMS advertisements
   from the SRMS server are only used inside the SRMS server's area,
   area-scoped flooding may be used."

REQUIRED is like MUST - I think you mean "AS-scoped flooded SHOULD be used.... area-scoped flooding MAY be used."

3) In Sec 4. "The Segment Routing Mapping Server, which is described in
   [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we
   need a single advertisement to advertise SIDs for multiple prefixes
   from a contiguous address range."

I've read through the vastly improved section (thank you) in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't see any explanation for why a contiguous address range is needed.

I can speculate that a primary purpose is to advertise SIDs for the loopback addresses of routers that don't support SR - and those loopback addresses are likely to be allocated from a contiguous range (though why some wouldn't be supporting SR and cause gaps isn't clear).

4) Sec 5: In the end of Sec 4.2 in draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: SR mappings advertisements cannot set Penultimate Hop Popping.
   In the previous example, P6 requires the presence of the segment 103
   such as to map it to the LDP label 1037.  For that reason, the P flag
   available in the Prefix-SID is not available in the Remote-Binding
   SID."
However, in this draft Sec 5 gives the following rules:

"As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server advertisement. However, PHP behavior SHOULD be done in following cases: The Prefix is intra-area type and the downstream neighbor is the originator of the prefix. The Prefix is inter-area type and downstream neighbor is an ABR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684]. The Prefix is external type and downstream neighbor is an ASBR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684].

These seem to be contradictory.

5) In Sec 7.1, it says "Multiple Mapping Servers can advertise
   Prefix-SIDs for the same prefix, in which case the same Prefix-SID
   MUST be advertised by all of them."

What is forcing this constraint?  Does it work if the Prefix-SID is an index into an
SRGB or SRLB that is not the same value globally? I don't see it specified in Sec 7.2 of draft-ietf-spring-segment-routing-ldp-interop-08?

Regards,
Alia