Subject: Re: [mpls] Comments on draft-aa-mpls-ldp-link-shut

From: Tarek Saad <[email-masked]>
Date: Sun, 17 Nov 2019 06:33:27 +0000

+ [email-masked]

From: Tarek Saad <[email-masked]>
Date: Sunday, November 17, 2019 at 2:32 PM
To: "[email-masked]" <[email-masked]>
Cc: Vishnu Pavan Beeram <[email-masked]>
Subject: Comments on draft-aa-mpls-ldp-link-shut

Hi co-authors,

Having gone through this draft, I have the following comments:

1.      Draft does not mention LDP session protection feature -- aka targeted LDP session to peer that handles the case of keeping LDP session UP in case of Hello Adj or link adjacency down. I see several vendors (at least Juniper/Cisco) who have support for this

2.      Section 2.5.5 or rfc5036 describes a hold timer that only after expiring will trigger the Hello adjacency deletion – and only after the last hello adjacency going down will trigger the LDP session to peer to go down.. i.e. the RFC 5036 does not dictate that LDP session to peer to go down immediately after link down as stated in draft-aa-mpls-ldp-link-shut section 3.

“
   An LSR
   maintains a hold timer with each Hello adjacency that it restarts
   when it receives a Hello that matches the adjacency.  If the timer
   expires without receipt of a matching Hello from the peer, LDP
   concludes that the peer no longer wishes to label switch using that
   label space for that link (or target, in the case of Targeted Hellos)
   or that the peer has failed.  The LSR then deletes the Hello
   adjacency.  When the last Hello adjacency for an LDP session is
   deleted, the LSR terminates the LDP session by sending a Notification
   message and closing the transport connection.
“
Given 2) above, do you still see ambiguity in handling link-down as described in RFC5036?

Regards,
Tarek

---

From: Anush Mohan <[email-masked]>
Date: Sun, 17 Nov 2019 07:17:38 +0000

Hi Tarek,

   Please find my replies inline.

Regards
Anush

From: Tarek Saad <[email-masked]>
Sent: Sunday, November 17, 2019 12:03 PM
To: [email-masked]
Cc: Vishnu Pavan Beeram <[email-masked]>; mpls <[email-masked]>
Subject: Re: Comments on draft-aa-mpls-ldp-link-shut

+ [email-masked]<mailto:[email-masked]>

From: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 17, 2019 at 2:32 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Subject: Comments on draft-aa-mpls-ldp-link-shut

Hi co-authors,

                     [Anush]: Agree, we need to mention this. It helps for the issue mentioned in the draft.

2.      Section 2.5.5 or rfc5036 describes a hold timer that only after expiring will trigger the Hello adjacency deletion - and only after the last hello adjacency going down will trigger the LDP session to peer to go down.. i.e. the RFC 5036 does not dictate that LDP session to peer to go down immediately after link down as stated in draft-aa-mpls-ldp-link-shut section 3.

"
   An LSR
"

              [Anush]: This particular section talks about procedures for maintaining LDP hello adjacencies, but doesn't explicitly
                       prevent any implementation from immediately tearing down LDP session, when the only LDP enabled link to a
                       peer goes down. Other places in the RFC leave it open to the implementation, to decide  when to terminate an LDP
                       session.

Regards,
Tarek

---

From: Anush Mohan <[email-masked]>
Date: Sun, 17 Nov 2019 07:24:27 +0000

Hi Tarek,

Regards
Anush

P.S:  Looks like my earlier reply got truncated.

Hi co-authors,

2.      Section 2.5.5 or rfc5036 describes a hold timer that only after expiring will trigger the Hello adjacency deletion - and only after the last hello adjacency going down will trigger the LDP session to peer to go down.. i.e. the RFC 5036 does not dictate that LDP session to peer to go down immediately after link down as stated in draft-aa-mpls-ldp-link-shut section 3