Re: [Technical Errata Reported] RFC5884 (5085)

Balaji Rajagopalan <balajir@juniper.net> Sat, 16 December 2017 14:48 UTC

Return-Path: <balajir@juniper.net>
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 B6F00126C25; Sat, 16 Dec 2017 06:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 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, 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 OWB3GA4SySZv; Sat, 16 Dec 2017 06:48:11 -0800 (PST)
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 A2CB0127599; Sat, 16 Dec 2017 06:48:11 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBGEi54O004504; Sat, 16 Dec 2017 06:48:04 -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=g7I2ubpojc8Zd+RuYauZ3LfAbKaGDjs5U9SMs/x2wPE=; b=wpvm+XeIYWoicfJD3otTnq6uar0LrvQ/x+E7PfMbgsJ4dk4Lw/Tc6GGz4l40zxUqZ/iF CqeLjeRU1EVsPQnOIuCTL42mhS34iAyKUTUKtT+Ij8tAnHjVeNm/eoAJnHoTObBjI1YL zUClfTT+UHz9+ZiWSVB3Ftop/EX6sjkIKRqIM9Uy49G0iCcC1gePUKp5ztzf8RN2GQfZ d66D5xBai13rYG51rDwjKuKzSZAsWf9sSp3JnwsXstyBni9qxfOS5AHf6T9/1spxcqVO ZybMwcTMW52w0E52mEtagZqIXm+eThyYPjmg5h9tE+euXgQEe/is6UzEJlNWyjQ0xRLU Hw==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0047.outbound.protection.outlook.com [216.32.180.47]) by mx0a-00273201.pphosted.com with ESMTP id 2ew3uc84rx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 16 Dec 2017 06:48:04 -0800
Received: from MWHPR05MB3215.namprd05.prod.outlook.com (10.173.229.146) by MWHPR05MB3504.namprd05.prod.outlook.com (10.174.250.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Sat, 16 Dec 2017 14:48:01 +0000
Received: from MWHPR05MB3215.namprd05.prod.outlook.com ([10.173.229.146]) by MWHPR05MB3215.namprd05.prod.outlook.com ([10.173.229.146]) with mapi id 15.20.0323.018; Sat, 16 Dec 2017 14:48:00 +0000
From: Balaji Rajagopalan <balajir@juniper.net>
To: Greg Mirsky <gregimirsky@gmail.com>, "BRUNGARD, DEBORAH A" <db3546@att.com>
CC: Kireeti Kompella <kireeti@juniper.net>, Jeffrey Haas <jhaas@pfrc.org>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "ginsberg@cisco.com" <ginsberg@cisco.com>, Thomas Nadeau <tnadeau@lucidvision.com>, mpls <mpls@ietf.org>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)
Thread-Topic: [Technical Errata Reported] RFC5884 (5085)
Thread-Index: AQHTEmO6It6KBy1xuUWF7JOUmCVKk6J/bMuAgAAJToCAB2B3AIAAOi4AgADYioCACJzagIAAwhAAgBV+5ICABOwLgIBeFPKAgDc7YoCAAYDFgIADI5MAgAAUigCAAXTSgA==
Date: Sat, 16 Dec 2017 14:48:00 +0000
Message-ID: <48B0601C-C430-4E7B-B577-77DF4052EC56@juniper.net>
References: <20170811053550.27303B81263@rfc-editor.org> <20170811173930.GJ24942@pfrc.org> <CA+RyBmWYRAT3g=zCN+ot9mFDYuPCOGCwyPQJp-+9AfA6oJjttA@mail.gmail.com> <DDFD74A7-D09D-43AE-9BAD-24273A53C55B@juniper.net> <705BEEE3-BC31-42CA-BE0F-06EB6E529A65@cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE29188220B@dggeml508-mbx.china.huawei.com> <6F83D826-CF7F-462A-BE54-35F46D76A9A8@juniper.net> <CA+RyBmVjBBXGh3DaR0vB90HwNjKxMw850e_bY1QSHuycyNP85g@mail.gmail.com> <ADFFD606-43A1-46F6-9D4D-BF2BF54851C2@juniper.net> <CA+RyBmXQzUf2wZrZWBUzX26LCaKSDd9j6Ppg=Aeo8Y5NrhKNKQ@mail.gmail.com> <82C1C94C-0D7B-40E8-9350-8FE5515A8264@juniper.net> <F64C10EAA68C8044B33656FA214632C8881E3898@MISOUT7MSGUSRDE.ITServices.sbc.com> <D104F2A9-9B64-4C9D-9273-EAA890F188E9@juniper.net> <F64C10EAA68C8044B33656FA214632C8881E9DE9@MISOUT7MSGUSRDE.ITServices.sbc.com> <CA+RyBmViC+6DPUNbh5AnU6Q9BWFtQ2DY=xstgp2Yn-fUCreKyQ@mail.gmail.com>
In-Reply-To: <CA+RyBmViC+6DPUNbh5AnU6Q9BWFtQ2DY=xstgp2Yn-fUCreKyQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-originating-ip: [116.197.184.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR05MB3504; 6:noY3alKLsHk+jfu/X5Nse/KubARQY9GRJtxEMYjRTXI6IcrpLheKp0EPHVLpSwE6IrndXr8cKZK7d3yPSzL7/qtJ0JfTvW9VX3oVrGJmoZxZk8odd86P7EMLMapz3el8ceZhegZXRNgJF7qSVDrhW3DbJhfqujJCJY1okss+9UY+R/+S6aiM4vgnnMNp5liaXgWeM8hStDDiorhT4rRVYtWhr4ZwimtXWl+DcWRYwRa23k80k2Y0L5f2rTdDg3xvzqgECZe1cC3dagRG8+/A+MYsgMAK9bk/Pg4A6WLdL3pR4YX+fdi1ZBi7OjzFce2r72Lil0qhfPGfv2HhW37YU7CrTOgLHmu73tWh/gFqYNI=; 5:ArnYgL8ljj25fBY/xAEkabvPXjDql5pAUntFvbOsbFPkZKqYITYrRGO6sW3cymCaYu3jsn5vjlXGdYT4uMQYJ0gdxdv3PblbtDl+XGBEdMhw6W0RUmx7958yr5JoRBX4vRI44QDzLyiOs3IAh1GRLN9BiNDEosAg8ZPBBsTf5BI=; 24:hNZTq7KK55xpEKiicWGbswcizt3QOCsnptqKhjpleJtVVA17/mQcA0Z+sxRmy7s0apsB6bcAteGP/dDrEYQbrIQ2bnwkZmZOo94TN0eMBgQ=; 7:OlQ+ZT0NJg3EWNES7fsSFNiPCy8lvQL23qPOskk24e2D4OkAgIwYW4vQMFsJQV8xYUsv/oZy5ZZXfiTFNfl24OCYS5IuXzFibfN0fzaz9WnHwchV8qYGeRlgdfekKCM2IXtD6lE7C1+fREwtDYaCkzBY6TD/xdAKKtOikJV8L7e9xqgV3laLCNpSarFNIyVkFvfBLK1hahgysQSlK29wGVmSB3gFKVWGnrvwVTAiw9/vTUeY6iMZ0tr6VGTa500E
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(346002)(39860400002)(51444003)(199004)(60444003)(24454002)(189003)(18926415007)(2900100001)(316002)(606006)(97736004)(33656002)(110136005)(58126008)(76176011)(6506007)(53546011)(54906003)(59450400001)(105586002)(66066001)(478600001)(733005)(14454004)(83716003)(6246003)(99286004)(5660300001)(25786009)(83506002)(229853002)(106356001)(53936002)(86362001)(82746002)(81156014)(81166006)(3280700002)(561944003)(102836003)(3846002)(6116002)(8936002)(6306002)(36756003)(53946003)(54896002)(68736007)(2950100002)(16200700003)(236005)(8676002)(3660700001)(6512007)(4326008)(39060400002)(77096006)(6436002)(966005)(93886005)(6486002)(2906002)(7736002)(9326002)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3504; H:MWHPR05MB3215.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: 671cff6f-9596-417b-9c31-08d54494013b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153051); SRVR:MWHPR05MB3504;
x-ms-traffictypediagnostic: MWHPR05MB3504:
x-microsoft-antispam-prvs: <MWHPR05MB350418E16AC3289D64BE6E62AB080@MWHPR05MB3504.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008)(97927398514766)(95692535739014)(21748063052155)(6911010853514)(225473673943800)(50582790962513);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231023)(6055026)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR05MB3504; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR05MB3504;
x-forefront-prvs: 0523CF0711
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_48B0601CC4304E7BB57777DF4052EC56junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 671cff6f-9596-417b-9c31-08d54494013b
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2017 14:48:00.7919 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3504
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-16_09:, , 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-1712160223
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/tSAXtZOZPEoF43bvnIot_lF34TI>
X-Mailman-Approved-At: Mon, 18 Dec 2017 06:13:20 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
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, 16 Dec 2017 14:48:17 -0000

