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

[<[e-mail]>]

Hi Alia,

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


Best Regards,

Stephane

From: rtgwg [mailto:[e-mail]] On Behalf Of Alia Atlas
Sent: Thursday, June 04, 2015 23:44
To: [e-mail]; [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 ☺.

  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.



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>”

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 ?



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.