Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt

From: [email-masked]
Date: Wed, 22 Jan 2014 05:02:17 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Operational management of Loop Free Alternates
        Authors         : Stephane Litkowski
                          Bruno Decraene
                          Clarence Filsfils
                          Kamran Raza
                          Martin Horneffer
                          Pushpasis Sarkar
	Filename        : draft-ietf-rtgwg-lfa-manageability-01.txt
	Pages           : 21
	Date            : 2014-01-22

Abstract:
   Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
   ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic
   (and MPLS LDP traffic by extension).  Following first deployment
   experiences, this document provides operational feedback on LFA,
   highlights some limitations, and proposes a set of refinements to
   address those limitations.  It also proposes required management
   specifications.

   This proposal is also applicable to remote LFA solution.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Maik Pfeil <[email-masked]>
Date: Wed, 22 Jan 2014 22:07:18 +0800

Hi,

as stated in section 4.2
<snip>

 To enhance such situation, an implementation SHOULD
   support triggering/activating LFA Fast Reroute for a given link when
   a manual shutdown is done.

</snip>

The triggering of a FRR could also happen by BFD in some
implementations. The last sentence should be more generalized or even
get more details. What exactly should a "shutdown" trigger? For e.g. a
tx-laser off on local side -> triggers LFA on remote side.

// Maik

2014/1/22 <[email-masked]>

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

---

From: <[email-masked]>
Date: Wed, 22 Jan 2014 15:22:08 +0100

Agree,

I will clarify with more details.

De : rtgwg [mailto:[email-masked]] De la part de Maik Pfeil
Envoyé : mercredi 22 janvier 2014 15:07
Cc : [email-masked]
Objet : Re: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt

Hi,

as stated in section 4.2
<snip>

</snip>

The triggering of a FRR could also happen by BFD in some implementations. The last sentence should be more generalized or even get more details. What exactly should a "shutdown" trigger? For e.g. a tx-laser off on local side -> triggers LFA on remote side.

// Maik

2014/1/22 <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 23 Jan 2014 21:24:10 +0000

Dear Authors,

I have given some  comments to you only, on the earlier version of this draft  few months back and I see some of them are taken care. Thx.

After re-reading this version, I  felt this is indeed addressing the important aspect and the value of policy based selection of alternatives 
As opposed to the alternatives with best protection. This document brings out lot of use cases and the configuration knobs to 
achieve the goal of the "policy" based preference on possible LFAs.

However, I see some of the sections documented are not directly related to the uses cases presented in Section 2, which in principle 
shows how and why the best protection is not good (excluding the IS-IS overload case) in all cases. 
For example:

1.  Section 3.1, which suggests the activation granularity requirement of the LFAs from Context, instance to address-family and per-prefix. 
      Here some of the choices are natural but I don't think this addresses any of the problems documented in Section 2.
      "..This means that if a specific
      prefix must be protected due to a configuration request, LFA must
      be computed and installed for this prefix even if the primary
      outgoing interface is not configured for protection."
      Could you clarify the must (2) in the sentence? Do you intend to say "MUST" there?

      Also I feel, for example, having per-prefix granularity for provisioning LFA or not is an implementation choice than an interoperability 
      issue while deployment.

2.  Section 4.3, "Required local information" Says -
     "MUST provide coverage information per activation domain of LFA
      (area, level, topology, instance, virtual router, address family
      ...)."
     To me this is good to have information and be very helpful for the operator but I am not sure mandating the coverage information granularity
     is addressing any of the issues presented in Section 2.

3. Similarly Section 4.4 coverage monitoring guidelines for the vendor implementations are good ones but these are neither addressing any issues 
     presented in Section 2 nor helping solve any interoperability issue. 

The problem I see with this is lot of implementations may quickly become non-compliant from customers point of view once this becomes RFC. Do you see that way?

Specific review Comments:
=====================

1. Section 2.1
   When the core link R8-R7 fails, R8 switches all traffic destined to
   all the PEx towards the edge node PE2.

  What is "all the PEx"??

2. Section 2.2
   "In the figure 2, let us consider the traffic coming from PE1 to PEx.
   Nominal path is R9-R8-R7-R6-PEx."

   You might mean to say R9-R8-R7-R10-R6-PEx ? Can you clarify?

3. Section 2.3
   Though it's not important to illustrate your point of using sub-optimal core links as LFA, it's good to mention the link costs of R3-PE1 and PE1-R4.
   Otherwise PE1 could become another potential node protecting alternative via non-core or whatever.. (at least can avoid confusion for the reader).

4.  For IGPs what exactly you meant when you say "topology" and how this is different than first bullet "Per address-family"?

5. Section 3.2.1
   "Especially, computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD to be
   performed before best alternate selection."
   
    SHOULD to be ==> SHOULD be
   
   Also,  say you might have a legacy node to deal with and you are not able to establish TLDP with PQ here 
   in that case, you might look for a knob to choose the policy (remote or local policy).

6.  "3.2.5.  Details on criterions" 
      Didn't understand the title and all sub-sections listed under should instead be 3.2.x level? I am saying this because I lost 
      where I was while reading.  I would suggest to re-organize better.

