Hi Bruno,
please see inline (##PP2):
On 16/06/2022 12:01, [email protected] wrote:
Hi Peter,
Thanks for your reply. Please see inline [Bruno2]
Orange Restricted
-----Original Message-----
From: Peter Psenak <[email protected]>
Sent: Thursday, June 16, 2022 11:22 AM
To: DECRAENE Bruno INNOV/NET <[email protected]>; [email protected]
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
Hi Bruno,
thanks for your feedback, please see inline (##PP):
On 15/06/2022 16:09, [email protected] wrote:
Hi Peter, authors, all
Thanks for the draft. I find it a useful contribution to the problem space.
IMHO the use of MAX_PATH_METRIC is a good idea in particular since it
can be made backward compatible and provides incremental benefits with
incremental deployment.
I also have two disagreements on the current draft. Both are minor IMO,
but authors may have a different opinion.
1. This draft defines a new signaling from an egress ABR to all ingress
ABR/PE. As such, this require all these nodes to agree on this
signaling. So I’d call for a STD track document.
##PP
there is no new signalling defined in the draft. We are using what has
been defined in the RFC5305/RFC5308
[Bruno2] By "signaling", I did not meant "protocol extension". I meant "signaling of
information". https://dictionary.cambridge.org/fr/dictionnaire/anglais/signal
Draft proposes an IGP announcement to signal something, more specifically that
the prefix becomes unreachable
##PP2
yes, we are using the existing signaling method to signal the loss of
reachability for the summary component.
2. IMO, the behavior defined in this draft is not backward compatible
with the specification of MAX_PATH_METRIC in an IP prefix.
##PP
I see no backward compatibility issue
RFC5305 says:
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 per the above, one (ABR) may (is allowed and free to do so) already
advertise both an aggregate prefix IP1/N with a regular metric and a
more specific prefix IP2/32 with MAX_PATH_METRIC.
With the above advertisement, all nodes compliant with RFC 5305 will
install IP1/N in their FIB and not consider IP2/32 during their SPF and
as a consequence not install it in their FIB.
In term of reachability, all nodes have IP reachability to all IP @ in
IP1 including IP2.
If one node now implements the draft, it will remove reachability for
IP2. And hence all my BGP routes using IPv2 for next-hop will be removed.
##PP
there is no such thing specified in the draft. What the drafts says is
that if the receiver is configured to do so, it can pass the UPA to the
applications that may be interested in it. How they act on it is outside
of the draft and ISIS as such.
[Bruno2] In the draft, I'm not seeing the text "if the receiver is configured to do
so". That would be a useful change (even though not enough to me)
##PP2
sure, we can easily add that. That is the idea.
I'm not sure where did you get the "remove reachability for IP2".
[Bruno2] From the title "Unreachable Prefix Announcement".
1) I think we'll agree that there was reachability before the announcement.
##PP2
one that comes from the summary
2) the draft is about announcing that the "Prefix" becomes "Unreachable".
That seems to be "removing reachability for the prefix". I'm open to using a different
terminology such as "Announcing the Prefix to be Unreachable" but I don't think that this
would change the conclusion.
There is other text in the draft, such as "The functionality being described is
called Unreachable Prefix Announcement (UPA)."
##PP2
yes, but you are talking forwarding. We only talk about signaling.
This looks clearly like a change in behavior to me, plus one which
introduce loss of reachability in an existing network.
3) The solution that I would suggest is:
- advertise the “unreachable prefix” with metric MAX_PATH_METRIC
- define a new “Extended Reachability Attribute Flags” ([RFC 7794])
explicitly signaling that the reachability to this prefix has been lost:
Unreachable Flag (U_flag). Set if this prefix is to be considered
unreachable.
##PP
I see no reason for the new flag. RFC5305/RFC5308 already provide a way
to signal unreachable prefix. That's all we need.
[Bruno2]
RFC5305/RFC5308 provides a way to advertise a prefix that "MUST NOT be considered during the
normal SPF computation". That is different from "a way to signal unreachable prefix"
##PP2
RFC5305/RFC5308 says "allow advertisement of a prefix for purposes other
than building the normal IPv4/v6 routing table"
We are just defining a new purpose why that may be done.
If you believe that all you need is RFC5305/RFC5308 I guess this means that we
don't need draft-ppsenak-lsr-igp-ureach-prefix-announce
##PP2
What is new from ISIS perspective is the procedure of generating the UPA
on ABR/ASBR and propagating it between areas/domains. That is for what
we need the draft, I believe.
thanks,
Peter
Thanks,
--Bruno
thanks,
Peter
This would allow for explicit signaling of the reachability (vs implicit
currently) and would be backward compatible with existing specification
and deployments.
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.
_________________________________________________________________________________________________________________________
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
