Re: [Teas] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

Shraddha Hegde <shraddha@juniper.net> Tue, 30 January 2018 17:21 UTC

Return-Path: <shraddha@juniper.net>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF88212EC35; Tue, 30 Jan 2018 09:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 LpwPZ-V_crW9; Tue, 30 Jan 2018 09:21:12 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B278A12ECC4; Tue, 30 Jan 2018 09:20:33 -0800 (PST)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0UHJ3nS020538; Tue, 30 Jan 2018 09:20:28 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=8LtCiXZUvZkes06RNi8kciPl3AAqIzces0lR/DWNgFg=; b=QeiI4JIDsyDCGvyQYKLow6IAeMfxWwlkI9BJcD0Bm7AhLxGnGMcG1yI3nxLTucxKn7bp tyZg1UxMUrtHVF0szLigJo1xTgoOmBrWW8+u1RRVGThVNaSqWI7+9WxtCXyfSdq1KTXw Qp8xOgk6v9EGzr5YlbmsyPjvR0LW4m46zhYvgFmIrG6lJyvVUBJbrmbQGEb2guiup/0t fQsd2I9SWM7jcUeTo7NhX8YqBH2KulxJ02IkDhOsEIzuTtx27HG5pp9nK3gcy1JfNdDR QG86fuHsSylIQEQL+8N60t4qiUbmCphPZ6jTdujNzCqQEtdhPrsuil81oo5O2wilPYWM +A==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0050.outbound.protection.outlook.com [216.32.180.50]) by mx0b-00273201.pphosted.com with ESMTP id 2ftt2m8mc0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jan 2018 09:20:27 -0800
Received: from BN3PR05MB2706.namprd05.prod.outlook.com (10.167.2.135) by BN3PR05MB2513.namprd05.prod.outlook.com (10.167.3.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Tue, 30 Jan 2018 17:20:24 +0000
Received: from BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) by BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) with mapi id 15.20.0464.008; Tue, 30 Jan 2018 17:20:24 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, Alia Atlas <akatlas@gmail.com>, Deborah Brungard <db3546@att.com>
CC: The IESG <iesg@ietf.org>, OSPF List <ospf@ietf.org>, "draft-ietf-ospf-link-overload@ietf.org" <draft-ietf-ospf-link-overload@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)
Thread-Index: AQHTlfFqOlRaQW7dW0mWm6XCT0W3bqOEuHcAgAfzuAA=
Date: Tue, 30 Jan 2018 17:20:24 +0000
Message-ID: <BN3PR05MB270667D760FD119D85AF4EBFD5E40@BN3PR05MB2706.namprd05.prod.outlook.com>
References: <151672688324.13994.3394246547043297427.idtracker@ietfa.amsl.com> <CAG4d1rew3JT-=tUTxgrwYs3AGNtuHKwys4u0noSF1Kgeff4r-A@mail.gmail.com> <CAG4d1rc0KAWof0evU8aZCFC3CVWZ2n0tKP6PJ4HO=Yw=SqvnFw@mail.gmail.com> <5C61C8AA-006A-44EF-AD48-5B971C7BF9BA@cisco.com>
In-Reply-To: <5C61C8AA-006A-44EF-AD48-5B971C7BF9BA@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR05MB2513; 7:0JzwBiuWpsdgkcVhhnEZ3ABK5HwVLpnN65SvN9mXOUjtuGhqLaltJq/mSBDRYLV+lcu1F/HG0VP0RiOVKzZdo3/Us5gz49cjedXI1nag+b/bfJcrBeESxsokxvbpj8JLd0MeUEWqDs/QfTQj0GA1olNQB54PUnN0MPcQBvwqNpLY3BGqRkXE+dV0qpA1LJdt1RAYUhAOLzX+ugbQerbMti6vaZATAPi1eV7rQH69cJ8JV3XcQxewhh62VuVRkn7k
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 7780e5ab-a3e3-48d4-1b88-08d56805bfe0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR05MB2513;
x-ms-traffictypediagnostic: BN3PR05MB2513:
x-microsoft-antispam-prvs: <BN3PR05MB2513F7D65226B11B4367A7F3D5E40@BN3PR05MB2513.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(120809045254105)(85827821059158)(97927398514766)(100405760836317)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN3PR05MB2513; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2513;
x-forefront-prvs: 0568F32D91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(376002)(346002)(366004)(51914003)(189003)(199004)(74316002)(97736004)(606006)(9686003)(54896002)(6436002)(66066001)(55016002)(6306002)(19609705001)(8936002)(236005)(8676002)(316002)(81156014)(2900100001)(81166006)(2950100002)(77096007)(33656002)(229853002)(26005)(186003)(53936002)(93886005)(106356001)(102836004)(105586002)(7736002)(7696005)(14454004)(4326008)(5660300001)(966005)(68736007)(53546011)(478600001)(3280700002)(6506007)(76176011)(110136005)(54906003)(6246003)(2906002)(3846002)(790700001)(6116002)(39060400002)(3660700001)(25786009)(99286004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2513; H:BN3PR05MB2706.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 7q3qtpPtWtOSxUa7nfxsT/LirRfveiQFXZTtYv0YF5A0I/psAJmj+0TsdhMVjDY1f0vs+iKiu58LaKsVOHB0Ew==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR05MB270667D760FD119D85AF4EBFD5E40BN3PR05MB2706namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 7780e5ab-a3e3-48d4-1b88-08d56805bfe0
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2018 17:20:24.5741 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2513
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-30_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801300214
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/bReLjTyz_qPCWQ4VeprKKKc_xAA>
Subject: Re: [Teas] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2018 17:21:21 -0000

Hi Deborah/Alia,

Thanks for the comments.
We really need a TE metric that can be used as last resort metric.
RFC 5817 is very clear that 0xffffffff is a last-resort metric.
Probably prior to 5817, there were no clear statements on
The metric 0xffffffff being usable metric and resulted in implementation
Differences.

I do see the conflict with RFC 5817 if this draft sets metric to 0xfffffffe.
I think all the confusion is not really worth.
While deploying feature in this draft operators have to make sure
All the head-ends are behaving correctly with respect to 0xffffffff.

I’ll change the TE metric to 0xffffffff in the next revision.
WG,
Let me know in case of any concern.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Thursday, January 25, 2018 9:06 PM
To: Alia Atlas <akatlas@gmail.com>; Deborah Brungard <db3546@att.com>
Cc: The IESG <iesg@ietf.org>; OSPF List <ospf@ietf.org>; draft-ietf-ospf-link-overload@ietf.org; ospf-chairs@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

Hi Alia,

From: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Date: Thursday, January 25, 2018 at 10:30 AM
To: Deborah Brungard <db3546@att.com<mailto:db3546@att.com>>
Cc: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>, OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>" <draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>, Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "ospf-chairs@ietf.org<mailto:ospf-chairs@ietf.org>" <ospf-chairs@ietf.org<mailto:ospf-chairs@ietf.org>>, "TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)" <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

More specifically, as Deborah pointed out, in RFC 5817 Section 4.1, it says
"Specifically, the node where graceful shutdown of a link is desired originates the TE LSA or IS-
   IS-LSP containing a Link TLV for the link under graceful shutdown
   with the Traffic Engineering metric set to 0xffffffff, 0 as
   unreserved bandwidth. "

and draft-ietf-ospf-link-overload-14 conflicts with that by using 0xfffffffe instead.

I’ll defer to Shraddha and the other authors on this one. We did discuss the RFC 5817 inconsistency once already and the intension is that TE interface would still be used as a last resort TE interface.

Thanks,
Acee


Regards,
Alia

On Thu, Jan 25, 2018 at 10:26 AM, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> wrote:
Could a look at the changes in draft-ietf-ospf-link-overload-14 happen?

Also, it would be good to get feedback from TEAS on this document and any concerns.

Thanks,
Alia

On Tue, Jan 23, 2018 at 12:01 PM, Deborah Brungard <db3546@att.com<mailto:db3546@att.com>> wrote:
Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-link-overload-13: 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=HqvwIxIY6w9NAMb9bpYAlqt5wh5HYxoQ3QkWOKcXXCU&s=xuIvfhP39cZHUJrGuga06L6ws5jUz7Qh5bAqTiGFwV4&e=>
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-ospf-link-overload/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dospf-2Dlink-2Doverload_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=HqvwIxIY6w9NAMb9bpYAlqt5wh5HYxoQ3QkWOKcXXCU&s=vOC5CmTSOwCtauM4jMmeswl6tf_g2mYmFi_x07D4sXY&e=>



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

This document is defining a MAX-TE-METRIC of 0xfffffffe. But RFC5817 defined
0xffffffff to be used for graceful shutdown. I noted an email exchange between
the author and Acee on this where Acee raised the question why RFC5817's value
was not used. Shraddha replied "We can if we have the Working Group Consensus".
There was no further discussion.

This document was not shared with teas which is responsible for TE (or ccamp
which was originally responsible for RFC5817).

Either this value needs to be changed to RFC5817's value or this TE metric
needs to be removed from this document until agreement with TEAS.


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

I found the title of section 7.2 "Controller Based Traffic Engineering
Deployments" confusing as it only is describing a controller controlling a
path. It is not "TE" in the IETF sense e.g. TE signaling. It would be much less
confusing if say "Controller Based Deployments" and "satisfying the traffic
engineering constraints"/s/"satisfying the constraints". Especially as for TE,
procedures already do exist.  I noted in the introduction you did reference
RFC5817 MPLS Graceful Shutdown on the procedures when doing a graceful shutdown
of a TE link.