7. 3.2.5.1.  LFA and ECMP
     It should have been "ECMP LFAs"
   
   And..
   "As mentioned in [RFC5286] Section 3.4., protecting a link within an
   ECMP by another primary nexthop is not a MUST.  Moreover, we already
   presented in this document, that maximizing the coverage of the
   failure case may not be the right approach and policy based choice of
   alternate may be preferred."

   If you just want to prevent one of the other ECMP link as LFA then you can provision "local" SRLGs.
   Then in this case you might get L3 or L4 but you are seeking both as LFAs.   I  see the current text put
    Lot of  emphasis on the point of not using one of the primary ECMP paths as alternatives with citation 
   on RFC 5286. 
   However,  you are *also* seeking for an ECMP LFA (if available, instead of tie breaking and give one 
  LFA eventually from the non-bundle).

   Also I didn't fully understand how can one enforce this as one can have another equal cost 
   alternate (non-bundled) path from PE1 to PE2 via P2 or some Px node. It seems in this case you are
   looking for all  non-ECMP LFAs to be installed as alternatives? 

8. Section 3.2.5.5
   "Rather than tagging interface on each node (using link color) to
   identify neighbor node type (as example), it would be helpful if
   routers could be identified in the IGP. "
   
    a) After this it completely talks IS-IS language. Probably this should be revisited to make it generic or applicable to the other IGP.
    b) Coming to IS-IS, you referred I-D.psarkar-isis-node-admin-tag but the text suggests, its own algorithm to identify the neighbor with 
       TLV135 and  is not complete in many fronts. 
    
 I would suggest revisit this section completely to focus on the point your of "neighbor preference" rather than incomplete IGP details. 

9. Section 4.5
   "4.5.  Deterministic and documents LFA selection behavior"
   The title didn't sound correct.

--
Uma C.

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 22, 2014 5:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

---

From: <[email-masked]>
Date: Tue, 28 Jan 2014 10:33:07 +0100

Hi Uma,

Thanks for your comment, please some mine inline.

-----Message d'origine-----
De : rtgwg [mailto:[email-masked]] De la part de Uma Chunduri
Envoyé : jeudi 23 janvier 2014 22:24
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt

Dear Authors,

After re-reading this version, I  felt this is indeed addressing the important aspect and the value of policy based selection of alternatives As opposed to the alternatives with best protection. This document brings out lot of use cases and the configuration knobs to achieve the goal of the "policy" based preference on possible LFAs.

However, I see some of the sections documented are not directly related to the uses cases presented in Section 2, which in principle shows how and why the best protection is not good (excluding the IS-IS overload case) in all cases. 
For example:

[SLI] "must" is not RFC2119 "MUST" :)
The idea is just, as mentioned in the previous sentence that "per prefix protection" overrides "per interface protection" configuration.

[SLI] Agree ... 

[SLI] When deploying LFA, coverage information is mandatory for the SP as coverage may change as topology is changing. Maybe we can mention this in section 2. What do you feel ?

[SLI] As mentionned in previous comment, coverage informations are mandatory to be able to maintain LFA deployment (SP experience speaking ...). As proposed, I can add something in section 2 to detail the need. 

1. Section 2.1

  What is "all the PEx"??

[SLI] PEx is a set a PE.

2. Section 2.2

[SLI] Right this is a mistake, I will fix it. Thanks

3. Section 2.3

[SLI] Agree, will fix it.

[SLI] Topology refers to multitopology IGP (MT extensions), this may be different from address family (OSPF for IPv6 is not a multitopology OSPF case)

5. Section 3.2.1

[SLI] will fix it.

[SLI] This may be managed by "neighbor exclude" policy statement.

6.  "3.2.5.  Details on criterions" 
      Didn't understand the title and all sub-sections listed under should instead be 3.2.x level? I am saying this because I lost 
      where I was while reading.  I would suggest to re-organize better

[SLI] Why not ... the idea is to give details on how each attribute should be retrieved.
So do you prefer to move all subsections to 3.2.x ? I'm ok with that.

7. 3.2.5.1.  LFA and ECMP

[SLI] Ok

   And..

[SLI] You are right. 

8. Section 3.2.5.5

[SLI] Agree, will fix it

9. Section 4.5

[SLI] Ok will fix it

--
Uma C.

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 22, 2014 5:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt

Abstract:

---

From: <[email-masked]>
Date: Tue, 28 Jan 2014 15:05:48 +0100

Hi Maik,

Here is a proposed new text, let me know if it fits your comment :

"Service providers often perform manual link shutdown (using router
   CLI) to perform some network changes/tests.  A manual link shutdown
   may be done at multiple level : physical interface, logical
   interface, IGP interface, BFD session ...  Especially testing or
   troubleshooting FRR requires to perform the manual shutdown on the
   remote end of the link as generally a local shutdown would not
   trigger FRR.

To enhance such situation, an implementation SHOULD
   support triggering/activating LFA Fast Reroute for a given link when
   a manual shutdown is done on a component that currently supports FRR
   activation.

   For example :

   o  if an implementation supports FRR activation upon BFD session down
      event, this implementation SHOULD support FRR activation when a
      manual shutdown is done on the BFD session.  But if an
      implementation does not support FRR activation on BFD session
      down, there is no need for this implementation to support FRR
      activation on manual shutdown of BFD session.

   o  if an implementation supports FRR activation on physical link down
      event (e.g.  Rx laser Off detection, or error threshold raised
      ...), this implementation SHOULD support FRR activation when a
      manual shutdown at physical interface is done.  But if an
      implementation does not support FRR activation on physical link
      down event, there is no need for this implementation to support
      FRR activation on manual physical link shutdown.

"

Stephane

Hi,

as stated in section 4.2
<snip>

</snip>

// Maik

Abstract: