Re: [mpls] YANG Data Model for MPLS LDP and mLDP

"Rajiv Asati (rajiva)" <> Sat, 09 April 2016 00:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6571212D0C7 for <>; Fri, 8 Apr 2016 17:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oc-K7-Q3d3QC for <>; Fri, 8 Apr 2016 17:54:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C30812D0C0 for <>; Fri, 8 Apr 2016 17:54:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5470; q=dns/txt; s=iport; t=1460163251; x=1461372851; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fWWs9UslSlakgzddSPPgDsq9WOJBfl10l4s0aAmuCrE=; b=dQGAiT2Dk4wAZ8Qj5U6TvhX9yt6vB0JqxfPgPmiG5qAMLLXHhl9Gb6vp uF4VsZ1kYyICyl+yHJ8pHrkd507Obbk46F0QznB/het2K9DyyVoGeA5GM MopPCSpaPBHX/prUtOwhtZzIdRByllvlGuel4446/t4tN9KWu6BrP1R5D A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="89855070"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2016 00:54:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u390sA7F005851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Apr 2016 00:54:10 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 19:54:09 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 19:54:09 -0500
From: "Rajiv Asati (rajiva)" <>
To: Eric Gray <>, "" <>
Thread-Topic: [mpls] YANG Data Model for MPLS LDP and mLDP
Thread-Index: AQHRkfpSY9I+d44DRkmey74svOJp4A==
Date: Sat, 09 Apr 2016 00:54:09 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] YANG Data Model for MPLS LDP and mLDP
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Apr 2016 00:54:14 -0000

Hi Eric,

Thanks for pointing out this exception. This certainly is worth a bit of discussion (even though we may well be splitting hair). 

It might be reasonable to say that the “peering” relationship does NOT survive during graceful restart, even though label bindings don’t get deleted upto the the grace period. The reason is that after the session is closed, neither LSRs could send any messages (KeepAlive, Address/Withdraw, Notification, Label Mapping/Request/Withdraw/Abort/Release etc.) as expected/required during the “peering” relationship.

With that in mind, the below definition seems reasonably accurate from modeling point of view:

Peer: An LDP session which has successfully progressed beyond its initialization
phase and is ready for binding exchange.

Having said the above, it does NOT hurt to add a note right below the definition. Something like: During Graceful Restart {RFC3478), LSRs must hold on to the label bindings upto the grace period even after the “session” is deleted.


> Specifically, while the definitions shown are closely related to the definitions originally used in RFC 5036 (and
> RFC 3036 before that),

I agree. However, the point was that rfc5036 loosely used these “neighbors” and “peers" and mixed their usage. Including 4 examples below (where 1st two should have used “peers” instead of “neighbors”, and last 2 should have use “neighbors” instead of “peers”)::  Independent Label Distribution Control

When using independent LSP control, each LSR may advertise label
   mappings to its neighbors at any time it desires.  For example, when
2.6.2.  Label Retention Mode

   binding for a FEC learned from a neighbor that is not its next hop
   for the FEC.

2.2.2.  LDP Identifiers

   A situation where an LSR would need to advertise more than one label
   space to a peer 

2.2.1.  Label Spaces

         Note that the use of a per interface label space only makes
         sense when the LDP peers are "directly connected" over an interface,

Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: mpls <> on behalf of Eric Gray <>
Date: Thursday, April 7, 2016 at 9:15 AM
To: "" <>
Subject: [mpls] YANG Data Model for MPLS LDP and mLDP

>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:  <> (or
> at
>The slides can be found at: 
>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