Subject: [mpls] Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Mar 2010 07:41:05 -0700

Dear Authors,
I'd like to continue our discussion of the proposals where we've stopped
yesterday. I do believe that the most important to these documents is
proposed change in handling TTL. Currently, as you've mentioned in the first
presentation, TTL of the outmost LSE must be decremented according to RFC
3032 and 3443. Perhaps it would be proper to discuss proposal that will
update accepted TTL handling and serves as foundation for your work. I have
to admit that it is not clear in what cases the rules of TTL handling should
be changed by your proposals.
And when looking at the problem you address in your work I see that as
implementation of "drop-and-continue" mode of ACH. I believe that the same
effect (send single OAM message that will be processed by all LSRs of the
LSP) can be currently supported with ACH of p2mp LSP.

Kind regards,
Greg Mirsky

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 13:36:07 -0400

Greg,

Section 4 'Packet processing' of draft-kini-mpls-lsp-fast-alert-00 includes in detail TTL handling. Specifically section 4.2 describes in detail how to process a received packet. More specifically the sentence starting with "In addition, if FLA bit is set" describes the difference in the processing. We can add more clarifying text.

Visualising it as drop-and-continue of ACH is correct as has been clearly illustrated in our presentation.

The GAL processing for P2MP LSPs only alerts the leaf nodes. It does not alert transit nodes.

Thanks

- Sri

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 24, 2010 7:41 AM
To: Autumn Liu; Sriganesh Kini; [email-masked]
Subject: Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

Dear Authors,
I'd like to continue our discussion of the proposals where we've stopped yesterday. I do believe that the most important to these documents is proposed change in handling TTL. Currently, as you've mentioned in the first presentation, TTL of the outmost LSE must be decremented according to RFC 3032 and 3443. Perhaps it would be proper to discuss proposal that will update accepted TTL handling and serves as foundation for your work. I have to admit that it is not clear in what cases the rules of TTL handling should be changed by your proposals.
And when looking at the problem you address in your work I see that as implementation of "drop-and-continue" mode of ACH. I believe that the same effect (send single OAM message that will be processed by all LSRs of the LSP) can be currently supported with ACH of p2mp LSP.

Kind regards,
Greg Mirsky

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Mar 2010 10:45:53 -0700

Dear Sri,
thank you for so expedient reply to my questions.
I think that change to TTL processing needs to be more generic than presence
of FLA bit. But that is my personal view.
In regard to p2mp ACH, I agree that a transit node would not process the
GAL, as the same true in p2p. But would like to point that there's nothing
that precludes operator to make each ring node a bud on a p2mp LSP (bud -
branch and leaf in one). Then we can support "drop-and-continue".

Regards,
Greg

On Wed, Mar 24, 2010 at 10:36 AM, Sriganesh Kini <
[email-masked]> wrote:

>  Greg,
>
> Section 4 'Packet processing' of draft-kini-mpls-lsp-fast-alert-00 includes
> in detail TTL handling. Specifically section 4.2 describes in detail how to
> process a received packet. More specifically the sentence starting with "In
> addition, if FLA bit is set" describes the difference in the processing. We
> can add more clarifying text.
>
>  ------------------------------
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, March 24, 2010 7:41 AM
> *To:* Autumn Liu; Sriganesh Kini; [email-masked]
> *Subject:* Comments to A fast LSP-alert Mechanism and Efficient FRR using
> Facility backup in ring topology
>
> Dear Authors,

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 14:42:46 -0400

You are welcome Greg.

Note that decrementing TTL for a packet that is to be forwarded is standard MPLS TTL processing. In our case we are use the TTL of GAL for this purpose. In that sense this is not any different from MPLS TTL processing. The FLA bit is merely to indicate that packet is to be forwarded in addition to being delivered locally. Since packet has to be forwarded on the LSP, the ILM operations of the LSP should dictate outgoing label. Since the next LSR must be alerted the TTL of the LSP label must be 1.

The main point being that FLA-bit is triggering the drop-and-continue behavior. TTL processing is in-line with MPLS.

