Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Peter Psenak <[e-mail]>]

Hi Bruno,

please see inline (##PP2):


On 16/06/2022 12:01, [e-mail] wrote:
> Hi Peter,
> 
> Thanks for your reply. Please see inline [Bruno2]
> 
> 
> 
> Orange Restricted
> 
>> -----Original Message-----
>> From: Peter Psenak <[e-mail]>
>> Sent: Thursday, June 16, 2022 11:22 AM
>> To: DECRAENE Bruno INNOV/NET <[e-mail]>; [e-mail]
>> 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, [e-mail] 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.
> 
>