Re: [Lsr] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13

"Acee Lindem (acee)" <acee@cisco.com> Wed, 06 May 2020 17:07 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 65CDF3A0827; Wed, 6 May 2020 10:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 header.b=O4+/b8el; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t5W+L10R
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 sLBsFqv29w2Y; Wed, 6 May 2020 10:06:59 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F60A3A0851; Wed, 6 May 2020 10:06:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5694; q=dns/txt; s=iport; t=1588784815; x=1589994415; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oLMWnCMiyl1mm12BuwsIQ5/pZIv8ecaPlW8wKDSn9/o=; b=O4+/b8elNXijU6zOdxogVgUKRS2OnhHIU+X9aGv84GYLhcMtGKvcX9F2 UGI2ZejxK3kLj1mDuUEqu8XzX/ArOWwMkTmaejOyMPXxbM+U52Od2k0Sj qQKowTQDWjM1h1Z6SnWU+qSY6GhBiAk/Fmz+Ex2bkfMOKV48z6G90jztz o=;
IronPort-PHdr: =?us-ascii?q?9a23=3AmPnpkxd1fXhVYcRwjngz4dRclGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfQ6ulPjKzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutbFzJqXr05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABL7rJe/5BdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE1AwEBAQELAYFTUQWBRi8qCoQZg0YDjSA?= =?us-ascii?q?lmDWBLhSBEANUCwEBAQwBAS0CBAEBhEQCF4FqJDYHDgIDAQELAQEFAQEBAgE?= =?us-ascii?q?FBG2FVgyFcQEBAQECARIREQwBATcBDwIBCBgCAhEVAgICMBUQAgQBDQUigwS?= =?us-ascii?q?CTAMOIAGpOgKBOYhhdoEygwABAQWFFBiCDgmBDioBgmKJYRqCAIEQAScMEIJ?= =?us-ascii?q?NPoQHHygXKIJTM4ItkUmhDAqCSJgWHYJbiGGEe4xpkBedHAIEAgQFAg4BAQW?= =?us-ascii?q?BWAEygVZwFWUBgj5QGA2QQoNyilZ0NwIGAQcBAQMJfI8GgTQBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,360,1583193600"; d="scan'208";a="764951450"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 17:06:33 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 046H6XUO002898 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 17:06:33 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 12:06:33 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 12:06:32 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 6 May 2020 12:06:32 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kysww00QayASvmAGc2TC2pQkAV6vAAP29/hAFm/iSef7JqkHk+w2ErhfKZ+3TXHQipviNSKYlWMS0dcz2c+uDQlaelaT53n01QKargvfWSEoKvBgWgt1VvEWXhok64l/9sTCWXaRMbewReeY/eN/JirEefXtEmBDI4ffWlAYQNfZNqAVsC2xQnQa7tvJZEohrwnjFsBBy1isEB/9YLEYfYxTJPVzMwrAB0X0CorC/si58yHlt6wcmXjnmVyaqucfXVB8fg+LI2N45xnNkndvzPfBQsPnlGiMaj6w6ERGFHx8f7N0WiDERJ4CBk53uYpuXW4S/32GJxP45Ksn/dQmZA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLMWnCMiyl1mm12BuwsIQ5/pZIv8ecaPlW8wKDSn9/o=; b=QJZ0ARi3kC1bKF/x+s8p3fkHexW+OTyQjV100fCoO1sETx6j2WUsqvbP8pgq+D6rFQ2S4xtZQ3ke1PaSOlnmWIsMq+FP81yEhoyuuJ+5TsNWNNb58w9DKT4YN3vaXwO0jk5UwNWq5TRG4fBcbjxJNwBqMIvLLNW6o2VO1OZqV7FYJppZFXOyRC0JMPqgAW5TnNrMhXQaXZcV/JRR0vfTfDtlb3dQ7uQDEZZH/iPiwJdX5dSGjT5/06O0Pt0Nt/r5fZkTowbV1uWxdzD5gwmdkxJp97y9i0gKwmB87YE90t7xBai+R8Rf2M734xyLRDJLqMuLaAeUuDCvhjt0FklV9Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLMWnCMiyl1mm12BuwsIQ5/pZIv8ecaPlW8wKDSn9/o=; b=t5W+L10RTBPdniwAPMdYcHZhYXiKKrNPDUCfVOES8DtEs+fgtHP+huUj7VvtYUJRJmFj3GTz6SSPxOdnQbTzK3X7HLcQpvJnUpPyeKqoRUUH2e3mYdS9d6fs4njABP8xSY56SmLWxRbDweMb8xGUuBoWLVxEYP9/1NPclj3UNig=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2869.namprd11.prod.outlook.com (2603:10b6:a02:c0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Wed, 6 May 2020 17:06:31 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::4950:e26c:503f:768e%6]) with mapi id 15.20.2958.029; Wed, 6 May 2020 17:06:31 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Dhruv Dhody <dhruv.ietf@gmail.com>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-ospf-mpls-elc.all@ietf.org" <draft-ietf-ospf-mpls-elc.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Rtgdir last call review of draft-ietf-ospf-mpls-elc-13
Thread-Index: AQHWI7zJp1lIg/K4HkKAIOX4h/7ar6ibN0uA///Pi4A=
Date: Wed, 6 May 2020 17:06:31 +0000
Message-ID: <101B38AE-6A11-4412-8E2D-B7C1DBE23855@cisco.com>
References: <158867189453.14412.14632358918213286203@ietfa.amsl.com> <8dd49248-84bd-a546-8fee-767ab75a182a@cisco.com> <CAB75xn65wcH23q1XO7EtONc7C38dyu43pMiWb0KoZspo7jdKmg@mail.gmail.com> <bc621daf-52b5-02b5-126a-84267b6cf548@cisco.com>
In-Reply-To: <bc621daf-52b5-02b5-126a-84267b6cf548@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 358ec5f3-c2eb-4b31-cdff-08d7f1dfd312
x-ms-traffictypediagnostic: BYAPR11MB2869:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB28697E517CCD37111A550756C2A40@BYAPR11MB2869.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +MQF0Lb2V/Y0oEWH/7DrOgbWF2FNj+P23ekb87Q45/vUlWGFE2oBw51nUc0SpkyuEYHicSYOEnC93kR7sZ4SxjiE6QHaH/lyErDBDdaW41et2T6sac3B0H+We0MYKP6LldZDF5dvOhD/Xx7/ttHMLamX3jGiHO838tNaJfP8wzlSkKFPxyi0AmsQB2T47qMDbKipElZrZ0jDwCH0xjDyuDwiXoxq/No6M2XmLQ42P8AANKn3aku5GvliGkFFWEmtbVpYTUfu4q18zLLIi4hFfTU548QukuWI1foPyENgiM/EU+pIXfZ6Mg1O3YbyOnBOe1e3H6ZOFf1dKfIqmtTEzSev6XE5a2A4USnr4iBwIV+5Fq8cQMcpRgkxiM2SM5Wk2lpZLzcDCIJEH6PLziLqd04PPqNNj67zM597WPb7LpD7wTlRRZVTuyT/RJY3Y0KGs2T07ECgGA3fGt6UI4lb7Bt5Hd00eX39XlbWVLVhvMYMaURcvbQF4Bgirv5aUHxouiluAwvsoiVaHdLtsd5/jg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(346002)(39860400002)(366004)(33430700001)(86362001)(110136005)(2616005)(66574014)(71200400001)(316002)(54906003)(6486002)(33440700001)(53546011)(6506007)(186003)(8676002)(8936002)(26005)(478600001)(33656002)(64756008)(36756003)(66476007)(6512007)(66946007)(2906002)(4326008)(66446008)(5660300002)(76116006)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ZzXXqQqO9qVdRQSxdGMXAX+2tmUzaC/CS0EPdbqEH9+Cal8bF3VM91ONI+lsdH2WKKgmaPOuC4vIKAJqfm6Zbm1bz2lIt1WJbuUCuBPK6dnXWv0hohmtScsWV/ws0hE+wLZPqV8zEqRTKX5m4rdSQwy2S8D0EzxHwnZiFn4bZu6VEy/T9MJZH9JVR78tRmcYJUIo5YflBW1LS/ciS9p3bJMBEAO61IRoZcrNvl5KXtvPgqgzK9SeYLMKFwYfKZWGKX/I0bhqqlXLUb/WGFbEzTGuVQ+tx9Emf7fqgYWydOcqxZy4JZfqXfUMiWdtv1o7KueEBDam4FnXLY5GHgPkIeUgVH98ZB5jKEemHcWur/DpsM4gjYkFUuBCeBDQuT59C4GQZ0p1ReP1Dn4Wytag9OXnOmFQHojmnOYTP87HheXkZ4+WXpnKAzGzLDyrmirg7oHZZ0n8czP080063VaCeHH0D0EBFT/SxMhvQCCaSh652Q82JiiD/c88XT6kpyBLvsDB+QOFEQGKxnVhmqeQv6A/SmGzBbH8d6dPD9mdYkC3FdvC0RB0F3bifPVUOkC3Guc9hEa1f8eYlzJl0D0K0H3Eoi7fBcrQNd7rgW6X+RJBPYPtYNCJdjkjSxyCk5CJJJKFtuL2EuZL6F/XoNpgQYVBl0dJncAOWmKSFQeQk798Ns8HJ0sn0/+jCqz7D8qxlTTK73K+6iWJ5u61myovw6yJyp8upUT/3TTVHqM2RjLTyL1pnpskGREbnfV5OX2OtCGRVoGZroy+tE3s97ylZixnsSXqpFsMtO/V+WquHP4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <F2801932E8BF744C85EA16E8460AB8E9@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 358ec5f3-c2eb-4b31-cdff-08d7f1dfd312
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 17:06:31.5621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: f+y4bTOfhJqzzbdPXkFc7fZC1sLLEKlkAIs2TDLIEK32McFwjsZ+nQbEOgLmTdzN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2869
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/D1aeg4R193umpjEd_mFZ06VwOdc>
Subject: Re: [Lsr] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13
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: Wed, 06 May 2020 17:07:06 -0000

