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

["Rajiv Asati (rajiva)" <[e-mail]>]

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.

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,
//




-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco







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

>Folks,
>
>
>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  <https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang%C2%A0> (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