Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT)
"Acee Lindem (acee)" <acee@cisco.com> Wed, 13 December 2017 19:52 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 465F1126D45; Wed, 13 Dec 2017 11:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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, 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 ZEfjp7PQmjKM; Wed, 13 Dec 2017 11:52:42 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946CF126B71; Wed, 13 Dec 2017 11:52:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5366; q=dns/txt; s=iport; t=1513194762; x=1514404362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yqXFtUFLrnRKR5x56DMo8gjX/ChQFG4sJxacIowUChk=; b=aWKv/qIUGLa8bkKeyT68Er6l8SAWylVccGlHBxgFkem1OvdjRJFAzcL5 ZFfvFcJUIDj5NfldBMlipSzcSNSNdWf4NQytIyWUOZ3lkhn1AfHsBtc2G Q9dw4i6/pMONDLnL7nbX7z15a0goHSixYth1aPrC9O2eOJNuaLfUllie4 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DHAACLhDFa/4oNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYM+ZnQnB4N7iiGPBpkOFIIBCiWFFgIahHk/GAEBAQEBAQEBAWsohSQGIxFFEAIBCA4MAh8HAgICMBUQAgQBDQWKKBCoZIInimEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPglGCC4M/gyuDLgEBgToBEgEJgyuCYwWKSphVAod5g3GJO4IWhhKED4cxjRCJKQIRGQGBOgEfOWBWGG8VgmODCIFOeAGHcoEkgRUBAQE
X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208";a="43687284"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 19:52:41 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBDJqfNG032205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 19:52:41 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 14:52:40 -0500
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.1320.000; Wed, 13 Dec 2017 14:52:40 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ospf-segment-routing-extensions@ietf.org" <draft-ietf-ospf-segment-routing-extensions@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT)
Thread-Index: AQHTc//QW8KMe4rBDkeHYsGEb/PtbKNBr9QA
Date: Wed, 13 Dec 2017 19:52:40 +0000
Message-ID: <D656EBBC.E14BF%acee@cisco.com>
References: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.com>
In-Reply-To: <151316206521.30067.6744549826451674092.idtracker@ietfa.amsl.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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C109D2983D905048B1E073CB8638DAE7@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/qYLbFkR-R3reTuZTsFkA7r7H8OA>
Subject: Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT)
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: Wed, 13 Dec 2017 19:52:46 -0000
Hi Alexey These all seem to be valid comments except for the one on byte order. Note that section 3.1 of RFC 2360 already states that IETF document packet encodings are in Network-Byte Order (NBO). https://www.ietf.org/rfc/rfc2360.txt Typically, we have not defined Reserved field usage. However, I guess we could say that they SHOULD be set to 0 on transmission and MUST be ignored on reception. This will allow for future reuse in a backward compatible manner. Thanks, Acee On 12/13/17, 5:47 AM, "Alexey Melnikov" <aamelnikov@fastmail.fm> wrote: >Alexey Melnikov has entered the following ballot position for >draft-ietf-ospf-segment-routing-extensions-23: 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-segment-routing-extension >s/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >This is generally a clearly written document, but it needs a few minor >changes >before I can recommend its approval for publication. > >1) In Section 3.2: > > o When a router receives multiple overlapping ranges, it MUST > conform to the procedures defined in > [I-D.ietf-spring-conflict-resolution]. > >RFC 2119 keyword usage makes the reference a Normative reference, yet it >is >currently listed as informative. > >3.4. SRMS Preference TLV > > The Segment Routing Mapping Server Preference TLV (SRMS Preference > TLV) is used to advertise a preference associated with the node that > acts as an SR Mapping Server. The role of an SRMS is described in > [I-D.ietf-spring-segment-routing-ldp-interop]. > >As draff-ietf-spring-segment-routing-ldp-interop needs to be read in >order to >understand what SR Mapping Server is, this reference must also be >Normative. > > SRMS preference is defined in [I-D.ietf-spring-conflict-resolution]. > >This just confirms that this reference must be Normative. > >2) In Section 3.1: > > When multiple SR-Algorithm TLVs are received from a given router, the > receiver SHOULD use the first occurrence of the TLV in the Router > Information LSA. 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 area-scoped > flooding scope SHOULD be used. If the SR-Algorithm TLV appears in > multiple Router Information LSAs that have the same flooding scope, > the SR-Algorithm TLV in the Router Information (RI) LSA with the > numerically smallest Instance ID SHOULD be used and subsequent > instances of the SR-Algorithm TLV SHOULD be ignored. > >In the last 2 sentences: why are you using SHOULD (twice) instead of >MUST? This >seems to affect interoperability. > >(I think there is similar text in another section.) > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Several TLVs have "Reserved" fields, yet you never explain what "Reserved" >means. You do explain what reserved flags mean in some of them. I suggest >either explicitly explaining what Reserved means in each case or specify >this >in the terminology section near the beginning of the document. > >The document never specifies byte order for length fields. > >The acronym NSSA is never explained and it has no reference. > >
- [OSPF] Alexey Melnikov's Discuss on draft-ietf-os… Alexey Melnikov
- Re: [OSPF] Alexey Melnikov's Discuss on draft-iet… Acee Lindem (acee)
- Re: [OSPF] Alexey Melnikov's Discuss on draft-iet… Peter Psenak
- Re: [OSPF] Alexey Melnikov's Discuss on draft-iet… Alexey Melnikov
- Re: [OSPF] Alexey Melnikov's Discuss on draft-iet… Alexey Melnikov
- Re: [OSPF] Alexey Melnikov's Discuss on draft-iet… Acee Lindem (acee)