Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01

"Paul Mattes (AZURE)" <pamattes@microsoft.com> Thu, 07 April 2016 20:09 UTC

Return-Path: <pamattes@microsoft.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 12F9A12D599 for <ospf@ietfa.amsl.com>; Thu, 7 Apr 2016 13:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 0yY6S6I6reR1 for <ospf@ietfa.amsl.com>; Thu, 7 Apr 2016 13:09:16 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD6812D609 for <ospf@ietf.org>; Thu, 7 Apr 2016 13:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R920221c+hLMY52Jm9a3GCxhikWuP2NWHLe7PGLl1N0=; b=PsjzexM6rAqxtctMb+W9ktNjj40Bk20n+QaXML5AcQT5noQ5K6Az3cwFE/43EuqlSlcg30YZSHvOHlm709FO+srs3qU0bMh2TV/W8zE8TvGWLePgTu2ZFRB3rybDuevHvttARCyA/s4gxfsD2qswemtyAn38IHt3ZwIgNn300T0=
Received: from BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) by BY2PR03MB126.namprd03.prod.outlook.com (10.242.36.21) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 20:09:12 +0000
Received: from BY2PR03MB125.namprd03.prod.outlook.com ([169.254.4.59]) by BY2PR03MB125.namprd03.prod.outlook.com ([169.254.4.59]) with mapi id 15.01.0447.027; Thu, 7 Apr 2016 20:09:12 +0000
From: "Paul Mattes (AZURE)" <pamattes@microsoft.com>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: Re: draft-ppsenak-ospf-te-link-attr-reuse-01
Thread-Index: AdGRBkuoT17MPXP6QIK/Jzco/SY5/Q==
Date: Thu, 7 Apr 2016 20:09:12 +0000
Message-ID: <BY2PR03MB125654A47392F2CA88229CACA900@BY2PR03MB125.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:67c:370:176:ecc1:f30f:2ca6:6842]
x-ms-office365-filtering-correlation-id: 6a853516-c741-4b3e-369c-08d35f207cc8
x-microsoft-exchange-diagnostics: 1; BY2PR03MB126; 5:4zUwp2ylVhow0HTOM4qp/OliN0VqRmrNXg84mJ1/ImMIclneQeQcJ1rXpwhrLJL2athw+jlOJkjWbF9B5gblDSshThHe8cBwzZ0JRqrZlqRDIjZcnSVza0fYgrIDUnJ0VIrogDbOi1Uo9KX22GXt9A==; 24:4K7ooWAaRF2sD3f0+4LKiYry0z12rBFX0LdogbT6mTV2zPjIjxbLll2o+CfoEDKA/tSE4Dpk3cq6u/3ea526Dh2nTr74L6Ef/g6MfQCYo4c=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB126;
x-microsoft-antispam-prvs: <BY2PR03MB1265660D362C3263F02662BCA900@BY2PR03MB126.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY2PR03MB126; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB126;
x-forefront-prvs: 0905A6B2C7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(11100500001)(76576001)(110136002)(2351001)(5004730100002)(19580395003)(92566002)(2501003)(5640700001)(5630700001)(86362001)(81166005)(230783001)(8990500004)(5002640100001)(10090500001)(74316001)(450100001)(107886002)(586003)(2906002)(16236675004)(10400500002)(19300405004)(5003600100002)(122556002)(2900100001)(19625215002)(10290500002)(97736004)(15975445007)(86612001)(3660700001)(5005710100001)(33656002)(3280700002)(790700001)(189998001)(1096002)(54356999)(87936001)(102836003)(6116002)(1730700002)(99286002)(50986999)(1220700001)(5008740100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB126; H:BY2PR03MB125.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB125654A47392F2CA88229CACA900BY2PR03MB125namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 20:09:12.4744 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB126
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/V4XHaKd5hGfNSZPtOK6Ht-QV8AI>
Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 07 Apr 2016 20:09:20 -0000

I would like to amplify some of the comments made about this draft at today's OSPF WG meeting.

The draft refers generically to TE when it really means RSVP TE. The draft should use the more-specific term "RSVP TE" or "RSVP-based TE" in most (but not all) of the places where "TE" is used. The most unhelpful place this occurs in section 1:
    Many of these link attributes are useful outside of the traditional MLPLS (sic) Traffic Engineering or GMPLS.
This should read:
    Many of these link attributes are useful outside of the traditional RSVP-based Traffic Engineering, or GMPLS.

Perhaps it would be helpful if SR-based Traffic Engineering were mentioned as a typical consumer of this new information, which would distinguish it from RSVP-TE as the primary consumer of the existing TLVs.

In Section 3.1, I also have issue with this statement:
    Additionally, link attributes are only advertised once when both OSPF TE and other applications are deployed on the same link.  This is not expected to be a common deployment scenario.
I don't think that this is a desired result, and I believe this is what Chris Bowers was trying to emphasize with his earlier comments. If a router currently advertises the existing TE TLVs, it should continue to advertise them after it implements this draft. Turning off advertisement of the existing TE TLVs (if somehow they were being advertised without enabling RSVP-TE on the link) should not be the default behavior, though perhaps it could be made an option. I know this default would be less efficient, but I don't think it is worth breaking backwards compatibility to have.

       pdm