Bruno,
please see inline:
On 25/07/2023 18:36, [email protected] wrote:
Peter,
Thanks for your answer.
Please see inline [Bruno]
From: Peter Psenak <[email protected]>
Sent: Tuesday, July 25, 2023 6:05 PM
Bruno,
On 25/07/2023 14:39, [email protected] wrote:
Hi all,
With RC5305, in IS-IS we can advertise two states for a prefix IP1:
* Positive reachability (state “1”), by advertising IP1 in TLV 135
with a metric lower than 0xFE000000
* No reachability (state “0”) by either:
o Not advertising IP1 in TLV 135
o Advertising IP1 in TLV 135with a metric larger than 0xFE000000
right, one being implicit the other one explicit.
For unreachable prefix announcement, we need to advertise a new state:
negative reachability (state “-1”) because advertising no reachability
(state “0”) is not enough since there is a covering prefix advertised.
Hence we need a new signaling.
draft-ppsenak-lsr-igp-ureach-prefix-announce is proposing to advertise
IP1 unreachability by advertising IP in TLV 135 with a metric larger
than 0xFE000000.
This does not work as this signal is already defined to advertise state
“0” (no reachability) while we want to advertise negative reachability
(state “-1”): one can’t signal two different states with a single signal.
This seems easy to fix in the last version of the draft: one just have
to signal state “-1” with the flags already defined and advertised.
In short, negative reachability would be signal by advertising IP1 in
TLV 135with a metric larger than 0xFE000000 and flag U (Unreachable
Prefix) or UP (Unreachable Planned Prefix) set.
that is exactly what the draft describes. I'm not sure what is your point.
On the receiving side, state “-1” is learned from the reception of
either flag.
This is a very simple change, and it would address my concern.
Can this be done?
I'm not sure what exactly are you asking for as the draft is already
describing what you are asking for.
[Bruno] Good if this is what is meant in the draft and if this is only
misunderstanding.
To be specific, I'm asking about the following changes for IS-IS (please feel
free to reformulate, OSPF is up to you)
§5.4
OLD:
U-Flag and UP-Flag are optional flags that have informative character.
Treatment of these flags on the receiver is optional and the usage of them is
outside of scope of this document.
NEW:
The setting of the U-Flag or the UP-Flag signals that the prefix is
unreachable. They constitute the UPA signals.
I don't think above is necessary:
[RFC5305] defines the encoding for advertising IPv4 prefixes using 4
octets of metric information. Section 4 specifies:
"If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered
during the normal SPF computation. This allows advertisement of a prefix
for purposes other than building the normal IP routing table. "
As a result of the above, from the IP routing perspective, prefix with a
metric larger then MAX_PATH_METRIC (0xFE00000) MUST be treated as
unreachable. If the implementation does not do that, it is clearly
violating RFC5305.
We added the new flags, to distinguish from other cases where the prefix
might be advertised with metric higher than 0xFE000000, whatever that
use case is. But the meaning of the metric higher than 0xFE000000 from
the IP routing perspective does not changes by the new flags.
§5
"Even though in all cases the treatment of such metric, or NU-bit, is specified for
IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised
in order to signal unreachability is useful to distinguish it from other cases where the
prefix with such metric is advertised."
:s/useful/required
§Abstract
OLD: This document describes how to use existing protocol mechanisms in IS-IS
and OSPF to advertise such prefix reachability loss.
NEW: This document defines two new flags in IS-IS and OSPF to advertise such
prefix reachability loss. In order to support incremental deployment, such
advertisement use a high metric value already having special meaning of OSPF
and IS-IS.
§1
OLD: This document describes how the use of existing protocol mechanisms can
support the necessary functionality without the need for any protocol
extensions. The functionality being described is called Unreachable Prefix
Announcement (UPA).
NEW: This document defines two new flags in IS-IS and OSPF to the necessary
functionality without the need for any protocol extensions. The functionality
being described is called Unreachable Prefix Announcement (UPA).
please see my above response. The treatment of the metric higher that
0xFE000000 and LSInfiity has been defined long time back and is not
affected by the newly defined flags.
thanks,
Peter
Thank you,
Regards,
--Bruno
The drawback is that the existing pre-standard implementation would need
to be updated. But that’s the rule for a pre-standard implementation.
not really, the handling of the metric higher that 0xFE000000 is already
defined in the existing spec.
regards,
Peter
The faster we do the change, the easier it is, especially for other
implementations.
--Bruno
____________________________________________________________________________________________________________
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.
Orange Restricted
____________________________________________________________________________________________________________
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