For an operator to change every P2P LSP that has been well deployed into a P2MP LSP just to deliver alert along the entire LSP is in our opinion unacceptable. Even for P2MP LSPs to be supplanted with bud LSRs to every transit LSR (for delivering alerts) has several issues
1. Protocol complexity since new leaves (that need just the alerts) have to be defined - may result in new types of sub-LSPs being defined
2. The scope of the alert is not easy to determine. What if one application needs to alert 2 LSRs along the LSP but another wants to alert all LSRs along the LSP?
3. All of the above adds unnecessary development complexity
4. Most importantly adds operational confusion since there are now different leaves - some for data and others for alerts (!)

All these would make such an approach infeasible.

- Sri

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 24, 2010 10:46 AM
To: Sriganesh Kini
Cc: Autumn Liu; [email-masked]
Subject: Re: Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

Dear Sri,
thank you for so expedient reply to my questions.
I think that change to TTL processing needs to be more generic than presence of FLA bit. But that is my personal view.
In regard to p2mp ACH, I agree that a transit node would not process the GAL, as the same true in p2p. But would like to point that there's nothing that precludes operator to make each ring node a bud on a p2mp LSP (bud - branch and leaf in one). Then we can support "drop-and-continue".

Regards,
Greg

On Wed, Mar 24, 2010 at 10:36 AM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Thanks

- Sri

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 24, 2010 7:41 AM
To: Autumn Liu; Sriganesh Kini; [email-masked]<mailto:[email-masked]>
Subject: Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

Dear Authors,

Kind regards,
Greg Mirsky

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Mar 2010 13:04:20 -0700

Dear Sri,
I'd be interested if you can refer to a particular RFC 3443 LSP model
whereas TTL of outer LSP would not be decremented.
And I'd like to note that I haven't suggested changing service p2p LSPs into
p2mp. One doesn't need DCN to follow each and every LSP in the network. A
DCN must have sufficient connectivity, that's all.

Regards,
Greg

On Wed, Mar 24, 2010 at 11:42 AM, Sriganesh Kini <
[email-masked]> wrote:

>  You are welcome Greg.
>
> Note that decrementing TTL for a packet that is to be forwarded is standard
> MPLS TTL processing. In our case we are use the TTL of GAL for this purpose.
> In that sense this is not any different from MPLS TTL processing. The FLA
> bit is merely to indicate that packet is to be forwarded in addition to
> being delivered locally. Since packet has to be forwarded on the LSP, the
> ILM operations of the LSP should dictate outgoing label. Since the next LSR
> must be alerted the TTL of the LSP label must be 1.
>
> The main point being that FLA-bit is triggering the drop-and-continue
> behavior. TTL processing is in-line with MPLS.
>
> For an operator to change every P2P LSP that has been well deployed into a
> P2MP LSP just to deliver alert along the entire LSP is in our opinion
> unacceptable. Even for P2MP LSPs to be supplanted with bud LSRs to every
> transit LSR (for delivering alerts) has several issues
> 1. Protocol complexity since new leaves (that need just the alerts) have to
> be defined - may result in new types of sub-LSPs being defined
> 2. The scope of the alert is not easy to determine. What if one application
> needs to alert 2 LSRs along the LSP but another wants to alert all LSRs
> along the LSP?
> 4. Most importantly adds operational confusion since there are now
> different leaves - some for data and others for alerts (!)
>
> *Sent:* Wednesday, March 24, 2010 10:46 AM
> *To:* Sriganesh Kini
> *Cc:* Autumn Liu; [email-masked]
> *Subject:* Re: Comments to A fast LSP-alert Mechanism and Efficient FRR
> using Facility backup in ring topology
>
> Dear Sri,
> I think that change to TTL processing needs to be more generic than
> presence of FLA bit. But that is my personal view.
>> Section 4 'Packet processing' of
>> draft-kini-mpls-lsp-fast-alert-00 includes in detail TTL handling.
>> Specifically section 4.2 describes in detail how to process a received
>> packet. More specifically the sentence starting with "In addition, if FLA
>> bit is set" describes the difference in the processing. We can add more
>> clarifying text.
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 24 Mar 2010 13:27:24 -0700

