Stephane,
As I have given my feedback on the recent updates offline and new versions
looks fine to me.
I have 2 more final comments as noted below [Uma1]:
========
3. Similarly Section 4.4 coverage monitoring guidelines for the vendor
implementations are good ones but these are neither addressing any issues
presented in Section 2 nor helping solve any interoperability issue.
The problem I see with this is lot of implementations may quickly become
non-compliant from customers point of view once this becomes RFC. Do you see
that way?
[SLI] As mentioned in previous comment, coverage informations are mandatory to
be able to maintain LFA deployment (SP experience speaking ...). As proposed, I
can add something in section 2 to detail the need.
[Uma1]: I am not at all saying coverage information and monitoring information
is less important, in fact it could be critical for SPs but my question is
towards,
how far we can mandate these kind of implementation choices of the vendors ?
5. Section 3.2.1
Also, say you might have a legacy node to deal with and you are not able to
establish TLDP with PQ here
in that case, you might look for a knob to choose the policy (remote or
local policy).
[SLI] This may be managed by "neighbor exclude" policy statement.
[Uma1]: It may not be neighbor exclude as this is PQ node's preference and
multiple destinations can have different PQs with same neighboring node.
Probably you mean to say node-admin tag kind of stuff?
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg