Subject: Re: [MPLS] LDP GR query

From: Ramesh Huliyar <[email-masked]>
Date: Tue, 17 Oct 2006 13:58:52 +0530 (IST)

Hello Lixing Wang,

As I had mentioned earlier, when there is a link failure (in this case, it is identified using BFD), the LDP session is removed and hence RTA and RTB will delete the lsp and reestablish the session. BFD can provide failure detection on any kind of  path between systems, including direct physical links, virtual  circuits, tunnels, MPLS LSPs, multihop routed paths, and   unidirectional links (so long as there is some return path, of  course.) So here even though the link failure is not occuring on the connected interface, BFD can identify the link failure.

Now, coming to the case where the 2 LSR are helper router (this is identified during LDP Session establishment where Reconnect timer is set to zero), then the moment LSR comes to know (usually by hello hold time expire) its neighbor is down, LDP session is brought down and it will not enter GR mode.

Regards
Ramesh Huliyar

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: Ramesh Huliyar <[email-masked]>; Yu Yi <[email-masked]>; [email-masked]
Sent: Tuesday, 17 October, 2006 12:43:04 PM
Subject: Re: [MPLS] LDP GR query

$B6uGr(B

DIV {
MARGIN:0px;}

Hi Ramesh,

Please see the below graph

If the link between the two LAN-SWITCH is down ,RTA and RTB will 

think the other side LSR restart,so these two LSR are all helper router.Thay 

will perform GR flow.Do you think it's good than the non-GR flow(the normal flow which 

session down).

I don't think so ,we should distinguish the LSR whether restart 

or not.If the LSR really restart,the GR flow is OK,but if not,I think,the LSR 

should delete the lsp and reestablish the session.

Lixing Wang

  ----- Original Message ----- 

  From: 

  Ramesh 

  Huliyar 

  To: [email-masked] ; Yu Yi ; [email-masked] 

  Sent: Tuesday, October 17, 2006 12:52 

PM

  Subject: Re: [MPLS] LDP GR query

  

  Hello 

  Lixing Wang,

What I understand from your problem statement is that, "if 

  there is a change in the lsp (deleted, next hop different) established 

  previous to the GR, it will delay the updation of lsp or basically 

  convergence". If the next hop for the FEC changes, label advertised from the 

  current next hop will be chosen (lable retention mode). Now to speed up the 

  convergence in case of deleted FEC, I think we should have a mechanism in LDP 

  control plane, where it can signal that the process of signalling FEC-to-Label 

  is completed. (Similar to the one in BGP, where we can signal the end of 

  UPDATE message)

Regards
Ramesh Huliyar

  ----- 

  Original Message ----
From: "[email-masked]" 

  <[email-masked]>
To: Yu Yi <[email-masked]>; Ramesh 

  Huliyar <[email-masked]>; [email-masked]
Sent: Tuesday, 

  17 October, 2006 8:13:00 AM
Subject: Re: [MPLS] LDP GR query

  DIV {
MARGIN:0px;}

  Hi Yu Yi,

  When two LSR fall into GR flow,then some LSP will be updated only after 

  GR,such as the lsp which should be deleted.

  I think GR flow will delay the updating of LSP,so it's better don't 

  perform GR flow in mistake.

  Lixing Wang

  

    ----- Original Message ----- 

    From: 

    Yu Yi 

    To: [email-masked] ; Ramesh 

    Huliyar ; [email-masked] 

    Sent: Tuesday, October 17, 2006 9:33 AM

    Subject: RE: [MPLS] LDP GR query

      I think for this scenario RTA 

    and RTB both consider the peer restart and perform the GR process. So RTA 

    will re-send all mapping and RTB also do so. and then after receiving 

    mapping all the LSP's stale flag are cleared and a perfect GR is 

    finished.

      The traffic won't be lost if 

    the forwarding plane is ok.  

    From: [email-masked] 

    [mailto:[email-masked]] 
