[mpls] YANG Data Model for MPLS LDP and mLDP

Eric Gray <eric.gray@ericsson.com> Thu, 07 April 2016 13:15 UTC

Return-Path: <eric.gray@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AFFDF12D93D for <mpls@ietfa.amsl.com>; Thu, 7 Apr 2016 06:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0cFWEGNdbz5P for <mpls@ietfa.amsl.com>; Thu, 7 Apr 2016 06:15:12 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661EC12D61C for <mpls@ietf.org>; Thu, 7 Apr 2016 06:15:06 -0700 (PDT)
X-AuditID: c6180641-f79fa6d0000057a9-ec-57065d332890
Received: from EUSAAHC006.ericsson.se (Unknown_Domain []) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 91.59.22441.33D56075; Thu, 7 Apr 2016 15:14:27 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([]) by EUSAAHC006.ericsson.se ([]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 09:15:04 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: YANG Data Model for MPLS LDP and mLDP
Thread-Index: AdGQz39OiiwIKDo0Sh2KJ/9vN87vVg==
Date: Thu, 07 Apr 2016 13:15:03 +0000
Message-ID: <95E28899-03A5-4941-B87B-34B14443E360@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-08B79AE5-A831-48DE-B4F0-DBBE5378A46B"; protocol="application/pkcs7-signature"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyuXRPlK5xLFu4weXF4ha3lq5kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxso7J9gL1jpXfHr8k6WBca99FyMnh4SAicTF9Z/YIGwxiQv3 1gPZXBxCAkcZJdYsmM8O4SxjlFh3cT07SBWbgIbEsTtrGUFsEQFliSMTu1lBbGEBPYmHGxYw Q8SNJd4susUEYetJ7Do2DyzOIqAiMXnlK7A4r4C9xO8nG8FmMgJt/n5qDVicWUBc4taT+UwQ F4lIPLx4Guo6UYmXj/+xghzELDCZUeLDjPlsEIMEJU7OfMIygVFwFpL+WcjqZiGpm8XIAZSI l1hz0BmiXl5i+9s5zBBhHYnJCxkhwtoSyxa+ZoawNSQ6v01khbAVJaZ0P2SHsK0lZvw6yAZh m0q8PvqREVnNAkaeVYwcpcUFObnpRoabGIGxdUyCzXEH495ez0OMAhyMSjy8CvtZw4VYE8uK K3MPMaoAtT7asPoCoxRLXn5eqpII7+FwtnAh3pTEyqrUovz4otKc1OJDjNIcLErivN6R/8KE BNITS1KzU1MLUotgskwcnFINjPPqnh+ceuzA7CD5HcXPkl9NflOaPbvAUNHaI9pt1z+H0x4b W3tua2xIXpUSwDD/fuG0YuGKTv8E1Skr55zMrfzUuK3HIdKrhnFKLqtGq8beuGNCGtonS81X 6Law992Y2DenbfaTDwdnrP4qxf552v65PO82Pn7A5ys5pYFLyX7dI98cNsYZU5VYijMSDbWY i4oTAQZPIby1AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/zkjdpR8eAnrKBbSOUzryx-AgNxs>
Subject: [mpls] YANG Data Model for MPLS LDP and mLDP
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 07 Apr 2016 13:15:13 -0000


Tuesday evening, at the joint TEAS/MPLS/PCE meeting, Rajiv presented the work he and his co-authors had done on a draft related to MPLS LDP and mLDP.  

The draft is at: https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang  (or at https://tools.ietf.org/html/draft-raza-mpls-ldp-mldp-yang).

The slides can be found at: https://www.ietf.org/proceedings/95/slides/slides-95-teas-14.pptx 

Afterwards, several people discussed the fact that there is something not-quite right about the definition of "peer" they would be using in their models.

Specifically, while the definitions shown are closely related to the definitions originally used in RFC 5036 (and RFC 3036 before that), they do not quite fit when considering LDP graceful restart (RFC 3478) - because the peer relationship survives the session relationship when using graceful restart - i.e. - the labels distributed by a peer remain valid for some time after the session ends. In fact, with LDP graceful restart, the intention is that the labels previously distributed by the peer would remain valid until explicitly withdrawn in the next (or a subsequent) session.

After some discussion, both after the meeting and earlier today, it seems likely this may be only one example of a case where the draft may not adequately address the implications of LDP graceful restart.

Eric Gray

Sent from my iPad