> For an operator to change every P2P LSP that has been well deployed into a P2MP LSP just to deliver alert along the entire LSP is in our opinion unacceptable. Even for P2MP LSPs to be supplanted wi…

I think it is important to point out the configuration in this case. You have a "ring" topology with static LSPs connecting each "segment" of this ring.   The point I made yesterday was that if you simply run BFD over each link between nodes to detect the fail-over (and trigger the FRR switch), I think you get the same effect except without having to modify 3 protocols (which Greg points out below).  Speaking as an operator, if I were to deploy this, I totally agree with Greg's point #4 on operational confusion.  

	--Tom

> On Wed, Mar 24, 2010 at 10:36 AM, Sriganesh Kini <[email-masked]> wrote:
> Greg,
>  
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 18:50:44 -0400

Thomas, point#4 that you attributed to Greg was made by me :-)

It was to explain why using P2MP to deliver alert's has additional complexity. Seems you agree ;-)

If static is used instead of signaled, then the RSVP-TE extensions are not applicable.

- Sri

________________________________
From: Thomas Nadeau [mailto:[email-masked]]
Sent: Wednesday, March 24, 2010 1:27 PM
To: Sriganesh Kini
Cc: Greg Mirsky; [email-masked]; Autumn Liu
Subject: Re: [mpls] Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

You are welcome Greg.

--Tom

- Sri

Cc: Autumn Liu; [email-masked]<mailto:[email-masked]>

Dear Sri,

Regards,
Greg

Thanks

- Sri

Dear Authors,

Kind regards,
Greg Mirsky

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 18:58:12 -0400

Greg,

Outer label (LSP label) TTL decrement (and expiry) is delivering the alert message to the local LSR (If it helps any view this as the 'drop' part of the 'drop-and-continue').

How would your suggestion work for P2P LSPs? Pls explain without referring to P2MP LSPs.

- Sri

Sent: Wednesday, March 24, 2010 1:04 PM

Dear Sri,
I'd be interested if you can refer to a particular RFC 3443 LSP model whereas TTL of outer LSP would not be decremented.
And I'd like to note that I haven't suggested changing service p2p LSPs into p2mp. One doesn't need DCN to follow each and every LSP in the network. A DCN must have sufficient connectivity, that's all.

Regards,
Greg

On Wed, Mar 24, 2010 at 11:42 AM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
You are welcome Greg.

- Sri

Dear Sri,

Regards,
Greg

Thanks

- Sri

Dear Authors,

Kind regards,
Greg Mirsky

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Mar 2010 16:32:51 -0700

Dear Sri,
I hope that by now you can agree that the proposal significantly modifies,
put it lightly, RFC 3443.
I don't understand why you have so strong animosity towards p2mp LSP-based
approach. I believe that ACH over p2mp LSP is practical and efficient in
certain topologies.
But if you insist on using only p2p model, then I'll repeat my earlier
suggestion to use  Link level GAL and FLA bit. If FLA bit is set then it is
processed as "drop-and-continue".

Regards,
Greg

On Wed, Mar 24, 2010 at 3:58 PM, Sriganesh Kini <[email-masked]
> wrote:

>  Greg,
>
> Outer label (LSP label) TTL decrement (and expiry) is delivering the alert
> message to the local LSR (If it helps any view this as the 'drop' part of
> the 'drop-and-continue').
>
> *Sent:* Wednesday, March 24, 2010 1:04 PM
>
> *To:* Sriganesh Kini
> And I'd like to note that I haven't suggested changing service p2p LSPs
> into p2mp. One doesn't need DCN to follow each and every LSP in the network.
> A DCN must have sufficient connectivity, that's all.
>
> Regards,
> Greg
>
>> Note that decrementing TTL for a packet that is to be forwarded is
>> standard MPLS TTL processing. In our case we are use the TTL of GAL for this
>> purpose. In that sense this is not any different from MPLS TTL processing.
>> The FLA bit is merely to indicate that packet is to be forwarded in addition
>> to being delivered locally. Since packet has to be forwarded on the LSP, the
>> 1. Protocol complexity since new leaves (that need just the alerts) have
>> to be defined - may result in new types of sub-LSPs being defined
>> 2. The scope of the alert is not easy to determine. What if one
>> application needs to alert 2 LSRs along the LSP but another wants to alert
>> all LSRs along the LSP?
>>> *Subject:* Comments to A fast LSP-alert Mechanism and Efficient FRR

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 20:22:17 -0400

Greg,

The modifications in the proposal are to do the drop-and-continue. TTL operations are all in line with the spirit of RFC4443.

No animosity towards p2mp. Just a case of applicability of any solution. Note that our proposed solution is applicable to P2MP too. If you could have explained in detail how your proposal works it may have been useful.

Link level GAL with FLA bit does not work, because the LSP is not identified. You cannot 'continue'.

- Sri

Sent: Wednesday, March 24, 2010 4:33 PM

Dear Sri,
I hope that by now you can agree that the proposal significantly modifies, put it lightly, RFC 3443.
I don't understand why you have so strong animosity towards p2mp LSP-based approach. I believe that ACH over p2mp LSP is practical and efficient in certain topologies.
But if you insist on using only p2p model, then I'll repeat my earlier suggestion to use  Link level GAL and FLA bit. If FLA bit is set then it is processed as "drop-and-continue".

Regards,
Greg

On Wed, Mar 24, 2010 at 3:58 PM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

- Sri

To: Sriganesh Kini

Dear Sri,

Regards,
Greg

- Sri

Dear Sri,

Regards,
Greg

Thanks

- Sri

Dear Authors,

Kind regards,
Greg Mirsky

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 24 Mar 2010 17:21:34 -0700

Tom was very well elucidated my thoughts.

I still fail to see the motivation. The changes being proposed are very scary to put it mildly.

Nitin

On 3/24/10 1:27 PM, "Thomas Nadeau" <[email-masked]> wrote:

You are welcome Greg.

--Tom

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 20:28:04 -0400

typo : RFC4443 should be RFC3443

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Wednesday, March 24, 2010 5:22 PM
To: Greg Mirsky
Cc: [email-masked]; Autumn Liu
Subject: Re: [mpls] Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

Greg,

- Sri

Dear Sri,

Regards,
Greg

- Sri

To: Sriganesh Kini

Dear Sri,

Regards,
Greg

- Sri

Dear Sri,

Regards,
Greg

Thanks

- Sri

Dear Authors,

Kind regards,
Greg Mirsky

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 20:33:10 -0400

See earlier reply to Tom's mail.

Motivation - see an application of this in draft-kini-mpls-ring-frr-facility-backup-00  

If you can elucidate what part is scary and why, it will be useful.

- Sri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
Sent: Wednesday, March 24, 2010 5:22 PM
To: Thomas Nadeau; Sriganesh Kini
Cc: [email-masked]; Autumn Liu
Subject: Re: [mpls] Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

Nitin

You are welcome Greg.

--Tom

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Mar 2010 17:45:16 -0700

Dear Sri,
since we're talking about specific topology, the ring topology, a possible
solution should use characteristics of that topology to be optimal, more
efficient than in general case. That is why, in my view, for the ring
topology it is beneficial to have Link OAM rather than LSP or TCM. And it
seems logical to report link failure to all ring nodes through link level
mechanism.
Please let me know if you'd like more details.

Regards,
Greg

On Wed, Mar 24, 2010 at 5:22 PM, Sriganesh Kini <[email-masked]

>  Greg,
>
> The modifications in the proposal are to do the drop-and-continue. TTL
> operations are all in line with the spirit of RFC4443.
>
> No animosity towards p2mp. Just a case of applicability of any solution.
> Note that our proposed solution is applicable to P2MP too. If you could have
> explained in detail how your proposal works it may have been useful.
>
> *Sent:* Wednesday, March 24, 2010 4:33 PM
>
> *To:* Sriganesh Kini
> On Wed, Mar 24, 2010 at 3:58 PM, Sriganesh Kini <
>>> For an operator to change every P2P LSP that has been well deployed into
>>> a P2MP LSP just to deliver alert along the entire LSP is in our opinion
>>>> Visualising it as drop-and-continue of ACH is correct as has
>>>> been clearly illustrated in our presentation.
>>>>

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 20:49:40 -0400

Greg,

draft-kini-mpls-lsp-fast-alert is not limited to ring topology

draft-kini-mpls-ring-frr-facility-backup uses ring topology for illustration clarity. See section 6 for the applicability to generic topologies.

- Sri

Sent: Wednesday, March 24, 2010 5:45 PM

Dear Sri,
since we're talking about specific topology, the ring topology, a possible solution should use characteristics of that topology to be optimal, more efficient than in general case. That is why, in my view, for the ring topology it is beneficial to have Link OAM rather than LSP or TCM. And it seems logical to report link failure to all ring nodes through link level mechanism.
Please let me know if you'd like more details.

Regards,
Greg

On Wed, Mar 24, 2010 at 5:22 PM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

- Sri

To: Sriganesh Kini

Dear Sri,

Regards,
Greg

- Sri

To: Sriganesh Kini

Dear Sri,

Regards,
Greg

- Sri

Dear Sri,

Regards,
Greg

Thanks

- Sri

Dear Authors,

Kind regards,
Greg Mirsky

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Mar 2010 17:51:22 -0700

Dear Sri,
you wrote:
"TTL operations are all in line with the spirit of RFC4443."

I hope that over time we'll get more opinions on the matter.

Regards,
Greg

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 24 Mar 2010 20:59:16 -0400

Look forward to more comments.

Will add clarifying text in the next version that should hopefully dispel any doubts.

- Sri

Sent: Wednesday, March 24, 2010 5:51 PM

Dear Sri,
you wrote:

Regards,
Greg

- Sri

To: Sriganesh Kini

Dear Sri,

Regards,
Greg

- Sri

To: Sriganesh Kini

Dear Sri,

Regards,
Greg

- Sri

Dear Sri,

Regards,
Greg

Thanks

- Sri

Dear Authors,

Kind regards,
Greg Mirsky

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 24 Mar 2010 23:55:58 -0700

Hi Sri,

> Motivation - see an application of this in
> draft-kini-mpls-ring-frr-facility-backup-00

Motivation seems to be to do ring protection in a bandwidth-efficient
mechanism and in a very fast fashion.

There are 2 parts to the above. The later part is "very fast fashion".
I am not convinced of this motivation. If FRR results in degraded service
for additional 200ms, I think it is better than requiring a whole bunch of
new procedures that will complicate how FRR works.
 
> If you can elucidate what part is scary and why, it will be useful.

It's scary because it is "assuming how hardware should work". More
specifically, it is specifying the following for hardware:
1) Check for TTL=1
2) Check if GAL is present and FLA-bit is set in G-Ach
3) Decrement TTL of inner-label (GAL) and forward the packet out.

MPLS forwarding is based off outer label and this is modifying the TTL in
the inner label.

In typical mpls forwarding, you do SWAP and decrement outer-label ttl.
Your procedures are also saying that the outer-label's TTL should also be 1.
So you are bypassing the ttl decrement procedures as well.

Thus it's breaking the mpls forwarding paradigm.

Thanks
Nitin 
 
> In that sense this is not any different from MPLS TTL processing. The FLA bit
> is merely to indicate that packet is to be forwarded in addition to being
> delivered locally. Since packet has to be forwarded on the LSP, the ILM
> operations of the LSP should dictate outgoing label. Since the next LSR must
> be alerted the TTL of the LSP label must be 1.
> 
> I think it is important to point out the configuration in this case. You have
> a "ring" topology with static LSPs connecting each "segment" of this ring.
> The point I made yesterday was that if you simply run BFD over each link
> between nodes to detect the fail-over (and trigger the FRR switch), I think
> you get the same effect except without having to modify 3 protocols (which
> Greg points out below).  Speaking as an operator, if I were to deploy this, I
> totally agree with Greg's point #4 on operational confusion.
> 
> --Tom

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 25 Mar 2010 19:08:30 -0400

Hi Nitin,

See inline @ [Sri] 