Hi Peter, Dhruv,

On 5/6/20, 12:00 PM, "Peter Psenak" <ppsenak@cisco.com> wrote:

    Hi Dhruv,

    please see inline:

    On 06/05/2020 17:40, Dhruv Dhody wrote:
    > Hi Peter,
    > 
    > Thanks for your reply, snipping to points that need further discussion...
    > 
    >> What about:
    >>
    >> Segment Routing with the MPLS Data Plane relies on Interior Gateway
    >> Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666] to signal
    >> labels.
    >>
    > 
    > Much better.
    > 
    > 
    >>> (3) Section 4
    >>>
    >>>      The absence of ERLD-MSD advertisements indicates only that the
    >>>      advertising node does not support advertisement of this capability.
    >>>
    >>>      Do you mean to differentiate between support for the capability itself v/s
    >>>      support for 'advertisement' only. But RFC 8662 says that ERLD value is
    >>>      advertised only when following conditions are met:
    >>
    >> What is meant is that even though all the below conditions are set, if
    >> the node does not support the advertisement, one can not conclude what
    >> its ERLD is.
    >>
    >> If the node supports the advertisement of the ERLD, but the below
    >> conditions are not met, the node should not advertise the ELC capability
    >> in a first place.
    >>
    > 
    > There are two things here - (a) the actual load balancing capability
    > of a node (b) the capability to advertise the ELC/ERLD. Usually
    > capability and the advertisement of the capability go together. In
    > this case we want to be explicit that the absence of ERLD-MSD
    > indicates just (b) and not (a).
    > 
    > You do use the word "only", so may its all fine! I will leave it to
    > you/shepherd.

    yes, the absence of ERLD-MSD advertisements only indicates that a node 
    does not support advertisement of (b).

    It can not be interpreted that (b) is not supported.  Old nodes that do 
    not advertise ERLD-MSD can not be assumed not to support non-zero ERLD.

    The "only" is there to express the above.

