Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

"Acee Lindem (acee)" <acee@cisco.com> Fri, 24 May 2019 12:55 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 C3C30120092 for <lsr@ietfa.amsl.com>; Fri, 24 May 2019 05:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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=VHwMbD7n; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SZiGzums
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 Sw7NvzPyqYh2 for <lsr@ietfa.amsl.com>; Fri, 24 May 2019 05:55:25 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10FA12003F for <lsr@ietf.org>; Fri, 24 May 2019 05:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28767; q=dns/txt; s=iport; t=1558702524; x=1559912124; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=V3vUd5wa/WPyU3fSTZNixC672NpQht0IR+aALTpjqRo=; b=VHwMbD7nm94Omn99xeIKPnlM6F5OeBD7Lghg58MdFGndCixiVPbsy0iK WA6toFeUlrhB9wH9/GoVH0Ukz7IIULov6ZNH7EibIx3QqVy/7T5x55CJ8 GHlUveq8U8WFWzgfjiGOwRtbM6Dfn67hqWQmfIFrJ2iL8MfWWgEHxamKt I=;
IronPort-PHdr: =?us-ascii?q?9a23=3ACo+jaxffO4JWRwOLljBo7NY+lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFl?= =?us-ascii?q?cejNkO2QkpAcqLE0r+effhYiESF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAADw6Odc/5FdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ4vJCwDaVUgBAsoCoQJg0cDhFKKJYIyJZcqgS4UgRADVAk?= =?us-ascii?q?BAQEMAQEYAQoKAgEBhEACF4InIzQJDgEDAQEEAQECAQRtHAyFSgEBAQECAQE?= =?us-ascii?q?BEBEdAQEsCwEECwIBCBEDAQIWDgQDAgICJQsUCQgCBA4FGweDAAGBHU0DDg8?= =?us-ascii?q?BAgyaVwKBOIhfcYEvgnkBAQWFBxiCDwMGgTQBi1IXgX+BEAEnDBOCHi4+gmE?= =?us-ascii?q?BAYEcDQUBDAYBPwYHCQmCSzKCJogxgnAIGDSCFIRglHlpCQKCDYx5gWmEMBu?= =?us-ascii?q?CH4ZjjT+OEJRFAgQCBAUCDgEBBYFPOGZxcBU7KgGCQYIPN4M5hRSFP3KBKYp?= =?us-ascii?q?QDheBCwGBIAEB?=
X-IronPort-AV: E=Sophos;i="5.60,507,1549929600"; d="scan'208,217";a="278295102"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2019 12:55:21 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x4OCtLbH010228 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 May 2019 12:55:21 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 May 2019 07:55:20 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 May 2019 08:55:17 -0400
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 24 May 2019 08:55:17 -0400
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=V3vUd5wa/WPyU3fSTZNixC672NpQht0IR+aALTpjqRo=; b=SZiGzums7P09Qimmb01WPdNo4raCT7sOFq7AF1ZjuL+eVuC2+PXV+b2Fw95aRQLPI5FfXRCycsolpavwuFBmZiwFcEBUq5WwaJDo17HRgvBkA7oBiakoXZdY0z9RERVI3GJyvu1Fs2AC5G2AJhpj9O6g9af/D8w66wPcbEweJPE=
Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB3117.namprd11.prod.outlook.com (52.135.126.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.17; Fri, 24 May 2019 12:55:15 +0000
Received: from SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::3006:a080:19fa:623e]) by SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::3006:a080:19fa:623e%6]) with mapi id 15.20.1922.018; Fri, 24 May 2019 12:55:15 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
CC: "olivier.dugeon@orange.com" <olivier.dugeon@orange.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt
Thread-Index: AQHVEU3eXo6Hmfrpu0iF/GpzsPhJ4aZ53XKAgABRsID//8sOgA==
Date: Fri, 24 May 2019 12:55:15 +0000
Message-ID: <4D072276-2395-43E1-8500-65977E6BCE1D@cisco.com>
References: <13373_1558605372_5CE66E3C_13373_9_1_f972f038-1368-158c-0c0f-0f85ae00ef79@orange.com> <EA356178-68F8-4869-B99A-3F07C1CF248E@cisco.com> <CAOj+MMFKAZj2VB=L9EjvUjp84jnVbYs-yCPGujfjqwoFksg-Gg@mail.gmail.com>
In-Reply-To: <CAOj+MMFKAZj2VB=L9EjvUjp84jnVbYs-yCPGujfjqwoFksg-Gg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [173.38.117.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a0d72f77-57f4-479c-a9f7-08d6e0471134
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:SN6PR11MB3117;
x-ms-traffictypediagnostic: SN6PR11MB3117:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <SN6PR11MB31173151D62ED50CA2C16D3AC2020@SN6PR11MB3117.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0047BC5ADE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(366004)(376002)(136003)(396003)(37854004)(199004)(189003)(66066001)(53936002)(8936002)(6246003)(186003)(36756003)(5660300002)(316002)(76176011)(99286004)(4326008)(6506007)(53546011)(102836004)(33656002)(66574012)(6916009)(25786009)(606006)(561944003)(54906003)(76116006)(64756008)(66446008)(66556008)(66946007)(73956011)(66476007)(91956017)(6306002)(54896002)(6512007)(86362001)(6486002)(71200400001)(83716004)(71190400001)(7736002)(81156014)(81166006)(6436002)(236005)(8676002)(476003)(446003)(2616005)(11346002)(229853002)(6116002)(3846002)(14454004)(68736007)(486006)(2906002)(82746002)(26005)(5024004)(256004)(14444005)(966005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3117; H:SN6PR11MB2845.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6pfvbTPW+6jRUy0TDbjbyE91B39EKUW6UHjkbMUL1NgajcWJgnkCOrn0yiXHR70DpLwm2IYxY8LRgJ0nlCdKbNMIhUnX6MkCBEYNpuKORod3grYWuHNmfbt4WluV299w87k3xAXtmVC6VJM6jXxoGVj439BRJqXEOhU8IDULzWbsypkoxWzR7Puew0vYndUs6LUX1y9Y+a50M5Q0bxF5V5J+yVRkyh1DcD3aIylsF/gIPaVPvH/UfKPgXkGPOBfIRvydEnv1h/FZhLiCA8gAb/1kHiHbwEt4bPhMtUjwkF0LT2ZIA46RsraSNOA4A9DK3OW/G6ya7oeWewJPso4Iw+8X8ys7WYz3vR5nqhWTh/z8jaT/KYPNfKJAUe6g0PADzlqsTSJ4qI/bBtxibqYQPKoU8Ebv+oTSVeMUTt/rmQc=
Content-Type: multipart/alternative; boundary="_000_4D072276239543E1850065977E6BCE1Dciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a0d72f77-57f4-479c-a9f7-08d6e0471134
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2019 12:55:15.3548 (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: acee@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3117
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/mfC0C0fUnRB0x8DPt2w95ImfRA4>
Subject: Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt
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: Fri, 24 May 2019 12:55:28 -0000

That would be for newer documents, these documents have been long overdue with a protracted discussion. I don’t think we want to delay them anymore. Also, including the BGP-LS is somewhat dependent on the complexity. For example, it made sense to decouple SR BGP-LS encodings from the IGP drafts.

Finally, this is orthogonal to the comment on the general issue of BGP-LS possibly having NLRI that exceeds what can be sent in a single 4K BGP update.

Thanks,
Acee

From: Robert Raszuk <robert@raszuk.net>
Date: Friday, May 24, 2019 at 8:07 AM
To: Acee Lindem <acee@cisco.com>
Cc: "olivier.dugeon@orange.com" <olivier.dugeon@orange.com>om>, "lsr@ietf.org" <lsr@ietf.org>
Subject: Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt


> With respect to your comments on BGP-LS, this is out of scope for LSR.

During last IETF it has been communicated by IDR chairs that there is an agreement that all IGP extensions in LSR WG will define in the same document also extensions to BGP-LS so the work is not duplicated and that IDR will stop dealing with IGP encoding.

Quote from minutes:

"Propose: one document to keep the encoding in both IGP and BGP-LS. asking LSR to handle encoding in their document set "

Chair's slide 5:

"Propose asking LSR to handle encoding in their document set"

Putting aside to what I personally think about BGP-LS are you as LSR co-chair not going to follow the above recommendation/proposal ?

Thx,
R.



On Fri, May 24, 2019 at 1:12 PM Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Hi Olivier,
I think the WG's energy has been completely focused on the dynamic flooding and these WG last calls didn't get the deserved attention.

As for as your comments, the first two were discussed for over a year and half. There were other advantages as well. For example, the link attribute encoding reduced (OSPFv2) or eliminated (OSPFv3) the need to correlate LSA attributes for a single link. We will note your objection in the shepherds report on the documents. We could even include a pointer to your quagga code that took a different approach if you wish to provide one.

With respect to your comments on BGP-LS, this is out of scope for LSR. While I haven't seen NLRI that hits the limit, I'm confident that the IDR WG will come up with a solution.

Thanks,
Acee

On 5/23/19, 5:57 AM, "Lsr on behalf of olivier.dugeon@orange.com<mailto:olivier.dugeon@orange.com>" <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org> on behalf of olivier.dugeon@orange.com<mailto:olivier.dugeon@orange.com>> wrote:

    Dear all

    As there is no more exchange about the two mentioned drafts since 3 weeks, I'll try to summarize the exchange and
    the requested modifications.

    The drafts proposed to extended IS-IS respectively OSPF to advertise new TE parameters to overcome 2 issues:
     1 - Topology incongruence between the IGP and TE
     2 - Provide different parameters per application

    For the first point, topology incongruence is not due to the protocol itself but to the fact that an operator
    may activate or not TE information on all links of its network. Indeed, RFC3630 and RFC5305 precise that TE
    information are Optionals.

    However, in both drafts, the term RECOMMENDED is used, which IMHO not solve the problem. An operator keeps the choice
    to activate or not this new TE information leading again to an incongruence network topology. At least, wording
    need to be change to MUST or MANDATORY. But, why not just change the wording of RFC3630 and RFC5305 ?

    In addition, no operator express explicitly that their are concern by topology incongruence.

     => Introduction sections should be improved to better justify why we need to modify TE link advertisement
     => Wording must be revise to avoid incongruence topology

    For the second point, TE information are related to a link not an application even if at the origin, RFC3630 and RFC5305
    were design for RSVP-TE. It is not mention in the RFCs that they could not be applicable to other protocol / application.

    If the idea, in liaison to first point, it to determine is an application / protocol is enable / disable on a given link,
    even if their have been not selected, drafts draft-hegde-ospf-advertising-te-protocols-01.txt and
    draft-hegde-isis-advertising-te-protocols-03.txt are largely sufficient as it is not necessary to duplicate link TE
    information. In addition, Router Information already provides indication on the support of SR by this router (presence
    of SRGB) where all IGP links are de-facto SR enable.

    Then, GMPLS specific attributes are not taken into account in these drafts.

     => GMPLS must be considered as another application and specific GMPLS attribute must be part of the drafts
     => or standardised only SABML / UDABML flags without duplicating TE information

    Network operational transition issues are poorly address in these drafts. Indeed, router upgrade
    take time in large scale network (several weeks even several months) leading cohabitation of the 2 systems which
    introduce a large degree of complexity for operators for network management.

     => Improve migration section to help operator during the transition phase

    And finally, if we go a bit further, dealing with SDN, all these new TE information need to be learnt by and SDN
    controller e.g. a PCE, which naturally conduct to use BGP-LS for this purpose. However, recent discussion in idr WG
    mention that there is already too many attributes that have been standardised dealing with problem with the maximum
    size of BGP message. These new TE information will also certainly appear as duplicate regarding RFC7752 and RFC8571.

    So, I would ask authors of both drafts to know how they intend to manage this problem ?
    For us, if these new TE information could not be learnt through BGP-LS, there is no interest to use them.

    Regards

    Olivier






    _________________________________________________________________________________________________________________________

    Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
    pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
    a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
    Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

    This message and its attachments may contain confidential or privileged information that may be protected by law;
    they should not be distributed, used or copied without authorisation.
    If you have received this email in error, please notify the sender and delete this message and its attachments.
    As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
    Thank you.

    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org<mailto:Lsr@ietf.org>
    https://www.ietf.org/mailman/listinfo/lsr


_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr