Re: [Teas] Genart last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

Harish Sitaraman <hsitaraman@juniper.net> Thu, 26 April 2018 16:19 UTC

Return-Path: <hsitaraman@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 952A8126DFB; Thu, 26 Apr 2018 09:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 NByfJVco1Pn1; Thu, 26 Apr 2018 09:19:43 -0700 (PDT)
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 C0AB1126DED; Thu, 26 Apr 2018 09:19:43 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3QF0HsO001733; Thu, 26 Apr 2018 08:01:39 -0700
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 : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=2kGcNaUEvPZ1BjbFznQsAeS3SMYoI+0ktpjE2o4eVxM=; b=JyAJ1ju93buMxndQJd7L5Xhk4s1FkgsNMKu1DTMltULC/1jGYZg2s0OPFZ8lULXhLrj5 dTPQxFFwC4jYGpyaeEOqmolmH4bjjkxJYGYfPT66m0Ik2caII2azfN50Ri5ZkKCvkZWr GZxIpUspJbolw1qSLew+ayJL8LeFchSxOt+bYjsb1zTUBWGTG2GpOip8YCMmuvbMwNpt rgRJKMMigTwYIS/uqpaQyFH6nr3shVRyGZqdEislSbIHrlIdxdQYp76V8Go/r51+mWi2 UJ/Sur1ToSJyG3EtOC4vR4pFmyMuDzKmmoUxgHbGN6Km1AezaJ+YqBymLpy+Mg1ZJn8I Zg==
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0177.outbound.protection.outlook.com [216.32.181.177]) by mx0b-00273201.pphosted.com with ESMTP id 2hkf5wg8e2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Apr 2018 08:01:38 -0700
Received: from BN7PR05MB3923.namprd05.prod.outlook.com (52.132.216.10) by BN7PR05MB4259.namprd05.prod.outlook.com (52.133.222.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.715.7; Thu, 26 Apr 2018 15:01:36 +0000
Received: from BN7PR05MB3923.namprd05.prod.outlook.com ([fe80::6580:763:8d31:8cf]) by BN7PR05MB3923.namprd05.prod.outlook.com ([fe80::6580:763:8d31:8cf%13]) with mapi id 15.20.0715.014; Thu, 26 Apr 2018 15:01:36 +0000
From: Harish Sitaraman <hsitaraman@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "ietf@ietf.org" <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "draft-ietf-teas-sr-rsvp-coexistence-rec.all@ietf.org" <draft-ietf-teas-sr-rsvp-coexistence-rec.all@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02
Thread-Index: AQHT18dkIeCXv6IML0icSF8Ee4hDlqQJd16AgACC3gCACL/LAA==
Date: Thu, 26 Apr 2018 15:01:36 +0000
Message-ID: <883B8ABA-075E-4A1D-A587-51427B70EDDF@juniper.net>
References: <152413294572.28724.1279477772622511232@ietfa.amsl.com> <AD259E57-5FE2-4307-B19E-F8F2D48EB8D2@juniper.net> <dcd5d930-82f0-9458-139d-6c1bc882ae6b@joelhalpern.com>
In-Reply-To: <dcd5d930-82f0-9458-139d-6c1bc882ae6b@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-originating-ip: [66.129.239.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN7PR05MB4259; 7:8m0Un/KKkBHlp4UTxPDv/qFzdJnp0+zmR7h8KY/Vr0dkA1AHxePlCn/LS6HvbZ68QMuDIPZj2T9mwyOBHH/+QSdLOcMR2ecB29eDId2vQ2N3hpsUsducNHHAK0i5QMJ4g3JqJZjCyYn3u5FWUv8i+I3C4WEgq9vHuZvUgFl2lOjWTWSCz2R6VzbcgKYw+kF6yOi2lGhlchvI9vkeXq40zt+ut2PhMl47WYdlf2Jy4u2Pn0F37/zgudeFBbfxQK54
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4259;
x-ms-traffictypediagnostic: BN7PR05MB4259:
x-microsoft-antispam-prvs: <BN7PR05MB4259182E2392D3366A2128D0C28E0@BN7PR05MB4259.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(190756311086443);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231232)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BN7PR05MB4259; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4259;
x-forefront-prvs: 0654257CF5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(396003)(39860400002)(39380400002)(199004)(189003)(37854004)(51914003)(186003)(110136005)(3660700001)(486006)(53546011)(2900100001)(2616005)(82746002)(83716003)(33656002)(76176011)(4326008)(6246003)(7736002)(97736004)(345774005)(6116002)(3846002)(14454004)(68736007)(102836004)(6506007)(229853002)(106356001)(66066001)(305945005)(25786009)(105586002)(8936002)(316002)(54906003)(58126008)(86362001)(6486002)(26005)(5250100002)(99286004)(6306002)(81166006)(36756003)(8676002)(5660300001)(81156014)(446003)(2906002)(478600001)(11346002)(6512007)(966005)(2501003)(53936002)(6436002)(476003)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4259; H:BN7PR05MB3923.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: py2yOxLK7sWc+yQjIr32Z3DXsPxjljJ5Gg/sQMyD4R6s2fUI5AzY8l/nGhK3gyNc4TW1JBxJ8zqavnonbGFPZ5CHVy3XJgVuF9tMFeDxfsIFM4JzFZ/t0qrG9xaxLZNk8UZTxhSkGCc6rJN87WNs9T8GaBPbx1wWnqRwaOEQyAs9W2RAt5QxjvusvZOA0wiz
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <E144762A9E1B8C469E17C23AF3CEABAA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3780a32e-ee03-4665-eed4-08d5ab869b81
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 3780a32e-ee03-4665-eed4-08d5ab869b81
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 15:01:36.5275 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4259
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-26_06:, , 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-1804260142
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/eIBTWreVgyisguCbu21FyygR3Zk>
Subject: Re: [Teas] Genart last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02
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: Thu, 26 Apr 2018 16:19:47 -0000

Hi Joel,

We've posted a -03 version of the draft. Let us know if it helps with the comments. See inline <HS>...

´╗┐On 4/20/18, 11:25 AM, "Joel M. Halpern" <jmh@joelhalpern.com>; wrote:

    Thank you for your replies.  Further in line, marked <jmh></jmh>
    Yours,
    Joel
    
    On 4/20/18 1:36 PM, Harish Sitaraman wrote:
    > 
    > Hi Joel,
    > 
    > Thanks for the review comments. Comments are inline with [HS].
    > 
    > On 4/19/18, 3:15 AM, "Joel Halpern" <jmh@joelhalpern.com>; wrote:
    >     
    >      Summary:
    >      
    >      Major issues:
    >          The focus of the draft seems to be the recommendation in section 3.5 that
    >          the maximum reservable bandwidth on a link be adjusted to reflect the SR
    >          traffic consumption.  There appear to be two issues that need to be
    >          discussed, both related to the difference between what the SR controller
    >          wants to reserve and what the router observes. First, an SR controller may
    >          be performing calculations without requiring that bandwidth be committed to
    >          the traffic.  The recommendation here assumes that all traffic using SR is
    >          high priority.  It may suffice to note that QoS markings in the labels
    >          (corresponding to diffserv markings in the underlying packet may hel with
    >          this.  Given the range of allowed behaviors in when RSVP-TE and SR are
    >          separate, it may also be necessary to restrict what the SR controllers do
    >          in these interworking cases.
    > 
    > [HS] In the first paragraph of section 3.5, there is text referring to SR having highest preemption priority but the SR traffic could have different QoS markings i.e. within SR there could be different classes of traffic which is accordingly handled by the forwarding plane (e.g. defined operator policy).
    
    <jmh>I think the document would be helped if this were described more 
    explicitly.  </jmh>

<HS> The first paragraph in section 3.5 explains the preemption priority and forwarding plane priority as follows:

   The solution relies on dynamically measuring SR traffic utilization
   on each TE interface and reducing the bandwidth allowed for use by
   RSVP-TE.  It is assumed that SR traffic receives precedence in terms
   of the placement on the path over RSVP traffic (that is, RSVP traffic
   can be preempted from the path in case of insufficient resources).
   This is logically equivalent to SR traffic having the best preemption
   priority in the network.  Note that this does not necessarily mean
   that SR traffic has higher QoS priority, in fact, SR and RSVP traffic
   may be in the same QoS class.
    
    > 
    >          Second, and more importantly, this solution
    >          assumes that short term traffic measurements are a good proxy for intended
    >          reservation.  Even assuming edge policing so that usage is less than or
    >          equal to the reservation, this will frequently underestimate the traffic
    >          reservation.  Such underestimates would seem to be able to cause
    >          significant problems.
    > 
    > [HS] Even with RSVP-TE LSPs where explicit admission-control is done to reserve bandwidth, the bandwidth that is reserved on the RSVP-TE LSP may differ from how much traffic actually arrives on the LSP (assuming no edge policing). As the traffic changes, auto-bandwidth implementation procedures might be there to adjust the LSP reservation at periodic intervals. This relies on short term LSP traffic measurement to achieve change in reservation.
    
    <jmh>A reference or two to other work on auto-reservation of bandwidth 
    based on measurement, particularly for RSVP-TE, would help the reader 
    understand the assumptions that lead to this being seen as workable.  It 
    would likely also help the reader know about any relevant limitations.</jmh>
    
<HS> Regarding the IETF reference for auto-bandwidth, I could only find the following PCE WG document: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-auto-bandwidth-06#page-8 (section 4) other than public references to vendor implementation documentation. 

    > 
    > [HS] SR traffic can preempt RSVP LSPs to make room for itself based on short term SR traffic measurement. The frequency at which SR statistics is collected for a TE interface and how often the Maximum-Reservable-Bandwidth is adjusted so that path computation engines for RSVP-TE LSPs get the updated TED information is implementation and deployment dependent (it could be aggressive to reflect SR traffic utilization in the TED often or done less frequently due to other deployment parameters). In the penultimate paragraph of section 3.5, there is text referring to the implementation choice.
    
    <jmh>The point of reservations is to try to anticipate future 
    conditions.  The fact that SR can preempt RSVP-TE is useful, but does 
    not really address the question.  If it could, then a simpler 
    recommendation would be to observe how much RSVP-TE trafic had to be 
    dropped, and redirect that much traffic elsewhere. </jmh>

<HS> We added the following in section 3.5: "This method of sampling traffic statistics and adjusting bandwidth reservation accordingly is similar to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs". The sentences preceding this explain the procedure and this is similar to auto-bandwidth for RSVP-TE.
    
    >      
    >      Minor issues:
    >          Section 3.5 assumes that the router can measure the traffic using SR.  This
    >          seems to rely on the unstated premise that the measurement is conditioned
    >          by the recognition of which labels are being used for SR.  This is
    >          reasonable.  It should be stated.
    > 
    > [HS] Fair point. However, the measured traffic is not just from SR labels (transit traffic) but also any traffic entering the SR domain over that outgoing interface. An implementation should be capable of measuring all the SR traffic going out of an interface. The text generically refers to needing ability to measure SR traffic statistics across the TE interface.
    
    <jmh>My point is that it would help the reader if the text were explicit 
    about what traffic needs to be recognized and how it is recognized. </jmh>

<HS> Added " The measured SR traffic includes all labelled SR traffic and any traffic entering the SR network over that TE interface."

Harish