IETF Logo Mail Archive

Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-iro-update-06: (with COMMENT)

"Alvaro Retana (aretana)" <aretana@cisco.com> Mon, 18 April 2016 17:55 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F93912E40E; Mon, 18 Apr 2016 10:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 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, RP_MATCHES_RCVD=-0.996, 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 n2XSu_zJnBEK; Mon, 18 Apr 2016 10:55:14 -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 5E0ED12E41B; Mon, 18 Apr 2016 10:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2057; q=dns/txt; s=iport; t=1461002110; x=1462211710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CyGUNa4McdvEn2vOuZJvH/73EKhKkkMrNQhHS+xL0Yk=; b=kQvDKmJyBPUt+ugyLhLnIfayX4pGogmliwlQO4rTLvCVGbmxLODjp1qS h1pi01x3BrAdcRSkuvTZjKK21J2AQn1UGPQAipWr9C6yTlsBDb1re8C6f T9bJHuP8Rt+BVuKAk1kepk5gDaM4amIt2WwaiDVvys0c8sF2vJUrb3rwt Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A6AgCRHhVX/5JdJa1dgziBUAa4FIIPAQ2BcYYOAoE4OBQBAQEBAQEBZSeEQgEBBDo/EAIBCDYQMiUCBAENBYgpvBQBAQEBAQEBAQEBAQEBAQEBAQEBF4YhhEuKFQEEkx6EcAGODYFnjSqGI4kHAR4BAUKCM4E1bIg8fgEBAQ
X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="262871050"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2016 17:55:09 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3IHt9dB014536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2016 17:55:09 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Apr 2016 12:55:08 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 18 Apr 2016 12:55:09 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>, The IESG <iesg@ietf.org>
Thread-Topic: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-iro-update-06: (with COMMENT)
Thread-Index: AQHRmYvidztpTfb3y0KuMQWBAo1xH5+QUrIA///B1YA=
Date: Mon, 18 Apr 2016 17:55:09 +0000
Message-ID: <D33A9655.11FF03%aretana@cisco.com>
References: <20160418160323.9332.67077.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8C747369@BLREML509-MBX.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8C747369@BLREML509-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0716E7681FEF7D4FA693D927475112AE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/QJs3NHRqCgOrgBsGtsIubDAWJME>
Cc: "draft-ietf-pce-iro-update@ietf.org" <draft-ietf-pce-iro-update@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-iro-update-06: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2016 17:55:16 -0000

On 4/18/16, 1:37 PM, "iesg on behalf of Dhruv Dhody"
<iesg-bounces@ietf.org on behalf of dhruv.dhody@huawei.com> wrote:

Dhruv:


Hi!

...
>> 2. Non conforming implementations
>> 
>> Section 3. (Other Considerations).  Given that other interpretations of
>> rfc5440 were possible, I think that the considerations in this section
>> are operational, so renaming may be a good idea.  I would expect that
>> because this is a Standards Track document that people will eventually
>> conform to it, so I think that the "RECOMMEND" at the bottom is not
>> needed.  [I think that's the only rfc2119 key word.]
>> 
>
>[Dhruv]: Will rename the section to "Operational Considerations".
>What would be a better wording to suggest not to have a mix deployment
>because of the issue mentioned in the section?

The "RECOMMENDATION" in the text is to conform to the document, not to
avoid mixed deployments.

I think that the rest of the text is mostly ok -- maybe simply focus it on
the potential impact of mixed deployments (see below).

Thanks!

Alvaro.



NEW>
3.  Operational Considerations

   Because of the lack of clarity in RFC 5440, it is possible to encounter
   implementations that always interpret the IRO sub-objects as loose.
When
   these implementations interwork with an implementation conforming to
   this document, the following impact might be seen:

   o  If a non-conforming (to this document) PCC sends an IRO, to a
      conforming (to this document) PCE, then the PCE may unexpectedly
      fail to find a path (since the PCC may think of IRO sub-objects as
      loose hops, but the PCE interprets them as strict hops).

   o  If a conforming PCC sends an IRO containing strict hops to a non-
      conforming PCE, then the PCE may erroneously return a path that
      does not comply with the requested strict hops (since the PCE
      interprets them all as loose hops).  The PCC may check the
      returned path and find the issue or it may end up using an
      incorrect path.

v2.23.0 | Report a Bug | By Email