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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