- Sri

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Wednesday, March 24, 2010 11:56 PM
To: Sriganesh Kini; Thomas Nadeau
Cc: [email-masked]; Autumn Liu
Subject: Re: [mpls] Comments to A fast LSP-alert Mechanism and Efficient FRR using Facility backup in ring topology

Hi Sri,

> draft-kini-mpls-ring-frr-facility-backup-00

Motivation seems to be to do ring protection in a bandwidth-efficient mechanism and in a very fast fashion.

[Sri] Correct

There are 2 parts to the above. The later part is "very fast fashion".
I am not convinced of this motivation. If FRR results in degraded service for additional 200ms, I think it is better than requiring a whole bunch of new procedures that will complicate how FRR works.

[Sri] Additional 200ms degraded service is not acceptable in many situations. Say in the problem stmt in section 3 of draft-kini-mpls-ring-frr-facility-backup-00 a LSP (say LSP-a) requiring 0.4G bandwidth was routed L9->L8. The service degradation could be up to 100% traffic loss which is simply not acceptable. Regarding the 'whole bunch of new procedures' let us take it one step at a time. They are quite simple once they are understood.
 
> If you can elucidate what part is scary and why, it will be useful.

It's scary because it is "assuming how hardware should work". More specifically, it is specifying the following for hardware:
1) Check for TTL=1

[Sri] This MUST be already done (in hardware) in all MPLS devices

[Sri] Checking for GAL MUST be already done. The only extra check required by draft-kini-mpls-fast-lsp-alert-00 is to check for the FLA-bit in ACH. Almost all the elements to do this must be already present in GAL handling. If cases where hardware is inflexible to do this we recommend doing this in firmware. If that is not possible in some rare cases then we recommend doing that in software (of course this will be slower). As with all solutions there will be good implementation that are fast and those that are not.

3) Decrement TTL of inner-label (GAL) and is forward the packet out.

[Sri] Correct. If TTL (of GAL) decrement procedures allow packet forwarding then forward a copy of the packet. 

MPLS forwarding is based off outer label and this is modifying the TTL in the inner label.

[Sri] We are NOT changing the forwarding being based on LSP label. Correct that GAL TTL is being decremented, but this enables the alert to be delivered to multiple LSRs at speeds that are much faster than involving control plane.

[Sri] TTL decrement procedures are NOT bypassed. All TTL decrement procedures as applied to the outer label are now applied to the TTL of GAL. Correct that the LSP label's outgoing TTL is set to 1, but that is to enable alerting the next LSR.

[Sri] It is NOT breaking the spirit of mpls forwarding paradigm (RFC3031/3032/3443). To re-iterate, all TTL decrement procedures are applicable and so is forwarding based on outer-label.

Thanks
Nitin 
 
> Subject: Re: [mpls] Comments to A fast LSP-alert Mechanism and 
> Efficient FRR using Facility backup in ring topology
> 
> 
> standard MPLS TTL processing. In our case we are use the TTL of GAL for this purpose.
> In that sense this is not any different from MPLS TTL processing. The 
> FLA bit is merely to indicate that packet is to be forwarded in 
> addition to being delivered locally. Since packet has to be forwarded 
> on the LSP, the ILM operations of the LSP should dictate outgoing 
> label. Since the next LSR must be alerted the TTL of the LSP label must be 1.
> 
> For an operator to change every P2P LSP that has been well deployed 
> into a P2MP LSP just to deliver alert along the entire LSP is in our 
> opinion unacceptable. Even for P2MP LSPs to be supplanted with bud 
> LSRs to every transit LSR (for delivering alerts) has several issues
> 
> I think it is important to point out the configuration in this case. 
> You have a "ring" topology with static LSPs connecting each "segment" of this ring.
> The point I made yesterday was that if you simply run BFD over each 
> link between nodes to detect the fail-over (and trigger the FRR 
> switch), I think you get the same effect except without having to 
> modify 3 protocols (which Greg points out below).  Speaking as an 
> operator, if I were to deploy this, I totally agree with Greg's point #4 on operational confusion.
> 
> --Tom