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.


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.


_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to