As document shepherd, I think this aligns with other OSPF functional capabilities.

Thanks,
Acee

    > 
    >>>
    >>>      *  MUST be entropy label capable and, as a consequence, MUST apply
    >>>         the data-plane procedures defined in [RFC6790].
    >>>
    >>>      *  MUST be able to read an ELI/EL, which is located within its ERLD
    >>>         value.
    >>>
    >>>      *  MUST take into account an EL within the first ERLD labels in its
    >>>         load-balancing function.
    >>>
    >>>      Thus, I am not sure about this sentence. Maybe you mean to say that the
    >>>      absence only indicates that the ERLD-MSD value of the node is unknown (and
    >>>      it might still be capable of handling ELI/EL)?
    >>>
    >>> (4) Section 4
    >>>
    >>>       What would be the behavior if an OSPF router receives a ERLD of the node
    >>>       but no ELC set for the corresponding prefix? That would be an error as per
    >>>       RFC 8662, we should specify how one handles it within OSPF. If it is to
    >>>       just ignore the ERLD, we should explicitly say that.
    >>
    >> the behavior is specified in the RFC 8662.  OSPF is just a messenger,
    >> not the consumer of this information.
    >>
    > 
    > Is there some text in RFC 8662 the clarify what one does on the
    > receiving side? I found only the sending conditions in section 4. How
    > does a receiving node behaves when he receives conflicting
    > information, which one does he trust (no ELC present or ERLD=10). We
    > could have interop issues here if you leave it open.

    well, if the node does not support ELC, then ERLD value is irrelevant. 
    It's like having a speed limit for a road with no entry.

    But that is something that does not belong to protocol drafts.

    thanks,
    Peter


    > 
    > Thanks!
    > Dhruv
    > 
    > PS. Since the comments are the same for the IS-IS I-D, no need duplicate them.
    > 
    >