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

Loa Andersson <loa@pi.nu> Sat, 09 April 2016 13:33 UTC

Return-Path: <loa@pi.nu>
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 1773212D6C7 for <mpls@ietfa.amsl.com>; Sat, 9 Apr 2016 06:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 VsnwdWcyxUIW for <mpls@ietfa.amsl.com>; Sat, 9 Apr 2016 06:33:49 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C571F12D689 for <mpls@ietf.org>; Sat, 9 Apr 2016 06:33:48 -0700 (PDT)
Received: from [10.10.2.96] (unknown [190.111.246.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 155001802AA8; Sat, 9 Apr 2016 15:33:45 +0200 (CEST)
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, Eric Gray <eric.gray@ericsson.com>, "mpls@ietf.org" <mpls@ietf.org>
References: <B18A1DD8-BA44-4ABE-B210-266D2589D83E@cisco.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <570904B2.6020708@pi.nu>
Date: Sat, 9 Apr 2016 21:33:38 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <B18A1DD8-BA44-4ABE-B210-266D2589D83E@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/9cnAJFFggZKLiPa99kKfrLyvElY>
Subject: Re: [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: Sat, 09 Apr 2016 13:33:51 -0000

Carlos and Eric,

On 2016-04-09 08:54, Rajiv Asati (rajiva) wrote:
> 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.
> //

I'm not entirely comfortable with this definition, the approach is
right, but a few words need to be changed. How about:

LDP Peers: A pair of LSRs that has established an LDP session between
themselves. The session has successfully progressed beyond its
initialization phase and the LSRs are exchanging label bindings or
are ready to to so.

As for Eric's comment, I think that for modeling purposes we could
invent something like a "parked LSP session".

/Loa
>
>
> 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.
>
> Thoughts?
>
>
>
>
>
>> 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”)::
>
>
> 2.6.1.1.  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,
> //
>
>
>
>