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

[Loa Andersson <[e-mail]>]

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