Subject: Re: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00

From: Huaimo Chen <[email-masked]>
Date: Mon, 16 Jun 2014 16:36:48 +0000

Hi Nobo,

    Thanks much for your suggestions and comments!

    It seems that 3.3 "Source Detects Failure" with some changes/enhancements works for protecting the primary ingress failure of a P2P LSP.

    3.3 "Source Detects Failure" may be updated as follows:

   Source Detects Failure or Source-Detect means that the source is
   responsible for detecting the failure of the primary ingress of an
   LSP quickly. The backup ingress is ready to import the traffic from the
   source into the backup LSP after the backup LSP is up.

   In normal operations, the source sends the traffic to the primary
   ingress.  When the source detects the failure of the primary ingress,
   it switches the traffic to the backup ingress, which delivers the
   traffic to the next hops of the primary ingress through the backup
   LSP, where the traffic is merged into the primary LSP.

   After the failure of the primary ingress happens and the backup 
   ingress determines the failure, the backup ingress sends/refreshes 
   PATH messages to the next hop node of the primary ingress of a P2P 
   LSP through the backup LSP as needed. The failure can be determined
   reliably through checking the Link State Database (LSDB).

Best Regards,
Huaimo
-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Sunday, June 15, 2014 6:03 PM
To: Huaimo Chen; Gregory Mirsky; Yimin Shen
Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; Toy, Mehmet; LEI LIU; [email-masked]; Ning So; lizhenbin 00147097; Quintin zhao; Richard Li
Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00

Hi Huaimo,

>     Thanks for your comments!

Thanks for responding!

Please see in-line.

> I believe 3.3 is the only one that works well. 3.1 can black hole the 
> traffic if the only failure is the link between source and ingress 
> (i.e. ingress node and link between ingress/backup being alive will 
> cause source to import the steam to backup, but backup will not import the stream to the P2MP tree).
> 
> [Huaimo] It seems that 3.3 "Source Detects Failure" works well for 
> protecting the primary ingress failure of a P2MP LSP. For a P2P LSP, 
> 3.3 seems not enough to provide protection for the primary ingress 
> failure of the LSP because we may need to send/refresh PATH messages 
> to the next hop node of the primary ingress of the P2P LSP through the 
> backup LSP when the primary ingress node fails.
> In the case that the link between the source and the primary ingress 
> fails,
> 3.1 " Backup and Source Detect Failure" may work well. The source may 
> locally distinguish between the failure of the primary ingress and 
> that of the link between the source and the primary ingress.  When the 
> source detects the failure of the link (but not the failure of the 
> primary ingress), it may continue to send the traffic to the primary 
> ingress via another link between the source and the primary ingress if there is one.

IMHO, what I think we should avoid is creating a solution that relies on two unsynchronized brains making a same decision. If we pursue this, we create a complex problem of how do we ensure two brains make the same decision or how do we synchronize the decision by two brains. Additionally, we should avoid creating a solution that relies on an LSR being able to deterministically differentiate between a link failure and a node failure, this is also another complex problem. If we can come up with a solution that avoids both of these problems, then the resulting solution should be much more stable (i.e. able to produce deterministic results).

Above, you said (3.1 " Backup and Source Detect Failure" may work well). Sure it might be easier from signaling perspective, but it's not easy from failure detection perspective (i.e. has two brain problem).

> > 5. Remove the detection modes that do not work from the draft.
> >   This is a challenging problem for us to have a perfect solution.
> > More discussions and comments may be needed.
> 
> Theoretically, all 4 scenarios (3.1-3.4) are interesting. However, 
> first question that I have (and perhaps should first get discussed) is 
> do we  _need to_ try to support all 4 scenarios and why. One possible 
> outcome is that folks are sufficiently happy with 3.3, and there are 
> no further problems to solve. If folks do indeed need other 
> solution(s) besides 3.3, then I agree that we should discuss some possibilities.
> 
> [Huaimo] 3.3 works for protecting the primary ingress failure of a P2MP LSP.
> We may just need to have a solution that works well for protecting the 
> primary ingress failure of a P2P LSP.

Perhaps an alternative way to approach this problem is to figure out how to do what you are doing with P2MP for P2P, and only use 3.3 as the detection.

