Re: [mpls] Adam Roach's Discuss on draft-ietf-mpls-spring-lsp-ping-11: (with DISCUSS and COMMENT)

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 12 October 2017 01:56 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5301D1342F8; Wed, 11 Oct 2017 18:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vl73-wctG0q6; Wed, 11 Oct 2017 18:56:49 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB36A1342F2; Wed, 11 Oct 2017 18:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20332; q=dns/txt; s=iport; t=1507773408; x=1508983008; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b8hLTOnSLJLHALpBNYD0ZZiB1ZrtUe9ekGLAPkyJUqQ=; b=DwynCWq1K9ZuJtLlyZECmP2O01EXSH3cJtAKz/1si7l+ueR2dWonGDJI h06+A56rDrmymCe86tSipx4oNKZtjBKlSja06uipSfI1d7/xczPS5FbES 7IvLvYkPaJCZnLqXd5MA3kjv+jbJW8mnUqsgbplHvsfR2sHPQxq4grbNa U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAACLy95Z/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4tZG4nB4Nzih+PLpJmhT8OggQKI4UYAhqERT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFHgYjRBIQAgEIPwMCAgIwFBECBA4FiUBkEKlwgieLPAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgy2CB4FRgWorgn+EUgESAYMyL4IyBYoTjkuIXwKHXI0LghS?= =?us-ascii?q?Fc4sIlTYCERkBgTgBHziBAwt4FVsBhTyBTnYBhxeBJIERAQEB?=
X-IronPort-AV: E=Sophos; i="5.43,363,1503360000"; d="scan'208,217"; a="15307469"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2017 01:56:34 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v9C1uYVL002164 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Oct 2017 01:56:34 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Oct 2017 21:56:33 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Wed, 11 Oct 2017 21:56:33 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Adam Roach <adam@nostrum.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-mpls-spring-lsp-ping@ietf.org" <draft-ietf-mpls-spring-lsp-ping@ietf.org>, Loa Andersson <loa@pi.nu>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Adam Roach's Discuss on draft-ietf-mpls-spring-lsp-ping-11: (with DISCUSS and COMMENT)
Thread-Index: AQHTQuKX8ZHNy1pWWECIDnlA2ziGxKLfozwAgAACqICAABIEAA==
Date: Thu, 12 Oct 2017 01:56:33 +0000
Message-ID: <318ADB04-1C83-4F36-91C6-7CC340153D68@cisco.com>
References: <150776189575.16711.15905921797919281380.idtracker@ietfa.amsl.com> <A1DD03DE-2C24-450D-ABFB-2757284FEDAF@cisco.com> <7350d5f0-9bb1-516a-ec71-287475abb59e@nostrum.com>
In-Reply-To: <7350d5f0-9bb1-516a-ec71-287475abb59e@nostrum.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.118.116.133]
Content-Type: multipart/alternative; boundary="_000_318ADB041C834F3691C67CC340153D68ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/aLp0fIIYPfIdfv_nExeg66ZSNgA>
Subject: Re: [mpls] Adam Roach's Discuss on draft-ietf-mpls-spring-lsp-ping-11: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Oct 2017 01:56:51 -0000

Mirrored indeed. Thanks Adam. These changes are in our working copy, which we will submit when Deborah signals.

—
Carlos Pignataro, carlos@cisco.com<mailto:carlos@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Oct 11, 2017, at 8:51 PM, Adam Roach <adam@nostrum.com<mailto:adam@nostrum.com>> wrote:

Thanks! These proposed changes all look correct, assuming the "Local Interface ID" changes are mirrored in "Remote Interface ID" as well.

/a

On 10/11/17 7:42 PM, Carlos Pignataro (cpignata) wrote:
Hi, Adam,

You found a nice bug. Thank you! Please see inline.

On Oct 11, 2017, at 6:44 PM, Adam Roach <adam@nostrum.com<mailto:adam@nostrum.com>> wrote:

Adam Roach has entered the following ballot position for
draft-ietf-mpls-spring-lsp-ping-11: 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-mpls-spring-lsp-ping/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5.3 indicates that "Advertising Node Identifier" and "Receiving Node
Identifier" are "4 or 6 octets." There are two issues that arise with the way
this is currently specified, both of which can lead to a lack of
interoperability:
Indeed. This text, which is included both in the Advertising and Receiving Node ID, needs fixing. In summary, Protocol 0 needs specification of the length and value, and Protocol 1 needs to disambiguate the length.

1. While implementors might infer that "Protocol=1" results in a 4-byte value,
and that "Protocol=2" results in a 6-byte value, it's a bit unclear what length
is to be used here for "Protocol=0.”
Indeed. For Protocol=0, there’s little we can glean. See text below.

2. The descriptions for both of these fields include: "When Protocol is set to
1, then the 32 rightmost bits represent OSPF Router ID."  This implies that the
field is *wider* than 32 bits when Protocol=1, which leaves deep ambiguity
about the circumstances under which the field is allowed to be 4 octets.
Correct. Meaning, you are correct and the text is incorrect. Protocol=1, 4-octet field, 32-bit OSPF Router-ID. Will fix. See below.

I would strongly recommend that this section add clear language that
unambiguously spells out how implementations are expected to select the field
width for the four variable-width fields in this Sub-TLV (the two I cite above
as well as the interface ID fields).

Yes. New text:

   Local Interface ID

      An identifier that is assigned by the local LSR for a link to
      which Adjacency Segment ID is bound.  This field is set to a local
      link address (IPv4 or IPv6).  For IPv4, this field is 4 octets;
      for IPv6, this field is 16 octets.  In case of unnumbered, this
      field is 4 octets and includes a 32 bit link identifier as defined
      in [RFC4203], [RFC5307].  If the Adjacency Segment ID represents
      parallel adjacencies ([I-D.ietf-spring-segment-routing]), this
      field is 4 octets and MUST be set to 4 octets of zeroes.
…
   Advertising Node Identifier

      It specifies the advertising node identifier.  When Protocol is
      set to 1, then this field is 4 octets and carries the 32-bit OSPF
      Router ID; if Protocol is set to 2, then this field is 6 octets
      and carries the 48-bit ISIS System ID; if Protocol is set to 0,
      then this field is 4 octets, and MUST be set to zero.

   Receiving Node Identifier

      It specifies the downstream node identifier.  When Protocol is set
      to 1, then this field is 4 octets and carries the 32-bit OSPF
      Router ID; if Protocol is set to 2, then this field is 6 octets
      and carries the 48-bit ISIS System ID; if Protocol is set to 0,
      then this field is 4 octets, and MUST be set to zero.


Thoughts? Other comments?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Sections 5.1, 5.2, and 5.3 define "Reserved" fields without indication of how
these fields should be treated. Recommend each of these be defined to "MUST be
set to 0 on send, MUST be ignored on receipt" -- this is the scheme that
maximizes the ability to use them in the future.

Correct. New text:

   Reserved

      MUST be set to 0 on send, and MUST be ignored on receipt.

In the three sections.

Section 5.3 sefines three values for "Adj Type": 0, 4, and 6. Please either
state that all other values are and will always be an error, or create an IANA
registry for this field.
Done as per Alvaro’s COMMENT.

Section 5.3 sefines three values for "Protocol": 0, 1, and 2. Please either
state that all other values are and will always be an error, or create an IANA
registry for this field.


Done as per Alvaro’s COMMENT.

Thanks,

— Carlos.