RE: draft-ietf-bfd-large-packets-02

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Sat, 09 November 2019 16:30 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9933E12008C for <rtg-bfd@ietfa.amsl.com>; Sat, 9 Nov 2019 08:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-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=cf7iIMCF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BXIANSxK
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 2ES_wMsLS5Gd for <rtg-bfd@ietfa.amsl.com>; Sat, 9 Nov 2019 08:30:25 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877BD120073 for <rtg-bfd@ietf.org>; Sat, 9 Nov 2019 08:30:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4360; q=dns/txt; s=iport; t=1573317025; x=1574526625; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=50SKv7vBi6H+BYUiJC1/QkDKPi6R03BliqAsAMVjsSI=; b=cf7iIMCFX+TQrjbcZiYszshO6xXLS/0/rI0VO2JF6HvQokUxLxKH23Ej zlvNfkqCtkTnZbyqry8JefDfxSoybpU4RmlpSrmVcw/lRkxrd5kUpHGf5 rPRMZD9vOM5jxCiGUyFSu3HEyHhpRLJzBnkkXDOMGVI4NVsUhiNuRcFHz s=;
IronPort-PHdr: =?us-ascii?q?9a23=3As2NSjhD7zWF8XOmrzrAcUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuI//sdCY3BstqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABn6cZd/4wNJK1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFtAgEBAQELAYFKUAWBRCAECyqEKYNGA4prgl6?= =?us-ascii?q?YAIJSA1QJAQEBDAEBLQIBAYRAAheDeSQ3Bg4CAwEDAgMCAQEEAQEBAgEFBG2?= =?us-ascii?q?FNwyFUQEBAQQSEREMAQE3AQsEAgEGAg4DBAEBAQICJgICAjAVCAgCBA4FCBq?= =?us-ascii?q?FRwMuAY9lkGMCgTiIYHWBMoJ+AQEFhQ4YghcJgQ4oAYwTGIFAP4EQR4JMPoR?= =?us-ascii?q?HJIJqMoIskAyeCAqCJZVfmXmoPQIEAgQFAg4BAQWBaCOBWHAVgydQERSQNgw?= =?us-ascii?q?Xg1CKUgF0gSiQPgEB?=
X-IronPort-AV: E=Sophos;i="5.68,286,1569283200"; d="scan'208";a="376314208"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2019 16:30:13 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xA9GUDwH009643 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Nov 2019 16:30:13 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 10:30:12 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 11:30:11 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 9 Nov 2019 10:30:11 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QdNtbcOtmtLHnRgnYoik5mBcReQGuGFplbJAAPx3TuHffwgkzjN8hH6jeVaoG8fpxgcOTmbrK7+rL0zmI0Bs8JSq1dhxZW30BNourd5qcsdymhhzM84DA7Gpzc1LMVej/BPDGNSHLqCF1y6rvDhRbffOMKTJdTTtcpalwkkRT541SzxTTFR8Xui53cgohBuW9DaTe0ZthZVkt7UZExl/O6EiJGCQP4U7IcM1RS2q0dJnOSLdeKCUIOU0MjY2F5yYnyUnkxPfOIRLGc0ya6L1k203b+CVPpyjRcZrU4z9a8o98xA4bkL/0LFw09uWS1s6XuSNDDo5t91Bd/pRlNip/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=50SKv7vBi6H+BYUiJC1/QkDKPi6R03BliqAsAMVjsSI=; b=ClzLRF05H+026wothvCdDWyzUYdNC1R/UtVy64tNUPkXmbWZnqgqGav6AVjQmPnaeu0H8AJebKyRYvxWc9RRR+gxm5ibgKYrDLsOoA4AOjUk2JdYzzH46H2fEI2y1KeYX1/Tc9rmG0RmJazc2KjWDzwQSRaA3IqorjXXBvN3CmkfV7gRNz1m9FjweC6iz7PuMJghR4lT4pOjmqNuMeh+jkrMh1qsPTX3bR2rULdcQ07AMn/mmCwJX84JuSH8CdL3O8tOsGTWS119fkjfvvP4xycH8EvwKQeltYpoNih/XU2fyT4jZeqK8+A2BzIO+tKWAd97n9vq7UiX2ba5KxvDMA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
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=50SKv7vBi6H+BYUiJC1/QkDKPi6R03BliqAsAMVjsSI=; b=BXIANSxK5YTWoEr6kBpkGUYiI3YbRFaoVx5WeZUHmd2MCMg7eDour0WAHrahdeoTOcR60xl5nROsU0aCOfC15LmCDGtMr1a/1MdyCI+GmRDliRHrSsbQHoqNGXM5udr5yFS5KFlCbO2d9kcVhYmRgF6SiysC37jLCkE+G+HlJVQ=
Received: from MWHPR11MB1341.namprd11.prod.outlook.com (10.169.237.144) by MWHPR11MB1951.namprd11.prod.outlook.com (10.175.52.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.22; Sat, 9 Nov 2019 16:30:09 +0000
Received: from MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::1c7d:aa6e:14ad:11ce]) by MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::1c7d:aa6e:14ad:11ce%8]) with mapi id 15.20.2430.023; Sat, 9 Nov 2019 16:30:09 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: draft-ietf-bfd-large-packets-02
Thread-Topic: draft-ietf-bfd-large-packets-02
Thread-Index: AQHVkMv1cle+Xn0mwk2I6saLmxQhfqd8F41ggAJKYoCABLB30A==
Date: Sat, 9 Nov 2019 16:30:09 +0000
Message-ID: <MWHPR11MB134101746828C2E0A852D9DFC17A0@MWHPR11MB1341.namprd11.prod.outlook.com>
References: <20191101155244.GA30539@pfrc.org> <MWHPR11MB134154282E02EB6116D506D6C17E0@MWHPR11MB1341.namprd11.prod.outlook.com> <C92B43ED-54EA-47C2-842A-2AB931DBF57A@pfrc.org>
In-Reply-To: <C92B43ED-54EA-47C2-842A-2AB931DBF57A@pfrc.org>
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=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1003::3e3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 93ee61f5-2954-484c-4781-08d76532167d
x-ms-traffictypediagnostic: MWHPR11MB1951:
x-microsoft-antispam-prvs: <MWHPR11MB195195DB28DA28513601E064C17A0@MWHPR11MB1951.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 021670B4D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(396003)(39860400002)(346002)(136003)(13464003)(31014005)(189003)(199004)(8936002)(8676002)(7736002)(6436002)(316002)(229853002)(305945005)(6916009)(81166006)(256004)(66446008)(81156014)(25786009)(5660300002)(66556008)(64756008)(71200400001)(71190400001)(52536014)(74316002)(102836004)(76176011)(7696005)(53546011)(6506007)(486006)(66476007)(476003)(11346002)(446003)(46003)(186003)(9686003)(2906002)(6116002)(14454004)(478600001)(66946007)(76116006)(86362001)(33656002)(55016002)(99286004)(4326008)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1951; H:MWHPR11MB1341.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wW1Bo/RM/wXLkZgUQGE6zWZ20Df//u5FDB4YAi9n01Rvt1IvGY1Ki5KdpE4MayCdXgx5UuFJcrDK+JT+V/JXnV7Oui1xRvb+X65YKBdEmwodBBdq7MZ7nQ/1n/Avj23Kf+KS8pVLL8umfCg1HeSQ3cYG5hiXSlbPRpuL9Ulv4y5Bpw0u6eai986Gu//DrPMzrESQ7q35M8Fq+sWv2ADLDMKjMF0XHAeb2o9gv//ovGyTE5YXCHn2CW6wraqeTwdwA5L/V4I7QPlzy68v6vLgUc0NK64FpsiLtaiVgWvaQUgtLSY/xB4jeJ1ugPJGQ0hgTTOH/n2O/NHB7scXlk4/5EXey23Z26yKd3e0J4tN5Ha9Lv1ygmT+C1tuIPn+GujFSULqeLsRolX8kAcMKW+3zCE/Jtl0P1hOYh/h09MTl1PaWmg/pKiHgKCYxB7gyj+8
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 93ee61f5-2954-484c-4781-08d76532167d
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2019 16:30:09.5254 (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: 3ugoIVrfVh9xrZ86/l5Q53uUZm/kqSZgrDwM1qNHml1tcXKWkjhdGgZJac0LVbJplkXdAEOD+UhhL64CNhRzfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1951
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/t-1lLqaSRnJNnidtsxJNoj_bA1E>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Nov 2019 16:30:27 -0000

Jeff -

I do not have a specific model in mind for S-BFD and large packets - implementations should be free to choose. I think you have covered the options well in your comments below. Mainly I wanted this discussed in the draft.

The only thing that might be troublesome is the notion of using a separate discriminator for large packet S-BFD (yes - I suggested this - not you 😊). This raises the unsolved problem of how does one indicate which discriminator is for which use case. Although the IGP extensions support advertising multiple S-BFD discriminators we never figured out how to indicate how a given discriminator should be used. I only mention it since this draft introduces a possible use case for multiple S-BFD discriminators - but this isn’t a new issue and doesn’t have to be solved by this draft.

   Les


> -----Original Message-----
> From: Jeffrey Haas <jhaas@pfrc.org>;
> Sent: Wednesday, November 06, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>;
> Cc: rtg-bfd@ietf.org
> Subject: Re: draft-ietf-bfd-large-packets-02
> 
> Les,
> 
> 
> > On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg)
> <ginsberg@cisco.com>; wrote:
> >
> > Jeff/Albert -
> >
> > Thanx for the updated version. This addresses my concerns.
> >
> > A couple of modest comments.
> >
> > 1)Section 3.4
> >
> > s/that balacing/that balancing
> 
> Queued for next rev.
> 
> > 2)Regarding S-BFD (Section 3.5)
> >
> > It would seem difficult to support (for a given discriminator) some sessions
> using large packets and some not. I  can think of a few options:
> >
> > a)Passive end uses large packets only if the Active end does. This assumes
> MTU is the same in both directions.
> 
> Asymmetric MTUs are not only possible, but likely in S-BFD scenarios.  But it's
> a valid point.
> 
> > b)A separate discriminator is used for large packet sessions
> > c)Use of large packets is always on (or always off) on the passive side
> >
> > Probably there are other choices.
> >
> > What did you have in mind? I think adding some guidance in that regard
> might be useful.
> 
> My personal thought on the matter had been roughly:
> - By default, respond with the same size IP encapsulation as you receive.
> - While S-BFD permits largely non-configured responses to Initiators, there's
> likely to be SOME configuration present.  If necessary, specific configuration
> can be given to cover size of packets to respond to.  (Roughly aligning with
> the ACLs used to manage whom can initiate S-BFD in the first place.)
> 
> One way to interpret your questions is that there should be some implied
> configuration for BFD for Large Packets, not only on the sending side, but on
> the receiver.
> 
> For the receiver, something roughly like "bfd.PaddedPduReceiveMaxSize" as
> a parameter.  Possibly acting also as a way to enable the feature or not.
> 
> For an S-BFD reflector, perhaps parameters to control beyond the receive
> max size whether it responds with the same size as the iP encapsulation, and
> whether there's a cap for such a response.
> 
> Does the above address your concerns?
> 
> -- Jeff