RE: AD Review of draft-ietf-rtgwg-lfa-manageability

[<[e-mail]>]

Hi Alia,

I just posted the version 9. For the moment, I kept the six (co-)authors. As I explained, everyone did more than just contributing and there was a strong involvement on draft text and specification, so it would be wonderful if you can agree to keep all of them.

Hope the modified text will fit your comments.

Thanks,

Stephane

------------------

A new version of I-D, draft-ietf-rtgwg-lfa-manageability-09.txt

has been successfully submitted by Stephane Litkowski and posted to the IETF repository.



Name:                  draft-ietf-rtgwg-lfa-manageability

Revision:              09

Title:                      Operational management of Loop Free Alternates

Document date:               2015-06-19

Group:                  rtgwg

Pages:                   28

URL:            https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lfa-manageability-09.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/

Htmlized:       https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-09

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-09



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.











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.



The IETF Secretariat




From: Alia Atlas [mailto:[e-mail]]
Sent: Thursday, June 18, 2015 20:11
To: LITKOWSKI Stephane SCE/IBNF
Cc: [e-mail]; [e-mail]
Subject: Re: AD Review of draft-ietf-rtgwg-lfa-manageability

Just a quick reminder - but an updated draft is needed by tomorrow to address these issues.
Otherwise, I will have to remove the draft from the telechat on June 25 and postpone it until June 9,
assuming the draft is updated next week.

Regards,
Alia

On Fri, Jun 12, 2015 at 10:22 AM, Alia Atlas <[e-mail]<mailto:[e-mail]>> wrote:
Hi Stephane,

On Fri, Jun 12, 2015 at 8:55 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alia,

Many thanks for your review, I will address them shortly and publish a new version.
Some comments inline.

Sounds good.



Best Regards,

Stephane

From: rtgwg [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Alia Atlas
Sent: Thursday, June 04, 2015 23:44
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: AD Review of draft-ietf-rtgwg-lfa-manageability


As is customary, I have done my AD Review of this draft.   Thank you for a clearly written and well thought out draft.

I do have some minor concerns,  as below, but I am also letting this draft move to IETF Last Call while they are addressed.   I will need an updated draft by June 18, so the draft can go on the IESG telechat on June 25.

Minor comments:

0)      This draft has 6 authors.  Please prune down to 5 or assign an editor or two.

[SLI] Everyone listed worked hardly on the text as well as on specifications, I will put myself as editor to keep everyone ☺.
We can talk about this.  Having 6 authors/editors is an exception that I would have to approve.

  1) In section 6.2.1, it says " When selecting the best alternate, the selection algorithm MUST
      consider all available alternates (connected or tunnel).  Especially,
      computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be
      performed before best alternate selection."

      Instead of "Especially" with a SHOULD - which implies that Remote LFA should always be run, could you change it to:  "For example with Remote LFA, computation of PQ set ...."?   I think the manageability concerns in this document are useful regardless of the fast-reroute technology and this is only a good example of an implementation ordering that is important.

[SLI] Fixed.

  2) In 6.2.4.1<http://6.2.4.1>: " attributes from PLR to alternate path are retrieved from the
      interface connected to the alternate."

      There can be multiple interfaces.  The correct behavior (union or  evaluate once per different interface) should be clearly described.  The similar issue exists for the alternate path and in 6.2.4.2, but there may be more or less freedom about controlling which path is taken.

[SLI] I need to discuss with my co authors on that.
Yes, I think this one is a non-trivial.  It's made more amusing by the probability of multiple paths taken at downstream hops.  I can see being conservative there but able to pick for the first hop.


 3) In Sec 6.2.6, "Maintain a preference system between alternates based on number of

      SRLG violations : more violations = less preference."   The way that I've seen SRLGs used as a soft restriction is by giving each SRLG a value.  Then one can prefer the lower sum.  This allows different consideration and valuation of the SRLGs.  Of course, this can fall back to each SRLG has a value of 1.   Could you please loosen the assumption here about equally valuing the SRLGs?  I'd prefer to see both alternatives allowed - but that is <no-hat>technical opinion</no-hat> whereas loosening the assumption is about not accidentally forcing more limited behavior and removing the ability to implement more sophisticated mechanisms.

[SLI] Right, here is a new text proposal which is more open:

“

When SRLG protection is computed, and implementation SHOULD permit to :

                                                <list style="symbols">

                                                <t>Exclude alternates violating SRLG.</t>

                                                <t>Maintain a preference system between alternates based on SRLG violations. How the preference system is implemented is out of scope of this document but here are few examples :

                                                <list style="symbols">

                                                <t>Preference based on number of violation. In this case : the more violation = the less preferred.</t>

                                                <t>Preference based on violation cost. In this case, each SRLG violation has an associated cost. The lower violation cost sum is preferred.</t>

                                                </list>”
Looks good.

The path considerations mentioned in (2) still apply.

4) In Sec 6.2.7, you might be interested in the link/node-attribute drafts that are being finished.

[SLI] Could you give me the pointers of drafts you are thinking about ?

You have the ISIS one for node admin tags.  I was also thinking of draft-ietf-ospf-node-admin-tag-02<http://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/>
and draft-ietf-ospf-prefix-link-attr-06<http://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/>.  For ISIS, it looks like the similar draft
only provides for prefix attributes and not link ones.

Regards,
Alia

5) In Sec 6.2.8: "The bandwidth criteria of the policy framework SHOULD work in two
   ways"  Please expand to "at least two ways" - there are other strategies as well that might be reasonable and no standardization reason to rule them out.

[SLI] Agree, fixed

Nits:
   a) Introduction needs to be the first section. Terminology can follow.

[SLI] Fixed

  b) Remote LFA reference needs updating to RFC 7490.  I think,  given some of the details in this draft,  that it should be a normative reference.

[SLI] Fixed.



Thanks for the good work,
Alia

_________________________________________________________________________________________________________________________



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.



_________________________________________________________________________________________________________________________

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.