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

Harish Sitaraman <hsitaraman@juniper.net> Fri, 20 April 2018 17:36 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 860CD127137; Fri, 20 Apr 2018 10:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 D7tE-lBSUtZx; Fri, 20 Apr 2018 10:36:41 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 252E712D869; Fri, 20 Apr 2018 10:36:41 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3KHYTS6025510; Fri, 20 Apr 2018 10:36:40 -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=LU14AsQbnL/m8F/oap7EOhVHW/Q7yJeH1UjbQmPfDho=; b=UR+DcSy5Tjv0lf0V5x2VcOqluG8ag64BDp8W1DKP5bq+9FokU0h+keG2ux6Y0T0aMgZo jBOi2jfbn0C8LARvk4eKEuhOvrIl3JtkIwNQ/+sw3dPxxVtQRmP999afsBp7EAZx6dFP Szw48BhPiKpHQ79zy8G5VI8XeVNzUDDWVcS7iRtLoYtvFwxuIRQry9vqI8aJhZo1DflH dXlxqM9QonriTwscZ0fvBzunA4wY+JrQZQ+mcCg0tGDhQ+yCyplSBtdT0j0QFMJZz2eJ NL6aonbPh48t67yaOwekq4Oi846Ww+4i5laGm7v9wnZUHsRxTyNIVy4leVaPdZ98bsup Ng==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0052.outbound.protection.outlook.com [207.46.163.52]) by mx0a-00273201.pphosted.com with ESMTP id 2hfk3k06jb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Apr 2018 10:36:40 -0700
Received: from BN7PR05MB3923.namprd05.prod.outlook.com (52.132.216.10) by BN7PR05MB4290.namprd05.prod.outlook.com (52.133.223.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.715.7; Fri, 20 Apr 2018 17:36:38 +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.007; Fri, 20 Apr 2018 17:36:38 +0000
From: Harish Sitaraman <hsitaraman@juniper.net>
To: Joel 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: AQHT18dkIeCXv6IML0icSF8Ee4hDlqQJd16A
Date: Fri, 20 Apr 2018 17:36:38 +0000
Message-ID: <AD259E57-5FE2-4307-B19E-F8F2D48EB8D2@juniper.net>
References: <152413294572.28724.1279477772622511232@ietfa.amsl.com>
In-Reply-To: <152413294572.28724.1279477772622511232@ietfa.amsl.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; BN7PR05MB4290; 7:cn1Bq5I3VwPtm3tJJQ+7M57i5+kzTr5GEBAAmh8+8ln9be7X6Qi7F2jPGrO9Xs7MNJOwi39Rh1+ONI74l8rLhRGRMjN6nHi8dKOqiahGGaQfWNx/P81gUL0lJTeG48wTQtwwgDvCxb842gNQvWpiu9ETfy7N6Ri4X4qsRjQw2A1iJsnCZkaXnFOqcK4gjm2Kb3BAp2bSGLbLWRvqTXlXZeaw0mzSSFMOcWdD8sc1QW+3OTBsXEqUr7B92zCRykVf
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4290;
x-ms-traffictypediagnostic: BN7PR05MB4290:
authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=juniper.net;
x-microsoft-antispam-prvs: <BN7PR05MB42902203F1F24AD4F7101CB1C2B40@BN7PR05MB4290.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231232)(944501396)(52105095)(3002001)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN7PR05MB4290; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4290;
x-forefront-prvs: 0648FCFFA8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(39380400002)(366004)(376002)(346002)(51914003)(37854004)(3660700001)(81166006)(305945005)(76176011)(8676002)(2501003)(5250100002)(83716003)(54906003)(8936002)(36756003)(110136005)(316002)(2616005)(476003)(6436002)(86362001)(11346002)(66066001)(82746002)(7736002)(3280700002)(446003)(6506007)(6486002)(6512007)(26005)(5660300001)(4326008)(3846002)(2906002)(6116002)(186003)(25786009)(6246003)(33656002)(2900100001)(478600001)(102836004)(53936002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4290; H:BN7PR05MB3923.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv;
x-microsoft-antispam-message-info: 2bpx9eiM55XEL6/d5YDiNl+KvgBKG9w2QC47zD4iRMB1VYA4+4UFHalIab9ZM/3HF6GIYqm4q+qE3/nsZaChjJV911TR7+8Yv27YeddXDrKmr2KvV1+rMefPxIMduTQOCUHLu0FlUXScgPYGUH0NxJ8XuyqavcsbPq7y/A7XOQdRlqgeoI9w6ohnrbYuzYYm
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <EAB2D71407249E44952190EF67038590@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: b485c846-96f3-4775-c989-08d5a6e54569
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b485c846-96f3-4775-c989-08d5a6e54569
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2018 17:36:38.4450 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4290
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-20_08:, , 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-1804200176
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-eEDTcmiDEivveLsYfEoIJiXJEA>
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: Fri, 20 Apr 2018 17:36:43 -0000

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).

        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. 

[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.
    
    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.
    
    Nits/editorial comments:
        The second paragraph of the introduction seems to have the opening text
        repeated twice.

[HS] Thanks - noted also as part of OPsDir review comments. The 2nd repeated sentence will be removed.
    
        The third paragraph of section 3.1 seems to be a repetition of the end of
        the second paragraph using slightly different words.

[HS] Ok, the aim was to offer a summary of the behavior separately so that its clear. If its ok, we can retain it.

--
Harish