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

[Alia Atlas <[e-mail]>]

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]> wrote:

> Hi Stephane,
>
> On Fri, Jun 12, 2015 at 8:55 AM, <[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]] *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 J.
>>
>> 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: " 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.
>>
>>
>