Perhaps another way to approach this problem is to figure out how the LSP from primary ingress and corresponding LSP from backup ingress can get associated so that the two LSPs are always active (i.e. backup ingress can takeover anytime) but share bandwidth reservation (i.e. no bandwidth resources wasted). This approach also has a benefit of backup ingress being able to run continuity check on the LSP before the takeover, so that backup ingress knows that backup LSP is healthy when it takes over. It would be a pity for the backup ingress to take over but traffic black holes because forwarding state on the backup ingress or merge-point LSR or elsewhere is bad.

> >    Is it acceptable to have a detection mode that works well in most 
> > of cases and can recover in other corner cases in a short time?
> 
> Is node failure more common than link failure? :) And how "short" are 
> we talking about? :)
> 
> Perhaps better to check with operators/customers who are asking for this?
> 
> [Huaimo] "short" should mean in ms not in seconds.

Thanks for the information.

> 
> I'd be happy to chip in to aid in tackling the problems, but 
> personally I'd like to know that we do indeed need to solve them.
> 
> [Huaimo] Thanks much for your willing to help!

Based on names on this email thread, and list of authors/contributors in the document, clearly there's an interest to solve this problem. I am also supportive of solving this problem. However, I'm just not convinced that we have come up with the best way to solve this problem [yet]. But I'm just one person.

In my VERY humble opinion, it might be beneficial to articulate the limitations with proposals in this draft and ask for comments/feedback from the community with open mind to potentially fresh ideas.

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 17 Jun 2014 17:33:25 +0000

Hi Huaimo,

My original intent was to highlight the limitations with detections proposed, and I believe that has been accomplished. Thank you for putting up with my effort to do so!

>    reliably through checking the Link State Database (LSDB).

Unfortunately, I don't think this additional text solves the problem. The backup ingress needs to know the health of the link between the source and primary ingress.  That particular link could very well be outside the TE topology (i.e. link is CE to PE[primary ingress]) in which case you do not have the trigger for the backup ingress to send the necessary PATH message. With LSDB trigger approach, you could be limiting the scope of the solution significantly.

LSP "association" approach (as roughly eluded in my earlier comment) still rings a nicer sound, but I think, at this point, this document needs RSVP signaling experts to provide comments and possibly alternative ideas.

Thanks!

-Nobo

> From: Huaimo Chen [mailto:[email-masked]]
> Sent: Monday, June 16, 2014 12:37 PM
> To: Nobo Akiya (nobo); Gregory Mirsky; Yimin Shen; [email-masked]
> Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; Toy,
> Mehmet; LEI LIU; [email-masked]; lizhenbin 00147097; Quintin zhao;
> Richard Li; mengnan 58534; [email-masked]
>     It seems that 3.3 "Source Detects Failure" with some
> changes/enhancements works for protecting the primary ingress failure of a
> P2P LSP.
> 
> Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; Toy,
> Mehmet; LEI LIU; [email-masked]; Ning So; lizhenbin 00147097; Quintin
> zhao; Richard Li
> IMHO, what I think we should avoid is creating a solution that relies on two
> unsynchronized brains making a same decision. If we pursue this, we create
> a complex problem of how do we ensure two brains make the same
> decision or how do we synchronize the decision by two brains. Additionally,
> we should avoid creating a solution that relies on an LSR being able to
> deterministically differentiate between a link failure and a node failure,
> this is also another complex problem. If we can come up with a solution that
> avoids both of these problems, then the resulting solution should be much
> more stable (i.e. able to produce deterministic results).
> 
> Above, you said (3.1 " Backup and Source Detect Failure" may work well).
> Sure it might be easier from signaling perspective, but it's not easy from
> failure detection perspective (i.e. has two brain problem).
> 
> Perhaps an alternative way to approach this problem is to figure out how to
> do what you are doing with P2MP for P2P, and only use 3.3 as the detection.
> 
> Perhaps another way to approach this problem is to figure out how the LSP
> from primary ingress and corresponding LSP from backup ingress can get
> associated so that the two LSPs are always active (i.e. backup ingress can
> takeover anytime) but share bandwidth reservation (i.e. no bandwidth
> resources wasted). This approach also has a benefit of backup ingress being
> able to run continuity check on the LSP before the takeover, so that backup
> ingress knows that backup LSP is healthy when it takes over. It would be a
> pity for the backup ingress to take over but traffic black holes because
> forwarding state on the backup ingress or merge-point LSR or elsewhere is
> bad.
> 
> Based on names on this email thread, and list of authors/contributors in the
> document, clearly there's an interest to solve this problem. I am also
> supportive of solving this problem. However, I'm just not convinced that we
> have come up with the best way to solve this problem [yet]. But I'm just one
> person.
> 
> In my VERY humble opinion, it might be beneficial to articulate the
> limitations with proposals in this draft and ask for comments/feedback from
> the community with open mind to potentially fresh ideas.
> 
> Thanks!
> 
> -Nobo

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 29 Jun 2014 16:22:58 +0000

