Re: [mpls] Comments on draft-aa-mpls-ldp-link-shut
Tarek Saad <tsaad.net@gmail.com> Sun, 17 November 2019 06:33 UTC
Return-Path: <tsaad.net@gmail.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 693F31200B6; Sat, 16 Nov 2019 22:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 kjhzNXRtE5dm; Sat, 16 Nov 2019 22:33:31 -0800 (PST)
Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8141E12007C; Sat, 16 Nov 2019 22:33:31 -0800 (PST)
Received: by mail-yw1-xc33.google.com with SMTP id m196so4677659ywd.5; Sat, 16 Nov 2019 22:33:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=iHd4hXnTFQDXOkbLWIKLytktmo7jVFd3Ul31yFnawEI=; b=UcQ4r6EYijRnah2rPsyVLt6jv9RQ8u/H54P/5ZxKtvOHrC9uwKZo88qOxLL0rJiehb c33IWAgKc+O5wq35L5bOLvlxiRpWyF4+TAgmDLD2EVrG2Htgb6ibvYw9Sb42q63PW83s EEcK11+zGeE2LVLF2gKel3emoA+csm3SSt8Yf3NgkKPmNRICm/G6vl5raDlZaqkjkS9R Ag/S+6Iq4E3OLD7uKqR09JXUfMt3PCK+BoHuUk2w2ZUmXAhFJ4lRILuS6rm3sgVOPR0o t9scnqPFs0IuC61YlYMr1PumRYMXi5Dpihi5jqZF56uJ6zeh6vqwf0NTcEWqJL3bjQb0 xKlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=iHd4hXnTFQDXOkbLWIKLytktmo7jVFd3Ul31yFnawEI=; b=sCO+5O/HXAsHIqYFSrjqWnq7HruS8V9inD+QPzaMFQ9nXrDuBwfDpiasPu60ZszCCg 5AN3un0dGoos0bCYRkHR4mqkTOVMtxw4pc4Bs3SVj7xzLJVT2B9IdXZRLHkfEiaRTs7l PrAAbuL9luIGCVY0wTtSot+63OFSWCk2nEGvYU9IIswjYfHAZKyVkMwYl+7TGMNH7vic VJhwi1Ty3xj/7jRpweNuSNhiRslWPZAdZsLZU84a/cCWAG7HYqMbteC3ytCy/3f6HAjE GfS4XyDb4dUUnYl1ydJ/Qw0iGkakKOjt76DCWuMHUoIjrH2upIR5M8dAH7yCN7i1bKeL U5pg==
X-Gm-Message-State: APjAAAVyCm2f/u9bkP5iWMLY3Su2aUnkLxG8+HQEIyff6m0jKF+mgGAK Iiho+rhGy1cFgDvzzdm94FiEJn27b3Y=
X-Google-Smtp-Source: APXvYqx2aWIn+Ilyh+9odSgVKbe1idF263znsK3ypUbqNXjNPJ6DfF46lAhYcyHXHzYmmIb7csOnbQ==
X-Received: by 2002:a81:1904:: with SMTP id 4mr11261006ywz.158.1573972410289; Sat, 16 Nov 2019 22:33:30 -0800 (PST)
Received: from DM6PR19MB3689.namprd19.prod.outlook.com ([2603:1036:301:21db::5]) by smtp.gmail.com with ESMTPSA id y196sm5834711ywa.5.2019.11.16.22.33.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Nov 2019 22:33:29 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: "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: ATA5OUMzHcJWY0o1mWjPbtSzZTxvX8rHr1Aw
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sun, 17 Nov 2019 06:33:27 +0000
Message-ID: <DM6PR19MB368974E13C15258185FA5DF6FC720@DM6PR19MB3689.namprd19.prod.outlook.com>
References: <DM6PR19MB36896FDCD631789277FE592AFC720@DM6PR19MB3689.namprd19.prod.outlook.com>
In-Reply-To: <DM6PR19MB36896FDCD631789277FE592AFC720@DM6PR19MB3689.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM6PR19MB368974E13C15258185FA5DF6FC720DM6PR19MB3689namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/A3X8b7Lb_4A65n-a5tY02y6wR18>
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 06:33:33 -0000
+ mpls@ietf.org From: Tarek Saad <tsaad.net@gmail.com> Date: Sunday, November 17, 2019 at 2:32 PM To: "draft-aa-mpls-ldp-link-shut@ietf.org" <draft-aa-mpls-ldp-link-shut@ietf.org> Cc: Vishnu Pavan Beeram <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 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? Regards, Tarek