Hi Greg,

Just responding to this point:

>> Whether egress LSR must reply is defined by the value of the Reply Mode field and it is absolutely valid to set the field to Do not reply.

Yes. The revised text points to the base RFC for compliance. So, the sender of LSP-Ping Echo request can still exercise this option. IOW, the revised text does not preclude the above option.  What needed to be clarified was that the receiver of the LPS-Ping request message cannot implicitly assume lack of interest on the sender’s part in receiving a reply, just by the presence of the discriminator.

Agree with your point about the RFC & errata not specifying how the sender should handle mismatch.

--
Balaji Rajagopalan



From: Greg Mirsky <gregimirsky@gmail.com>
Date: Saturday, 16 December 2017 at 3:33 AM
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, Balaji Rajagopalan <balajir@juniper.net>, Jeffrey Haas <jhaas@pfrc.org>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "ginsberg@cisco.com" <ginsberg@cisco.com>, Thomas Nadeau <tnadeau@lucidvision.com>, mpls <mpls@ietf.org>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Hi Deborah, et. al,
I agree with the final text though I cannot agree with the Notes where stating:
Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.
Whether egress LSR must reply is defined by the value of the Reply Mode field and it is absolutely valid to set the field to Do not reply. As for inclusion of BFD discriminator in the reply message, I believe, that RFC 5884 and the Errata leave an open question of ingress LSR action upon receiving the reply with BFD discriminator allocated by the egress. We had started discussion in Singapore during the presentation of draft-mirsky-mpls-bfd-bootstrap-clarify. Doing RFC5884bis may be the better option rather than multiplicity of Erratas.

