Hi Bruno,

On 27/03/2023 06:59, [email protected] 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)?

UPA is meant to be sent only for prefixes that are never advertised as reachable at all - e.g., all ABRs/ASBRs use the same summarization. So above case should ideally never happen.

To answer your question - reachability always prevails, that is the existing protocol behavior, we are not altering that. If R1 advertises prefix with unreachable metric and R2 advertises prefix with valid metric, the prefix becomes reachable via R2.

 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?)

above is a misconfiguration IMHO.
Again, we rely on existing behavior, where reachbability prevails.

 3. 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?

for SR-MPLS flex-algo, FAPM metric is used for non-0 algo. The U-flag is set on TLV-135, and is only considered for algos for which the FAPM is set to unreachable metric. For algo 0 the metric of the TLV-135 is used.

For SRv6 and IP flex-algo, as the prefix is bound to the algo, the signalling is algo specfic.


     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”?

please see above.

     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…)?

are you asking about the UPA redistribution? I guess implementation may support that, but only between protocols that support UPA - BGP is not. But how is that done is out of scope.


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

no. For BGP PIC to be triggered by UPA, the UPA must be sent for the prefix that is used to resolve BGP prefixes. But the treatment of the UPA is outside of the scope.

 5. 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”?

sure :)

 6. “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?

I would not treat attached-bit as a summary. Most implementations do not recurse BGP routes over default route.

thanks,
Peter


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

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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to