Re: [Lsr] PUA&UPA Converge Efforts(LSInfinity or MaxAge)

Tue, 28 Mar 2023 15:14:32 -0700

Hi, All:

As discussed within the list, we have noticed there will be confusion for the usage/implementation/deployment of LSInfinity. 

Because the main motivation for this field is to let the legacy nodes bypass the PUA/UPA message, we propose use the MaxAge of the LSA to accomplish such task. The reasons are the following:

1) RFC2328 has described the similar results for these two fields:

   (1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA.

2) The PUA/UPA message is one PULSE message, it should not exist within the network long time. Exploitable this value is straightforward to be implemented/deployed.


Aijun Wang
China Telecom

On Mar 27, 2023, at 15:02, Aijun Wang <wangai...@tsinghua.org.cn> wrote:

Hi, Bruno:

Let me answer some questions from you based on the current PUA solution. 

From the inline replies, we think the converged draft should be based on PUA draft.

Aijun Wang
China Telecom

On Mar 27, 2023, at 14:00, bruno.decra...@orange.com wrote:













Hi
authors,


 


Please find below some questions.


 


    

  1. Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises IP1 with MAX metric.
 Is this prefix reachable or unreachable (or both)?

[WAJ] This is the network partition scenario that we mentioned in the meeting, and also in the document.(UPA has no similar solution now)

According to our considerations, the prefixes IP1 will be reachable via ABR1. This is the right answer for such situation.


“When only some of the ABRs can't reach the failure node/link, as that described in Section 3.2, along with the PUAM message for the associated prefixe from these ABRs, the ABR that can reach the PUAM prefix should advertise the specific route to this prefix. The internal routers within another area can then bypass the ABRs that can't reach the PUAM prefix, to reach the prefix that advertised in PUAM message.”


  2. Assuming ABR1 advertises a summary address but ABR2 does not. If ABR2 advertises IP1 with MAX metric does this count as UPA? (i.e. may a router advertise unreachability for a prefix advertised by another router?)

[WAJ] In principle, the ABR that doesn’t send the summary address shouldn’t send the PUA/UPA message. So, normally, the ABR2 will not send such message with the MAX metric set.

If it is sent out by ABR2 by any way, but not by ABR1, then it belongs to again the partition scenario(the receiver will know that it can reach such prefix via ABR1, not ABR2)

  2. Can you clarify the scope of the UPA signaling? E.g. if TLV 135 advertises prefix IP1 with MAX metric
    1. does this signal UPA for all FlexAlgo?
    2. If IS-IS Flexible Algorithm Prefix Metric is advertised, is MAX metric to be advertised in the main TLV, or per FAPM sub-TLV, or both? Can you specify the behavior in case on “inconsistencies”?
    3. Does this signal UPA If the summary address (aka the less specific prefix) is advertised in a different IS-IS instance or in a different protocol (e.g. OSPF, BGP…)?

[WAJ] I think Peter can explain the above questions more clearly. Anyway, this is the reason that we mentioned during the meeting that we shouldn’t design the solution that relying heavily on the LSInfinity exploration.

The less to depend on it, the better. That is the reason that we introduce the capabilities negotiation procedure(UPA based solution cannot be deployed without the dependency on the LSInfinity in future, this is unacceptable. The rely on the LSInfinity, or other bypass method should be only temporary)——once all the routers within the area support such capabilities, such feature will have no relation with the LSInfinity which may be used in other scenarios.

  1. Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will trigger BGP PIC edge for 255 /32)

[WAJ] In principle, the ABR send only the PUA information for /32 prefix. As stated in the PUA draft:

Based on such information, the ABR will only advertise the PUAM message when the tracked prefixes(for example, the loopback addresses of PEs that run BGP) that within the summary address is missing.


  2. For UPA of SRv6 locators for algo 0 or 1, is the MAX METRIC to be advertised for TLV 27 or 236 or both? Can you specify the behavior in case on “inconsistencies”?
  3. “a summary address which covers the prefix is being advertised by the ABR/ASBR”. For IS-IS, does the Attached bit count as a summary address or is it needed to advertise a summary address in IP reachability?
[WAJ] The ABR should advertise a summary address. It’s the pre-condition to advertise the PUA/UPA message.

 

Ideally it would be good if the draft were updated to answer the above questions.


[WAJ] We want to express again that the PUA solution is more thorough solution—covering more aspects than UPA solution, and is also earlier solution for this problem and should be the base for the future converge.

There is also other methods that let unsupported nodes to bypass the LSA that carry the unreachable signaling information, for example, set the MAX-AGE of the LSA. The specific in RFC2328 has the following description:

   (1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA.

Using the MaxAge field can avoid the confusions with the usages of LSInfinity in FlexAlgo.

If the above solution is acceptable, we can update the draft accordingly. Such bypass method may be more clearer than LSInfinity.
 

 

Thanks,

Regards,

--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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to