On 09/11/2022 22:51, Aijun Wang wrote:
Hi, Peter:
Actually, the “unreachable” meaning of LSInfinity in current standard is
not the same as the “unreachable” meaning that we are supposed to act:
1) In current standard, the “unreachable” is meant that the related
prefix will not be in the FIB.(you can read again and again
https://www.rfc-editor.org/rfc/rfc2328.html#page-157
<https://www.rfc-editor.org/rfc/rfc2328.html#page-157>)
2) What we aim to solve is that although the specific prefixes is not in
the FIB, there is another summary address that cover it is in the FIB.
Even in such situations, the specific prefixes is still unreachable.
Then, depend solely on 1) is not enough.
We must need one explicit information to signal 2).
There are so many experts within LSR state that your solution is not
appropriate, will bring much chaos into the network, you still insist
your approach. Is this productive?
interesting that you, who hardly listen to these experts at all, are
saying that.
Peter
The final solution should be definitely in “Standard Track”, but not
your approach.
The explicit signaling is the right direction.
Even the experts in LSR are confusing on your multiplex usage of
“LSInfinity”, how to deploy it in the large scale network?
Please don’t let the operator struggle to explain such vague usages to
its Network OPS, Network Planning team.
Aijun Wang
China Telecom
I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior. However, prefixes with > 0xfe000000 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.
for me flagging something that is unreachable with a unreachable flag
is redundant. But I let the WG to decide. That would obviously push
the draft to standard track trajectory.
Peter
Cheers,
-David
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