Hi Nobo,

    Thanks much for your comments and suggestions!
    My answers/explanations are inline below.

Best Regards,
Huaimo
-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 1:33 PM
To: Huaimo Chen; Gregory Mirsky; Yimin Shen; [email-masked]
Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; Toy, Mehmet; LEI LIU; [email-masked]; lizhenbin 00147097; Quintin zhao; Richard Li; mengnan 58534; [email-masked]
Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00

Hi Huaimo,

[Huaimo] We will continue putting our effort on this if needed.

[Huaimo] The text will be revised. A method for reliably detecting the failure of the primary ingress before the PATH message expires (at the next hop nodes of the primary ingress) is needed. Thus, after the primary ingress fails, the backup ingress can use this method to detect the failure, and the primary LSP will still be alive since the PATH message is refreshed before the next hop nodes remove the states for the primary LSP. 
It seems that the critical point is to make sure that the method to be used can reliably detect the failure of the primary ingress within a given time (seconds). 
After the primary ingress fails, it will not be reachable after routing convergence. It looks like checking whether the primary ingress is reachable is a possible method. 
Before the primary ingress fails, it has some links to other nodes such the link to the backup ingress node and the links to the next hop nodes of the primary ingress. These links are recorded in the Link State Database (LSDB). After the primary ingress fails, these links will disappear from the Link State Database (LSDB) after IGP converges. Thus it seems that checking whether there is not any link to the primary ingress in LSDB is another possible method. Whether the link between the source and the primary ingress is outside of the TE topology may not affect the method. After the primary ingress fails, all the links to it will disappear (i.e., there will be no link to it). 

[Huaimo] We will keep this in our mind.

Thanks!

-Nobo

> Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, 
> Fengman'; Toy, Mehmet; LEI LIU; [email-masked]; lizhenbin 
> 00147097; Quintin zhao; Richard Li; mengnan 58534; 
> [email-masked]
> changes/enhancements works for protecting the primary ingress failure 
> of a P2P LSP.
> 
> Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, 
> Fengman'; Toy, Mehmet; LEI LIU; [email-masked]; Ning So; lizhenbin 
> 00147097; Quintin zhao; Richard Li
> > I believe 3.3 is the only one that works well. 3.1 can black hole 
> > the traffic if the only failure is the link between source and 
> > ingress (i.e. ingress node and link between ingress/backup being 
> > alive will cause source to import the steam to backup, but backup 
> > will not import
> the stream to the P2MP tree).
> >
> > to the next hop node of the primary ingress of the P2P LSP through 
> > the backup LSP when the primary ingress node fails.
> > 3.1 " Backup and Source Detect Failure" may work well. The source 
> > may locally distinguish between the failure of the primary ingress 
> > and that of the link between the source and the primary ingress.  
> > When the source detects the failure of the link (but not the failure 
> > of the primary ingress), it may continue to send the traffic to the 
> > primary ingress via another link between the source and the primary 
> > ingress if
> there is one.
> 
> IMHO, what I think we should avoid is creating a solution that relies 
> on two unsynchronized brains making a same decision. If we pursue 
> this, we create a complex problem of how do we ensure two brains make 
> the same decision or how do we synchronize the decision by two brains. 
> Additionally, we should avoid creating a solution that relies on an 
> LSR being able to deterministically differentiate between a link 
> failure and a node failure, this is also another complex problem. If 
> we can come up with a solution that avoids both of these problems, 
> then the resulting solution should be much more stable (i.e. able to produce deterministic results).
> 
> Sure it might be easier from signaling perspective, but it's not easy 
> from failure detection perspective (i.e. has two brain problem).
> 
> > first question that I have (and perhaps should first get discussed) 
> > is do we  _need to_ try to support all 4 scenarios and why. One 
> > possible outcome is that folks are sufficiently happy with 3.3, and 
> > there are no further problems to solve. If folks do indeed need 
> > other
> > [Huaimo] 3.3 works for protecting the primary ingress failure of a 
> > P2MP
> LSP.
> > We may just need to have a solution that works well for protecting 
> > the primary ingress failure of a P2P LSP.
> 
> Perhaps an alternative way to approach this problem is to figure out 
> how to do what you are doing with P2MP for P2P, and only use 3.3 as the detection.
> 
> Perhaps another way to approach this problem is to figure out how the 
> LSP from primary ingress and corresponding LSP from backup ingress can 
> get associated so that the two LSPs are always active (i.e. backup 
> ingress can takeover anytime) but share bandwidth reservation (i.e. no 
> bandwidth resources wasted). This approach also has a benefit of 
> backup ingress being able to run continuity check on the LSP before 
> the takeover, so that backup ingress knows that backup LSP is healthy 
> when it takes over. It would be a pity for the backup ingress to take 
> over but traffic black holes because forwarding state on the backup 
> ingress or merge-point LSR or elsewhere is bad.
> 
> > >    Is it acceptable to have a detection mode that works well in 
> > > most of cases and can recover in other corner cases in a short time?
> >
> > Is node failure more common than link failure? :) And how "short" 
> > are we talking about? :)
> >
> Based on names on this email thread, and list of authors/contributors 
> in the document, clearly there's an interest to solve this problem. I 
> am also supportive of solving this problem. However, I'm just not 
> convinced that we have come up with the best way to solve this problem 
> [yet]. But I'm just one person.
> 
> limitations with proposals in this draft and ask for comments/feedback 
> from the community with open mind to potentially fresh ideas.
> 
> Thanks!
> 
> -Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 29 Jun 2014 20:57:06 +0000

Hi Huaimo,

Thank you for continued discussion!

> Unfortunately, I don't think this additional text solves the problem. The
> backup ingress needs to know the health of the link between the source
> and primary ingress.  That particular link could very well be outside the TE
> topology (i.e. link is CE to PE[primary ingress]) in which case you do not
> have the trigger for the backup ingress to send the necessary PATH message.
> With LSDB trigger approach, you could be limiting the scope of the solution
> significantly.
> 
> [Huaimo] The text will be revised. A method for reliably detecting the
> failure of the primary ingress before the PATH message expires (at the next
> hop nodes of the primary ingress) is needed. Thus, after the primary ingress
> fails, the backup ingress can use this method to detect the failure, and the
> primary LSP will still be alive since the PATH message is refreshed before
> the next hop nodes remove the states for the primary LSP.
> It seems that the critical point is to make sure that the method to be used
> can reliably detect the failure of the primary ingress within a given time
> (seconds).
> After the primary ingress fails, it will not be reachable after routing
> convergence. It looks like checking whether the primary ingress is reachable
> is a possible method.
> Before the primary ingress fails, it has some links to other nodes such the
> link to the backup ingress node and the links to the next hop nodes of the
> primary ingress. These links are recorded in the Link State Database (LSDB).
> After the primary ingress fails, these links will disappear from the Link State
> Database (LSDB) after IGP converges. Thus it seems that checking whether
> there is not any link to the primary ingress in LSDB is another possible
> method. Whether the link between the source and the primary ingress is
> outside of the TE topology may not affect the method. After the primary
> ingress fails, all the links to it will disappear (i.e., there will be no link to it).
> 
> LSP "association" approach (as roughly eluded in my earlier comment) still
> rings a nicer sound, but I think, at this point, this document needs RSVP
> signaling experts to provide comments and possibly alternative ideas.

I'm not very keen on monitoring multiple links owned by the primary ingress by the backup ingress, less the better & one is the best, ideally. Perhaps this can be accomplished by monitoring just one IP address, as you eluded in the first half in above. I.E. the disappearance of the primary ingress node from the LSDB is the trigger for the backup ingress to send the PATH message to take over the LSP, for (3.1.  Backup and Source Detect Failure) and (3.2.  Backup Detects Failure). Question is, which IP address of the primary ingress should be monitored by the backup ingress? Is it the TE router-ID of the primary ingress or the IP address described in the Ingress IPv4/IPv6 Address Subobject? Assuming that the monitored IP address of the primary ingress by the backup ingress is a persistent address (i.e. loopback address and not address of a link), then I agree, it appears clearly described IGP convergence based trigger procedures can produce sufficient determinism.

Thanks!

-Nobo