Best regards,
Greg

On Fri, Dec 15, 2017 at 2:50 PM, BRUNGARD, DEBORAH A <db3546@att.com<mailto:db3546@att.com>> wrote:
Hi Kireeti,

Other than doing a revised RFC, this is the (only) way to correct an error, then when the RFC is revised, all the errata need to be included/reviewed.

As for implementers, the current Errata is shown as a hyperlink next to the RFC number. Hopefully, an implementer (and all users) check this.

Thanks for responding😊 I’ll interpret silence of the others over this past month as agreement and make the changes.

Deborah


From: Kireeti Kompella [mailto:kireeti@juniper.net<mailto:kireeti@juniper.net>]
Sent: Wednesday, December 13, 2017 3:54 PM
To: BRUNGARD, DEBORAH A <db3546@att.com<mailto:db3546@att.com>>
Cc: Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>; Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>>; ginsberg@cisco.com<mailto:ginsberg@cisco.com>; Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>

Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Hi Deborah,

I’m fine with Balaji’s proposal.

As I said, I’m fine with an erratum, but I leave it to the iesg/rfc editor which would be more effective from the point of view of ensuring that future implementations follow this change.
Kireeti

On Dec 12, 2017, at 22:57, BRUNGARD, DEBORAH A <db3546@att.com<mailto:db3546@att.com>> wrote:
Hi,