Sent: 

    2006$BG/(B10$B7n(B17$BF|(B 8:50 AM
To: Ramesh Huliyar; Yi, 

    Yu (SUNP:1G11); [email-masked]
Subject: Re: [MPLS] LDP GR 

    query

    

    Hello,

    Then how about another 

    scenario?

    Another example that the LDP 

    session will be down when the LSR$B!G(Bs neighbor can$B!G(Bt send out 

    it$B!G(Bs packet, including hello packet or keepalive packet, if the 

    control plane of it$B!G(Bs neighbor is very busy or occurs some error 

    ,then the LDP session will 

    be down. In this case this two LSR will conclude that it$B!G(Bs 

    neighbor restart and the LSR will implement GR flow.

    I mean the LDP protocol has 

    some problem.In this case the link is ok,so the BFD can't be 

    used.

    When they re-establish the 

    session,they will perform GR flow together.

     

    

      ----- Original Message ----- 

      From: 

      Ramesh Huliyar 

      To: Yu Yi ; [email-masked] ; [email-masked] 

      Sent: Monday, October 16, 2006 8:36 PM

      Subject: Re: [MPLS] LDP GR query

      

      Hello,

I 

      feel that RTB LDP session will go down with RTA immidietly when the link 

      goes down. After the re-establishment of the LDP session, RTB will be 

      sending FT session TLV with Recovery Time 0. This will cause the RTA to 

      remove the stale FEC-to-label mapping. But until this happens, traffic 

      will be black holed.

To overcome this, other methods of identifying 

      link failures in RTA have to be employed, such as BFD, this will help RTA 

      to use alternate FEC-to-Label mapping, because link failure does not start 

      LDP GR but it will bring down LDP session in case of link level 

      LDP.

Regards
Ramesh Huliyar

      ----- 

      Original Message ----
From: Yu Yi <[email-masked]>
To: 

      [email-masked]; [email-masked]
Sent: Monday, 16 October, 

      2006 2:51:33 PM
Subject: RE: [MPLS] LDP GR query

      BODY {
MARGIN-TOP:25px;FONT-SIZE:10pt;MARGIN-LEFT:25px;COLOR:#000000;}
P.msoNormal {
MARGIN-TOP:0px;FONT-SIZE:10pt;MARGIN-LEFT:0px;COLOR:#ffffcc;}
LI.msoNormal {
MARGIN-TOP:0px;FONT-SIZE:10pt;MARGIN-LEFT:0px;COLOR:#ffffcc;}

        For your case it is fine. RTB should be in 

      normal case(normal session down)(no any GR flow) and delete all 

      LSPs which are established on the port.  After session up 

      again RTA will re-send the same label mapping which are sent before 

      session down. But as you know during this period the MPLS traffic are 

      lost. So this is not a complete GR case. 

        GR is applicable only if the forwarding 

      plane is fine.

      

      From: 

      [email-masked] [mailto:[email-masked]] 
Sent: 

      2006$BG/(B10$B7n(B16$BF|(B 3:07 PM
To: 

      [email-masked]
Subject: [MPLS] LDP GR 

      query

       

      Hi 

      I have query 

      related to LDP Graceful Restart. 

      RFC 3478 say

      When an LSR detects that its LDP session with a neighbor went 

      down,

         and the LSR knows that the neighbor is 

      capable of preserving its MPLS

         forwarding state across the restart (as 

      was indicated by the FT

         Session TLV in the Initialization message 

      received from the

         neighbor), the LSR retains the label-FEC 

      bindings received via that

         session (rather than discarding the 

      bindings), but marks them as

         "stale".

        RFC 3478 say that a router will implement GR flow when it 

      detect that its LDP session with a neighbor went down.

       But there are many cases which can cause the LDP 

      session went down ,and it$B!G(Bs neighbor don$B!G(Bt restart 

      actually.

      Consider this 

      scenario: 

       

      

      Suppose that the link between RTB and LAN-SWITCH is broken down, 

      then RTA will detects that its LDP session with RTB went down, then RTA 

      will implement GR flow, even the LDP session between RTA and RTB is 

      re-established after the link between RTB and LAN-SWITCH  

      is resumed. Because the FT TLV in the initialization message of RTB 

      don$B!G(Bt indicate that RTB whether reboot or not, so RTA is still 

      implement GR flow.

      Now RTA is in GR flow , but RTB isn$B!G(Bt in GR 

      flow.

      But what will happen if RTA is in GR flow , at the same time RTB 

      isn$B!G(Bt in GR flow? I think it will fall into 

      confusion.

      Another example that the LDP session will be down is that the LSR$B!G(Bs neighbor 

      can$B!G(Bt send out it$B!G(Bs packet, including hello packet or 

      keepalive packet, if the control plane of it$B!G(Bs neighbor is very 

      busy or occurs some error ,then the LDP session will be down. In this case the LSR will conclude 

      that it$B!G(Bs neighbor restart and the LSR will implement GR 

      flow.

      _______________________________________________
mpls mailing 

      list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Thu, 19 Oct 2006 08:46:37 +0800

$B6uGr(BHello Ramesh Huliyar,
You said,
Now, coming to the case where the 2 LSR are helper router (this is identified during LDP Session establishment where Reconnect timer is set to zero), then the moment LSR comes to know (usually by hello hold time expire) its neighbor is down, LDP session is brought down and it will not enter GR mode.

I think,the Reconnect timer is used for next restart,not used for this time
RFC 3478 

2. LDP Extension

Setting the FT Reconnect Timeout to 0 indicates that the sender of

   the TLV will not preserve its forwarding state across the restart,

   yet the sender supports the procedures, defined in Section 3.3,

   "Restart of LDP communication with a neighbor LSR" of this document,

   and therefore could take advantage if its neighbor to preserve its

   forwarding state across the restart.

If the LSR set the Reconnect Timeout to 0 and send this TLV to it's neighbour,it's neighbour will not help the LSR resume when the LSR restart next time.

Lixing wang

----- Original Message ----- 
  From: Ramesh Huliyar 
  To: [email-masked] ; Yu Yi ; [email-masked] 
  Sent: Tuesday, October 17, 2006 4:28 PM
  Subject: Re: [MPLS] LDP GR query

  Hello Lixing Wang,

  Regards
  Ramesh Huliyar