IETF Logo Mail Archive

Re: [mpls] Comments on draft-aa-mpls-ldp-link-shut

Anush Mohan <anush.mohan@ericsson.com> Sun, 17 November 2019 07:17 UTC

Return-Path: <anush.mohan@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B321200C1; Sat, 16 Nov 2019 23:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 CeNG6fpMyQ8B; Sat, 16 Nov 2019 23:17:41 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::602]) (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 C15AB1200B6; Sat, 16 Nov 2019 23:17:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=crzvbA5P51rbiG/1mAkC/4mk8F3L5VbtMKlN0vdI+8thYfeYBR71YNHIebYBSkir8GnobvzyGP3/wmB7FeMJQr22muIsccAnjmDDI6mMC2LIfPRzM2P1tVoFCQAxuJ1IoZbtSjOOxjY0L62Jz9+JyVMdzwE3WY7JAP/N1deNpCrKuSeyRmpI3ugOtTiPjxA+B6DgTYQSkcuMmbjQx+kBldAk96sEpfiwmncP2Bb/o2BqUf+3N9YjoDy0nqwFvXnPK4Z2sjbG2BGJFyqXKkyCcgUhZYPKNZ9reGY++ZJDOAn+dlkYX+YPWbTwwXXMInjQmkEebfgT98LGuQL0iZRNDA==
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=Y9CiPGQN2hcN9nTdN349QjsfMmUTvBuwoD1txGf1bM4=; b=GK8rZV3NAhqRAlncQ0EuUU6BSpbNSRQw9l+3eBGPRC9a4V2jnmnUEMLw9Rnb5qNBT3C9Q23e27f/5XjJr5Nhm3vpLteZK6YLvjmHdfG6caKhBYuaBotknL9zwMX4C1vcgXeLfvlp++rrZ7Fpyk1zZcl2bJYHfhdfKZ1RBpXej1p4Fph/htpZQsuv9S/yk0AKjtjc2cuqCjLILcjeU2o4jAV03RH2W7eK7M/znmsWIxrIi+oVKfsIECzvJHNoDWjfmmkI7GG1+a7k6UbBGp+O9mTTz4VLOsoz6FqvqHXEkldHoX1vStTGUvqLS8V1X6JvwmiByjoMyvVByV8etKjD0A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y9CiPGQN2hcN9nTdN349QjsfMmUTvBuwoD1txGf1bM4=; b=k07mCb+ai3z32fVKWVPY5VUIkyLopYCrIYa+Ak8O2QzgrOztqFpKqHSk9u1fbmC5OKJCP9ZG+P4/MBiJfy/bjGhtAf9UgjXNatTG4+/6sc+kBA7CiIbAWeEIdTr4UltJhxNbGkSDgd0GQDhRVREozSVQkCZQsKcL9gsFb4leiEM=
Received: from VI1PR0701MB2672.eurprd07.prod.outlook.com (10.173.85.135) by VI1PR0701MB2797.eurprd07.prod.outlook.com (10.173.83.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Sun, 17 Nov 2019 07:17:38 +0000
Received: from VI1PR0701MB2672.eurprd07.prod.outlook.com ([fe80::b102:1cb6:f55f:122]) by VI1PR0701MB2672.eurprd07.prod.outlook.com ([fe80::b102:1cb6:f55f:122%9]) with mapi id 15.20.2474.012; Sun, 17 Nov 2019 07:17:38 +0000
From: Anush Mohan <anush.mohan@ericsson.com>
To: Tarek Saad <tsaad.net@gmail.com>, "draft-aa-mpls-ldp-link-shut@ietf.org" <draft-aa-mpls-ldp-link-shut@ietf.org>
CC: Vishnu Pavan Beeram <vbeeram@juniper.net>, mpls <mpls@ietf.org>
Thread-Topic: Comments on draft-aa-mpls-ldp-link-shut
Thread-Index: AQHVnRDXLAapMOsZ4Ue+SbbHTFeRRKeO57SAgAAImZA=
Date: Sun, 17 Nov 2019 07:17:38 +0000
Message-ID: <VI1PR0701MB2672F6415B820A035E126AEF83720@VI1PR0701MB2672.eurprd07.prod.outlook.com>
References: <DM6PR19MB36896FDCD631789277FE592AFC720@DM6PR19MB3689.namprd19.prod.outlook.com> <DM6PR19MB368974E13C15258185FA5DF6FC720@DM6PR19MB3689.namprd19.prod.outlook.com>
In-Reply-To: <DM6PR19MB368974E13C15258185FA5DF6FC720@DM6PR19MB3689.namprd19.prod.outlook.com>
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=anush.mohan@ericsson.com;
x-originating-ip: [2401:4900:2181:d5aa:7499:4acc:dd2b:764d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3464a41b-fba6-409b-54ab-08d76b2e3a1e
x-ms-traffictypediagnostic: VI1PR0701MB2797:
x-microsoft-antispam-prvs: <VI1PR0701MB27974E8205ED862AD3D70E6C83720@VI1PR0701MB2797.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 02243C58C6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(366004)(346002)(376002)(189003)(199004)(9686003)(6436002)(74316002)(186003)(5660300002)(54906003)(110136005)(66476007)(64756008)(102836004)(66556008)(66446008)(478600001)(99286004)(66946007)(7696005)(14444005)(256004)(14454004)(52536014)(6506007)(53546011)(790700001)(6116002)(76176011)(76116006)(71190400001)(71200400001)(86362001)(55016002)(486006)(476003)(44832011)(81156014)(81166006)(446003)(316002)(8676002)(11346002)(4326008)(33656002)(9326002)(46003)(8936002)(6306002)(7736002)(54896002)(229853002)(2501003)(2906002)(25786009)(6246003)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2797; H:VI1PR0701MB2672.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: sZKwzHacxxOA8JSTFJk7nWyOCRLmU7JxN7OewaC1rTw3rNp02lJaNls0uhCW5VHSt2/OW1W3bGyaeaFljo/E0Tjsi3PQkasn/2d7w4NdrQDKehgGTcWhsAVwciiVDSa0ncXEEpGdOA8uZjlhxTmuCuLWLtKKtSnG1F3Yj2o03mHaq+zIqHSAS+OSgFoHBA6QNcnYyX5SJ+ls2946Mnwlc6W9VqomCmw+HI7MlG3dBo427Q4mWypFOd5ea0veF6LbK2cmodSYpJTJg4VZzvOu2ORn14fAbGyyKAOaREJ3pXB9NYOrDUwXQu9ocF+vBVfQ/FNJ6XsVCLBS4AnewrA/cWLzGKGfqDTKROBFCbjVXO0TjwuALmtgQqBC4Qd9SImLaeEoN75F1UhHB+H/ng4N1iWrIMLUxKrIHNzwnkDBfigtznIGNZF7BR6CUy3LFJZw
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB2672F6415B820A035E126AEF83720VI1PR0701MB2672_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3464a41b-fba6-409b-54ab-08d76b2e3a1e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2019 07:17:38.2539 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EXjT5MG79jrO68XM3nQac55hzC9ZrNkGZ7Rr17cKPUUDcFp/psNugqYCplakIbsk1lDlkVGenipOeR2uQ/hR9/HFasLqQAMgH5E+JC/b5sU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2797
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/0w33IR-z7DPSa-QDxvd3bWDT8gA>
Subject: Re: [mpls] Comments on draft-aa-mpls-ldp-link-shut
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Nov 2019 07:17:43 -0000

Hi Tarek,

   Please find my replies inline.

Regards
Anush

From: Tarek Saad <tsaad.net@gmail.com>
Sent: Sunday, November 17, 2019 12:03 PM
To: draft-aa-mpls-ldp-link-shut@ietf.org
Cc: Vishnu Pavan Beeram <vbeeram@juniper.net>; mpls <mpls@ietf.org>
Subject: Re: Comments on draft-aa-mpls-ldp-link-shut

+ mpls@ietf.org<mailto:mpls@ietf.org>

From: Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>
Date: Sunday, November 17, 2019 at 2:32 PM
To: "draft-aa-mpls-ldp-link-shut@ietf.org<mailto:draft-aa-mpls-ldp-link-shut@ietf.org>" <draft-aa-mpls-ldp-link-shut@ietf.org<mailto:draft-aa-mpls-ldp-link-shut@ietf.org>>
Cc: Vishnu Pavan Beeram <vbeeram@juniper.net<mailto:vbeeram@juniper.net>>
Subject: Comments on draft-aa-mpls-ldp-link-shut

Hi co-authors,

Having gone through this draft, I have the following comments:

1.      Draft does not mention LDP session protection feature -- aka targeted LDP session to peer that handles the case of keeping LDP session UP in case of Hello Adj or link adjacency down. I see several vendors (at least Juniper/Cisco) who have support for this

                     [Anush]: Agree, we need to mention this. It helps for the issue mentioned in the draft.


2.      Section 2.5.5 or rfc5036 describes a hold timer that only after expiring will trigger the Hello adjacency deletion - and only after the last hello adjacency going down will trigger the LDP session to peer to go down.. i.e. the RFC 5036 does not dictate that LDP session to peer to go down immediately after link down as stated in draft-aa-mpls-ldp-link-shut section 3.


"
   An LSR
   maintains a hold timer with each Hello adjacency that it restarts
   when it receives a Hello that matches the adjacency.  If the timer
   expires without receipt of a matching Hello from the peer, LDP
   concludes that the peer no longer wishes to label switch using that
   label space for that link (or target, in the case of Targeted Hellos)
   or that the peer has failed.  The LSR then deletes the Hello
   adjacency.  When the last Hello adjacency for an LDP session is
   deleted, the LSR terminates the LDP session by sending a Notification
   message and closing the transport connection.
"
Given 2) above, do you still see ambiguity in handling link-down as described in RFC5036?

              [Anush]: This particular section talks about procedures for maintaining LDP hello adjacencies, but doesn't explicitly
                       prevent any implementation from immediately tearing down LDP session, when the only LDP enabled link to a
                       peer goes down. Other places in the RFC leave it open to the implementation, to decide  when to terminate an LDP
                       session.

Regards,
Tarek

v2.23.0 | Report a Bug | By Email