I’ve not seen a reply to Balaji’s proposal? It’s a slight tweak to Les’s on 10/4.

I agree we can do this as an Errata. I can fix the proposal in Errata 5085, just need agreement on what you want to do.

Deborah


From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Balaji Rajagopalan
Sent: Tuesday, November 07, 2017 8:00 AM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>; Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>; Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>>; ginsberg@cisco.com<mailto:ginsberg@cisco.com>
Cc: Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>>; Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: [mpls] [Technical Errata Reported] RFC5884 (5085)

Hi,

From the discussions, I could list down four changes:

-         Explicitly state compliance to RFC 8029
-         Re-arrange the text so LSP-Ping description follows BFD
-         Remove the redundant comma
-         Explicitly mention that LSP-Ping reply optionally carries a discriminator. This was the key change I wanted to propose. Section 6.1 does not state whether the discriminator in the LSP-Ping reply is mandatory or optional. Section 6 has ambiguity in the text, which the proposed text seeks to address.

The following text replaces the last two paragraphs of section 6:

<begin>

On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR, if the validation of the FEC in the LSP Ping Echo request message succeeds.  This BFD Control packet MUST set the Your Discriminator field to the discriminator received from the ingress LSR in the LSP Ping Echo request message. The local discriminator assigned by the egress LSR MUST be used as the My Discriminator field in the BFD session packets sent by the egress LSR.

The ingress LSR follows the procedures in [BFD] to send BFD Control packets to the egress LSR in response to the BFD Control packets received from the egress LSR.  The BFD Control packets from the ingress to the egress LSR MUST set the local discriminator of the egress LSR in the Your Discriminator field.  The egress LSR demultiplexes the BFD session based on the received Your Discriminator field.  As mentioned above, the egress LSR MUST send Control packets to the ingress LSR with the Your Discriminator field set to the local discriminator of the ingress LSR.  The ingress LSR   uses this to demultiplex the BFD session.

The egress LSR processes the LSP Ping Echo request message in accordance with the procedures defined in [RFC 8029]. The LSP Ping Echo reply message generated by the egress LSR MAY carry the local discriminator assigned by it for the BFD session, as specified in section 6.1.

<end>

--
Balaji Rajagopalan



From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Saturday, 9 September 2017 at 3:16 AM
To: Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>
Cc: Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>, Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Hi Balaj,
I think that we need help from WG chairs to find the best way to handle this case. The original Errata that triggered this very helpful discussion propsed the following new text:
The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session.
Your new proposal is very much different:
The egress LSR MUST follow the procedures described in [RFC4379] in processing the LSP Ping request. The LSP Ping reply generated by the egress MAY carry the local discriminator assigned by it for the BFD session.
I agree with latter but think that text proposed by Les goes further in clarifying bootstrapping of BFD session. Perhaps the question is not only in improving the original text:
The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session.
but making the whole RFC 5884 clearer by drafting 5884bis. I 'd propose two questions to continue the discussion:

  *   would 5884bis recommend use of particular Reply mode in echo request with BFD Discriminator TLV;
  *   whether echo reply includes BFD Discriminator it the Reply mode is set to one of values that commands to send the reply.
To the first I propose to consider that the ingress LER SHOULD set Reply mode to No reply. And to the second that the ingress LER SHOULD NOT include BFD Discriminator TLV when sending echo reply to the BFD session bootstrapping LSP ping.

Regards,
Greg

On Tue, Sep 5, 2017 at 6:06 AM, Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>> wrote:
Hi Greg,

While all the issues you bring up are valid, the change I had proposed merely makes a minor correction to improve textual clarity. There was no attempt to alter the protocol in any way.

I think both the following aspects are non-trivial, and are beyond the scope of errata. Perhaps, these issues are better addressed in a “-bis”.

-         Removal of BFD-disc from the LSP-Ping reply. I defer to Kireeti & other authors of the RFC to comment/decide whether BFD-disc can be removed from the reply.
-         Rules to specify handling of mismatch between BFD-disc in the LSP-Ping reply & the BFD session

--
Balaji Rajagopalan


From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Wednesday, 23 August 2017 at 7:51 AM
To: Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>
Cc: Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>, Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>

Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Hi Balaji,
I've been thinking about the value of including BFD Discriminator TLV in echo reply sent by egress. What we'd expect ingress to do upon receiving the reply? Match to bfd.remoteDiscr? I think that then echo reply must include the value from the original BFD Discriminator TLV so that ingress uses it to demux BFD sessions. Or ingress doesn't validate the value in BFD Discriminator TLV but only that the TLV is included in reply? If we leave actions of the ingress upon receipt of the reply with BFD Discriminator underspecified it may result in another set of interoperability issues. Perhaps the simplest way to avoid that would be to not allow BFD Discriminator TLV in the reply.

Regards,
Greg

On Tue, Aug 22, 2017 at 2:16 AM, Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>> wrote:
That sounds better. How about the following text?

The egress LSR MUST follow the procedures described in [RFC4379] in processing the LSP Ping request. The LSP Ping reply generated by the egress MAY carry the local discriminator assigned by it for the BFD session.

--
Balaji Rajagopalan

From: Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>
Date: Thursday, 17 August 2017 at 8:45 AM
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>, Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: RE: [Technical Errata Reported] RFC5884 (5085)

Indeed, I also like Les’s suggestion!

Best regards,
Mach

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>] On Behalf Of Carlos Pignataro (cpignata)
Sent: Wednesday, August 16, 2017 10:20 PM
To: Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>; Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>>; Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

This sounds like a good summary of the tactical fix.

(Although, like Les wrote down, saying “MUST follow [LSP-Ping]” is better than “MUST Send a Reply”)

As an aside -- When it comes to Interop, I remember also issues around the UDP Port on the egress BFD Control packet, depending on whether the response is IP-based vs. over an MPLS LSP.  Tracking this down, this was identified at https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00447.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_rtg-2Dbfd_current_msg00447.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=H6rQa_WisJtG2nGx-kOD0r0EF0bSm7KfoMzouNR6nBI&s=sev9d10du5VFV_jwTtQJYZfbaVnRmHM1mFLGIOAkwUc&e=> (comments on Sections 6 and 7), and it seems, we may have the right bug but a wrong fix.

Thanks,

-- Carlos.

From: Rtg-bfd <rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of Balaji Rajagopalan <balajir@juniper.net<mailto:balajir@juniper.net>>
Date: Wednesday, August 16, 2017 at 1:23 AM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>, Jeff Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>, Tom Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

I’m aware of three different behaviours from three different vendors that I came across in the course of inter-op:
-         Always respond to an LSP-Ping request carrying a BFD disc
-         Never send a response to an LSP-Ping request carrying a BFD disc
-         Don’t respond to the first LSP-Ping request carrying a BFD disc, but respond to the subsequent ones


This experience leads me to believe that this procedure is NOT well-understood.  So, publication of errata on this issue is necessary.

As some of the co-authors have clarified in further emails, inclusion of BFD discriminator in the LSP-Ping request does not change LSP-Ping’s basic function. So, the egress must send a reply. This is what the erratum clarifies.

--
Balaji Rajagopalan



From: Rtg-bfd <rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Friday, 11 August 2017 at 11:42 PM
To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: Kireeti Kompella <kireeti@juniper.net<mailto:kireeti@juniper.net>>, Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Re-sending to the corrected list (apologies for duplicates).

Dear All,
I suggest to reject this proposal. The current text is clear and the mechanics of bootstrapping BFD session over MPLS LSP is well understood - remote peer MUST start sending BFD control packets first and BFD peer MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV.

Regards,
Greg


On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>> wrote:
[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.

-- Jeff