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

From: Alia Atlas <[email-masked]>
Date: Thu, 4 Jun 2015 17:44:16 -0400

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.

  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.

  2) In 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.

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.

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.

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.

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

  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.

Thanks for the good work,
Alia

---

From: <[email-masked]>
Date: Fri, 12 Jun 2015 12:55:17 +0000

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:[email-masked]] On Behalf Of Alia Atlas
Sent: Thursday, June 04, 2015 23:44
To: [email-masked]; [email-masked]
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>”

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:

[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.

_________________________________________________________________________________________________________________________

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: Alia Atlas <[email-masked]>
Date: Fri, 12 Jun 2015 10:22:48 -0400

Hi Stephane,

> Many thanks for your review, I will address them shortly and publish a new
Sounds good.

>
>
>
>
> Best Regards,
>
>
>
> Stephane
>
>
>
> *From:* rtgwg [mailto:[email-masked]] *On Behalf Of *Alia Atlas
> *Sent:* Thursday, June 04, 2015 23:44
> *To:* [email-masked]; [email-masked]
> *Subject:* AD Review of draft-ietf-rtgwg-lfa-manageability
>
>
>
> [SLI] Everyone listed worked hardly on the text as well as on
> specifications, I will put myself as editor to keep everyone J.
>
> We can talk about this.  Having 6 authors/editors is an exception that I
would have to approve.

>       Instead of "Especially" with a SHOULD - which implies that Remote
> LFA should always be run, could you change it to:  "For example with Remote
>   2) In 6.2.4.1: " attributes from PLR to alternate path are retrieved
> from the
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
>                                                 <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.

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

>    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:
>   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.
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 18 Jun 2015 14:11:27 -0400

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 <[email-masked]> wrote:

>> 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:
>>
>>       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.
>>

---

From: <[email-masked]>
Date: Fri, 19 Jun 2015 15:09:04 +0000

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:[email-masked]]
Sent: Thursday, June 18, 2015 20:11
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stephane,

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

Sounds good.

Best Regards,

Stephane

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

Minor comments:

[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.

[SLI] Fixed.

[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.

“

                                                <list style="symbols">

                                                <list style="symbols">

                                                </list>”
Looks good.

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

[SLI] Agree, fixed

Nits:

[SLI] Fixed

[SLI] Fixed.

Thank you.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 19 Jun 2015 16:55:51 -0400

RTGWG & Stephane,

Thank you very much for the thorough and clear addressing of my technical
concerns.
I would strongly urge others in the working group to read through the
updated draft.  The
changes are clarifications of the appropriate behavior - but I am
interested in being certain
that he updates are seen by the working group.

PLEASE send any comments or concerns or that it looks good to you in the
next week.  I
may hold the draft in AD Follow-up for a few days (not past the end of
June) if I don't see
that the WG has seen these changes.

Basically, I don't think that they are technical changes such that it's
necessary to go back
through the last call process - but they are significantly more than merely
editorial, so I would
be more comfortable with others doing a quick review also.

Thanks,
Alia

On Fri, Jun 19, 2015 at 11:09 AM, <[email-masked]> wrote:

>  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.
>
>
>
> 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:
>
> 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:[email-masked]]
> *Sent:* Thursday, June 18, 2015 20:11
> *To:* LITKOWSKI Stephane SCE/IBNF
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: AD Review of draft-ietf-rtgwg-lfa-manageability
>
>
>