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

[bruno . decraene]

For the record, -04 published last week adequately addresses my comments.

-- Bruno


Orange Restricted

-Original Message-
From: DECRAENE Bruno INNOV/NET
Sent: Monday, July 31, 2023 11:12 AM
To: Peter Psenak 
Cc: lsr 
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Thanks Peter.

-- Bruno



> -Original Message-
> From: Peter Psenak 
> Sent: Sunday, July 30, 2023 8:04 PM
>
> Hi Bruno,
>
> I will update the draft.
>
> thanks,
> Peter
>
> On 28/07/2023 14:32, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak 
> >> Sent: Thursday, July 27, 2023 8:00 PM
> >>
> >> Bruno,
> >>
> >> On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
> >>
> >>>
> >>> Bottom line:
> >>> - we see that this can be problematic in some cases
> >>> - it's very easy to fix by mandating the use of the flags(s).
> >>
> >> I believe we understand each other. I even believe we are in a violent
> >> agreement, although we have different view on some specific details.
> >>
> >> Would SHOULD language in terms of using the new flags for UPA take care
> >> of your concerns?
> >
> > To summarize, my concern is that with the current text, any advertisement 
> > with a metric higher than 0xFE00 would be interpreted as UPA by nodes 
> > enabling UPA. This essentially forbid any past or future use of this whole 
> > range of metric, which I find problematic and unnecessary.
> >
> > There may be multiple ways to address this. I can think of two (below) but 
> > I'm open to other solutions that you would propose.
> > 1) UPA behavior is triggered by one a the flag being set (and metric 
> > >0xFE00)
> > 2) UPA is triggered by a specific metric value. This would allow other 
> > usages to pick a different value without interfering with UPA. If so I 
> > would have a preference to have a registered value so creating an IANA 
> > registry would be needed (with some values for private use)
> > ...
> >
> > (Clearly, we only need one, not both of them).
> >
> > Coming back to your proposal (thank you) and your question, if option 1 
> > (flag) is used, my proposed changes are detailed in 
> > https://mailarchive.ietf.org/arch/msg/lsr/AN6Lfd58i5RS3cq06EqwOyrOLGY/
> >
> > They are recopied below for ease of discussion (and to fix some errors)
> >
> > §5.4
> > OLD:  U-Flag and UP-Flag are optional flags that have informative 
> > character. Treatment of these flags on the receiver is optional and the 
> > usage of them is outside of scope of this document.
> > NEW: The setting of the U-Flag or the UP-Flag signals that the prefix is 
> > unreachable. They constitute the UPA signals.
> >
> > §5
> > "Even though in all cases the treatment of such metric, or NU-bit, is 
> > specified for IS-IS, OSPF and OSPFv3, having an explicit way to signal that 
> > the prefix was advertised in order to signal unreachability is useful to 
> > distinguish it from other cases where the prefix with such metric is 
> > advertised."
> > :s/useful/required
> >
> > §Abstract
> > OLD:  This document describes how to use existing protocol mechanisms in 
> > IS-IS and OSPF to advertise such prefix reachability loss.
> > NEW: This document defines two new flags in IS-IS and OSPF to advertise 
> > such prefix reachability loss. In order to support incremental deployment, 
> > such advertisement use a high metric value already having special meaning 
> > in OSPF and IS-IS.
> >
> > §1
> > OLD:  This document describes how the use of existing protocol mechanisms 
> > can support the necessary functionality without the need for any protocol 
> > extensions. The functionality being described is called Unreachable Prefix 
> > Announcement (UPA).
> > NEW: This document defines two new flags in IS-IS and OSPF to support the 
> > necessary functionality. The functionality being described is called 
> > Unreachable Prefix Announcement (UPA).
> >
> >
> > I would propose an additional  editorial change
> > OLD: 5. Signaling the UPA origin
> > NEW: 5. Signaling UPA
> >
> > OLD: 5.1. Signaling the UPA origin in IS-IS
> > NEW: 5.1. Signaling UPA in IS-IS
> >
> >
> > Please feel free to reformulate as needed.
> > I've focused on IS-IS. I leave the OSPF parts up to you.
> >
> > Thanks,
> > --Bruno
> >
> >>>
> >>> What's preventing the authors to just fix this?
> >>>

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

[bruno . decraene]

Thanks Peter.

-- Bruno


Orange Restricted

> -Original Message-
> From: Peter Psenak 
> Sent: Sunday, July 30, 2023 8:04 PM
>
> Hi Bruno,
>
> I will update the draft.
>
> thanks,
> Peter
>
> On 28/07/2023 14:32, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak 
> >> Sent: Thursday, July 27, 2023 8:00 PM
> >>
> >> Bruno,
> >>
> >> On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
> >>
> >>>
> >>> Bottom line:
> >>> - we see that this can be problematic in some cases
> >>> - it's very easy to fix by mandating the use of the flags(s).
> >>
> >> I believe we understand each other. I even believe we are in a violent
> >> agreement, although we have different view on some specific details.
> >>
> >> Would SHOULD language in terms of using the new flags for UPA take care
> >> of your concerns?
> >
> > To summarize, my concern is that with the current text, any advertisement 
> > with a metric higher than 0xFE00 would be interpreted as UPA by nodes 
> > enabling UPA. This essentially forbid any past or future use of this whole 
> > range of metric, which I find problematic and unnecessary.
> >
> > There may be multiple ways to address this. I can think of two (below) but 
> > I'm open to other solutions that you would propose.
> > 1) UPA behavior is triggered by one a the flag being set (and metric 
> > >0xFE00)
> > 2) UPA is triggered by a specific metric value. This would allow other 
> > usages to pick a different value without interfering with UPA. If so I 
> > would have a preference to have a registered value so creating an IANA 
> > registry would be needed (with some values for private use)
> > ...
> >
> > (Clearly, we only need one, not both of them).
> >
> > Coming back to your proposal (thank you) and your question, if option 1 
> > (flag) is used, my proposed changes are detailed in 
> > https://mailarchive.ietf.org/arch/msg/lsr/AN6Lfd58i5RS3cq06EqwOyrOLGY/
> >
> > They are recopied below for ease of discussion (and to fix some errors)
> >
> > §5.4
> > OLD:  U-Flag and UP-Flag are optional flags that have informative 
> > character. Treatment of these flags on the receiver is optional and the 
> > usage of them is outside of scope of this document.
> > NEW: The setting of the U-Flag or the UP-Flag signals that the prefix is 
> > unreachable. They constitute the UPA signals.
> >
> > §5
> > "Even though in all cases the treatment of such metric, or NU-bit, is 
> > specified for IS-IS, OSPF and OSPFv3, having an explicit way to signal that 
> > the prefix was advertised in order to signal unreachability is useful to 
> > distinguish it from other cases where the prefix with such metric is 
> > advertised."
> > :s/useful/required
> >
> > §Abstract
> > OLD:  This document describes how to use existing protocol mechanisms in 
> > IS-IS and OSPF to advertise such prefix reachability loss.
> > NEW: This document defines two new flags in IS-IS and OSPF to advertise 
> > such prefix reachability loss. In order to support incremental deployment, 
> > such advertisement use a high metric value already having special meaning 
> > in OSPF and IS-IS.
> >
> > §1
> > OLD:  This document describes how the use of existing protocol mechanisms 
> > can support the necessary functionality without the need for any protocol 
> > extensions. The functionality being described is called Unreachable Prefix 
> > Announcement (UPA).
> > NEW: This document defines two new flags in IS-IS and OSPF to support the 
> > necessary functionality. The functionality being described is called 
> > Unreachable Prefix Announcement (UPA).
> >
> >
> > I would propose an additional  editorial change
> > OLD: 5. Signaling the UPA origin
> > NEW: 5. Signaling UPA
> >
> > OLD: 5.1. Signaling the UPA origin in IS-IS
> > NEW: 5.1. Signaling UPA in IS-IS
> >
> >
> > Please feel free to reformulate as needed.
> > I've focused on IS-IS. I leave the OSPF parts up to you.
> >
> > Thanks,
> > --Bruno
> >
> >>>
> >>> What's preventing the authors to just fix this?
> >>>
> >>> In the absence of an implementation section in the draft, does the only 
> >>> disclosed implementation (IOS-XR) support the flags and set a flag with 
> >>> the UPA?
> >>
> >> I don't think discussing the details of the particular implementation
> >> belongs to this list. We can discuss that privately.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Thanks,
> >>> --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 

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

[Peter Psenak]

Hi Bruno,

I will update the draft.

thanks,
Peter

On 28/07/2023 14:32, bruno.decra...@orange.com wrote:

Peter,
  

From: Peter Psenak 
Sent: Thursday, July 27, 2023 8:00 PM

Bruno,

On 27/07/2023 16:12, bruno.decra...@orange.com wrote:



Bottom line:
- we see that this can be problematic in some cases
- it's very easy to fix by mandating the use of the flags(s).


I believe we understand each other. I even believe we are in a violent
agreement, although we have different view on some specific details.

Would SHOULD language in terms of using the new flags for UPA take care
of your concerns?


To summarize, my concern is that with the current text, any advertisement with 
a metric higher than 0xFE00 would be interpreted as UPA by nodes enabling 
UPA. This essentially forbid any past or future use of this whole range of 
metric, which I find problematic and unnecessary.

There may be multiple ways to address this. I can think of two (below) but I'm 
open to other solutions that you would propose.
1) UPA behavior is triggered by one a the flag being set (and metric 
>0xFE00)
2) UPA is triggered by a specific metric value. This would allow other usages 
to pick a different value without interfering with UPA. If so I would have a 
preference to have a registered value so creating an IANA registry would be 
needed (with some values for private use)
...

(Clearly, we only need one, not both of them).

Coming back to your proposal (thank you) and your question, if option 1 (flag) 
is used, my proposed changes are detailed in 
https://mailarchive.ietf.org/arch/msg/lsr/AN6Lfd58i5RS3cq06EqwOyrOLGY/

They are recopied below for ease of discussion (and to fix some errors)

§5.4
OLD:  U-Flag and UP-Flag are optional flags that have informative character. 
Treatment of these flags on the receiver is optional and the usage of them is 
outside of scope of this document.
NEW: The setting of the U-Flag or the UP-Flag signals that the prefix is 
unreachable. They constitute the UPA signals.

§5
"Even though in all cases the treatment of such metric, or NU-bit, is specified for 
IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised 
in order to signal unreachability is useful to distinguish it from other cases where the 
prefix with such metric is advertised."
:s/useful/required

§Abstract
OLD:  This document describes how to use existing protocol mechanisms in IS-IS 
and OSPF to advertise such prefix reachability loss.
NEW: This document defines two new flags in IS-IS and OSPF to advertise such 
prefix reachability loss. In order to support incremental deployment, such 
advertisement use a high metric value already having special meaning in OSPF 
and IS-IS.

§1
OLD:  This document describes how the use of existing protocol mechanisms can 
support the necessary functionality without the need for any protocol 
extensions. The functionality being described is called Unreachable Prefix 
Announcement (UPA).
NEW: This document defines two new flags in IS-IS and OSPF to support the 
necessary functionality. The functionality being described is called 
Unreachable Prefix Announcement (UPA).

  
I would propose an additional  editorial change

OLD: 5. Signaling the UPA origin
NEW: 5. Signaling UPA

OLD: 5.1. Signaling the UPA origin in IS-IS
NEW: 5.1. Signaling UPA in IS-IS


Please feel free to reformulate as needed.
I've focused on IS-IS. I leave the OSPF parts up to you.

Thanks,
--Bruno



What's preventing the authors to just fix this?

In the absence of an implementation section in the draft, does the only 
disclosed implementation (IOS-XR) support the flags and set a flag with the UPA?


I don't think discussing the details of the particular implementation
belongs to this list. We can discuss that privately.

thanks,
Peter



Thanks,
--Bruno


Orange Restricted

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

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

[bruno . decraene]

Peter,
 
> From: Peter Psenak 
> Sent: Thursday, July 27, 2023 8:00 PM
> 
> Bruno,
> 
> On 27/07/2023 16:12, bruno.decra...@orange.com wrote:
> 
> >
> > Bottom line:
> > - we see that this can be problematic in some cases
> > - it's very easy to fix by mandating the use of the flags(s).
> 
> I believe we understand each other. I even believe we are in a violent
> agreement, although we have different view on some specific details.
>
> Would SHOULD language in terms of using the new flags for UPA take care
> of your concerns?

To summarize, my concern is that with the current text, any advertisement with 
a metric higher than 0xFE00 would be interpreted as UPA by nodes enabling 
UPA. This essentially forbid any past or future use of this whole range of 
metric, which I find problematic and unnecessary.

There may be multiple ways to address this. I can think of two (below) but I'm 
open to other solutions that you would propose.
1) UPA behavior is triggered by one a the flag being set (and metric 
>0xFE00)
2) UPA is triggered by a specific metric value. This would allow other usages 
to pick a different value without interfering with UPA. If so I would have a 
preference to have a registered value so creating an IANA registry would be 
needed (with some values for private use)
...

(Clearly, we only need one, not both of them).

Coming back to your proposal (thank you) and your question, if option 1 (flag) 
is used, my proposed changes are detailed in 
https://mailarchive.ietf.org/arch/msg/lsr/AN6Lfd58i5RS3cq06EqwOyrOLGY/

They are recopied below for ease of discussion (and to fix some errors)

§5.4
OLD:  U-Flag and UP-Flag are optional flags that have informative character. 
Treatment of these flags on the receiver is optional and the usage of them is 
outside of scope of this document.
NEW: The setting of the U-Flag or the UP-Flag signals that the prefix is 
unreachable. They constitute the UPA signals.

§5
"Even though in all cases the treatment of such metric, or NU-bit, is specified 
for IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix 
was advertised in order to signal unreachability is useful to distinguish it 
from other cases where the prefix with such metric is advertised."
:s/useful/required

§Abstract
OLD:  This document describes how to use existing protocol mechanisms in IS-IS 
and OSPF to advertise such prefix reachability loss.
NEW: This document defines two new flags in IS-IS and OSPF to advertise such 
prefix reachability loss. In order to support incremental deployment, such 
advertisement use a high metric value already having special meaning in OSPF 
and IS-IS.

§1
OLD:  This document describes how the use of existing protocol mechanisms can 
support the necessary functionality without the need for any protocol 
extensions. The functionality being described is called Unreachable Prefix 
Announcement (UPA).
NEW: This document defines two new flags in IS-IS and OSPF to support the 
necessary functionality. The functionality being described is called 
Unreachable Prefix Announcement (UPA).

 
I would propose an additional  editorial change
OLD: 5. Signaling the UPA origin
NEW: 5. Signaling UPA

OLD: 5.1. Signaling the UPA origin in IS-IS
NEW: 5.1. Signaling UPA in IS-IS


Please feel free to reformulate as needed. 
I've focused on IS-IS. I leave the OSPF parts up to you.

Thanks,
--Bruno

> >
> > What's preventing the authors to just fix this?
> >
> > In the absence of an implementation section in the draft, does the only 
> > disclosed implementation (IOS-XR) support the flags and set a flag with the 
> > UPA?
> 
> I don't think discussing the details of the particular implementation
> belongs to this list. We can discuss that privately.
> 
> thanks,
> Peter
> 
> >
> > Thanks,
> > --Bruno

Orange Restricted

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

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

[Peter Psenak]

Bruno,

On 27/07/2023 16:12, bruno.decra...@orange.com wrote:



Bottom line:
- we see that this can be problematic in some cases
- it's very easy to fix by mandating the use of the flags(s).


I believe we understand each other. I even believe we are in a violent 
agreement, although we have different view on some specific details.


Would SHOULD language in terms of using the new flags for UPA take care 
of your concerns?




What's preventing the authors to just fix this?

In the absence of an implementation section in the draft, does the only 
disclosed implementation (IOS-XR) support the flags and set a flag with the UPA?


I don't think discussing the details of the particular implementation 
belongs to this list. We can discuss that privately.


thanks,
Peter



Thanks,
--Bruno


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

Hi Bruno

Agreed on typical ISP.

With your example if you have “BGP free” core you do not run into the
looping issue described.

Typically most ISPs run “BGP free” core.

However as Peter explained if you run BGP on the P nodes you have to run
UPA on all P nodes.

Kind Regards

Gyan

On Thu, Jul 27, 2023 at 9:31 AM  wrote:

> Hi Gyan,
>
>
>
> Please see inline.
>
>
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Thursday, July 27, 2023 6:38 AM
> *To:* DECRAENE Bruno INNOV/NET 
> *Cc:* Peter Psenak ; lsr 
> *Subject:* Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
>
>
>
> Hi Bruno
>
>
>
> Can you give an example of an application or scenario where you are
> forwarding hop by hop routing simultaneously with end to end encapsulation.
>
>
>
>1. As already replied by Robert, the point if not about having both at
>the same time. The point is to clarify the applicability of UPA. And most
>importantly, when UPA should not be used.
>2. To reply to your question, an ISP could/would typically forward hop
>by hop the IPv4 Internet traffic. It could also uses encapsulation for IPv6
>Internet (e.g. 6PE) and VPN services. (And I’m pretty certain that this is
>not a theoretical only scenario  )
>
>
>
> Regards,
>
> --Bruno
>
>
>
> So the end to end encapsulation would be MPLS, SR-MPLS or  SRv6 and both
> global table routing and L3 VPN instances and even simultaneously all three
> would be end to end encapsulation.
>
>
>
> I was trying to imagine a scenario where you have hop by hop forwarding
> which would be IP forwarding without MPLS or L3 VPN just straight IP
> forwarding.
>
>
>
> If you are doing global table IPv6 that would be the one possible scenario
> and with that in parallel have MPLS / SR-MPLS as ships in night during a
> migration  phase.
>
>
>
> RSVP-TE if you throw into the mix that is also same end to end
> encapsulation over LSP MPLS dataplane.
>
>
>
>  In an end state network I can’t see how you would have two different data
> planes simultaneously.
>
>
>
> In the DC you could have IP fabric hop by hop and migrating to NVO VXLAN
> or GENEVE end to end encapsulation.
>
>
>
> Anytime you have an  overlay such as VPN or NVO are all end to end
> encapsulations.
>
>
>
> So it’s few and far between scenarios with hop by hop which would be any
> scenario using vanilla IP fabric single tenant and no overlay.
>
>
>
> Thoughts?
>
>
>
> Gyan
>
>
>
> On Wed, Jul 26, 2023 at 10:38 AM  wrote:
>
> Peter,
>
> please see inline
>
>
> > From: Peter Psenak 
> > Sent: Tuesday, July 25, 2023 10:04 PM
> >
> > Bruno,
> >
> > please see inline:
> >
> > On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
> > > Peter,
> > >
> > > Thank for you answer. Please see inline [Bruno]
> > >
> > >
> > >> From: Peter Psenak 
> > >> Sent: Tuesday, July 25, 2023 6:11 PM
> > >>
> > >> Bruno,
> > >>
> > >> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > >>> Hi all,
> > >>>
> > >>> IP reachability advertised by IS-IS is often used by other routing
> and
> > >>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > >>> such, UPA may affect those protocols.
> > >>>
> > >>> Has UPA been presented in other WGs in the routing areas?
> > >>>
> > >>> I believe this would be prudent if not required.
> > >>
> > >> why do you believe so? How is this different to an IGP prefix becoming
> > >> unreachable without UPA?
> > >
> > > [Bruno] Because, at least for IS-IS, this is a protocol extension.
> > >
> > > When receiving:
> > > IP1/32 with metric 0xFE01
> > > IP1/24 with metric 10  (covering aggregate)
> > >
> > > Legacy routers will only consider the aggregate for the SPF/RIB
> > > IP1/24 with metric 10
> >
> > even routers with UPA processing enabled would only use IP2/24 in
> > forwarding. The UPA would only be used to send signal to apps like BGP.
>
> you are correct.
> (I meant legacy node will not see the UPA hence that IP1/32 is unreachable)
>
> > >
> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible
> and used.
> > >
> > > UPA compliant routers will consider the aggregate for the SPF/RIB,
> plus they will consider that IP1/32 is unreachable.
> >
> > no, they

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

[bruno . decraene]

Peter,

Please see inline (##Bruno2)
 

> From: Peter Psenak  
> 
> Bruno,
> 
> please see inline (##PP2):

disclaimer: to ease further reading I took the liberty to edit some #PP into 
#PP2
(if I made some errors, they were not intentional)

> 
> On 26/07/2023 23:34, bruno.decra...@orange.com wrote:
> > Peter,
> > 
> >   
> >> From: Peter Psenak 
> >> Sent: Wednesday, July 26, 2023 11:26 PM
> >>
> >> Bruno,
> >>
> >> please see inline (##PP):
> >>
> >> On 26/07/2023 22:46, bruno.decra...@orange.com wrote:
> >>> Peter,
> >>>
> >>> Please see inline
> >>>
>  From: Peter Psenak 
> 
>  Bruno,
> 
>  please see inline:
> 
>  On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > Please see inline
> > 
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 6:49 PM
> >>
> >> Bruno,
> >>
> >> please see inline:
> >>
> >> On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
> >>> Peter,
> >>>
> >>> Thanks for your answer.
> >>> Please see inline [Bruno]
> >>>  
> >>>  
>  From: Peter Psenak 
>  Sent: Tuesday, July 25, 2023 6:05 PM
> 
>  Bruno,
> 
>  On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
> >   * No reachability (state “0”) by either:
> >   o Not advertising IP1 in TLV 135
> >   o Advertising IP1 in TLV 135with a metric larger than 
> > 0xFE00
> 
>  right, one being implicit the other one explicit.
> >
> >
> > Here you agree that advertising IP1 in TLV 135with a metric larger than 
> > 0xFE00 is equivalent to No reachability / state “0” / Not 
> > advertising IP1 in TLV 135
> >
> 
> >
> > 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 0xFE00.
> >
> > 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 0xFE00 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.
> >>>
> >>> [Bruno] Good if this is what is meant in the draft and if this is 
> >>> only misunderstanding.
> >>> To be specific, I'm asking about the following changes for IS-IS 
> >>> (please feel free to reformulate, OSPF is up to you)
> >>>
> >>> §5.4
> >>> OLD:
> >>> U-Flag and UP-Flag are optional flags that have informative 
> >>> character. Treatment of these flags on the receiver is optional and 
> >>> the usage of them is outside of scope of this document.
> >>>
> >>> NEW:
> >>> The setting of the U-Flag or the UP-Flag signals that the prefix is 
> >>> unreachable. They constitute the UPA signals.
> >>
> >> I don't think above is necessary:
> >>
> >> [RFC5305] defines the encoding for advertising IPv4 prefixes using 4
> >> octets of metric information. Section 4 specifies:
> >>
> >> "If a prefix is advertised with a metric larger then MAX_PATH_METRIC
> >> (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
> >> during the normal SPF computation. This allows 

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

[bruno . decraene]

Hi Gyan,

Please see inline.


From: Gyan Mishra 
Sent: Thursday, July 27, 2023 6:38 AM
To: DECRAENE Bruno INNOV/NET 
Cc: Peter Psenak ; lsr 
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno

Can you give an example of an application or scenario where you are forwarding 
hop by hop routing simultaneously with end to end encapsulation.


  1.  As already replied by Robert, the point if not about having both at the 
same time. The point is to clarify the applicability of UPA. And most 
importantly, when UPA should not be used.
  2.  To reply to your question, an ISP could/would typically forward hop by 
hop the IPv4 Internet traffic. It could also uses encapsulation for IPv6 
Internet (e.g. 6PE) and VPN services. (And I’m pretty certain that this is not 
a theoretical only scenario  )

Regards,
--Bruno

So the end to end encapsulation would be MPLS, SR-MPLS or  SRv6 and both global 
table routing and L3 VPN instances and even simultaneously all three would be 
end to end encapsulation.

I was trying to imagine a scenario where you have hop by hop forwarding which 
would be IP forwarding without MPLS or L3 VPN just straight IP forwarding.

If you are doing global table IPv6 that would be the one possible scenario and 
with that in parallel have MPLS / SR-MPLS as ships in night during a migration  
phase.

RSVP-TE if you throw into the mix that is also same end to end encapsulation 
over LSP MPLS dataplane.

 In an end state network I can’t see how you would have two different data 
planes simultaneously.

In the DC you could have IP fabric hop by hop and migrating to NVO VXLAN or 
GENEVE end to end encapsulation.

Anytime you have an  overlay such as VPN or NVO are all end to end 
encapsulations.

So it’s few and far between scenarios with hop by hop which would be any 
scenario using vanilla IP fabric single tenant and no overlay.

Thoughts?

Gyan

On Wed, Jul 26, 2023 at 10:38 AM 
mailto:bruno.decra...@orange.com>> wrote:
Peter,

please see inline


> From: Peter Psenak mailto:ppse...@cisco.com>>
> Sent: Tuesday, July 25, 2023 10:04 PM
>
> Bruno,
>
> please see inline:
>
> On 25/07/2023 20:58, 
> bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:
> > Peter,
> >
> > Thank for you answer. Please see inline [Bruno]
> >
> >
> >> From: Peter Psenak mailto:ppse...@cisco.com>>
> >> Sent: Tuesday, July 25, 2023 6:11 PM
> >>
> >> Bruno,
> >>
> >> On 25/07/2023 14:39, 
> >> bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:
> >>> Hi all,
> >>>
> >>> IP reachability advertised by IS-IS is often used by other routing and
> >>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> >>> such, UPA may affect those protocols.
> >>>
> >>> Has UPA been presented in other WGs in the routing areas?
> >>>
> >>> I believe this would be prudent if not required.
> >>
> >> why do you believe so? How is this different to an IGP prefix becoming
> >> unreachable without UPA?
> >
> > [Bruno] Because, at least for IS-IS, this is a protocol extension.
> >
> > When receiving:
> > IP1/32 with metric 0xFE01
> > IP1/24 with metric 10  (covering aggregate)
> >
> > Legacy routers will only consider the aggregate for the SPF/RIB
> > IP1/24 with metric 10
>
> even routers with UPA processing enabled would only use IP2/24 in
> forwarding. The UPA would only be used to send signal to apps like BGP.

you are correct.
(I meant legacy node will not see the UPA hence that IP1/32 is unreachable)

> >
> > As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible and 
> > used.
> >
> > UPA compliant routers will consider the aggregate for the SPF/RIB, plus 
> > they will consider that IP1/32 is unreachable.
>
> no, they will NOT consider that IP1/32 is unreachable.
>
> UPA is only used to signal the unreachability to apps that are
> interested.

"apps" are part of the router, in particular BGP.
So let me rephrase: the BGP protocol on UPA compliant routers will consider the 
aggregate for the SPF/RIB, plus they will consider that IP1/32 is unreachable.

> What the apps do with it is out of the scope of UPA.

Use of UPA have consequences. Some good (advertising loss of reachability), 
some bads (forwarding loops for BGP prefixes which are routed hop by hop).
I don't think that we can claim the benefits (adopt UPA because it's useful for 
e.g. BGP PIC edge) and refuse to talk about the drawbacks.

>
> > As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and not 
> > used.
> >
> > (note that I have assume that the UPA 

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

[Gyan Mishra]

Understood.  Thanks for clarification.

Thanks

Gyan

On Thu, Jul 27, 2023 at 2:14 AM Robert Raszuk  wrote:

> >  where you are forwarding hop by hop routing simultaneously with end to
> end encapsulation.
>
> That is not the point here. What you said above is mutually exclusive.
>
> The issue arise when you are not doing end to end encapsulation as
> current UPA draft does not preclude using UPA for such networks where
> routing decision is made at each transit node of the domain or at each
> segment endpoint.
>
> Rgs,
> Robert
>
>
> On Wed, Jul 26, 2023 at 9:38 PM Gyan Mishra  wrote:
>
>> Hi Bruno
>>
>> Can you give an example of an application or scenario where you are
>> forwarding hop by hop routing simultaneously with end to end encapsulation.
>>
>> So the end to end encapsulation would be MPLS, SR-MPLS or  SRv6 and both
>> global table routing and L3 VPN instances and even simultaneously all three
>> would be end to end encapsulation.
>>
>> I was trying to imagine a scenario where you have hop by hop forwarding
>> which would be IP forwarding without MPLS or L3 VPN just straight IP
>> forwarding.
>>
>> If you are doing global table IPv6 that would be the one possible
>> scenario and with that in parallel have MPLS / SR-MPLS as ships in night
>> during a migration  phase.
>>
>> RSVP-TE if you throw into the mix that is also same end to end
>> encapsulation over LSP MPLS dataplane.
>>
>>  In an end state network I can’t see how you would have two different
>> data planes simultaneously.
>>
>> In the DC you could have IP fabric hop by hop and migrating to NVO VXLAN
>> or GENEVE end to end encapsulation.
>>
>> Anytime you have an  overlay such as VPN or NVO are all end to end
>> encapsulations.
>>
>> So it’s few and far between scenarios with hop by hop which would be any
>> scenario using vanilla IP fabric single tenant and no overlay.
>>
>> Thoughts?
>>
>> Gyan
>>
>> On Wed, Jul 26, 2023 at 10:38 AM  wrote:
>>
>>> Peter,
>>>
>>> please see inline
>>>
>>>
>>> > From: Peter Psenak 
>>> > Sent: Tuesday, July 25, 2023 10:04 PM
>>> >
>>> > Bruno,
>>> >
>>> > please see inline:
>>> >
>>> > On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
>>> > > Peter,
>>> > >
>>> > > Thank for you answer. Please see inline [Bruno]
>>> > >
>>> > >
>>> > >> From: Peter Psenak 
>>> > >> Sent: Tuesday, July 25, 2023 6:11 PM
>>> > >>
>>> > >> Bruno,
>>> > >>
>>> > >> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
>>> > >>> Hi all,
>>> > >>>
>>> > >>> IP reachability advertised by IS-IS is often used by other routing
>>> and
>>> > >>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...).
>>> As
>>> > >>> such, UPA may affect those protocols.
>>> > >>>
>>> > >>> Has UPA been presented in other WGs in the routing areas?
>>> > >>>
>>> > >>> I believe this would be prudent if not required.
>>> > >>
>>> > >> why do you believe so? How is this different to an IGP prefix
>>> becoming
>>> > >> unreachable without UPA?
>>> > >
>>> > > [Bruno] Because, at least for IS-IS, this is a protocol extension.
>>> > >
>>> > > When receiving:
>>> > > IP1/32 with metric 0xFE01
>>> > > IP1/24 with metric 10  (covering aggregate)
>>> > >
>>> > > Legacy routers will only consider the aggregate for the SPF/RIB
>>> > > IP1/24 with metric 10
>>> >
>>> > even routers with UPA processing enabled would only use IP2/24 in
>>> > forwarding. The UPA would only be used to send signal to apps like BGP.
>>>
>>> you are correct.
>>> (I meant legacy node will not see the UPA hence that IP1/32 is
>>> unreachable)
>>>
>>> > >
>>> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible
>>> and used.
>>> > >
>>> > > UPA compliant routers will consider the aggregate for the SPF/RIB,
>>> plus they will consider that IP1/32 is unreachable.
>>> >
>>> > no, they will NOT consider that IP1/32 is unreachable.
>>> >
>>> > UPA is only used to signal the unreachability to apps that are
>>> > interested.
>>>
>>> "apps" are part of the router, in particular BGP.
>>> So let me rephrase: the BGP protocol on UPA compliant routers will
>>> consider the aggregate for the SPF/RIB, plus they will consider that IP1/32
>>> is unreachable.
>>>
>>> > What the apps do with it is out of the scope of UPA.
>>>
>>> Use of UPA have consequences. Some good (advertising loss of
>>> reachability), some bads (forwarding loops for BGP prefixes which are
>>> routed hop by hop).
>>> I don't think that we can claim the benefits (adopt UPA because it's
>>> useful for e.g. BGP PIC edge) and refuse to talk about the drawbacks.
>>>
>>> >
>>> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible
>>> and not used.
>>> > >
>>> > > (note that I have assume that the UPA signal is sent to BGP, but
>>> this is the same picture if UPA is only used by BGP PIC Edge)
>>> > >
>>> > >
>>> > >
>>> > >>>
>>> > >>> In particular, BGP is (heavily) using reachability of (loopbacks)
>>> > >>> addresses advertised in IS-IS in order to evaluate the
>>> reachability of

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

[Robert Raszuk]

>  where you are forwarding hop by hop routing simultaneously with end to
end encapsulation.

That is not the point here. What you said above is mutually exclusive.

The issue arise when you are not doing end to end encapsulation as
current UPA draft does not preclude using UPA for such networks where
routing decision is made at each transit node of the domain or at each
segment endpoint.

Rgs,
Robert


On Wed, Jul 26, 2023 at 9:38 PM Gyan Mishra  wrote:

> Hi Bruno
>
> Can you give an example of an application or scenario where you are
> forwarding hop by hop routing simultaneously with end to end encapsulation.
>
> So the end to end encapsulation would be MPLS, SR-MPLS or  SRv6 and both
> global table routing and L3 VPN instances and even simultaneously all three
> would be end to end encapsulation.
>
> I was trying to imagine a scenario where you have hop by hop forwarding
> which would be IP forwarding without MPLS or L3 VPN just straight IP
> forwarding.
>
> If you are doing global table IPv6 that would be the one possible scenario
> and with that in parallel have MPLS / SR-MPLS as ships in night during a
> migration  phase.
>
> RSVP-TE if you throw into the mix that is also same end to end
> encapsulation over LSP MPLS dataplane.
>
>  In an end state network I can’t see how you would have two different data
> planes simultaneously.
>
> In the DC you could have IP fabric hop by hop and migrating to NVO VXLAN
> or GENEVE end to end encapsulation.
>
> Anytime you have an  overlay such as VPN or NVO are all end to end
> encapsulations.
>
> So it’s few and far between scenarios with hop by hop which would be any
> scenario using vanilla IP fabric single tenant and no overlay.
>
> Thoughts?
>
> Gyan
>
> On Wed, Jul 26, 2023 at 10:38 AM  wrote:
>
>> Peter,
>>
>> please see inline
>>
>>
>> > From: Peter Psenak 
>> > Sent: Tuesday, July 25, 2023 10:04 PM
>> >
>> > Bruno,
>> >
>> > please see inline:
>> >
>> > On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
>> > > Peter,
>> > >
>> > > Thank for you answer. Please see inline [Bruno]
>> > >
>> > >
>> > >> From: Peter Psenak 
>> > >> Sent: Tuesday, July 25, 2023 6:11 PM
>> > >>
>> > >> Bruno,
>> > >>
>> > >> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
>> > >>> Hi all,
>> > >>>
>> > >>> IP reachability advertised by IS-IS is often used by other routing
>> and
>> > >>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...).
>> As
>> > >>> such, UPA may affect those protocols.
>> > >>>
>> > >>> Has UPA been presented in other WGs in the routing areas?
>> > >>>
>> > >>> I believe this would be prudent if not required.
>> > >>
>> > >> why do you believe so? How is this different to an IGP prefix
>> becoming
>> > >> unreachable without UPA?
>> > >
>> > > [Bruno] Because, at least for IS-IS, this is a protocol extension.
>> > >
>> > > When receiving:
>> > > IP1/32 with metric 0xFE01
>> > > IP1/24 with metric 10  (covering aggregate)
>> > >
>> > > Legacy routers will only consider the aggregate for the SPF/RIB
>> > > IP1/24 with metric 10
>> >
>> > even routers with UPA processing enabled would only use IP2/24 in
>> > forwarding. The UPA would only be used to send signal to apps like BGP.
>>
>> you are correct.
>> (I meant legacy node will not see the UPA hence that IP1/32 is
>> unreachable)
>>
>> > >
>> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible
>> and used.
>> > >
>> > > UPA compliant routers will consider the aggregate for the SPF/RIB,
>> plus they will consider that IP1/32 is unreachable.
>> >
>> > no, they will NOT consider that IP1/32 is unreachable.
>> >
>> > UPA is only used to signal the unreachability to apps that are
>> > interested.
>>
>> "apps" are part of the router, in particular BGP.
>> So let me rephrase: the BGP protocol on UPA compliant routers will
>> consider the aggregate for the SPF/RIB, plus they will consider that IP1/32
>> is unreachable.
>>
>> > What the apps do with it is out of the scope of UPA.
>>
>> Use of UPA have consequences. Some good (advertising loss of
>> reachability), some bads (forwarding loops for BGP prefixes which are
>> routed hop by hop).
>> I don't think that we can claim the benefits (adopt UPA because it's
>> useful for e.g. BGP PIC edge) and refuse to talk about the drawbacks.
>>
>> >
>> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible
>> and not used.
>> > >
>> > > (note that I have assume that the UPA signal is sent to BGP, but this
>> is the same picture if UPA is only used by BGP PIC Edge)
>> > >
>> > >
>> > >
>> > >>>
>> > >>> In particular, BGP is (heavily) using reachability of (loopbacks)
>> > >>> addresses advertised in IS-IS in order to evaluate the reachability
>> of
>> > >>> BGP routes and compute their preference.
>> > >>>
>> > >>> If UPA is not interpreted the same ways by all routers, forwarding
>> loops
>> > >>> may occur in a hop by hop routed network. (because different routers
>> > >>> would select different paths since 

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

[Gyan Mishra]

Hi Bruno

Can you give an example of an application or scenario where you are
forwarding hop by hop routing simultaneously with end to end encapsulation.

So the end to end encapsulation would be MPLS, SR-MPLS or  SRv6 and both
global table routing and L3 VPN instances and even simultaneously all three
would be end to end encapsulation.

I was trying to imagine a scenario where you have hop by hop forwarding
which would be IP forwarding without MPLS or L3 VPN just straight IP
forwarding.

If you are doing global table IPv6 that would be the one possible scenario
and with that in parallel have MPLS / SR-MPLS as ships in night during a
migration  phase.

RSVP-TE if you throw into the mix that is also same end to end
encapsulation over LSP MPLS dataplane.

 In an end state network I can’t see how you would have two different data
planes simultaneously.

In the DC you could have IP fabric hop by hop and migrating to NVO VXLAN or
GENEVE end to end encapsulation.

Anytime you have an  overlay such as VPN or NVO are all end to end
encapsulations.

So it’s few and far between scenarios with hop by hop which would be any
scenario using vanilla IP fabric single tenant and no overlay.

Thoughts?

Gyan

On Wed, Jul 26, 2023 at 10:38 AM  wrote:

> Peter,
>
> please see inline
>
>
> > From: Peter Psenak 
> > Sent: Tuesday, July 25, 2023 10:04 PM
> >
> > Bruno,
> >
> > please see inline:
> >
> > On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
> > > Peter,
> > >
> > > Thank for you answer. Please see inline [Bruno]
> > >
> > >
> > >> From: Peter Psenak 
> > >> Sent: Tuesday, July 25, 2023 6:11 PM
> > >>
> > >> Bruno,
> > >>
> > >> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > >>> Hi all,
> > >>>
> > >>> IP reachability advertised by IS-IS is often used by other routing
> and
> > >>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > >>> such, UPA may affect those protocols.
> > >>>
> > >>> Has UPA been presented in other WGs in the routing areas?
> > >>>
> > >>> I believe this would be prudent if not required.
> > >>
> > >> why do you believe so? How is this different to an IGP prefix becoming
> > >> unreachable without UPA?
> > >
> > > [Bruno] Because, at least for IS-IS, this is a protocol extension.
> > >
> > > When receiving:
> > > IP1/32 with metric 0xFE01
> > > IP1/24 with metric 10  (covering aggregate)
> > >
> > > Legacy routers will only consider the aggregate for the SPF/RIB
> > > IP1/24 with metric 10
> >
> > even routers with UPA processing enabled would only use IP2/24 in
> > forwarding. The UPA would only be used to send signal to apps like BGP.
>
> you are correct.
> (I meant legacy node will not see the UPA hence that IP1/32 is unreachable)
>
> > >
> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible
> and used.
> > >
> > > UPA compliant routers will consider the aggregate for the SPF/RIB,
> plus they will consider that IP1/32 is unreachable.
> >
> > no, they will NOT consider that IP1/32 is unreachable.
> >
> > UPA is only used to signal the unreachability to apps that are
> > interested.
>
> "apps" are part of the router, in particular BGP.
> So let me rephrase: the BGP protocol on UPA compliant routers will
> consider the aggregate for the SPF/RIB, plus they will consider that IP1/32
> is unreachable.
>
> > What the apps do with it is out of the scope of UPA.
>
> Use of UPA have consequences. Some good (advertising loss of
> reachability), some bads (forwarding loops for BGP prefixes which are
> routed hop by hop).
> I don't think that we can claim the benefits (adopt UPA because it's
> useful for e.g. BGP PIC edge) and refuse to talk about the drawbacks.
>
> >
> > > As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and
> not used.
> > >
> > > (note that I have assume that the UPA signal is sent to BGP, but this
> is the same picture if UPA is only used by BGP PIC Edge)
> > >
> > >
> > >
> > >>>
> > >>> In particular, BGP is (heavily) using reachability of (loopbacks)
> > >>> addresses advertised in IS-IS in order to evaluate the reachability
> of
> > >>> BGP routes and compute their preference.
> > >>>
> > >>> If UPA is not interpreted the same ways by all routers, forwarding
> loops
> > >>> may occur in a hop by hop routed network. (because different routers
> > >>> would select different paths since they use different information to
> > >>> select their path)
> > >>
> > >> I don't see a problem, please provide an example.
> > >
> > > iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
> > > |
> > > |
> > > ePE3 (IP1)
> > >
> > >
> > > 
> > >
> > > ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering
> routers in L2.
> > >
> > >
> > >
> > > ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have
> both BGP paths to IP1.
> > > Traffic to IP1 is IP routed hop by hop from iPE1.
> > > P2 support 

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

[Robert Raszuk]

Peter,

I am with you that enabling signalling UPA to the application is up to the
operator.

But going with Bruno's concern, the app (say BGP) on vendor X may use UPA
in a completely different way that on vendor Y then again on vendor Z. One
may invalidate a path with a given next hop for 5 sec the other for 120 sec
etc ... as an example.

So as suggested I think UPA should not be (in fact I would use normative
MUST NOT be) enabled for address families which do not use end to end
encapsulation.

Thx,
R,

On Wed, Jul 26, 2023 at 8:41 AM Peter Psenak  wrote:

> Hi Bruno,
>
> please see inline:
>
> On 26/07/2023 16:38, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > please see inline
> >
> >
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 10:04 PM
> >>
> >> Bruno,
> >>
> >> please see inline:
> >>
> >> On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
> >>> Peter,
> >>>
> >>> Thank for you answer. Please see inline [Bruno]
> >>>
> >>>
>  From: Peter Psenak 
>  Sent: Tuesday, July 25, 2023 6:11 PM
> 
>  Bruno,
> 
>  On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > IP reachability advertised by IS-IS is often used by other routing
> and
> > signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > such, UPA may affect those protocols.
> >
> > Has UPA been presented in other WGs in the routing areas?
> >
> > I believe this would be prudent if not required.
> 
>  why do you believe so? How is this different to an IGP prefix becoming
>  unreachable without UPA?
> >>>
> >>> [Bruno] Because, at least for IS-IS, this is a protocol extension.
> >>>
> >>> When receiving:
> >>> IP1/32 with metric 0xFE01
> >>> IP1/24 with metric 10  (covering aggregate)
> >>>
> >>> Legacy routers will only consider the aggregate for the SPF/RIB
> >>> IP1/24 with metric 10
> >>
> >> even routers with UPA processing enabled would only use IP2/24 in
> >> forwarding. The UPA would only be used to send signal to apps like BGP.
> >
> > you are correct.
> > (I meant legacy node will not see the UPA hence that IP1/32 is
> unreachable)
> >
> >>>
> >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible
> and used.
> >>>
> >>> UPA compliant routers will consider the aggregate for the SPF/RIB,
> plus they will consider that IP1/32 is unreachable.
> >>
> >> no, they will NOT consider that IP1/32 is unreachable.
> >>
> >> UPA is only used to signal the unreachability to apps that are
> >> interested.
> >
> > "apps" are part of the router, in particular BGP.
> > So let me rephrase: the BGP protocol on UPA compliant routers will
> consider the aggregate for the SPF/RIB, plus they will consider that IP1/32
> is unreachable.
> >
> >> What the apps do with it is out of the scope of UPA.
> >
> > Use of UPA have consequences. Some good (advertising loss of
> reachability), some bads (forwarding loops for BGP prefixes which are
> routed hop by hop).
> > I don't think that we can claim the benefits (adopt UPA because it's
> useful for e.g. BGP PIC edge) and refuse to talk about the drawbacks.
>
> ##PP
> we basically leave the responsibility to the consumer of the UPA, as the
> treatment of the UPA signal an its consequence on the app is app specific.
>
> But we can clarify that in the draft.
>
> >
> >>
> >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and
> not used.
> >>>
> >>> (note that I have assume that the UPA signal is sent to BGP, but this
> is the same picture if UPA is only used by BGP PIC Edge)
> >>>
> >>>
> >>>
> >
> > In particular, BGP is (heavily) using reachability of (loopbacks)
> > addresses advertised in IS-IS in order to evaluate the reachability
> of
> > BGP routes and compute their preference.
> >
> > If UPA is not interpreted the same ways by all routers, forwarding
> loops
> > may occur in a hop by hop routed network. (because different routers
> > would select different paths since they use different information to
> > select their path)
> 
>  I don't see a problem, please provide an example.
> >>>
> >>> iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
> >>>  |
> >>>  |
> >>> ePE3 (IP1)
> >>>
> >>>
> >>> 
> >>>
> >>> ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering
> routers in L2.
> >>>
> >>>
> >>>
> >>> ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have
> both BGP paths to IP1.
> >>> Traffic to IP1 is IP routed hop by hop from iPE1.
> >>> P2 support UPA, P1 does not.
> >>> ePE2 fails and ABR1 advertise UPA in level 1.
> >>>
> >>>
> >>> P1 does not support UPA so is unaware of ePE2 failure and keeps
> routing IP1 toward ePE2, hence P2.
> >>> P2 supports UPA so knows that the ePE2 is down and invalidate BGP
> routes using this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.
> >>>

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

[Peter Psenak]

Bruno,

please see inline (##PP2):

On 26/07/2023 23:34, bruno.decra...@orange.com wrote:

Peter,

  

From: Peter Psenak 
Sent: Wednesday, July 26, 2023 11:26 PM

Bruno,

please see inline (##PP):

On 26/07/2023 22:46, bruno.decra...@orange.com wrote:

Peter,

Please see inline
   

From: Peter Psenak 

Bruno,

please see inline:

On 25/07/2023 21:11, bruno.decra...@orange.com wrote:

Peter,

Please see inline


From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:49 PM

Bruno,

please see inline:

On 25/07/2023 18:36, bruno.decra...@orange.com wrote:

Peter,

Thanks for your answer.
Please see inline [Bruno]
 
 

From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:05 PM

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
  * No reachability (state “0”) by either:
  o Not advertising IP1 in TLV 135
  o Advertising IP1 in TLV 135with a metric larger than 0xFE00


right, one being implicit the other one explicit.



Here you agree that advertising IP1 in TLV 135with a metric larger than 
0xFE00 is equivalent to No reachability / state “0” / Not advertising IP1 
in TLV 135





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 0xFE00.

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 0xFE00 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.


[Bruno] Good if this is what is meant in the draft and if this is only 
misunderstanding.
To be specific, I'm asking about the following changes for IS-IS (please feel 
free to reformulate, OSPF is up to you)

§5.4
OLD:
U-Flag and UP-Flag are optional flags that have informative character. 
Treatment of these flags on the receiver is optional and the usage of them is 
outside of scope of this document.

NEW:
The setting of the U-Flag or the UP-Flag signals that the prefix is 
unreachable. They constitute the UPA signals.


I don't think above is necessary:

[RFC5305] defines the encoding for advertising IPv4 prefixes using 4
octets of metric information. Section 4 specifies:

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE00, 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. "


Agreed with the quote.

"prefix NOT considered during normal SPF computation" does not change/affect 
the outcome of the SPF computation. Hence does not remove reachability if a covering 
prefix is present.


right. And UPA treatment is no different. It is only used to signal
unreachability to apps that are interested. It does not change anything
in forwarding itself.


UPA changes/stop forwarding to BGP prefix using the UPA prefix as netxt-hop.
This is a change in forwarding.


##PP
If the egress PE goes down BGP would move away to alternate NH -  all we
do with UPA is to let BGP know sooner. Processing of the UPA is optional
and you are free ignore it and wait till the BGP finds out the remote PE
is dead. I see no backward compatibility problem here.


   


Plus at the beginning of this email, you agreed that this signaling translate into state 
"0". (absence of reachability signal)
I don't see how you can now say that this signaling translate in state "-1" 
(negative reachability)



As a result of the above, from the IP routing perspective, prefix with a
metric larger then MAX_PATH_METRIC (0xFE0) MUST be treated as
unreachable.


a) This prefix is absent in the RIB/FIB (just like if it were not advertised in 
TLV)
b) Covering prefix is in the RIB/FIB.
c) Net result is (positive) reachability.

Could you point to the line(s) that you disagree with?


I agree, and 

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

[bruno . decraene]

Peter,

 
> From: Peter Psenak  
> Sent: Wednesday, July 26, 2023 11:26 PM
> 
> Bruno,
> 
> please see inline (##PP):
> 
> On 26/07/2023 22:46, bruno.decra...@orange.com wrote:
> > Peter,
> > 
> > Please see inline
> >   
> >> From: Peter Psenak 
> >>
> >> Bruno,
> >>
> >> please see inline:
> >>
> >> On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
> >>> Peter,
> >>>
> >>> Please see inline
> >>>
>  From: Peter Psenak 
>  Sent: Tuesday, July 25, 2023 6:49 PM
> 
>  Bruno,
> 
>  please see inline:
> 
>  On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
> > Peter,
> >
> > Thanks for your answer.
> > Please see inline [Bruno]
> > 
> > 
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 6:05 PM
> >>
> >> Bruno,
> >>
> >> On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
> >>>  * No reachability (state “0”) by either:
> >>>  o Not advertising IP1 in TLV 135
> >>>  o Advertising IP1 in TLV 135with a metric larger than 
> >>> 0xFE00
> >>
> >> right, one being implicit the other one explicit.
> >>>
> >>>
> >>> Here you agree that advertising IP1 in TLV 135with a metric larger than 
> >>> 0xFE00 is equivalent to No reachability / state “0” / Not advertising 
> >>> IP1 in TLV 135
> >>>
> >>
> >>>
> >>> 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 0xFE00.
> >>>
> >>> 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 0xFE00 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.
> >
> > [Bruno] Good if this is what is meant in the draft and if this is only 
> > misunderstanding.
> > To be specific, I'm asking about the following changes for IS-IS 
> > (please feel free to reformulate, OSPF is up to you)
> >
> > §5.4
> > OLD:
> > U-Flag and UP-Flag are optional flags that have informative character. 
> > Treatment of these flags on the receiver is optional and the usage of 
> > them is outside of scope of this document.
> >
> > NEW:
> > The setting of the U-Flag or the UP-Flag signals that the prefix is 
> > unreachable. They constitute the UPA signals.
> 
>  I don't think above is necessary:
> 
>  [RFC5305] defines the encoding for advertising IPv4 prefixes using 4
>  octets of metric information. Section 4 specifies:
> 
>  "If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>  (0xFE00, 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. "
> >>>
> >>> Agreed with the quote.
> >>>
> >>> "prefix NOT considered during normal SPF computation" does not 
> >>> change/affect the outcome of the SPF computation. Hence does not remove 
> >>> reachability if a covering prefix is present.
> >>
> >> right. And UPA treatment is no different. It is only used to signal
> >> unreachability to apps that are interested. It does not change anything
> >> in forwarding itself.
> > 
> > UPA changes/stop forwarding to BGP prefix using the UPA prefix as netxt-hop.
> > This is a change in forwarding.
> 
> ##PP
> If the egress PE 

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

[Peter Psenak]

Bruno,

please see inline (##PP):

On 26/07/2023 22:46, bruno.decra...@orange.com wrote:

Peter,

Please see inline
  

From: Peter Psenak 

Bruno,

please see inline:

On 25/07/2023 21:11, bruno.decra...@orange.com wrote:

Peter,

Please see inline
   

From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:49 PM

Bruno,

please see inline:

On 25/07/2023 18:36, bruno.decra...@orange.com wrote:

Peter,

Thanks for your answer.
Please see inline [Bruno]



From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:05 PM

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
 * No reachability (state “0”) by either:
 o Not advertising IP1 in TLV 135
 o Advertising IP1 in TLV 135with a metric larger than 0xFE00


right, one being implicit the other one explicit.



Here you agree that advertising IP1 in TLV 135with a metric larger than 
0xFE00 is equivalent to No reachability / state “0” / Not advertising IP1 
in TLV 135





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 0xFE00.

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 0xFE00 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.


[Bruno] Good if this is what is meant in the draft and if this is only 
misunderstanding.
To be specific, I'm asking about the following changes for IS-IS (please feel 
free to reformulate, OSPF is up to you)

§5.4
OLD:
U-Flag and UP-Flag are optional flags that have informative character. 
Treatment of these flags on the receiver is optional and the usage of them is 
outside of scope of this document.

NEW:
The setting of the U-Flag or the UP-Flag signals that the prefix is 
unreachable. They constitute the UPA signals.


I don't think above is necessary:

[RFC5305] defines the encoding for advertising IPv4 prefixes using 4
octets of metric information. Section 4 specifies:

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE00, 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. "


Agreed with the quote.

"prefix NOT considered during normal SPF computation" does not change/affect 
the outcome of the SPF computation. Hence does not remove reachability if a covering 
prefix is present.


right. And UPA treatment is no different. It is only used to signal
unreachability to apps that are interested. It does not change anything
in forwarding itself.


UPA changes/stop forwarding to BGP prefix using the UPA prefix as netxt-hop.
This is a change in forwarding.


##PP
If the egress PE goes down BGP would move away to alternate NH -  all we 
do with UPA is to let BGP know sooner. Processing of the UPA is optional 
and you are free ignore it and wait till the BGP finds out the remote PE 
is dead. I see no backward compatibility problem here.



  


Plus at the beginning of this email, you agreed that this signaling translate into state 
"0". (absence of reachability signal)
I don't see how you can now say that this signaling translate in state "-1" 
(negative reachability)

   

As a result of the above, from the IP routing perspective, prefix with a
metric larger then MAX_PATH_METRIC (0xFE0) MUST be treated as
unreachable.


a) This prefix is absent in the RIB/FIB (just like if it were not advertised in 
TLV)
b) Covering prefix is in the RIB/FIB.
c) Net result is (positive) reachability.

Could you point to the line(s) that you disagree with?


I agree, and exactly same happens with UPA in terms of forwarding.


Let's have IP2 being a BGP prefix having IP1 as BGP NH

Today, if IP1 is advertised with a metric larger then 

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

[bruno . decraene]

Peter,

Please see inline
 
> From: Peter Psenak  
> 
> Bruno,
> 
> please see inline:
> 
> On 25/07/2023 21:11, bruno.decra...@orange.com wrote:
> > Peter,
> > 
> > Please see inline
> >   
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 6:49 PM
> >>
> >> Bruno,
> >>
> >> please see inline:
> >>
> >> On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
> >>> Peter,
> >>>
> >>> Thanks for your answer.
> >>> Please see inline [Bruno]
> >>>
> >>>
>  From: Peter Psenak 
>  Sent: Tuesday, July 25, 2023 6:05 PM
> 
>  Bruno,
> 
>  On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
> > * No reachability (state “0”) by either:
> > o Not advertising IP1 in TLV 135
> > o Advertising IP1 in TLV 135with a metric larger than 0xFE00
> 
>  right, one being implicit the other one explicit.
> > 
> > 
> > Here you agree that advertising IP1 in TLV 135with a metric larger than 
> > 0xFE00 is equivalent to No reachability / state “0” / Not advertising 
> > IP1 in TLV 135
> > 
> 
> >
> > 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 0xFE00.
> >
> > 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 0xFE00 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.
> >>>
> >>> [Bruno] Good if this is what is meant in the draft and if this is only 
> >>> misunderstanding.
> >>> To be specific, I'm asking about the following changes for IS-IS (please 
> >>> feel free to reformulate, OSPF is up to you)
> >>>
> >>> §5.4
> >>> OLD:
> >>> U-Flag and UP-Flag are optional flags that have informative character. 
> >>> Treatment of these flags on the receiver is optional and the usage of 
> >>> them is outside of scope of this document.
> >>>
> >>> NEW:
> >>> The setting of the U-Flag or the UP-Flag signals that the prefix is 
> >>> unreachable. They constitute the UPA signals.
> >>
> >> I don't think above is necessary:
> >>
> >> [RFC5305] defines the encoding for advertising IPv4 prefixes using 4
> >> octets of metric information. Section 4 specifies:
> >>
> >> "If a prefix is advertised with a metric larger then MAX_PATH_METRIC
> >> (0xFE00, 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. "
> > 
> > Agreed with the quote.
> > 
> > "prefix NOT considered during normal SPF computation" does not 
> > change/affect the outcome of the SPF computation. Hence does not remove 
> > reachability if a covering prefix is present.
> 
> right. And UPA treatment is no different. It is only used to signal 
> unreachability to apps that are interested. It does not change anything 
> in forwarding itself.

UPA changes/stop forwarding to BGP prefix using the UPA prefix as netxt-hop.
This is a change in forwarding.
 
> > 
> > Plus at the beginning of this email, you agreed that this signaling 
> > translate into state "0". (absence of reachability signal)
> > I don't see how you can now say that this signaling translate in state "-1" 
> > (negative reachability)
> > 
> >   
> >> As a result of the above, from the IP routing perspective, prefix with a
> >> metric larger then MAX_PATH_METRIC (0xFE0) MUST be treated as
> >> unreachable.
> > 
> > a) This prefix is absent in the RIB/FIB (just like if it were not 
> > 

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

[bruno . decraene]

Hi Peter,

Please see inline.

 
> From: Peter Psenak  
> Sent: Wednesday, July 26, 2023 5:41 PM
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 26/07/2023 16:38, bruno.decra...@orange.com wrote:
> > Peter,
> > 
> > please see inline
> >   
> > 
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 10:04 PM
> >>
> >> Bruno,
> >>
> >> please see inline:
> >>
> >> On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
> >>> Peter,
> >>>
> >>> Thank for you answer. Please see inline [Bruno]
> >>>
> >>>
>  From: Peter Psenak 
>  Sent: Tuesday, July 25, 2023 6:11 PM
> 
>  Bruno,
> 
>  On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > IP reachability advertised by IS-IS is often used by other routing and
> > signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > such, UPA may affect those protocols.
> >
> > Has UPA been presented in other WGs in the routing areas?
> >
> > I believe this would be prudent if not required.
> 
>  why do you believe so? How is this different to an IGP prefix becoming
>  unreachable without UPA?
> >>>
> >>> [Bruno] Because, at least for IS-IS, this is a protocol extension.
> >>>
> >>> When receiving:
> >>> IP1/32 with metric 0xFE01
> >>> IP1/24 with metric 10  (covering aggregate)
> >>>
> >>> Legacy routers will only consider the aggregate for the SPF/RIB
> >>> IP1/24 with metric 10
> >>
> >> even routers with UPA processing enabled would only use IP2/24 in
> >> forwarding. The UPA would only be used to send signal to apps like BGP.
> > 
> > you are correct.
> > (I meant legacy node will not see the UPA hence that IP1/32 is unreachable)
> >   
> >>>
> >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible and 
> >>> used.
> >>>
> >>> UPA compliant routers will consider the aggregate for the SPF/RIB, plus 
> >>> they will consider that IP1/32 is unreachable.
> >>
> >> no, they will NOT consider that IP1/32 is unreachable.
> >>
> >> UPA is only used to signal the unreachability to apps that are
> >> interested.
> > 
> > "apps" are part of the router, in particular BGP.
> > So let me rephrase: the BGP protocol on UPA compliant routers will consider 
> > the aggregate for the SPF/RIB, plus they will consider that IP1/32 is 
> > unreachable.
> > 
> >> What the apps do with it is out of the scope of UPA.
> > 
> > Use of UPA have consequences. Some good (advertising loss of reachability), 
> > some bads (forwarding loops for BGP prefixes which are routed hop by hop).
> > I don't think that we can claim the benefits (adopt UPA because it's useful 
> > for e.g. BGP PIC edge) and refuse to talk about the drawbacks.
> 
> ##PP
> we basically leave the responsibility to the consumer of the UPA, as the 
> treatment of the UPA signal an its consequence on the app is app specific.
> 
> But we can clarify that in the draft.
> 
> >   
> >>
> >>> As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and 
> >>> not used.
> >>>
> >>> (note that I have assume that the UPA signal is sent to BGP, but this is 
> >>> the same picture if UPA is only used by BGP PIC Edge)
> >>>
> >>>
> >>>
> >
> > In particular, BGP is (heavily) using reachability of (loopbacks)
> > addresses advertised in IS-IS in order to evaluate the reachability of
> > BGP routes and compute their preference.
> >
> > If UPA is not interpreted the same ways by all routers, forwarding loops
> > may occur in a hop by hop routed network. (because different routers
> > would select different paths since they use different information to
> > select their path)
> 
>  I don't see a problem, please provide an example.
> >>>
> >>> iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
> >>>  |
> >>>  |
> >>>   ePE3 (IP1)
> >>>
> >>>
> >>> 
> >>>
> >>> ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering routers 
> >>> in L2.
> >>>
> >>>
> >>>
> >>> ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have 
> >>> both BGP paths to IP1.
> >>> Traffic to IP1 is IP routed hop by hop from iPE1.
> >>> P2 support UPA, P1 does not.
> >>> ePE2 fails and ABR1 advertise UPA in level 1.
> >>>
> >>>
> >>> P1 does not support UPA so is unaware of ePE2 failure and keeps routing 
> >>> IP1 toward ePE2, hence P2.
> >>> P2 supports UPA so knows that the ePE2 is down and invalidate BGP routes 
> >>> using this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.
> >>>
> >>> --> forwarding loop between P1 and P2 for destination IP1
> >>
> >> - UPA processing is optional and disabled by default
> >> - typically P1 and P2 would not run BGP at all, so there would be no
> >> issues if UPA would be used on iPE1
> >> - if you run BGP hop by hop, you would need to consistently enable UPA
> >> on all routers.
> > 
> > Good that we agree on some bad consequences of 

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

[Peter Psenak]

Hi Bruno,

please see inline:

On 26/07/2023 16:38, bruno.decra...@orange.com wrote:

Peter,

please see inline
  


From: Peter Psenak 
Sent: Tuesday, July 25, 2023 10:04 PM

Bruno,

please see inline:

On 25/07/2023 20:58, bruno.decra...@orange.com wrote:

Peter,

Thank for you answer. Please see inline [Bruno]
   
   

From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:11 PM

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com wrote:

Hi all,

IP reachability advertised by IS-IS is often used by other routing and
signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
such, UPA may affect those protocols.

Has UPA been presented in other WGs in the routing areas?

I believe this would be prudent if not required.


why do you believe so? How is this different to an IGP prefix becoming
unreachable without UPA?


[Bruno] Because, at least for IS-IS, this is a protocol extension.

When receiving:
IP1/32 with metric 0xFE01
IP1/24 with metric 10  (covering aggregate)

Legacy routers will only consider the aggregate for the SPF/RIB
IP1/24 with metric 10


even routers with UPA processing enabled would only use IP2/24 in
forwarding. The UPA would only be used to send signal to apps like BGP.


you are correct.
(I meant legacy node will not see the UPA hence that IP1/32 is unreachable)
  


As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible and used.

UPA compliant routers will consider the aggregate for the SPF/RIB, plus they 
will consider that IP1/32 is unreachable.


no, they will NOT consider that IP1/32 is unreachable.

UPA is only used to signal the unreachability to apps that are
interested.


"apps" are part of the router, in particular BGP.
So let me rephrase: the BGP protocol on UPA compliant routers will consider the 
aggregate for the SPF/RIB, plus they will consider that IP1/32 is unreachable.


What the apps do with it is out of the scope of UPA.


Use of UPA have consequences. Some good (advertising loss of reachability), 
some bads (forwarding loops for BGP prefixes which are routed hop by hop).
I don't think that we can claim the benefits (adopt UPA because it's useful for 
e.g. BGP PIC edge) and refuse to talk about the drawbacks.


##PP
we basically leave the responsibility to the consumer of the UPA, as the 
treatment of the UPA signal an its consequence on the app is app specific.


But we can clarify that in the draft.

  



As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and not used.

(note that I have assume that the UPA signal is sent to BGP, but this is the 
same picture if UPA is only used by BGP PIC Edge)





In particular, BGP is (heavily) using reachability of (loopbacks)
addresses advertised in IS-IS in order to evaluate the reachability of
BGP routes and compute their preference.

If UPA is not interpreted the same ways by all routers, forwarding loops
may occur in a hop by hop routed network. (because different routers
would select different paths since they use different information to
select their path)


I don't see a problem, please provide an example.


iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
 |
 |
ePE3 (IP1)




ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering routers in L2.



ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have both BGP 
paths to IP1.
Traffic to IP1 is IP routed hop by hop from iPE1.
P2 support UPA, P1 does not.
ePE2 fails and ABR1 advertise UPA in level 1.


P1 does not support UPA so is unaware of ePE2 failure and keeps routing IP1 
toward ePE2, hence P2.
P2 supports UPA so knows that the ePE2 is down and invalidate BGP routes using 
this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.

--> forwarding loop between P1 and P2 for destination IP1


- UPA processing is optional and disabled by default
- typically P1 and P2 would not run BGP at all, so there would be no
issues if UPA would be used on iPE1
- if you run BGP hop by hop, you would need to consistently enable UPA
on all routers.


Good that we agree on some bad consequences of UPA in case of partial 
deployment.
Can we have a text, if not a section, in the draft to talk about that partial 
deployment?
At least to raise awareness of the potential issues depending the 
"application". Ideally, I would have a preference to specifically indicate the 
cases that are problematic, but that would imply having a review from all routing WG.
Again, I think that the BGP case should be described as this the typical target 
that had been discussed on the list to promote UPA, and both IS-IS and BGP are 
important for the routing/network. I don't think IS-IS can shirk responsibility 
for advertising reachability/unreachability to other protocols relying on IS-IS.
  
a first proposal could be

6.1 Partial Deployement
Partial deployment of UPA translates into inconsistent knowledge of the 
unreachability 

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

[bruno . decraene]

Peter,

please see inline 
 

> From: Peter Psenak  
> Sent: Tuesday, July 25, 2023 10:04 PM
> 
> Bruno,
> 
> please see inline:
> 
> On 25/07/2023 20:58, bruno.decra...@orange.com wrote:
> > Peter,
> > 
> > Thank for you answer. Please see inline [Bruno]
> >   
> >   
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 6:11 PM
> >>
> >> Bruno,
> >>
> >> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> >>> Hi all,
> >>>
> >>> IP reachability advertised by IS-IS is often used by other routing and
> >>> signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> >>> such, UPA may affect those protocols.
> >>>
> >>> Has UPA been presented in other WGs in the routing areas?
> >>>
> >>> I believe this would be prudent if not required.
> >>
> >> why do you believe so? How is this different to an IGP prefix becoming
> >> unreachable without UPA?
> > 
> > [Bruno] Because, at least for IS-IS, this is a protocol extension.
> > 
> > When receiving:
> > IP1/32 with metric 0xFE01
> > IP1/24 with metric 10  (covering aggregate)
> > 
> > Legacy routers will only consider the aggregate for the SPF/RIB
> > IP1/24 with metric 10
> 
> even routers with UPA processing enabled would only use IP2/24 in 
> forwarding. The UPA would only be used to send signal to apps like BGP.

you are correct.
(I meant legacy node will not see the UPA hence that IP1/32 is unreachable)
 
> > 
> > As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible and 
> > used.
> > 
> > UPA compliant routers will consider the aggregate for the SPF/RIB, plus 
> > they will consider that IP1/32 is unreachable.
> 
> no, they will NOT consider that IP1/32 is unreachable.
> 
> UPA is only used to signal the unreachability to apps that are 
> interested. 

"apps" are part of the router, in particular BGP.
So let me rephrase: the BGP protocol on UPA compliant routers will consider the 
aggregate for the SPF/RIB, plus they will consider that IP1/32 is unreachable.

> What the apps do with it is out of the scope of UPA.

Use of UPA have consequences. Some good (advertising loss of reachability), 
some bads (forwarding loops for BGP prefixes which are routed hop by hop).
I don't think that we can claim the benefits (adopt UPA because it's useful for 
e.g. BGP PIC edge) and refuse to talk about the drawbacks.
 
> 
> > As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and not 
> > used.
> > 
> > (note that I have assume that the UPA signal is sent to BGP, but this is 
> > the same picture if UPA is only used by BGP PIC Edge)
> > 
> > 
> > 
> >>>
> >>> In particular, BGP is (heavily) using reachability of (loopbacks)
> >>> addresses advertised in IS-IS in order to evaluate the reachability of
> >>> BGP routes and compute their preference.
> >>>
> >>> If UPA is not interpreted the same ways by all routers, forwarding loops
> >>> may occur in a hop by hop routed network. (because different routers
> >>> would select different paths since they use different information to
> >>> select their path)
> >>
> >> I don't see a problem, please provide an example.
> > 
> > iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
> > |
> > |
> > ePE3 (IP1)
> > 
> > 
> > 
> > 
> > ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering routers in 
> > L2.
> > 
> > 
> > 
> > ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have both 
> > BGP paths to IP1.
> > Traffic to IP1 is IP routed hop by hop from iPE1.
> > P2 support UPA, P1 does not.
> > ePE2 fails and ABR1 advertise UPA in level 1.
> > 
> > 
> > P1 does not support UPA so is unaware of ePE2 failure and keeps routing IP1 
> > toward ePE2, hence P2.
> > P2 supports UPA so knows that the ePE2 is down and invalidate BGP routes 
> > using this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.
> > 
> > --> forwarding loop between P1 and P2 for destination IP1
> 
> - UPA processing is optional and disabled by default
> - typically P1 and P2 would not run BGP at all, so there would be no 
> issues if UPA would be used on iPE1
> - if you run BGP hop by hop, you would need to consistently enable UPA 
> on all routers.

Good that we agree on some bad consequences of UPA in case of partial 
deployment.
Can we have a text, if not a section, in the draft to talk about that partial 
deployment?
At least to raise awareness of the potential issues depending the 
"application". Ideally, I would have a preference to specifically indicate the 
cases that are problematic, but that would imply having a review from all 
routing WG.
Again, I think that the BGP case should be described as this the typical target 
that had been discussed on the list to promote UPA, and both IS-IS and BGP are 
important for the routing/network. I don't think IS-IS can shirk responsibility 
for advertising reachability/unreachability to other protocols relying on IS-IS.
 
a first proposal 

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

[Peter Psenak]

Bruno,

please see inline:

On 25/07/2023 21:11, bruno.decra...@orange.com wrote:

Peter,

Please see inline
  

From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:49 PM

Bruno,

please see inline:

On 25/07/2023 18:36, bruno.decra...@orange.com wrote:

Peter,

Thanks for your answer.
Please see inline [Bruno]
   
   

From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:05 PM

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
* No reachability (state “0”) by either:
o Not advertising IP1 in TLV 135
o Advertising IP1 in TLV 135with a metric larger than 0xFE00


right, one being implicit the other one explicit.



Here you agree that advertising IP1 in TLV 135with a metric larger than 
0xFE00 is equivalent to No reachability / state “0” / Not advertising IP1 
in TLV 135





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 0xFE00.

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 0xFE00 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.


[Bruno] Good if this is what is meant in the draft and if this is only 
misunderstanding.
To be specific, I'm asking about the following changes for IS-IS (please feel 
free to reformulate, OSPF is up to you)

§5.4
OLD:
U-Flag and UP-Flag are optional flags that have informative character. 
Treatment of these flags on the receiver is optional and the usage of them is 
outside of scope of this document.

NEW:
The setting of the U-Flag or the UP-Flag signals that the prefix is 
unreachable. They constitute the UPA signals.


I don't think above is necessary:

[RFC5305] defines the encoding for advertising IPv4 prefixes using 4
octets of metric information. Section 4 specifies:

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE00, 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. "


Agreed with the quote.

"prefix NOT considered during normal SPF computation" does not change/affect 
the outcome of the SPF computation. Hence does not remove reachability if a covering 
prefix is present.


right. And UPA treatment is no different. It is only used to signal 
unreachability to apps that are interested. It does not change anything 
in forwarding itself.




Plus at the beginning of this email, you agreed that this signaling translate into state 
"0". (absence of reachability signal)
I don't see how you can now say that this signaling translate in state "-1" 
(negative reachability)

  

As a result of the above, from the IP routing perspective, prefix with a
metric larger then MAX_PATH_METRIC (0xFE0) MUST be treated as
unreachable.


a) This prefix is absent in the RIB/FIB (just like if it were not advertised in 
TLV)
b) Covering prefix is in the RIB/FIB.
c) Net result is (positive) reachability.

Could you point to the line(s) that you disagree with?


I agree, and exactly same happens with UPA in terms of forwarding.





If the implementation does not do that, it is clearly
violating RFC5305.

We added the new flags, to distinguish from other cases where the prefix
might be advertised with metric higher than 0xFE00, whatever that
use case is. But the meaning of the metric higher than 0xFE00 from
the IP routing perspective does not changes by the new flags.


This is exactly the concerned that I raised in my original email. (the one you 
did not see the difference between my point and the draft).


I'm still not clear what is your concern.

thanks,
Peter



Thanks,
--Bruno



§5
"Even though in all cases the treatment of such metric, or NU-bit, is specified for 

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

[Peter Psenak]

Bruno,

please see inline:

On 25/07/2023 20:58, bruno.decra...@orange.com wrote:

Peter,

Thank for you answer. Please see inline [Bruno]
  
  

From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:11 PM

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com wrote:

Hi all,

IP reachability advertised by IS-IS is often used by other routing and
signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
such, UPA may affect those protocols.

Has UPA been presented in other WGs in the routing areas?

I believe this would be prudent if not required.


why do you believe so? How is this different to an IGP prefix becoming
unreachable without UPA?


[Bruno] Because, at least for IS-IS, this is a protocol extension.

When receiving:
IP1/32 with metric 0xFE01
IP1/24 with metric 10  (covering aggregate)

Legacy routers will only consider the aggregate for the SPF/RIB
IP1/24 with metric 10


even routers with UPA processing enabled would only use IP2/24 in 
forwarding. The UPA would only be used to send signal to apps like BGP.




As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible and used.

UPA compliant routers will consider the aggregate for the SPF/RIB, plus they 
will consider that IP1/32 is unreachable.


no, they will NOT consider that IP1/32 is unreachable.

UPA is only used to signal the unreachability to apps that are 
interested. What the apps do with it is out of the scope of UPA.




As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and not used.

(note that I have assume that the UPA signal is sent to BGP, but this is the 
same picture if UPA is only used by BGP PIC Edge)





In particular, BGP is (heavily) using reachability of (loopbacks)
addresses advertised in IS-IS in order to evaluate the reachability of
BGP routes and compute their preference.

If UPA is not interpreted the same ways by all routers, forwarding loops
may occur in a hop by hop routed network. (because different routers
would select different paths since they use different information to
select their path)


I don't see a problem, please provide an example.


iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
|
|
ePE3 (IP1)




ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering routers in L2.



ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have both BGP 
paths to IP1.
Traffic to IP1 is IP routed hop by hop from iPE1.
P2 support UPA, P1 does not.
ePE2 fails and ABR1 advertise UPA in level 1.


P1 does not support UPA so is unaware of ePE2 failure and keeps routing IP1 
toward ePE2, hence P2.
P2 supports UPA so knows that the ePE2 is down and invalidate BGP routes using 
this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.

--> forwarding loop between P1 and P2 for destination IP1


- UPA processing is optional and disabled by default
- typically P1 and P2 would not run BGP at all, so there would be no 
issues if UPA would be used on iPE1
- if you run BGP hop by hop, you would need to consistently enable UPA 
on all routers.


thanks,
Peter



A priori same thing with BGP PIC edge >

Thanks,
--Bruno



If an ingress PE decides to switch to an alternate BGP path, how does
that creates any potential loop? And why all egress PEs would need to do
the same?



This is not considered nor discussed in the draft. Quite the contrary,
draft says that recognition, processing and use of UPA is a local
consideration.


yes, and we want to keep it that way.

thanks,
Peter




I would suggest to at minimum present this draft to IDR and gets the
feedback from the IDR WG.

--Bruno





Orange Restricted

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

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

[bruno . decraene]

Peter,

> From: Peter Psenak 
> Sent: Tuesday, July 25, 2023 7:38 PM
> To: Robert Raszuk 
>
> Hi Robert,
>
>
>
> On 25/07/2023 18:51, Robert Raszuk wrote:
> > Hey Peter,
> >
> > I think the point Bruno is making is valid ... Imagine dual or triple
> > vendor network and hop by hop routing (no end to end SAFI).
> >
> > That means that all nodes should be in synch in terms to react on UPA,
>
> chapter 7 of the draft says:
>
> "Processing of the received UPAs is optional and SHOULD be controlled by
> the configuration at the receiver. The receiver itself, based on its
> configuration, decides what the UPA will be used for and what
> applications, if any, will be notified when UPA is received."
>
> So we have a way to achieve consistency if it is ever needed.

Assuming that all nodes in the flooding domain support UPA, and that consistent 
configuration is applied on all nodes, and that UPA is enabled on a flag 
day/second.

> For most
> cases, the network wide consistency is not needed.

Since we agree that there is a consistency issue in some cases, it would be 
good for the draft to be explicit about this and says when the draft is not 
applicable.

Thanks,
--Bruno

> thanks,
> Peter
>
> >
> > Of course you will say that this is up to wise operator to enable it
> > only when it makes sense ... but I think the point is still valid and
> > clearly for none tunneled networks (if ever to use UPA) this is NOT a
> > local decision,
> >
> > For vast majority it is local as forwarding is using some sort of PE-PE
> > encapsulation.
> >
> > Cheers,
> > R.
> >
> >
> > On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak
> > mailto:40cisco@dmarc.ietf.org>>
> > wrote:
> >
> > Bruno,
> >
> > On 25/07/2023 14:39, bruno.decra...@orange.com
> >  wrote:
> >  > Hi all,
> >  >
> >  > IP reachability advertised by IS-IS is often used by other
> > routing and
> >  > signaling protocols (e.g., BGP, PIM (rpf vector) LDP,
> > RSVP-TE...). As
> >  > such, UPA may affect those protocols.
> >  >
> >  > Has UPA been presented in other WGs in the routing areas?
> >  >
> >  > I believe this would be prudent if not required.
> >
> > why do you believe so? How is this different to an IGP prefix becoming
> > unreachable without UPA?
> >
> >  >
> >  > In particular, BGP is (heavily) using reachability of (loopbacks)
> >  > addresses advertised in IS-IS in order to evaluate the
> > reachability of
> >  > BGP routes and compute their preference.
> >  >
> >  > If UPA is not interpreted the same ways by all routers,
> > forwarding loops
> >  > may occur in a hop by hop routed network. (because different routers
> >  > would select different paths since they use different information to
> >  > select their path)
> >
> > I don't see a problem, please provide an example.
> > If an ingress PE decides to switch to an alternate BGP path, how does
> > that creates any potential loop? And why all egress PEs would need
> > to do
> > the same?
> >
> >  >
> >  > This is not considered nor discussed in the draft. Quite the
> > contrary,
> >  > draft says that recognition, processing and use of UPA is a local
> >  > consideration.
> >
> > yes, and we want to keep it that way.
> >
> > thanks,
> > Peter
> >
> >
> >  >
> >  > I would suggest to at minimum present this draft to IDR and gets the
> >  > feedback from the IDR WG.
> >  >
> >  > --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
> > 
> >
>

Orange 

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

[bruno . decraene]

Thanks Robert, you got my point.
More inline.

From: Robert Raszuk 
Sent: Tuesday, July 25, 2023 7:51 PM
To: Peter Psenak 
Cc: DECRAENE Bruno INNOV/NET ; lsr 
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi,

> So we have a way to achieve consistency if it is ever needed.

Well you do not have any protocol way to assure that operational configuration 
mistakes will not result in inconsistent routing.
+1

But overall I do agree that for the vast majority of applications that concern 
is not really applicable ?
In all cases, the draft needs to say when it’s applicable and when it’s not 
applicable and must not be used.

In fact I would be happy if you limit the UPA scope *only* for services which 
use end to end encapsulation.
Yes but AFAIK currently BGP decision process and BGP PIC edge does not make the 
different if the same loopback is used both for encapsulating traffic for some 
AFI/SAFI and for hop by hop routing for some others AFI/SAFI.

It is also important to observe that this is not negative routing and that P 
nodes will continue to forward packets to destinations marked as UPA as the 
information will not be really reflected as holes/drops in their respective 
FIBs.
Absolutely, that is not negative forwarding and forwarding to the IGP prefix is 
unchanged.
But that is a negative reachability signal in routing.

Thanks,
--Bruno

Thx,
R.



On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Robert,



On 25/07/2023 18:51, Robert Raszuk wrote:
> Hey Peter,
>
> I think the point Bruno is making is valid ... Imagine dual or triple
> vendor network and hop by hop routing (no end to end SAFI).
>
> That means that all nodes should be in synch in terms to react on UPA,

chapter 7 of the draft says:

"Processing of the received UPAs is optional and SHOULD be controlled by
the configuration at the receiver. The receiver itself, based on its
configuration, decides what the UPA will be used for and what
applications, if any, will be notified when UPA is received."

So we have a way to achieve consistency if it is ever needed. For most
cases, the network wide consistency is not needed.

thanks,
Peter

>
> Of course you will say that this is up to wise operator to enable it
> only when it makes sense ... but I think the point is still valid and
> clearly for none tunneled networks (if ever to use UPA) this is NOT a
> local decision,
>
> For vast majority it is local as forwarding is using some sort of PE-PE
> encapsulation.
>
> Cheers,
> R.
>
>
> On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak
> mailto:40cisco@dmarc.ietf.org> 
> <mailto:40cisco@dmarc.ietf.org<mailto:40cisco@dmarc.ietf.org>>>
> wrote:
>
> Bruno,
>
> On 25/07/2023 14:39, 
> bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
> <mailto:bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> 
> wrote:
>  > Hi all,
>  >
>  > IP reachability advertised by IS-IS is often used by other
> routing and
>  > signaling protocols (e.g., BGP, PIM (rpf vector) LDP,
> RSVP-TE...). As
>  > such, UPA may affect those protocols.
>  >
>  > Has UPA been presented in other WGs in the routing areas?
>  >
>  > I believe this would be prudent if not required.
>
> why do you believe so? How is this different to an IGP prefix becoming
> unreachable without UPA?
>
>  >
>  > In particular, BGP is (heavily) using reachability of (loopbacks)
>  > addresses advertised in IS-IS in order to evaluate the
> reachability of
>  > BGP routes and compute their preference.
>  >
>  > If UPA is not interpreted the same ways by all routers,
> forwarding loops
>  > may occur in a hop by hop routed network. (because different routers
>  > would select different paths since they use different information to
>  > select their path)
>
> I don't see a problem, please provide an example.
> If an ingress PE decides to switch to an alternate BGP path, how does
> that creates any potential loop? And why all egress PEs would need
> to do
> the same?
>
>  >
>  > This is not considered nor discussed in the draft. Quite the
> contrary,
>  > draft says that recognition, processing and use of UPA is a local
>  > consideration.
>
> yes, and we want to keep it that way.
>
> thanks,
> Peter
>
>
>  >
>  > I would suggest to at minimum present this draft to IDR and gets the
>  > feedback from the IDR WG.
>  >
>  > --Bruno
>  >
>  >
> 
> _

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

[bruno . decraene]

Peter,

Please see inline  
 
> From: Peter Psenak  
> Sent: Tuesday, July 25, 2023 6:49 PM
> 
> Bruno,
> 
> please see inline:
> 
> On 25/07/2023 18:36, bruno.decra...@orange.com wrote:
> > Peter,
> > 
> > Thanks for your answer.
> > Please see inline [Bruno]
> >   
> >   
> >> From: Peter Psenak 
> >> Sent: Tuesday, July 25, 2023 6:05 PM
> >>
> >> Bruno,
> >>
> >> On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
> >>>* No reachability (state “0”) by either:
> >>>o Not advertising IP1 in TLV 135
> >>>o Advertising IP1 in TLV 135with a metric larger than 0xFE00
> >>
> >> right, one being implicit the other one explicit.


Here you agree that advertising IP1 in TLV 135with a metric larger than 
0xFE00 is equivalent to No reachability / state “0” / Not advertising IP1 
in TLV 135

> >>
> >>>
> >>> 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 0xFE00.
> >>>
> >>> 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 0xFE00 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.
> > 
> > [Bruno] Good if this is what is meant in the draft and if this is only 
> > misunderstanding.
> > To be specific, I'm asking about the following changes for IS-IS (please 
> > feel free to reformulate, OSPF is up to you)
> > 
> > §5.4
> > OLD:
> > U-Flag and UP-Flag are optional flags that have informative character. 
> > Treatment of these flags on the receiver is optional and the usage of them 
> > is outside of scope of this document.
> > 
> > NEW:
> > The setting of the U-Flag or the UP-Flag signals that the prefix is 
> > unreachable. They constitute the UPA signals.
> 
> I don't think above is necessary:
> 
> [RFC5305] defines the encoding for advertising IPv4 prefixes using 4 
> octets of metric information. Section 4 specifies:
> 
> "If a prefix is advertised with a metric larger then MAX_PATH_METRIC 
> (0xFE00, 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. "

Agreed with the quote. 

"prefix NOT considered during normal SPF computation" does not change/affect 
the outcome of the SPF computation. Hence does not remove reachability if a 
covering prefix is present.

Plus at the beginning of this email, you agreed that this signaling translate 
into state "0". (absence of reachability signal)
I don't see how you can now say that this signaling translate in state "-1" 
(negative reachability)

 
> As a result of the above, from the IP routing perspective, prefix with a 
> metric larger then MAX_PATH_METRIC (0xFE0) MUST be treated as 
> unreachable.

a) This prefix is absent in the RIB/FIB (just like if it were not advertised in 
TLV)
b) Covering prefix is in the RIB/FIB.
c) Net result is (positive) reachability.

Could you point to the line(s) that you disagree with?

> If the implementation does not do that, it is clearly 
> violating RFC5305.
> 
> We added the new flags, to distinguish from other cases where the prefix 
> might be advertised with metric higher than 0xFE00, whatever that 
> use case is. But the meaning of the metric higher than 0xFE00 from 
> the IP routing perspective does not changes by the new flags.

This is exactly the concerned that I raised in my original email. (the one you 
did not see the difference between my point and the draft).

Thanks,
--Bruno

> > 
> > §5
> > "Even though in all cases the treatment of such 

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

[bruno . decraene]

Peter,

Thank for you answer. Please see inline [Bruno]
 
 
> From: Peter Psenak  
> Sent: Tuesday, July 25, 2023 6:11 PM
> 
> Bruno,
> 
> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > Hi all,
> > 
> > IP reachability advertised by IS-IS is often used by other routing and 
> > signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As 
> > such, UPA may affect those protocols.
> > 
> > Has UPA been presented in other WGs in the routing areas?
> > 
> > I believe this would be prudent if not required.
> 
> why do you believe so? How is this different to an IGP prefix becoming 
> unreachable without UPA?

[Bruno] Because, at least for IS-IS, this is a protocol extension.

When receiving:
IP1/32 with metric 0xFE01
IP1/24 with metric 10  (covering aggregate)

Legacy routers will only consider the aggregate for the SPF/RIB
IP1/24 with metric 10  

As a result, a BGP route IP2 with BGP Next-Hop IP1 is still feasible and used.

UPA compliant routers will consider the aggregate for the SPF/RIB, plus they 
will consider that IP1/32 is unreachable.
As a result, a BGP route IP2 with BGP Next-Hop IP1 is not feasible and not used.

(note that I have assume that the UPA signal is sent to BGP, but this is the 
same picture if UPA is only used by BGP PIC Edge)



> > 
> > In particular, BGP is (heavily) using reachability of (loopbacks) 
> > addresses advertised in IS-IS in order to evaluate the reachability of 
> > BGP routes and compute their preference.
> > 
> > If UPA is not interpreted the same ways by all routers, forwarding loops 
> > may occur in a hop by hop routed network. (because different routers 
> > would select different paths since they use different information to 
> > select their path)
> 
> I don't see a problem, please provide an example.

iPE1 - P1 - P2 - ABR1 - P3 - ePE2 (IP1)
   |
   |
ePE3 (IP1)




ABR1 is L1L2. It advertises, in L1, an aggregate prefix covering routers in L2.



ePE2 and ePE3 advertise IP1 in BGP. ePE2 is preferred. All nodes have both BGP 
paths to IP1.
Traffic to IP1 is IP routed hop by hop from iPE1.
P2 support UPA, P1 does not.
ePE2 fails and ABR1 advertise UPA in level 1.


P1 does not support UPA so is unaware of ePE2 failure and keeps routing IP1 
toward ePE2, hence P2.
P2 supports UPA so knows that the ePE2 is down and invalidate BGP routes using 
this BGP Next-Hop. Hence P2 routes IP1 toward ePE3.

--> forwarding loop between P1 and P2 for destination IP1

A priori same thing with BGP PIC edge.


Thanks,
--Bruno


> If an ingress PE decides to switch to an alternate BGP path, how does 
> that creates any potential loop? And why all egress PEs would need to do 
> the same?
> 
> > 
> > This is not considered nor discussed in the draft. Quite the contrary, 
> > draft says that recognition, processing and use of UPA is a local 
> > consideration.
> 
> yes, and we want to keep it that way.
> 
> thanks,
> Peter
> 
> 
> > 
> > I would suggest to at minimum present this draft to IDR and gets the 
> > feedback from the IDR WG.
> > 
> > --Bruno
> > 
>

Orange Restricted

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

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

[Peter Psenak]

Robert,

On 25/07/2023 19:50, Robert Raszuk wrote:

Hi,

 > So we have a way to achieve consistency if it is ever needed.

Well you do not have any protocol way to assure that operational 
configuration mistakes will not result in inconsistent routing.


But overall I do agree that for the vast majority of applications that 
concern is not really applicable ? In fact I would be happy if you limit 
the UPA scope *only* for services which use end to end encapsulation.


that is certainly the main use case we are targeting.



It is also important to observe that this is not negative routing and 
that P nodes will continue to forward packets to destinations marked as 
UPA as the information will not be really reflected as holes/drops in 
their respective FIBs.


that is indeed the case. The forwarding based on the less specific route 
is not affected by UPA.


thanks,
Peter


Thx,
R.



On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak > wrote:


Hi Robert,



On 25/07/2023 18:51, Robert Raszuk wrote:
 > Hey Peter,
 >
 > I think the point Bruno is making is valid ... Imagine dual or
triple
 > vendor network and hop by hop routing (no end to end SAFI).
 >
 > That means that all nodes should be in synch in terms to react on
UPA,

chapter 7 of the draft says:

"Processing of the received UPAs is optional and SHOULD be
controlled by
the configuration at the receiver. The receiver itself, based on its
configuration, decides what the UPA will be used for and what
applications, if any, will be notified when UPA is received."

So we have a way to achieve consistency if it is ever needed. For most
cases, the network wide consistency is not needed.

thanks,
Peter

 >
 > Of course you will say that this is up to wise operator to enable it
 > only when it makes sense ... but I think the point is still valid
and
 > clearly for none tunneled networks (if ever to use UPA) this is
NOT a
 > local decision,
 >
 > For vast majority it is local as forwarding is using some sort of
PE-PE
 > encapsulation.
 >
 > Cheers,
 > R.
 >
 >
 > On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak
 > mailto:40cisco@dmarc.ietf.org>
>>
 > wrote:
 >
 >     Bruno,
 >
 >     On 25/07/2023 14:39, bruno.decra...@orange.com

 >     > wrote:
 >      > Hi all,
 >      >
 >      > IP reachability advertised by IS-IS is often used by other
 >     routing and
 >      > signaling protocols (e.g., BGP, PIM (rpf vector) LDP,
 >     RSVP-TE...). As
 >      > such, UPA may affect those protocols.
 >      >
 >      > Has UPA been presented in other WGs in the routing areas?
 >      >
 >      > I believe this would be prudent if not required.
 >
 >     why do you believe so? How is this different to an IGP prefix
becoming
 >     unreachable without UPA?
 >
 >      >
 >      > In particular, BGP is (heavily) using reachability of
(loopbacks)
 >      > addresses advertised in IS-IS in order to evaluate the
 >     reachability of
 >      > BGP routes and compute their preference.
 >      >
 >      > If UPA is not interpreted the same ways by all routers,
 >     forwarding loops
 >      > may occur in a hop by hop routed network. (because
different routers
 >      > would select different paths since they use different
information to
 >      > select their path)
 >
 >     I don't see a problem, please provide an example.
 >     If an ingress PE decides to switch to an alternate BGP path,
how does
 >     that creates any potential loop? And why all egress PEs would
need
 >     to do
 >     the same?
 >
 >      >
 >      > This is not considered nor discussed in the draft. Quite the
 >     contrary,
 >      > draft says that recognition, processing and use of UPA is
a local
 >      > consideration.
 >
 >     yes, and we want to keep it that way.
 >
 >     thanks,
 >     Peter
 >
 >
 >      >
 >      > I would suggest to at minimum present this draft to IDR
and gets the
 >      > feedback from the IDR WG.
 >      >
 >      > --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 

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

[Robert Raszuk]

Hi,

> So we have a way to achieve consistency if it is ever needed.

Well you do not have any protocol way to assure that operational
configuration mistakes will not result in inconsistent routing.

But overall I do agree that for the vast majority of applications that
concern is not really applicable ? In fact I would be happy if you limit
the UPA scope *only* for services which use end to end encapsulation.

It is also important to observe that this is not negative routing and that
P nodes will continue to forward packets to destinations marked as UPA as
the information will not be really reflected as holes/drops in their
respective FIBs.

Thx,
R.



On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak  wrote:

> Hi Robert,
>
>
>
> On 25/07/2023 18:51, Robert Raszuk wrote:
> > Hey Peter,
> >
> > I think the point Bruno is making is valid ... Imagine dual or triple
> > vendor network and hop by hop routing (no end to end SAFI).
> >
> > That means that all nodes should be in synch in terms to react on UPA,
>
> chapter 7 of the draft says:
>
> "Processing of the received UPAs is optional and SHOULD be controlled by
> the configuration at the receiver. The receiver itself, based on its
> configuration, decides what the UPA will be used for and what
> applications, if any, will be notified when UPA is received."
>
> So we have a way to achieve consistency if it is ever needed. For most
> cases, the network wide consistency is not needed.
>
> thanks,
> Peter
>
> >
> > Of course you will say that this is up to wise operator to enable it
> > only when it makes sense ... but I think the point is still valid and
> > clearly for none tunneled networks (if ever to use UPA) this is NOT a
> > local decision,
> >
> > For vast majority it is local as forwarding is using some sort of PE-PE
> > encapsulation.
> >
> > Cheers,
> > R.
> >
> >
> > On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak
> > mailto:40cisco@dmarc.ietf.org>>
>
> > wrote:
> >
> > Bruno,
> >
> > On 25/07/2023 14:39, bruno.decra...@orange.com
> >  wrote:
> >  > Hi all,
> >  >
> >  > IP reachability advertised by IS-IS is often used by other
> > routing and
> >  > signaling protocols (e.g., BGP, PIM (rpf vector) LDP,
> > RSVP-TE...). As
> >  > such, UPA may affect those protocols.
> >  >
> >  > Has UPA been presented in other WGs in the routing areas?
> >  >
> >  > I believe this would be prudent if not required.
> >
> > why do you believe so? How is this different to an IGP prefix
> becoming
> > unreachable without UPA?
> >
> >  >
> >  > In particular, BGP is (heavily) using reachability of (loopbacks)
> >  > addresses advertised in IS-IS in order to evaluate the
> > reachability of
> >  > BGP routes and compute their preference.
> >  >
> >  > If UPA is not interpreted the same ways by all routers,
> > forwarding loops
> >  > may occur in a hop by hop routed network. (because different
> routers
> >  > would select different paths since they use different information
> to
> >  > select their path)
> >
> > I don't see a problem, please provide an example.
> > If an ingress PE decides to switch to an alternate BGP path, how does
> > that creates any potential loop? And why all egress PEs would need
> > to do
> > the same?
> >
> >  >
> >  > This is not considered nor discussed in the draft. Quite the
> > contrary,
> >  > draft says that recognition, processing and use of UPA is a local
> >  > consideration.
> >
> > yes, and we want to keep it that way.
> >
> > thanks,
> > Peter
> >
> >
> >  >
> >  > I would suggest to at minimum present this draft to IDR and gets
> the
> >  > feedback from the IDR WG.
> >  >
> >  > --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.
> 

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

[Peter Psenak]

Hi Robert,



On 25/07/2023 18:51, Robert Raszuk wrote:

Hey Peter,

I think the point Bruno is making is valid ... Imagine dual or triple 
vendor network and hop by hop routing (no end to end SAFI).


That means that all nodes should be in synch in terms to react on UPA,


chapter 7 of the draft says:

"Processing of the received UPAs is optional and SHOULD be controlled by 
the configuration at the receiver. The receiver itself, based on its 
configuration, decides what the UPA will be used for and what 
applications, if any, will be notified when UPA is received."


So we have a way to achieve consistency if it is ever needed. For most 
cases, the network wide consistency is not needed.


thanks,
Peter



Of course you will say that this is up to wise operator to enable it 
only when it makes sense ... but I think the point is still valid and 
clearly for none tunneled networks (if ever to use UPA) this is NOT a 
local decision,


For vast majority it is local as forwarding is using some sort of PE-PE 
encapsulation.


Cheers,
R.


On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> 
wrote:


Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com
 wrote:
 > Hi all,
 >
 > IP reachability advertised by IS-IS is often used by other
routing and
 > signaling protocols (e.g., BGP, PIM (rpf vector) LDP,
RSVP-TE...). As
 > such, UPA may affect those protocols.
 >
 > Has UPA been presented in other WGs in the routing areas?
 >
 > I believe this would be prudent if not required.

why do you believe so? How is this different to an IGP prefix becoming
unreachable without UPA?

 >
 > In particular, BGP is (heavily) using reachability of (loopbacks)
 > addresses advertised in IS-IS in order to evaluate the
reachability of
 > BGP routes and compute their preference.
 >
 > If UPA is not interpreted the same ways by all routers,
forwarding loops
 > may occur in a hop by hop routed network. (because different routers
 > would select different paths since they use different information to
 > select their path)

I don't see a problem, please provide an example.
If an ingress PE decides to switch to an alternate BGP path, how does
that creates any potential loop? And why all egress PEs would need
to do
the same?

 >
 > This is not considered nor discussed in the draft. Quite the
contrary,
 > draft says that recognition, processing and use of UPA is a local
 > consideration.

yes, and we want to keep it that way.

thanks,
Peter


 >
 > I would suggest to at minimum present this draft to IDR and gets the
 > feedback from the IDR WG.
 >
 > --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

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

[Robert Raszuk]

Hey Peter,

I think the point Bruno is making is valid ... Imagine dual or triple
vendor network and hop by hop routing (no end to end SAFI).

That means that all nodes should be in synch in terms to react on UPA,

Of course you will say that this is up to wise operator to enable it only
when it makes sense ... but I think the point is still valid and clearly
for none tunneled networks (if ever to use UPA) this is NOT a local
decision,

For vast majority it is local as forwarding is using some sort of PE-PE
encapsulation.

Cheers,
R.


On Tue, Jul 25, 2023 at 9:11 AM Peter Psenak  wrote:

> Bruno,
>
> On 25/07/2023 14:39, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > IP reachability advertised by IS-IS is often used by other routing and
> > signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As
> > such, UPA may affect those protocols.
> >
> > Has UPA been presented in other WGs in the routing areas?
> >
> > I believe this would be prudent if not required.
>
> why do you believe so? How is this different to an IGP prefix becoming
> unreachable without UPA?
>
> >
> > In particular, BGP is (heavily) using reachability of (loopbacks)
> > addresses advertised in IS-IS in order to evaluate the reachability of
> > BGP routes and compute their preference.
> >
> > If UPA is not interpreted the same ways by all routers, forwarding loops
> > may occur in a hop by hop routed network. (because different routers
> > would select different paths since they use different information to
> > select their path)
>
> I don't see a problem, please provide an example.
> If an ingress PE decides to switch to an alternate BGP path, how does
> that creates any potential loop? And why all egress PEs would need to do
> the same?
>
> >
> > This is not considered nor discussed in the draft. Quite the contrary,
> > draft says that recognition, processing and use of UPA is a local
> > consideration.
>
> yes, and we want to keep it that way.
>
> thanks,
> Peter
>
>
> >
> > I would suggest to at minimum present this draft to IDR and gets the
> > feedback from the IDR WG.
> >
> > --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

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

[Peter Psenak]

Bruno,

please see inline:

On 25/07/2023 18:36, bruno.decra...@orange.com wrote:

Peter,

Thanks for your answer.
Please see inline [Bruno]
  
  

From: Peter Psenak 
Sent: Tuesday, July 25, 2023 6:05 PM

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
   * No reachability (state “0”) by either:
   o Not advertising IP1 in TLV 135
   o Advertising IP1 in TLV 135with a metric larger than 0xFE00


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 0xFE00.

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 0xFE00 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.


[Bruno] Good if this is what is meant in the draft and if this is only 
misunderstanding.
To be specific, I'm asking about the following changes for IS-IS (please feel 
free to reformulate, OSPF is up to you)

§5.4
OLD:
U-Flag and UP-Flag are optional flags that have informative character. 
Treatment of these flags on the receiver is optional and the usage of them is 
outside of scope of this document.

NEW:
The setting of the U-Flag or the UP-Flag signals that the prefix is 
unreachable. They constitute the UPA signals.


I don't think above is necessary:

[RFC5305] defines the encoding for advertising IPv4 prefixes using 4 
octets of metric information. Section 4 specifies:


"If a prefix is advertised with a metric larger then MAX_PATH_METRIC 
(0xFE00, 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 a result of the above, from the IP routing perspective, prefix with a 
metric larger then MAX_PATH_METRIC (0xFE0) MUST be treated as 
unreachable. If the implementation does not do that, it is clearly 
violating RFC5305.


We added the new flags, to distinguish from other cases where the prefix 
might be advertised with metric higher than 0xFE00, whatever that 
use case is. But the meaning of the metric higher than 0xFE00 from 
the IP routing perspective does not changes by the new flags.




§5
"Even though in all cases the treatment of such metric, or NU-bit, is specified for 
IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised 
in order to signal unreachability is useful to distinguish it from other cases where the 
prefix with such metric is advertised."
:s/useful/required

§Abstract
OLD:  This document describes how to use existing protocol mechanisms in IS-IS 
and OSPF to advertise such prefix reachability loss.
NEW: This document defines two new flags in IS-IS and OSPF to advertise such  
prefix reachability loss. In order to support incremental deployment, such 
advertisement use a high metric value already having special meaning of OSPF 
and IS-IS.

§1
OLD:  This document describes how the use of existing protocol mechanisms can 
support the necessary functionality without the need for any protocol 
extensions. The functionality being described is called Unreachable Prefix 
Announcement (UPA).
NEW: This document defines two new flags in IS-IS and OSPF to the necessary 
functionality without the need for any protocol extensions. The functionality 
being described is called Unreachable Prefix Announcement (UPA).


please see my above response. The treatment of the metric higher that 
0xFE00 and LSInfiity has been defined long time back and is not 
affected by the newly defined flags.


thanks,
Peter


Thank you,
Regards,
--Bruno



The drawback is that the existing pre-standard implementation would need
to be updated. But that’s the rule for a pre-standard 

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

[bruno . decraene]

Peter,

Thanks for your answer.
Please see inline [Bruno]
 
 
> From: Peter Psenak  
> Sent: Tuesday, July 25, 2023 6:05 PM
> 
> Bruno,
> 
> On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
> >   * No reachability (state “0”) by either:
> >   o Not advertising IP1 in TLV 135
> >   o Advertising IP1 in TLV 135with a metric larger than 0xFE00
> 
> 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 0xFE00.
> > 
> > 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 0xFE00 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.

[Bruno] Good if this is what is meant in the draft and if this is only 
misunderstanding.
To be specific, I'm asking about the following changes for IS-IS (please feel 
free to reformulate, OSPF is up to you)

§5.4
OLD: 
U-Flag and UP-Flag are optional flags that have informative character. 
Treatment of these flags on the receiver is optional and the usage of them is 
outside of scope of this document.

NEW: 
The setting of the U-Flag or the UP-Flag signals that the prefix is 
unreachable. They constitute the UPA signals.

§5
"Even though in all cases the treatment of such metric, or NU-bit, is specified 
for IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix 
was advertised in order to signal unreachability is useful to distinguish it 
from other cases where the prefix with such metric is advertised."
:s/useful/required

§Abstract
OLD:  This document describes how to use existing protocol mechanisms in IS-IS 
and OSPF to advertise such prefix reachability loss.
NEW: This document defines two new flags in IS-IS and OSPF to advertise such  
prefix reachability loss. In order to support incremental deployment, such 
advertisement use a high metric value already having special meaning of OSPF 
and IS-IS.

§1
OLD:  This document describes how the use of existing protocol mechanisms can 
support the necessary functionality without the need for any protocol 
extensions. The functionality being described is called Unreachable Prefix 
Announcement (UPA).
NEW: This document defines two new flags in IS-IS and OSPF to the necessary 
functionality without the need for any protocol extensions. The functionality 
being described is called Unreachable Prefix Announcement (UPA). 

Thank you,
Regards,
--Bruno

> > 
> > 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 0xFE00 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 

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

[Peter Psenak]

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com wrote:

Hi all,

IP reachability advertised by IS-IS is often used by other routing and 
signaling protocols (e.g., BGP, PIM (rpf vector) LDP, RSVP-TE...). As 
such, UPA may affect those protocols.


Has UPA been presented in other WGs in the routing areas?

I believe this would be prudent if not required.


why do you believe so? How is this different to an IGP prefix becoming 
unreachable without UPA?




In particular, BGP is (heavily) using reachability of (loopbacks) 
addresses advertised in IS-IS in order to evaluate the reachability of 
BGP routes and compute their preference.


If UPA is not interpreted the same ways by all routers, forwarding loops 
may occur in a hop by hop routed network. (because different routers 
would select different paths since they use different information to 
select their path)


I don't see a problem, please provide an example.
If an ingress PE decides to switch to an alternate BGP path, how does 
that creates any potential loop? And why all egress PEs would need to do 
the same?




This is not considered nor discussed in the draft. Quite the contrary, 
draft says that recognition, processing and use of UPA is a local 
consideration.


yes, and we want to keep it that way.

thanks,
Peter




I would suggest to at minimum present this draft to IDR and gets the 
feedback from the IDR WG.


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

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

[Peter Psenak]

Bruno,

On 25/07/2023 14:39, bruno.decra...@orange.com 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 0xFE00
  * No reachability (state “0”) by either:
  o Not advertising IP1 in TLV 135
  o Advertising IP1 in TLV 135with a metric larger than 0xFE00


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 0xFE00.


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

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

[Peter Psenak]

Robert,

On 27/03/2023 17:18, Robert Raszuk wrote:
 > All it does that it advertises UPA for  prefixes that are summarized 
on it and change from reachable to unreachable


Ok but this is a bit too vague,

If my ABR disconnects from an area nodes it should remove the summary 
and not inject possibly 100s or 1000s of UPAs. And IMO the draft should 
describe this procedure in detail.


Section 6 has the following text:

"It is also recommended that implementations limit the number of UPA
 advertisements which can be originated at a given time."

thanks,
Peter


Thx,
R

On Mon, Mar 27, 2023 at 8:07 AM Peter Psenak > wrote:


Robert,

On 27/03/2023 16:57, Robert Raszuk wrote:
 >     Hi Peter,
 >
 >      >  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.
 >
 >
 > "UPA must be sent for the prefix that is used to resolve BGP
prefixes."
 >
 > Are you saying that UPA is only /32 or /128 ?

I have not said that.


 >
 > So if my PE has /64 loopback and I use it for next hops I can not
send
 > UPA for /64 ?

sure you can.

 > And how would ABR know what I am using as BGP next hops if
 > it may not even run service BGP at all ?

it does not need to know. All it does that it advertises UPA for
prefixes that are summarized on it and change from reachable to
unreachable. If you use /32 as BGP HN and it is covered by the summary,
when you receive UPA for that /32 you may decide to activate PIC. Same
is true if you resolve over /64 locator instead of /32. Again, all this
is up to the implementation. All that drafts specifies is the
indication
of the unreachability from the summarization point.

Peter

 >
 > Thx.
 > R.
 >
 >



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

> All it does that it advertises UPA for  prefixes that are summarized on
it and change from reachable to unreachable

Ok but this is a bit too vague,

If my ABR disconnects from an area nodes it should remove the summary and
not inject possibly 100s or 1000s of UPAs. And IMO the draft should
describe this procedure in detail.

Thx,
R

On Mon, Mar 27, 2023 at 8:07 AM Peter Psenak  wrote:

> Robert,
>
> On 27/03/2023 16:57, Robert Raszuk wrote:
> > Hi Peter,
> >
> >  >  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.
> >
> >
> > "UPA must be sent for the prefix that is used to resolve BGP prefixes."
> >
> > Are you saying that UPA is only /32 or /128 ?
>
> I have not said that.
>
>
> >
> > So if my PE has /64 loopback and I use it for next hops I can not send
> > UPA for /64 ?
>
> sure you can.
>
> > And how would ABR know what I am using as BGP next hops if
> > it may not even run service BGP at all ?
>
> it does not need to know. All it does that it advertises UPA for
> prefixes that are summarized on it and change from reachable to
> unreachable. If you use /32 as BGP HN and it is covered by the summary,
> when you receive UPA for that /32 you may decide to activate PIC. Same
> is true if you resolve over /64 locator instead of /32. Again, all this
> is up to the implementation. All that drafts specifies is the indication
> of the unreachability from the summarization point.
>
> Peter
>
> >
> > Thx.
> > R.
> >
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Robert,

On 27/03/2023 16:57, Robert Raszuk wrote:

Hi Peter,

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


"UPA must be sent for the prefix that is used to resolve BGP prefixes."

Are you saying that UPA is only /32 or /128 ?


I have not said that.




So if my PE has /64 loopback and I use it for next hops I can not send 
UPA for /64 ? 


sure you can.

And how would ABR know what I am using as BGP next hops if 
it may not even run service BGP at all ?


it does not need to know. All it does that it advertises UPA for 
prefixes that are summarized on it and change from reachable to 
unreachable. If you use /32 as BGP HN and it is covered by the summary, 
when you receive UPA for that /32 you may decide to activate PIC. Same 
is true if you resolve over /64 locator instead of /32. Again, all this 
is up to the implementation. All that drafts specifies is the indication 
of the unreachability from the summarization point.


Peter



Thx.
R.




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

>
> Hi Peter,
>


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


"UPA must be sent for the prefix that is used to resolve BGP prefixes."

Are you saying that UPA is only /32 or /128 ?

So if my PE has /64 loopback and I use it for next hops I can not send UPA
for /64 ? And how would ABR know what I am using as BGP next hops if it may
not even run service BGP at all ?

Thx.
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Bruno,

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


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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Christian Hopps]

"Les Ginsberg (ginsberg)"  writes:


Chris/David -



I was replying to Peter saying that implementations are using the max metric
announcements to avoid sending traffic to overload routers.


[LES:] Are you claiming this because you know this to be true - or are you just 
speculating that an implementation "might" do this?


I think you may have misunderstood me. I wasn't claiming anything, rather I was 
replying to a point Peter brought up about overload bit.

I believe David was also not talking about overload bit either. He was saying 
there was a case of using a >= max metric prefix to distribute non-routing 
specific information about a prefix, and thus it would probably be wrong to modify 
routing to that prefix based on that advertisement. At least that's how I read his 
comment.

Thanks,
Chris.



If there is an implementation doing this (i.e., sending max-metric for prefixes
in conjunction with setting the OL bit) I would like to know - and I would like
to know why such an implementation does this.

I am familiar with implementations that may set max-link-metric in conjunction 
with setting the OL bit.
I am also familiar with implementations that withdraw advertisements of 
prefixes in conjunction with setting the OL bit (oftentimes under control of a 
configuration option).
But I am not aware of implementations that send prefix advertisements with max
metric in conjunction with setting the OL bit. Doing so seems rather odd and not
very useful. If an implementation wants to indicate that traffic for that
destination should not be sent to that router, it would normally simply stop
advertising the prefix.
(The OL bit, of course, would keep traffic from transiting the router.)

??

   Les



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Les Ginsberg (ginsberg)]

Chris/David -

> 
> I was replying to Peter saying that implementations are using the max metric
> announcements to avoid sending traffic to overload routers. 

[LES:] Are you claiming this because you know this to be true - or are you just 
speculating that an implementation "might" do this?

If there is an implementation doing this (i.e., sending max-metric for prefixes 
in conjunction with setting the OL bit) I would like to know - and I would like 
to know why such an implementation does this.

I am familiar with implementations that may set max-link-metric in conjunction 
with setting the OL bit.
I am also familiar with implementations that withdraw advertisements of 
prefixes in conjunction with setting the OL bit (oftentimes under control of a 
configuration option).
But I am not aware of implementations that send prefix advertisements with max 
metric in conjunction with setting the OL bit. Doing so seems rather odd and 
not very useful. If an implementation wants to indicate that traffic for that 
destination should not be sent to that router, it would normally simply stop 
advertising the prefix.
(The OL bit, of course, would keep traffic from transiting the router.)

??

   Les



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 12/11/2022 06:45, Christian Hopps wrote:



On Nov 9, 2022, at 2:13 PM, Peter Psenak  
wrote:

On 09/11/2022 14:56, David Lamparter wrote:

On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:

I guess I'd like to understand what one would accomplish with further
specification of prefix reachable? What requirement would this
satisfy? For the use case UPA is designed to handle (triggering BGP
PIC or other local action) , I can't see that there would be any case
where you wouldn’t want to take this action for an unreachable prefix.

The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric > 0xfe00 is 
unreachable. Implementations use the max-metric today to signal the prefix 
unreachability - to avoid reaching local/leaked/redistributed prefixes in cases 
where OL-bit is set on the originator. So we are not doing anything new here 
really.


[as wg-member]

But his interpretation seems correct. RFC5305 says specifically that the prefix 
is not to be used for building the normal IP routing table, that would include 
not creating/installing blackhole/reject routes in the normal IP routing table.

If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE00, 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.

Do the implementations you’re referring to install unreachable routes in the IP 
routing table, seemingly in violation of this?


no.

And we are not proposing anything like that to be done with UPA either. 
The usage of the UPA is up to the receiving application. How it deals 
with the UPA signal is outside of the scope of the UPA draft.


thanks,
Peter




Thanks,
Chris.



I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.
To boil this down into the core of the essence and be explicit,
- you can create an IS-IS prefix reachability for some arbitrary prefix,
   and stick > 0xfe00 into the metric, and that won't have any effect
   on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
   for one reason or another were decided to be routing-related and thus
   make sense to put there
- the assumption for the use case is that there are indeed less specific
   covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
   semantics attached to something that didn't have them before, which
   breaks things (or rather: prevents enabling/deployment of the UPA
   feature)


and why that would be a problem? Such prefix would never be used to for 
resolution of the BGP prefix. So the presence of such unreachable prefix would 
never trigger any action even of the UPA processing was enabled on the 
receiver. I don't see a problem.


- (if those extra prefixes are created with 0x metric, a
   configurable >= limit for UPA does not help either.)


again, what is the problem?


Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.

thanks,
Peter


Cheers,
-David


___
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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Hi Chris,

> If that means they are installing a negative route then they are
modifying the IP routing table.
> If he meant they don't do anything with the announcement, well then
that's in spec.

There are lots of options between installing negative route in IP routing
table and not doing anything with that.

As example negative route may be passed directly to BGP to invalidate BGP
next hop and trigger a new best path run on a set of routes which happen to
select path with such next hop as best.

That would not require to install negative route anywhere.

Second an implementation may have N RIBs - one of them be negative and be
used for next hop validation. It is clearly not an IP routing table
in terms of IP reachability.

A good test perhaps would be to locally originate ICMP ping to PUA covered
dst from PUA receiving node after getting PUA for 1.1.1.1/32 (before the
timeout) ... If ICMP packets will go out of the box to IGP neighbor as
covered by say summary of 1.1.1.0/24 that means PUA is in spec as IP
routing table is unaltered. If we would not see such packets that would
mean there is base for more discussions and the point you are making
stands.

Cheers,
Robert


On Sun, Nov 13, 2022 at 1:18 PM Christian Hopps  wrote:

>
> Robert Raszuk  writes:
>
> > Chris,
> >
> >> unreachable routes in the IP routing table
>
> That quote leaves zero context at all for what I was saying.
>
> I was replying to Peter saying that implementations are using the max
> metric announcements to avoid sending traffic to overload routers. If that
> means they are installing a negative route then they are modifying the IP
> routing table. If he meant they don't do anything with the announcement,
> well then that's in spec.
>
> Thanks,
> Chris.
>
> >
> > I don't see anywhere in the UPA spec even a hint that those
> > unreachable pulses would be installed in the IP routing table. It
> > seems to be a local implementation choice how ISIS or OSPF would
> > inform other protocols about them.
> >
> > In fact the quote you provided specifically "other than building the
> > normal IP routing table" IMO endorses quite verbatim what Peter
> > claims. They can be used for other purposes then building a
> > reachability table.
> >
> > Thx,
> > R.
> >
> >
> >
> >
> >
> >
> > On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps 
> > wrote:
> >
> >
> >
> > > On Nov 9, 2022, at 2:13 PM, Peter Psenak  > 40cisco@dmarc.ietf.org> wrote:
> > >
> > > On 09/11/2022 14:56, David Lamparter wrote:
> > >> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee)
> > wrote:
> > >>> I guess I'd like to understand what one would accomplish with
> > further
> > >>> specification of prefix reachable? What requirement would
> > this
> > >>> satisfy? For the use case UPA is designed to handle
> > (triggering BGP
> > >>> PIC or other local action) , I can't see that there would be
> > any case
> > >>> where you wouldn’t want to take this action for an
> > unreachable prefix.
> > >> The problem is that a prefix with metric > 0xfe00 isn't
> > actually an
> > >> unreachable prefix, it's a prefix that doesn't have specific
> > routing
> > >> information associated with it, which in turn allows sticking
> > other data
> > >> into it that might be routing-related but not quite a
> > reachability.
> > >
> > > well, that is your interpretation. For me a prefix with metric
> > > 0xfe00 is unreachable. Implementations use the max-metric
> > today to signal the prefix unreachability - to avoid reaching
> > local/leaked/redistributed prefixes in cases where OL-bit is set
> > on the originator. So we are not doing anything new here really.
> >
> > [as wg-member]
> >
> > But his interpretation seems correct. RFC5305 says specifically
> > that the prefix is not to be used for building the normal IP
> > routing table, that would include not creating/installing
> > blackhole/reject routes in the normal IP routing table.
> >
> >If a prefix is advertised with a metric larger then
> > MAX_PATH_METRIC
> >(0xFE00, 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.
> >
> > Do the implementations you’re referring to install unreachable
> > routes in the IP routing table, seemingly in violation of this?
> >
> > Thanks,
> > Chris.
> >
> >
> > >> I vaguely remember several years back we did indeed implement
> > something
> > >> (seriously no memory on details) that resulted in the creation
> > of a new
> > >> prefix reachability TLV with some experimental/local
> > sub-TLVs.  These
> > >> prefixes did not exist in the IS-IS domain beforehand.  I have
> > no idea
> > >> what the 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Christian Hopps]

Robert Raszuk  writes:


Chris,


unreachable routes in the IP routing table


That quote leaves zero context at all for what I was saying.

I was replying to Peter saying that implementations are using the max metric 
announcements to avoid sending traffic to overload routers. If that means they 
are installing a negative route then they are modifying the IP routing table. 
If he meant they don't do anything with the announcement, well then that's in 
spec.

Thanks,
Chris.



I don't see anywhere in the UPA spec even a hint that those
unreachable pulses would be installed in the IP routing table. It
seems to be a local implementation choice how ISIS or OSPF would
inform other protocols about them. 

In fact the quote you provided specifically "other than building the
normal IP routing table" IMO endorses quite verbatim what Peter
claims. They can be used for other purposes then building a
reachability table. 

Thx,
R.






On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps 
wrote:



> On Nov 9, 2022, at 2:13 PM, Peter Psenak  wrote:
>
> On 09/11/2022 14:56, David Lamparter wrote:
>> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee)
wrote:
>>> I guess I'd like to understand what one would accomplish with
further
>>> specification of prefix reachable? What requirement would
this
>>> satisfy? For the use case UPA is designed to handle
(triggering BGP
>>> PIC or other local action) , I can't see that there would be
any case
>>> where you wouldn’t want to take this action for an
unreachable prefix.
>> The problem is that a prefix with metric > 0xfe00 isn't
actually an
>> unreachable prefix, it's a prefix that doesn't have specific
routing
>> information associated with it, which in turn allows sticking
other data
>> into it that might be routing-related but not quite a
reachability.
>
> well, that is your interpretation. For me a prefix with metric
> 0xfe00 is unreachable. Implementations use the max-metric
today to signal the prefix unreachability - to avoid reaching
local/leaked/redistributed prefixes in cases where OL-bit is set
on the originator. So we are not doing anything new here really.

[as wg-member]

But his interpretation seems correct. RFC5305 says specifically
that the prefix is not to be used for building the normal IP
routing table, that would include not creating/installing
blackhole/reject routes in the normal IP routing table.

   If a prefix is advertised with a metric larger then
MAX_PATH_METRIC
   (0xFE00, 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.

Do the implementations you’re referring to install unreachable
routes in the IP routing table, seemingly in violation of this?

Thanks,
Chris.


>> I vaguely remember several years back we did indeed implement
something
>> (seriously no memory on details) that resulted in the creation
of a new
>> prefix reachability TLV with some experimental/local
sub-TLVs.  These
>> prefixes did not exist in the IS-IS domain beforehand.  I have
no idea
>> what the operational reality is on the existence of such
things, but I
>> know that /some/ code exists that does this.
>> To boil this down into the core of the essence and be
explicit,
>> - you can create an IS-IS prefix reachability for some
arbitrary prefix,
>>   and stick > 0xfe00 into the metric, and that won't have
any effect
>>   on the existing IS-IS domain
>> - this has in fact been done to carry custom bits of
information that
>>   for one reason or another were decided to be routing-related
and thus
>>   make sense to put there
>> - the assumption for the use case is that there are indeed
less specific
>>   covering prefixes around, providing actual reachability
>> - any setup doing that would now suddenly have fresh
"unreachable"
>>   semantics attached to something that didn't have them
before, which
>>   breaks things (or rather: prevents enabling/deployment of
the UPA
>>   feature)
>
> and why that would be a problem? Such prefix would never be
used to for resolution of the BGP prefix. So the presence of such
unreachable prefix would never trigger any action even of the UPA
processing was enabled on the receiver. I don't see a problem.
>
>> - (if those extra prefixes are created with 0x metric,
a
>>   configurable >= limit for UPA does not help either.)
>
> again, what is the problem?
>
>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever
else is
>> (IMHO) not a significant cost, and completely eliminates this
issue.

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Robert:

>  "other than building the normal IP routing table" 

There may be different purposes, so advertise the “unreachable within the 
summary address” should be signed explicitly.

Aijun Wang
China Telecom

> On Nov 12, 2022, at 11:59, Robert Raszuk  wrote:
> 
> 
> Chris,
> 
> > unreachable routes in the IP routing table
> 
> I don't see anywhere in the UPA spec even a hint that those unreachable 
> pulses would be installed in the IP routing table. It seems to be a local 
> implementation choice how ISIS or OSPF would inform other protocols about 
> them. 
> 
> In fact the quote you provided specifically "other than building the normal 
> IP routing table" IMO endorses quite verbatim what Peter claims. They can be 
> used for other purposes then building a reachability table. 
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
>> On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps  wrote:
>> 
>> 
>> > On Nov 9, 2022, at 2:13 PM, Peter Psenak 
>> >  wrote:
>> > 
>> > On 09/11/2022 14:56, David Lamparter wrote:
>> >> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
>> >>> I guess I'd like to understand what one would accomplish with further
>> >>> specification of prefix reachable? What requirement would this
>> >>> satisfy? For the use case UPA is designed to handle (triggering BGP
>> >>> PIC or other local action) , I can't see that there would be any case
>> >>> where you wouldn’t want to take this action for an unreachable prefix.
>> >> The problem is that a prefix with metric > 0xfe00 isn't actually an
>> >> unreachable prefix, it's a prefix that doesn't have specific routing
>> >> information associated with it, which in turn allows sticking other data
>> >> into it that might be routing-related but not quite a reachability.
>> > 
>> > well, that is your interpretation. For me a prefix with metric > 
>> > 0xfe00 is unreachable. Implementations use the max-metric today to 
>> > signal the prefix unreachability - to avoid reaching 
>> > local/leaked/redistributed prefixes in cases where OL-bit is set on the 
>> > originator. So we are not doing anything new here really.
>> 
>> [as wg-member]
>> 
>> But his interpretation seems correct. RFC5305 says specifically that the 
>> prefix is not to be used for building the normal IP routing table, that 
>> would include not creating/installing blackhole/reject routes in the normal 
>> IP routing table.
>> 
>>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>>(0xFE00, 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.
>> 
>> Do the implementations you’re referring to install unreachable routes in the 
>> IP routing table, seemingly in violation of this?
>> 
>> Thanks,
>> Chris.
>> 
>> 
>> >> I vaguely remember several years back we did indeed implement something
>> >> (seriously no memory on details) that resulted in the creation of a new
>> >> prefix reachability TLV with some experimental/local sub-TLVs.  These
>> >> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>> >> what the operational reality is on the existence of such things, but I
>> >> know that /some/ code exists that does this.
>> >> To boil this down into the core of the essence and be explicit,
>> >> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>> >>   and stick > 0xfe00 into the metric, and that won't have any effect
>> >>   on the existing IS-IS domain
>> >> - this has in fact been done to carry custom bits of information that
>> >>   for one reason or another were decided to be routing-related and thus
>> >>   make sense to put there
>> >> - the assumption for the use case is that there are indeed less specific
>> >>   covering prefixes around, providing actual reachability
>> >> - any setup doing that would now suddenly have fresh "unreachable"
>> >>   semantics attached to something that didn't have them before, which
>> >>   breaks things (or rather: prevents enabling/deployment of the UPA
>> >>   feature)
>> > 
>> > and why that would be a problem? Such prefix would never be used to for 
>> > resolution of the BGP prefix. So the presence of such unreachable prefix 
>> > would never trigger any action even of the UPA processing was enabled on 
>> > the receiver. I don't see a problem.
>> > 
>> >> - (if those extra prefixes are created with 0x metric, a
>> >>   configurable >= limit for UPA does not help either.)
>> > 
>> > again, what is the problem?
>> > 
>> >> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
>> >> (IMHO) not a significant cost, and completely eliminates this issue.
>> >> The only reason against it (that I can think of) is that the
>> >> advertisement might be a little bit larger;  a new sub-TLV or flag bit
>> >> should be completely invisible to existing implementations (= I don't
>> >> see how 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Chris,

> unreachable routes in the IP routing table

I don't see anywhere in the UPA spec even a hint that those unreachable
pulses would be installed in the IP routing table. It seems to be a local
implementation choice how ISIS or OSPF would inform other protocols about
them.

In fact the quote you provided specifically "other than building the normal
IP routing table" IMO endorses quite verbatim what Peter claims. They can
be used for other purposes then building a reachability table.

Thx,
R.






On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps  wrote:

>
>
> > On Nov 9, 2022, at 2:13 PM, Peter Psenak  40cisco@dmarc.ietf.org> wrote:
> >
> > On 09/11/2022 14:56, David Lamparter wrote:
> >> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> >>> I guess I'd like to understand what one would accomplish with further
> >>> specification of prefix reachable? What requirement would this
> >>> satisfy? For the use case UPA is designed to handle (triggering BGP
> >>> PIC or other local action) , I can't see that there would be any case
> >>> where you wouldn’t want to take this action for an unreachable prefix.
> >> The problem is that a prefix with metric > 0xfe00 isn't actually an
> >> unreachable prefix, it's a prefix that doesn't have specific routing
> >> information associated with it, which in turn allows sticking other data
> >> into it that might be routing-related but not quite a reachability.
> >
> > well, that is your interpretation. For me a prefix with metric >
> 0xfe00 is unreachable. Implementations use the max-metric today to
> signal the prefix unreachability - to avoid reaching
> local/leaked/redistributed prefixes in cases where OL-bit is set on the
> originator. So we are not doing anything new here really.
>
> [as wg-member]
>
> But his interpretation seems correct. RFC5305 says specifically that the
> prefix is not to be used for building the normal IP routing table, that
> would include not creating/installing blackhole/reject routes in the normal
> IP routing table.
>
>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>(0xFE00, 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.
>
> Do the implementations you’re referring to install unreachable routes in
> the IP routing table, seemingly in violation of this?
>
> Thanks,
> Chris.
>
>
> >> I vaguely remember several years back we did indeed implement something
> >> (seriously no memory on details) that resulted in the creation of a new
> >> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >> what the operational reality is on the existence of such things, but I
> >> know that /some/ code exists that does this.
> >> To boil this down into the core of the essence and be explicit,
> >> - you can create an IS-IS prefix reachability for some arbitrary prefix,
> >>   and stick > 0xfe00 into the metric, and that won't have any effect
> >>   on the existing IS-IS domain
> >> - this has in fact been done to carry custom bits of information that
> >>   for one reason or another were decided to be routing-related and thus
> >>   make sense to put there
> >> - the assumption for the use case is that there are indeed less specific
> >>   covering prefixes around, providing actual reachability
> >> - any setup doing that would now suddenly have fresh "unreachable"
> >>   semantics attached to something that didn't have them before, which
> >>   breaks things (or rather: prevents enabling/deployment of the UPA
> >>   feature)
> >
> > and why that would be a problem? Such prefix would never be used to for
> resolution of the BGP prefix. So the presence of such unreachable prefix
> would never trigger any action even of the UPA processing was enabled on
> the receiver. I don't see a problem.
> >
> >> - (if those extra prefixes are created with 0x metric, a
> >>   configurable >= limit for UPA does not help either.)
> >
> > again, what is the problem?
> >
> >> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >> (IMHO) not a significant cost, and completely eliminates this issue.
> >> The only reason against it (that I can think of) is that the
> >> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >> should be completely invisible to existing implementations (= I don't
> >> see how this would create compatibility or rollout problems.)
> >
> > I'm afraid, you forgot to consider an operational aspect of the solution.
> >
> > thanks,
> > Peter
> >
> >> Cheers,
> >> -David
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Christian Hopps]

> On Nov 9, 2022, at 2:13 PM, Peter Psenak  
> wrote:
> 
> On 09/11/2022 14:56, David Lamparter wrote:
>> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
>>> I guess I'd like to understand what one would accomplish with further
>>> specification of prefix reachable? What requirement would this
>>> satisfy? For the use case UPA is designed to handle (triggering BGP
>>> PIC or other local action) , I can't see that there would be any case
>>> where you wouldn’t want to take this action for an unreachable prefix.
>> The problem is that a prefix with metric > 0xfe00 isn't actually an
>> unreachable prefix, it's a prefix that doesn't have specific routing
>> information associated with it, which in turn allows sticking other data
>> into it that might be routing-related but not quite a reachability.
> 
> well, that is your interpretation. For me a prefix with metric > 0xfe00 
> is unreachable. Implementations use the max-metric today to signal the prefix 
> unreachability - to avoid reaching local/leaked/redistributed prefixes in 
> cases where OL-bit is set on the originator. So we are not doing anything new 
> here really.

[as wg-member]

But his interpretation seems correct. RFC5305 says specifically that the prefix 
is not to be used for building the normal IP routing table, that would include 
not creating/installing blackhole/reject routes in the normal IP routing table.

   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, 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.

Do the implementations you’re referring to install unreachable routes in the IP 
routing table, seemingly in violation of this?

Thanks,
Chris.


>> I vaguely remember several years back we did indeed implement something
>> (seriously no memory on details) that resulted in the creation of a new
>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>> what the operational reality is on the existence of such things, but I
>> know that /some/ code exists that does this.
>> To boil this down into the core of the essence and be explicit,
>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>   and stick > 0xfe00 into the metric, and that won't have any effect
>>   on the existing IS-IS domain
>> - this has in fact been done to carry custom bits of information that
>>   for one reason or another were decided to be routing-related and thus
>>   make sense to put there
>> - the assumption for the use case is that there are indeed less specific
>>   covering prefixes around, providing actual reachability
>> - any setup doing that would now suddenly have fresh "unreachable"
>>   semantics attached to something that didn't have them before, which
>>   breaks things (or rather: prevents enabling/deployment of the UPA
>>   feature)
> 
> and why that would be a problem? Such prefix would never be used to for 
> resolution of the BGP prefix. So the presence of such unreachable prefix 
> would never trigger any action even of the UPA processing was enabled on the 
> receiver. I don't see a problem.
> 
>> - (if those extra prefixes are created with 0x metric, a
>>   configurable >= limit for UPA does not help either.)
> 
> again, what is the problem?
> 
>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
>> (IMHO) not a significant cost, and completely eliminates this issue.
>> The only reason against it (that I can think of) is that the
>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
>> should be completely invisible to existing implementations (= I don't
>> see how this would create compatibility or rollout problems.)
> 
> I'm afraid, you forgot to consider an operational aspect of the solution.
> 
> thanks,
> Peter
> 
>> Cheers,
>> -David
> 
> ___
> 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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

>
>
> > I think the point of this was that it could be other applications where
> > an ephemeral unreachability notification is useful. For this type of
> > notification, recursive route resolution is the primary application.
> > However, I’ll defer to the authors.
>
> that is correct indeed.
>

Ok that explanation works !

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 10/11/2022 11:59, Acee Lindem (acee) wrote:

Hi Robert,

*From: *Robert Raszuk 
*Date: *Thursday, November 10, 2022 at 10:51 AM
*To: *Acee Lindem 
*Cc: *Peter Psenak , Bruno Decraene 
, David Lamparter , 
"lsr@ietf.org" 
*Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA 
IS-IS semantics


 > But BGP service PIC is the use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using 
BGP for such signalling as "BGP may not be running there at all".


So if the draft works *only* with service provided by BGP let's please 
state it clearly in the document. This is not my current assumption.


I think the point of this was that it could be other applications where 
an ephemeral unreachability notification is useful. For this type of 
notification, recursive route resolution is the primary application. 
However, I’ll defer to the authors.


that is correct indeed.

thanks,
Peter




Thanks,
Acee

Many thx,

R.

On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) <mailto:a...@cisco.com>> wrote:


Hi Robert,

*From: *Robert Raszuk mailto:rob...@raszuk.net>>
*Date: *Thursday, November 10, 2022 at 9:41 AM
*To: *Peter Psenak mailto:40cisco@dmarc.ietf.org>>
*Cc: *Bruno Decraene mailto:bruno.decra...@orange.com>>, David Lamparter
mailto:equi...@diac24.net>>, Acee Lindem
mailto:a...@cisco.com>>, "lsr@ietf.org
    <mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
*Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce /
UPA IS-IS semantics

Peter,

 > But:
 > - that is nonetheless a change which is non backward
compatible with people currently using such high metric without
the intention to mean UPA
 > - to differentiate different usages (e.g. your UPA, my other
usage such as "graceful shutdown" (still reachable but will
disappear soon), endpoint CPU load is 80%...) one

well, the question is whether it would not make sense to trigger
UPA for
the above mentioned usages as well. Because eventually the
destination
is becoming unreachable anyway and I would want my services to
reroute
to alternate egress node. But seems like folks want to have a
way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top.
Example - some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ...
especially considering that they are history after the timeout
irrespective of the remote prefix state.

But BGP service PIC is the use case this draft is targeting? For
example, there is no intent to install negative routes throughout
the domain.

Thanks,
Acee

Cheers,

R.


thanks,
Peter

 > would need to use different metric values that would need to
be at least locally registered. So why not have the IANA
register a flag and avoid each network operator to do that job?
 >
 > In all cases, I don't see a reason for UPA to change the
meaning of all the metric values >0xFE00. You can pick a
single value (e.g. 0xFE01) and that would equally work for
your use case.
 >
 > Regards,
 > --Bruno
 >
 >
 >
 >
 >>
 >>>
 >>> I vaguely remember several years back we did indeed
implement something
 >>> (seriously no memory on details) that resulted in the
creation of a new
 >>> prefix reachability TLV with some experimental/local
sub-TLVs.  These
 >>> prefixes did not exist in the IS-IS domain beforehand.  I
have no idea
 >>> what the operational reality is on the existence of such
things, but I
 >>> know that /some/ code exists that does this.
 >>>
 >>> To boil this down into the core of the essence and be explicit,
 >>>
 >>> - you can create an IS-IS prefix reachability for some
arbitrary prefix,
 >>>     and stick > 0xfe00 into the metric, and that won't
have any effect
 >>>     on the existing IS-IS domain
 >>> - this has in fact been done to carry custom bits of
information that
 >>>     for one reason or another were decided to be
routing-related and thus
 >>>     make sense to put there
 >>> - the assumption for the use case is

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Thursday, November 10, 2022 at 10:51 AM
To: Acee Lindem 
Cc: Peter Psenak , Bruno Decraene 
, David Lamparter , 
"lsr@ietf.org" 
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS 
semantics

> But BGP service PIC is the use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using BGP 
for such signalling as "BGP may not be running there at all".

So if the draft works *only* with service provided by BGP let's please state it 
clearly in the document. This is not my current assumption.

I think the point of this was that it could be other applications where an 
ephemeral unreachability notification is useful. For this type of notification, 
recursive route resolution is the primary application. However, I’ll defer to 
the authors.

Thanks,
Acee


Many thx,
R.



On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Thursday, November 10, 2022 at 9:41 AM
To: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>
Cc: Bruno Decraene 
mailto:bruno.decra...@orange.com>>, David Lamparter 
mailto:equi...@diac24.net>>, Acee Lindem 
mailto:a...@cisco.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS 
semantics

Peter,

> But:
> - that is nonetheless a change which is non backward compatible with people 
> currently using such high metric without the intention to mean UPA
> - to differentiate different usages (e.g. your UPA, my other usage such as 
> "graceful shutdown" (still reachable but will disappear soon), endpoint CPU 
> load is 80%...) one

well, the question is whether it would not make sense to trigger UPA for
the above mentioned usages as well. Because eventually the destination
is becoming unreachable anyway and I would want my services to reroute
to alternate egress node. But seems like folks want to have a way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example - 
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ... especially 
considering that they are history after the timeout irrespective of the remote 
prefix state.

But BGP service PIC is the use case this draft is targeting? For example, there 
is no intent to install negative routes throughout the domain.

Thanks,
Acee


Cheers,
R.








thanks,
Peter

> would need to use different metric values that would need to be at least 
> locally registered. So why not have the IANA register a flag and avoid each 
> network operator to do that job?
>
> In all cases, I don't see a reason for UPA to change the meaning of all the 
> metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
> that would equally work for your use case.
>
> Regards,
> --Bruno
>
>
>
>
>>
>>>
>>> I vaguely remember several years back we did indeed implement something
>>> (seriously no memory on details) that resulted in the creation of a new
>>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>>> what the operational reality is on the existence of such things, but I
>>> know that /some/ code exists that does this.
>>>
>>> To boil this down into the core of the essence and be explicit,
>>>
>>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>> and stick > 0xfe00 into the metric, and that won't have any effect
>>> on the existing IS-IS domain
>>> - this has in fact been done to carry custom bits of information that
>>> for one reason or another were decided to be routing-related and thus
>>> make sense to put there
>>> - the assumption for the use case is that there are indeed less specific
>>> covering prefixes around, providing actual reachability
>>> - any setup doing that would now suddenly have fresh "unreachable"
>>> semantics attached to something that didn't have them before, which
>>> breaks things (or rather: prevents enabling/deployment of the UPA
>>> feature)
>>
>> and why that would be a problem? Such prefix would never be used to for
>> resolution of the BGP prefix. So the presence of such unreachable prefix
>> would never trigger any action even of the UPA processing was enabled on
>> th

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Peter:

I suggest that you consider such problems and the solutions from the broader 
viewpoint, not just the behavior of one single device, or only from the vendor 
side.
To deploy the mechanism into the network, the operator must assure it will not 
conflict with other possible usages, and no more constrained for the network 
planning, network operations.

There are already amounts of solutions cannot be deployed widespread in the 
network.

Let’s take the explicit signaling approaches. 



Aijun Wang
China Telecom

> On Nov 10, 2022, at 10:41, Peter Psenak  
> wrote:
> 
> On 09/11/2022 22:51, Aijun Wang wrote:
>> Hi, Peter:
>> Actually, the “unreachable” meaning of LSInfinity in current standard is not 
>> the same as the “unreachable” meaning that we are supposed to act:
>> 1) In current standard, the “unreachable” is meant that the related prefix 
>> will not be in the FIB.(you can read again and again 
>> https://www.rfc-editor.org/rfc/rfc2328.html#page-157 
>> )
>> 2) What we aim to solve is that although the specific prefixes is not in the 
>> FIB, there is another summary address that cover it is in the FIB. Even in 
>> such situations, the specific prefixes is still unreachable.
>> Then, depend solely on 1) is not enough.
>> We must need one explicit information to signal 2).
>> There are so many experts within LSR state that your solution is not 
>> appropriate,  will bring much chaos into the network, you still insist your 
>> approach. Is this productive?
> 
> interesting that you, who hardly listen to these experts at all, are saying 
> that.
> 
> Peter
> 
> 
>> The final solution should be definitely in “Standard Track”, but not your 
>> approach.
>> The explicit signaling is the right direction.
>> Even the experts in LSR are confusing on your multiplex usage of 
>> “LSInfinity”, how to deploy it in the large scale network?
>> Please don’t let the operator struggle to explain such vague usages to its 
>> Network OPS, Network Planning team.
>> Aijun Wang
>> China Telecom
>>> 
 I wasn't clear on that in the first mail but Bruno clarified
 that this would still be inside a high-metric prefix reachability TLV.
 The only difference is that there is a flag/sub-TLV inside that triggers
 UPA behavior.  However, prefixes with > 0xfe00 metric *without*
 the UPA indicator MUST be ignored as they were before and MUST NOT
 trigger UPA/PIC.
>>> 
>>> for me flagging something that is unreachable with a unreachable flag is 
>>> redundant. But I let the WG to decide. That would obviously push the draft 
>>> to standard track trajectory.
>>> 
>>> Peter
>>> 
>>> 
 Cheers,
 -David
>>> 
>>> ___
>>> 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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

> But BGP service PIC is the use case this draft is targeting?

For many emails on LSR and beyond I got point from authors against using
BGP for such signalling as "BGP may not be running there at all".

So if the draft works *only* with service provided by BGP let's please
state it clearly in the document. This is not my current assumption.

Many thx,
R.



On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Robert Raszuk 
> *Date: *Thursday, November 10, 2022 at 9:41 AM
> *To: *Peter Psenak 
> *Cc: *Bruno Decraene , David Lamparter <
> equi...@diac24.net>, Acee Lindem , "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA
> IS-IS semantics
>
>
>
> Peter,
>
>
>
> > But:
> > - that is nonetheless a change which is non backward compatible with
> people currently using such high metric without the intention to mean UPA
> > - to differentiate different usages (e.g. your UPA, my other usage such
> as "graceful shutdown" (still reachable but will disappear soon), endpoint
> CPU load is 80%...) one
>
> well, the question is whether it would not make sense to trigger UPA for
> the above mentioned usages as well. Because eventually the destination
> is becoming unreachable anyway and I would want my services to reroute
> to alternate egress node. But seems like folks want to have a way to
> differentiate, so I'm not going to argue against it.
>
>
>
> I think You are right if there is a hierarchical service above it.
>
>
>
> But consider flat routing - where there is no BGP service on top. Example
> - some DCs do use flat routing.
>
>
>
> With that I am afraid UPA triggers may not work well (or at all) ...
> especially considering that they are history after the timeout irrespective
> of the remote prefix state.
>
>
>
> But BGP service PIC is the use case this draft is targeting? For example,
> there is no intent to install negative routes throughout the domain.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thanks,
> Peter
>
> > would need to use different metric values that would need to be at least
> locally registered. So why not have the IANA register a flag and avoid each
> network operator to do that job?
> >
> > In all cases, I don't see a reason for UPA to change the meaning of all
> the metric values >0xFE00. You can pick a single value (e.g.
> 0xFE01) and that would equally work for your use case.
> >
> > Regards,
> > --Bruno
> >
> >
> >
> >
> >>
> >>>
> >>> I vaguely remember several years back we did indeed implement something
> >>> (seriously no memory on details) that resulted in the creation of a new
> >>> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >>> what the operational reality is on the existence of such things, but I
> >>> know that /some/ code exists that does this.
> >>>
> >>> To boil this down into the core of the essence and be explicit,
> >>>
> >>> - you can create an IS-IS prefix reachability for some arbitrary
> prefix,
> >>> and stick > 0xfe00 into the metric, and that won't have any
> effect
> >>> on the existing IS-IS domain
> >>> - this has in fact been done to carry custom bits of information that
> >>> for one reason or another were decided to be routing-related and
> thus
> >>> make sense to put there
> >>> - the assumption for the use case is that there are indeed less
> specific
> >>> covering prefixes around, providing actual reachability
> >>> - any setup doing that would now suddenly have fresh "unreachable"
> >>> semantics attached to something that didn't have them before, which
> >>> breaks things (or rather: prevents enabling/deployment of the UPA
> >>> feature)
> >>
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix. So the presence of such unreachable prefix
> >> would never trigger any action even of the UPA processing was enabled on
> >> the receiver. I don't see a problem.
> >>
> >>> - (if those extra prefixes are created with 0x metric, a
> &g

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Thursday, November 10, 2022 at 9:41 AM
To: Peter Psenak 
Cc: Bruno Decraene , David Lamparter 
, Acee Lindem , "lsr@ietf.org" 

Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS 
semantics

Peter,

> But:
> - that is nonetheless a change which is non backward compatible with people 
> currently using such high metric without the intention to mean UPA
> - to differentiate different usages (e.g. your UPA, my other usage such as 
> "graceful shutdown" (still reachable but will disappear soon), endpoint CPU 
> load is 80%...) one

well, the question is whether it would not make sense to trigger UPA for
the above mentioned usages as well. Because eventually the destination
is becoming unreachable anyway and I would want my services to reroute
to alternate egress node. But seems like folks want to have a way to
differentiate, so I'm not going to argue against it.

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example - 
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ... especially 
considering that they are history after the timeout irrespective of the remote 
prefix state.

But BGP service PIC is the use case this draft is targeting? For example, there 
is no intent to install negative routes throughout the domain.

Thanks,
Acee


Cheers,
R.








thanks,
Peter

> would need to use different metric values that would need to be at least 
> locally registered. So why not have the IANA register a flag and avoid each 
> network operator to do that job?
>
> In all cases, I don't see a reason for UPA to change the meaning of all the 
> metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
> that would equally work for your use case.
>
> Regards,
> --Bruno
>
>
>
>
>>
>>>
>>> I vaguely remember several years back we did indeed implement something
>>> (seriously no memory on details) that resulted in the creation of a new
>>> prefix reachability TLV with some experimental/local sub-TLVs.  These
>>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>>> what the operational reality is on the existence of such things, but I
>>> know that /some/ code exists that does this.
>>>
>>> To boil this down into the core of the essence and be explicit,
>>>
>>> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>>> and stick > 0xfe00 into the metric, and that won't have any effect
>>> on the existing IS-IS domain
>>> - this has in fact been done to carry custom bits of information that
>>> for one reason or another were decided to be routing-related and thus
>>> make sense to put there
>>> - the assumption for the use case is that there are indeed less specific
>>> covering prefixes around, providing actual reachability
>>> - any setup doing that would now suddenly have fresh "unreachable"
>>> semantics attached to something that didn't have them before, which
>>> breaks things (or rather: prevents enabling/deployment of the UPA
>>> feature)
>>
>> and why that would be a problem? Such prefix would never be used to for
>> resolution of the BGP prefix. So the presence of such unreachable prefix
>> would never trigger any action even of the UPA processing was enabled on
>> the receiver. I don't see a problem.
>>
>>> - (if those extra prefixes are created with 0x metric, a
>>> configurable >= limit for UPA does not help either.)
>>
>> again, what is the problem?
>>
>>>
>>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
>>> (IMHO) not a significant cost, and completely eliminates this issue.
>>> The only reason against it (that I can think of) is that the
>>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
>>> should be completely invisible to existing implementations (= I don't
>>> see how this would create compatibility or rollout problems.)
>>
>> I'm afraid, you forgot to consider an operational aspect of the solution.
>>
>> thanks,
>> Peter
>>
>>>
>>> Cheers,
>>>
>>>
>>> -David
>>>
>>
>
> Orange Restricted
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou p

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 09/11/2022 22:51, Aijun Wang wrote:

Hi, Peter:

Actually, the “unreachable” meaning of LSInfinity in current standard is 
not the same as the “unreachable” meaning that we are supposed to act:
1) In current standard, the “unreachable” is meant that the related 
prefix will not be in the FIB.(you can read again and again 
https://www.rfc-editor.org/rfc/rfc2328.html#page-157 
)


2) What we aim to solve is that although the specific prefixes is not in 
the FIB, there is another summary address that cover it is in the FIB. 
Even in such situations, the specific prefixes is still unreachable.


Then, depend solely on 1) is not enough.
We must need one explicit information to signal 2).

There are so many experts within LSR state that your solution is not 
appropriate,  will bring much chaos into the network, you still insist 
your approach. Is this productive?


interesting that you, who hardly listen to these experts at all, are 
saying that.


Peter




The final solution should be definitely in “Standard Track”, but not 
your approach.

The explicit signaling is the right direction.

Even the experts in LSR are confusing on your multiplex usage of 
“LSInfinity”, how to deploy it in the large scale network?


Please don’t let the operator struggle to explain such vague usages to 
its Network OPS, Network Planning team.


Aijun Wang
China Telecom



I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.


for me flagging something that is unreachable with a unreachable flag 
is redundant. But I let the WG to decide. That would obviously push 
the draft to standard track trajectory.


Peter



Cheers,
-David


___
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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Peter,

> But:
> > - that is nonetheless a change which is non backward compatible with
> people currently using such high metric without the intention to mean UPA
> > - to differentiate different usages (e.g. your UPA, my other usage such
> as "graceful shutdown" (still reachable but will disappear soon), endpoint
> CPU load is 80%...) one
>
> well, the question is whether it would not make sense to trigger UPA for
> the above mentioned usages as well. Because eventually the destination
> is becoming unreachable anyway and I would want my services to reroute
> to alternate egress node. But seems like folks want to have a way to
> differentiate, so I'm not going to argue against it.
>

I think You are right if there is a hierarchical service above it.

But consider flat routing - where there is no BGP service on top. Example -
some DCs do use flat routing.

With that I am afraid UPA triggers may not work well (or at all) ...
especially considering that they are history after the timeout irrespective
of the remote prefix state.

Cheers,
R.








>
> thanks,
> Peter
>
> > would need to use different metric values that would need to be at least
> locally registered. So why not have the IANA register a flag and avoid each
> network operator to do that job?
> >
> > In all cases, I don't see a reason for UPA to change the meaning of all
> the metric values >0xFE00. You can pick a single value (e.g.
> 0xFE01) and that would equally work for your use case.
> >
> > Regards,
> > --Bruno
> >
> >
> >
> >
> >>
> >>>
> >>> I vaguely remember several years back we did indeed implement something
> >>> (seriously no memory on details) that resulted in the creation of a new
> >>> prefix reachability TLV with some experimental/local sub-TLVs.  These
> >>> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> >>> what the operational reality is on the existence of such things, but I
> >>> know that /some/ code exists that does this.
> >>>
> >>> To boil this down into the core of the essence and be explicit,
> >>>
> >>> - you can create an IS-IS prefix reachability for some arbitrary
> prefix,
> >>> and stick > 0xfe00 into the metric, and that won't have any
> effect
> >>> on the existing IS-IS domain
> >>> - this has in fact been done to carry custom bits of information that
> >>> for one reason or another were decided to be routing-related and
> thus
> >>> make sense to put there
> >>> - the assumption for the use case is that there are indeed less
> specific
> >>> covering prefixes around, providing actual reachability
> >>> - any setup doing that would now suddenly have fresh "unreachable"
> >>> semantics attached to something that didn't have them before, which
> >>> breaks things (or rather: prevents enabling/deployment of the UPA
> >>> feature)
> >>
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix. So the presence of such unreachable prefix
> >> would never trigger any action even of the UPA processing was enabled on
> >> the receiver. I don't see a problem.
> >>
> >>> - (if those extra prefixes are created with 0x metric, a
> >>> configurable >= limit for UPA does not help either.)
> >>
> >> again, what is the problem?
> >>
> >>>
> >>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >>> (IMHO) not a significant cost, and completely eliminates this issue.
> >>> The only reason against it (that I can think of) is that the
> >>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >>> should be completely invisible to existing implementations (= I don't
> >>> see how this would create compatibility or rollout problems.)
> >>
> >> I'm afraid, you forgot to consider an operational aspect of the
> solution.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Cheers,
> >>>
> >>>
> >>> -David
> >>>
> >>
> >
> > Orange Restricted
> >
> >
> _
> >
> > 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.
> > 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

Bruno,

On 10/11/2022 02:18, bruno.decra...@orange.com wrote:

Peter,


From: Peter Psenak 
Sent: Wednesday, November 9, 2022 2:13 PM

On 09/11/2022 14:56, David Lamparter wrote:

On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:

I guess I'd like to understand what one would accomplish with further
specification of prefix reachable? What requirement would this
satisfy? For the use case UPA is designed to handle (triggering BGP
PIC or other local action) , I can't see that there would be any case
where you wouldn’t want to take this action for an unreachable prefix.


The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric >
0xfe00 is unreachable. Implementations use the max-metric today to
signal the prefix unreachability - to avoid reaching
local/leaked/redistributed prefixes in cases where OL-bit is set on the
originator. So we are not doing anything new here really.


I'm a bit surprised since even draft-ppsenak-lsr-igp-ureach-prefix-announce 
seems to say the contrary:

Old nodes:
" Existing nodes in a network which receive UPA advertisements will
ignore them."

New nodes:
"As per the definitions referenced in the preceding section, any
prefix advertisement with a metric value greater than 0xFE00 can
be used for purposes other than normal routing calculations.  Such an
advertisement can be interpreted by the receiver as a UPA."

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-01#section-2.1

So draft seems to clearly state that the UPA is a new interpretation leading to 
a new behavior.

To me, the difference of opinions expressed on the list is the following:
a) draft-ppsenak-lsr-igp-ureach-prefix-announce is fine with the specific 
metric value being locally interpreted as UPA even though that's not a 
standard/global behavior
b) multiple other persons on the list have preference for an explicit signaling with a 
standardized meaning being "UPA"

I agree that "a" can be made to work, with a local interpretation through local 
config or new code.


thanks for admitting that.


But:
- that is nonetheless a change which is non backward compatible with people 
currently using such high metric without the intention to mean UPA
- to differentiate different usages (e.g. your UPA, my other usage such as "graceful shutdown" (still reachable but will disappear soon), endpoint CPU load is 80%...) one 


well, the question is whether it would not make sense to trigger UPA for 
the above mentioned usages as well. Because eventually the destination 
is becoming unreachable anyway and I would want my services to reroute 
to alternate egress node. But seems like folks want to have a way to 
differentiate, so I'm not going to argue against it.


thanks,
Peter


would need to use different metric values that would need to be at least 
locally registered. So why not have the IANA register a flag and avoid each 
network operator to do that job?

In all cases, I don't see a reason for UPA to change the meaning of all the metric 
values >0xFE00. You can pick a single value (e.g. 0xFE01) and that 
would equally work for your use case.

Regards,
--Bruno








I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.

To boil this down into the core of the essence and be explicit,

- you can create an IS-IS prefix reachability for some arbitrary prefix,
and stick > 0xfe00 into the metric, and that won't have any effect
on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
for one reason or another were decided to be routing-related and thus
make sense to put there
- the assumption for the use case is that there are indeed less specific
covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
semantics attached to something that didn't have them before, which
breaks things (or rather: prevents enabling/deployment of the UPA
feature)


and why that would be a problem? Such prefix would never be used to for
resolution of the BGP prefix. So the presence of such unreachable prefix
would never trigger any action even of the UPA processing was enabled on
the receiver. I don't see a problem.


- (if those extra prefixes are created with 0x metric, a
configurable >= 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[bruno.decraene]

Peter,

> From: Peter Psenak  
> Sent: Wednesday, November 9, 2022 2:13 PM
> 
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> >> I guess I'd like to understand what one would accomplish with further
> >> specification of prefix reachable? What requirement would this
> >> satisfy? For the use case UPA is designed to handle (triggering BGP
> >> PIC or other local action) , I can't see that there would be any case
> >> where you wouldn’t want to take this action for an unreachable prefix.
> > 
> > The problem is that a prefix with metric > 0xfe00 isn't actually an
> > unreachable prefix, it's a prefix that doesn't have specific routing
> > information associated with it, which in turn allows sticking other data
> > into it that might be routing-related but not quite a reachability.
> 
> well, that is your interpretation. For me a prefix with metric > 
> 0xfe00 is unreachable. Implementations use the max-metric today to 
> signal the prefix unreachability - to avoid reaching 
> local/leaked/redistributed prefixes in cases where OL-bit is set on the 
> originator. So we are not doing anything new here really.

I'm a bit surprised since even draft-ppsenak-lsr-igp-ureach-prefix-announce 
seems to say the contrary:

Old nodes:
" Existing nodes in a network which receive UPA advertisements will
   ignore them."

New nodes:
"As per the definitions referenced in the preceding section, any
   prefix advertisement with a metric value greater than 0xFE00 can
   be used for purposes other than normal routing calculations.  Such an
   advertisement can be interpreted by the receiver as a UPA."

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-01#section-2.1

So draft seems to clearly state that the UPA is a new interpretation leading to 
a new behavior.

To me, the difference of opinions expressed on the list is the following:
a) draft-ppsenak-lsr-igp-ureach-prefix-announce is fine with the specific 
metric value being locally interpreted as UPA even though that's not a 
standard/global behavior
b) multiple other persons on the list have preference for an explicit signaling 
with a standardized meaning being "UPA"

I agree that "a" can be made to work, with a local interpretation through local 
config or new code.
But:
- that is nonetheless a change which is non backward compatible with people 
currently using such high metric without the intention to mean UPA
- to differentiate different usages (e.g. your UPA, my other usage such as 
"graceful shutdown" (still reachable but will disappear soon), endpoint CPU 
load is 80%...) one would need to use different metric values that would need 
to be at least locally registered. So why not have the IANA register a flag and 
avoid each network operator to do that job?

In all cases, I don't see a reason for UPA to change the meaning of all the 
metric values >0xFE00. You can pick a single value (e.g. 0xFE01) and 
that would equally work for your use case.

Regards,
--Bruno




> 
> > 
> > I vaguely remember several years back we did indeed implement something
> > (seriously no memory on details) that resulted in the creation of a new
> > prefix reachability TLV with some experimental/local sub-TLVs.  These
> > prefixes did not exist in the IS-IS domain beforehand.  I have no idea
> > what the operational reality is on the existence of such things, but I
> > know that /some/ code exists that does this.
> > 
> > To boil this down into the core of the essence and be explicit,
> > 
> > - you can create an IS-IS prefix reachability for some arbitrary prefix,
> >and stick > 0xfe00 into the metric, and that won't have any effect
> >on the existing IS-IS domain
> > - this has in fact been done to carry custom bits of information that
> >for one reason or another were decided to be routing-related and thus
> >make sense to put there
> > - the assumption for the use case is that there are indeed less specific
> >covering prefixes around, providing actual reachability
> > - any setup doing that would now suddenly have fresh "unreachable"
> >semantics attached to something that didn't have them before, which
> >breaks things (or rather: prevents enabling/deployment of the UPA
> >feature)
> 
> and why that would be a problem? Such prefix would never be used to for 
> resolution of the BGP prefix. So the presence of such unreachable prefix 
> would never trigger any action even of the UPA processing was enabled on 
> the receiver. I don't see a problem.
> 
> > - (if those extra prefixes are created with 0x metric, a
> >configurable >= limit for UPA does not help either.)
> 
> again, what is the problem?
> 
> > 
> > Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> > (IMHO) not a significant cost, and completely eliminates this issue.
> > The only reason against it (that I can think of) is that the
> > 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Robert Raszuk]

Aijun,

 > there is another summary address that covers it is in the FIB.

You keep bringing this point over and over.

But what you are not aware of is that service route validation or
invalidation can be set and tracked for reachability with specific length
of the next hop. Both validation and invalidation can be of different
length. So from this point of view what UPA suggests works just fine.

Your local implementation can trivially be able to handle such triggers for
invalidation.

I have my own reservations for UPA but I do not see how points you are
raising are of any real issues.

Kind regards,
R.









On Wed, Nov 9, 2022 at 10:51 PM Aijun Wang 
wrote:

> Hi, Peter:
>
> Actually, the “unreachable” meaning of LSInfinity in current standard is
> not the same as the “unreachable” meaning that we are supposed to act:
> 1) In current standard, the “unreachable” is meant that the related prefix
> will not be in the FIB.(you can read again and again
> https://www.rfc-editor.org/rfc/rfc2328.html#page-157)
>
> 2) What we aim to solve is that although the specific prefixes is not in
> the FIB, there is another summary address that cover it is in the FIB. Even
> in such situations, the specific prefixes is still unreachable.
>
> Then, depend solely on 1) is not enough.
> We must need one explicit information to signal 2).
>
> There are so many experts within LSR state that your solution is not
> appropriate,  will bring much chaos into the network, you still insist your
> approach. Is this productive?
>
> The final solution should be definitely in “Standard Track”, but not your
> approach.
> The explicit signaling is the right direction.
>
> Even the experts in LSR are confusing on your multiplex usage of
> “LSInfinity”, how to deploy it in the large scale network?
>
> Please don’t let the operator struggle to explain such vague usages to its
> Network OPS, Network Planning team.
>
> Aijun Wang
> China Telecom
>
>
> I wasn't clear on that in the first mail but Bruno clarified
>
> that this would still be inside a high-metric prefix reachability TLV.
>
> The only difference is that there is a flag/sub-TLV inside that triggers
>
> UPA behavior.  However, prefixes with > 0xfe00 metric *without*
>
> the UPA indicator MUST be ignored as they were before and MUST NOT
>
> trigger UPA/PIC.
>
>
> for me flagging something that is unreachable with a unreachable flag is
> redundant. But I let the WG to decide. That would obviously push the draft
> to standard track trajectory.
>
> Peter
>
>
> Cheers,
>
> -David
>
>
> ___
> 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Peter:

Actually, the “unreachable” meaning of LSInfinity in current standard is not 
the same as the “unreachable” meaning that we are supposed to act:
1) In current standard, the “unreachable” is meant that the related prefix will 
not be in the FIB.(you can read again and again 
https://www.rfc-editor.org/rfc/rfc2328.html#page-157)

2) What we aim to solve is that although the specific prefixes is not in the 
FIB, there is another summary address that cover it is in the FIB. Even in such 
situations, the specific prefixes is still unreachable.

Then, depend solely on 1) is not enough.
We must need one explicit information to signal 2).

There are so many experts within LSR state that your solution is not 
appropriate,  will bring much chaos into the network, you still insist your 
approach. Is this productive?

The final solution should be definitely in “Standard Track”, but not your 
approach.
The explicit signaling is the right direction.

Even the experts in LSR are confusing on your multiplex usage of “LSInfinity”, 
how to deploy it in the large scale network?

Please don’t let the operator struggle to explain such vague usages to its 
Network OPS, Network Planning team.

Aijun Wang
China Telecom
> 
>> I wasn't clear on that in the first mail but Bruno clarified
>> that this would still be inside a high-metric prefix reachability TLV.
>> The only difference is that there is a flag/sub-TLV inside that triggers
>> UPA behavior.  However, prefixes with > 0xfe00 metric *without*
>> the UPA indicator MUST be ignored as they were before and MUST NOT
>> trigger UPA/PIC.
> 
> for me flagging something that is unreachable with a unreachable flag is 
> redundant. But I let the WG to decide. That would obviously push the draft to 
> standard track trajectory.
> 
> Peter
> 
> 
>> Cheers,
>> -David
> 
> ___
> 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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 09/11/2022 16:32, David Lamparter wrote:

On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:

On 09/11/2022 15:48, David Lamparter wrote:

On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:

as far as that /128 is not used as BGP next-hop (which obviously is not
the case),


You keep saying things are "obvious"; they are not.  Why are you
assuming that my /128 is not in fact used as a BGP next-hop?

My /128 is a routing no-op right now.  The /64 is what gives the nexthop
reachability.  With your change, the /128 takes precedence as a more
specific unreachable.


well, if you have a service end-point that is advertised as /128 with
unreachable metric


metric > 0xfe00 is not "unreachable".  It's "no information".  You
have to continue in your SPF and use less specific prefixes if any are
available.  That's the entire point of this thread and/or the different
reading we have of 5305/5308.


if the "no information" results in unreachability, which is clear from 
the 5305/5308, we can use it to signal unreachability.


Anyway, we can keep arguing, but will hardly reach an agreement. The 
decision is on the WG.


What is important is that we will use the metric > 0xfe00 for 
signalling unreachability whether we add something on top of it or not.






and you expect your services to work, I would be very careful. We can
speculate whether that is something that is suppose to work or not,


As noted in an earlier mail, I'm not speaking speculatively.  Code
exists that does this.  The services work.  I have no information on how
common the pattern is, but I can positively affirm its existence.


well, I doubt such code has ever been deployed in production. And I can 
tell you it will likely break many implementations :)


Peter




[...]

If you introduce a new mechanism, routers not understanding the new
extension would still consider the prefix reachable.


... and routers not understanding the new extension will continue
blissfully ignoring the prefix, as they did before.  Why do you think
the prefix is suddenly considered reachable?  The prefix would still
have > 0xfe00 metric, is that the point of misunderstanding in this
thread?


you did not say that before, did you?


Bruno did, it's in a direct ancestor to this mail (parent to Acee's
mail); I assumed you had read it:

(I:)

I'd rather not do that and just add a sub-TLV for it.

(Bruno:)

I'm fine to use max_prefix as per RFC 5305 (prefix not considered during
SPF) as this allow for incremental deployment.
But in my opinion, advertising the unreachability semantic requires an
additional explicit signaling. (I'm proposing a prefix flag, but that seem
like a detail at this point)

(I:)

ACK


[...]

I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.


for me flagging something that is unreachable with a unreachable flag is
redundant. But I let the WG to decide. That would obviously push the
draft to standard track trajectory.


It would already need to be on standards track as it is, since it is
changing IS-IS behavior in an incompatible way.

Or, again, we need to errata 5305/5308.  The wording seems pretty clear
to me, but apparently the way I consider it to be clear in differs from
the way you consider it to be clear in.  That's the worst kind of
ambiguity, when the ambiguity itself is insidiously hidden... >
Sighing,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

On Wed, Nov 09, 2022 at 03:16:11PM +, Peter Psenak wrote:
> On 09/11/2022 15:48, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> >> as far as that /128 is not used as BGP next-hop (which obviously is not
> >> the case),
> > 
> > You keep saying things are "obvious"; they are not.  Why are you
> > assuming that my /128 is not in fact used as a BGP next-hop?
> > 
> > My /128 is a routing no-op right now.  The /64 is what gives the nexthop
> > reachability.  With your change, the /128 takes precedence as a more
> > specific unreachable.
> 
> well, if you have a service end-point that is advertised as /128 with 
> unreachable metric

metric > 0xfe00 is not "unreachable".  It's "no information".  You
have to continue in your SPF and use less specific prefixes if any are
available.  That's the entire point of this thread and/or the different
reading we have of 5305/5308.

> and you expect your services to work, I would be very careful. We can
> speculate whether that is something that is suppose to work or not,

As noted in an earlier mail, I'm not speaking speculatively.  Code
exists that does this.  The services work.  I have no information on how
common the pattern is, but I can positively affirm its existence.

[...]
> >> If you introduce a new mechanism, routers not understanding the new
> >> extension would still consider the prefix reachable.
> > 
> > ... and routers not understanding the new extension will continue
> > blissfully ignoring the prefix, as they did before.  Why do you think
> > the prefix is suddenly considered reachable?  The prefix would still
> > have > 0xfe00 metric, is that the point of misunderstanding in this
> > thread?  
> 
> you did not say that before, did you?

Bruno did, it's in a direct ancestor to this mail (parent to Acee's
mail); I assumed you had read it:

(I:)
> > > I'd rather not do that and just add a sub-TLV for it.
(Bruno:)
> > I'm fine to use max_prefix as per RFC 5305 (prefix not considered during
> > SPF) as this allow for incremental deployment.
> > But in my opinion, advertising the unreachability semantic requires an
> > additional explicit signaling. (I'm proposing a prefix flag, but that seem
> > like a detail at this point)
(I:)
> ACK

[...]
> > I wasn't clear on that in the first mail but Bruno clarified
> > that this would still be inside a high-metric prefix reachability TLV.
> > The only difference is that there is a flag/sub-TLV inside that triggers
> > UPA behavior.  However, prefixes with > 0xfe00 metric *without*
> > the UPA indicator MUST be ignored as they were before and MUST NOT
> > trigger UPA/PIC.
> 
> for me flagging something that is unreachable with a unreachable flag is 
> redundant. But I let the WG to decide. That would obviously push the 
> draft to standard track trajectory.

It would already need to be on standards track as it is, since it is
changing IS-IS behavior in an incompatible way.

Or, again, we need to errata 5305/5308.  The wording seems pretty clear
to me, but apparently the way I consider it to be clear in differs from
the way you consider it to be clear in.  That's the worst kind of
ambiguity, when the ambiguity itself is insidiously hidden...

Sighing,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 09/11/2022 15:48, David Lamparter wrote:

On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:

On 09/11/2022 15:26, David Lamparter wrote:

On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:

and why that would be a problem? Such prefix would never be used to for
resolution of the BGP prefix.


Says who?  If I have an external BGP nexthop on a shared network (e.g.
IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
an additional /128 in IS-IS with 0x metric in IS-IS carrying
ancillary data.


as far as that /128 is not used as BGP next-hop (which obviously is not
the case),


You keep saying things are "obvious"; they are not.  Why are you
assuming that my /128 is not in fact used as a BGP next-hop?

My /128 is a routing no-op right now.  The /64 is what gives the nexthop
reachability.  With your change, the /128 takes precedence as a more
specific unreachable.


well, if you have a service end-point that is advertised as /128 with 
unreachable metric and you expect your services to work, I would be very 
careful. We can speculate whether that is something that is suppose to 
work or not, IMHO it is hardly something that we need to worry about.





UPA for such /128 is harmless.



The 5305/5308 text is - for me, quite clearly - saying this 0x
prefix I just arbitrarily stuck in there has no effect on routing
operation at all.  Now it suddenly does.


what is the difference you see? I see none.


The difference is that I already have a /128 with 0x metric in
my IS-IS domain, which with your draft enabled is now processed to tell
BGP that the nexthop is unreachable.  It didn't do that before.



the question is whether that matters or not, please see above.




Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.


Please elaborate what that operational aspect is?


metric > 0xfe00 will not result in prefix reachability on any
existing router.


It results in nothing, yes ...


If you introduce a new mechanism, routers not understanding the new
extension would still consider the prefix reachable.


... and routers not understanding the new extension will continue
blissfully ignoring the prefix, as they did before.  Why do you think
the prefix is suddenly considered reachable?  The prefix would still
have > 0xfe00 metric, is that the point of misunderstanding in this
thread?  


you did not say that before, did you?


I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.


for me flagging something that is unreachable with a unreachable flag is 
redundant. But I let the WG to decide. That would obviously push the 
draft to standard track trajectory.


Peter




Cheers,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

On Wed, Nov 09, 2022 at 02:32:35PM +, Peter Psenak wrote:
> On 09/11/2022 15:26, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> >> and why that would be a problem? Such prefix would never be used to for
> >> resolution of the BGP prefix.
> > 
> > Says who?  If I have an external BGP nexthop on a shared network (e.g.
> > IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
> > an additional /128 in IS-IS with 0x metric in IS-IS carrying
> > ancillary data.
> 
> as far as that /128 is not used as BGP next-hop (which obviously is not 
> the case),

You keep saying things are "obvious"; they are not.  Why are you
assuming that my /128 is not in fact used as a BGP next-hop?

My /128 is a routing no-op right now.  The /64 is what gives the nexthop
reachability.  With your change, the /128 takes precedence as a more
specific unreachable.

> UPA for such /128 is harmless.
> 
> > 
> > The 5305/5308 text is - for me, quite clearly - saying this 0x
> > prefix I just arbitrarily stuck in there has no effect on routing
> > operation at all.  Now it suddenly does.
> 
> what is the difference you see? I see none.

The difference is that I already have a /128 with 0x metric in
my IS-IS domain, which with your draft enabled is now processed to tell
BGP that the nexthop is unreachable.  It didn't do that before.

> >>> Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> >>> (IMHO) not a significant cost, and completely eliminates this issue.
> >>> The only reason against it (that I can think of) is that the
> >>> advertisement might be a little bit larger;  a new sub-TLV or flag bit
> >>> should be completely invisible to existing implementations (= I don't
> >>> see how this would create compatibility or rollout problems.)
> >>
> >> I'm afraid, you forgot to consider an operational aspect of the solution.
> > 
> > Please elaborate what that operational aspect is?
> 
> metric > 0xfe00 will not result in prefix reachability on any
> existing router.

It results in nothing, yes ...

> If you introduce a new mechanism, routers not understanding the new
> extension would still consider the prefix reachable.

... and routers not understanding the new extension will continue
blissfully ignoring the prefix, as they did before.  Why do you think
the prefix is suddenly considered reachable?  The prefix would still
have > 0xfe00 metric, is that the point of misunderstanding in this
thread?  I wasn't clear on that in the first mail but Bruno clarified
that this would still be inside a high-metric prefix reachability TLV.
The only difference is that there is a flag/sub-TLV inside that triggers
UPA behavior.  However, prefixes with > 0xfe00 metric *without*
the UPA indicator MUST be ignored as they were before and MUST NOT
trigger UPA/PIC.

Cheers,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 09/11/2022 15:26, David Lamparter wrote:

On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:

On 09/11/2022 14:56, David Lamparter wrote:

On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric >
0xfe00 is unreachable. Implementations use the max-metric today to
signal the prefix unreachability - to avoid reaching
local/leaked/redistributed prefixes in cases where OL-bit is set on the
originator. So we are not doing anything new here really.


That is my interpretation and our implementation.  If we are discovering
ambiguity in this, we seriously need to errata-fix it, as noted in my
original mail.  (And I'll happily fix our implementation too.)


- you can create an IS-IS prefix reachability for some arbitrary prefix,
and stick > 0xfe00 into the metric, and that won't have any effect
on the existing IS-IS domain

[...]

- any setup doing that would now suddenly have fresh "unreachable"
semantics attached to something that didn't have them before, which
breaks things (or rather: prevents enabling/deployment of the UPA
feature)


and why that would be a problem? Such prefix would never be used to for
resolution of the BGP prefix.


Says who?  If I have an external BGP nexthop on a shared network (e.g.
IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
an additional /128 in IS-IS with 0x metric in IS-IS carrying
ancillary data.


as far as that /128 is not used as BGP next-hop (which obviously is not 
the case), UPA for such /128 is harmless.




The 5305/5308 text is - for me, quite clearly - saying this 0x
prefix I just arbitrarily stuck in there has no effect on routing
operation at all.  Now it suddenly does.


what is the difference you see? I see none.





Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.


Please elaborate what that operational aspect is?


metric > 0xfe00 will not result in prefix reachability on any 
existing router. If you introduce a new mechanism, routers not 
understanding the new extension would still consider the prefix reachable.


thanks,
Peter


Thanks,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

On Wed, Nov 09, 2022 at 02:13:17PM +, Peter Psenak wrote:
> On 09/11/2022 14:56, David Lamparter wrote:
> > On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> > The problem is that a prefix with metric > 0xfe00 isn't actually an
> > unreachable prefix, it's a prefix that doesn't have specific routing
> > information associated with it, which in turn allows sticking other data
> > into it that might be routing-related but not quite a reachability.
> 
> well, that is your interpretation. For me a prefix with metric > 
> 0xfe00 is unreachable. Implementations use the max-metric today to 
> signal the prefix unreachability - to avoid reaching 
> local/leaked/redistributed prefixes in cases where OL-bit is set on the 
> originator. So we are not doing anything new here really.

That is my interpretation and our implementation.  If we are discovering
ambiguity in this, we seriously need to errata-fix it, as noted in my
original mail.  (And I'll happily fix our implementation too.)

> > - you can create an IS-IS prefix reachability for some arbitrary prefix,
> >and stick > 0xfe00 into the metric, and that won't have any effect
> >on the existing IS-IS domain
[...]
> > - any setup doing that would now suddenly have fresh "unreachable"
> >semantics attached to something that didn't have them before, which
> >breaks things (or rather: prevents enabling/deployment of the UPA
> >feature)
> 
> and why that would be a problem? Such prefix would never be used to for 
> resolution of the BGP prefix.

Says who?  If I have an external BGP nexthop on a shared network (e.g.
IXP), my IS-IS may have a route for the IXP's IPv6 /64, and I may have
an additional /128 in IS-IS with 0x metric in IS-IS carrying
ancillary data.

The 5305/5308 text is - for me, quite clearly - saying this 0x
prefix I just arbitrarily stuck in there has no effect on routing
operation at all.  Now it suddenly does.

> > Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
> > (IMHO) not a significant cost, and completely eliminates this issue.
> > The only reason against it (that I can think of) is that the
> > advertisement might be a little bit larger;  a new sub-TLV or flag bit
> > should be completely invisible to existing implementations (= I don't
> > see how this would create compatibility or rollout problems.)
> 
> I'm afraid, you forgot to consider an operational aspect of the solution.

Please elaborate what that operational aspect is?

Thanks,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

On 09/11/2022 14:56, David Lamparter wrote:

On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:

I guess I'd like to understand what one would accomplish with further
specification of prefix reachable? What requirement would this
satisfy? For the use case UPA is designed to handle (triggering BGP
PIC or other local action) , I can't see that there would be any case
where you wouldn’t want to take this action for an unreachable prefix.


The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.


well, that is your interpretation. For me a prefix with metric > 
0xfe00 is unreachable. Implementations use the max-metric today to 
signal the prefix unreachability - to avoid reaching 
local/leaked/redistributed prefixes in cases where OL-bit is set on the 
originator. So we are not doing anything new here really.




I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.

To boil this down into the core of the essence and be explicit,

- you can create an IS-IS prefix reachability for some arbitrary prefix,
   and stick > 0xfe00 into the metric, and that won't have any effect
   on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
   for one reason or another were decided to be routing-related and thus
   make sense to put there
- the assumption for the use case is that there are indeed less specific
   covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
   semantics attached to something that didn't have them before, which
   breaks things (or rather: prevents enabling/deployment of the UPA
   feature)


and why that would be a problem? Such prefix would never be used to for 
resolution of the BGP prefix. So the presence of such unreachable prefix 
would never trigger any action even of the UPA processing was enabled on 
the receiver. I don't see a problem.



- (if those extra prefixes are created with 0x metric, a
   configurable >= limit for UPA does not help either.)


again, what is the problem?



Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)


I'm afraid, you forgot to consider an operational aspect of the solution.

thanks,
Peter



Cheers,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

Aijun,

On 09/11/2022 13:21, Aijun Wang wrote:

Hi, Peter:

I think you over explain the meaning of “LSInfinity”. I concur with David:


A less specific prefix may cover it


Then, you conclusion that:


when a prefix is "not considered during the normal Shortest Path First (SPF) 
computation", the result will be that the prefix will become unreachable. I guess we 
can agree on that


Is NOT correct.

“the result will be that the specific prefix isn’t existing within the FIB, but 
not unreachable——-because there may be one less specific prefix covers it.”


and what exactly is the point? You can have a default route in your 
domain. Are you saying that in such case every destination is reachable? 
Obviously not.




Then, let’s stick on the original statements about the meaning of “LSInfinity”, 
no more explanations, no more confusion then.


we are not changing that in any way.

Peter



Aijun Wang
China Telecom


On Nov 9, 2022, at 12:06, Peter Psenak  
wrote:

Hi David,


On 09/11/2022 11:44, David Lamparter wrote:
Hi Peter, hi all,
to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour.  Reading 5305/5308,
... "if a prefix is advertised with a metric larger
than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
considered during the normal Shortest Path First (SPF)
computation."
A prefix that is "not considered" is not an unreachable prefix.  It's a
prefix that is in the DB but ignored entirely, as if it wasn't there at
all.  A less specific prefix may cover it, and I would expect that to
work normally.


when a prefix is "not considered during the normal Shortest Path First (SPF) 
computation", the result will be that the prefix will become unreachable. I guess we 
can agree on that.

And I'm not sure what do you mean by "in the DB but ignored entirely". It will 
not be ignored, it will be maintained similarly in the DB as any other reachable prefix.


The UPA draft is changing this such that now some values may mean that
the prefix is in fact unreachable.  I'd rather not do that and just add
a sub-TLV for it.


We are not changing anything in terms of meaning of the prefix metric higher 
than 0xFE00 - and that is why this is backward compatible. If we would be 
changing the meaning of the metric it would not be.

Using a new Sub-TLV to signal unreachability makes the solution non backward 
compatible, and harder to deploy, for no good reason IMHO.

thanks,
Peter



(Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
the only one to read it that way and that's a pretty important
errata?!?)
Cheers,
-David


___
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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
> I guess I'd like to understand what one would accomplish with further
> specification of prefix reachable? What requirement would this
> satisfy? For the use case UPA is designed to handle (triggering BGP
> PIC or other local action) , I can't see that there would be any case
> where you wouldn’t want to take this action for an unreachable prefix.

The problem is that a prefix with metric > 0xfe00 isn't actually an
unreachable prefix, it's a prefix that doesn't have specific routing
information associated with it, which in turn allows sticking other data
into it that might be routing-related but not quite a reachability.

I vaguely remember several years back we did indeed implement something
(seriously no memory on details) that resulted in the creation of a new
prefix reachability TLV with some experimental/local sub-TLVs.  These
prefixes did not exist in the IS-IS domain beforehand.  I have no idea
what the operational reality is on the existence of such things, but I
know that /some/ code exists that does this.

To boil this down into the core of the essence and be explicit,

- you can create an IS-IS prefix reachability for some arbitrary prefix,
  and stick > 0xfe00 into the metric, and that won't have any effect
  on the existing IS-IS domain
- this has in fact been done to carry custom bits of information that
  for one reason or another were decided to be routing-related and thus
  make sense to put there
- the assumption for the use case is that there are indeed less specific
  covering prefixes around, providing actual reachability
- any setup doing that would now suddenly have fresh "unreachable"
  semantics attached to something that didn't have them before, which
  breaks things (or rather: prevents enabling/deployment of the UPA
  feature)
- (if those extra prefixes are created with 0x metric, a
  configurable >= limit for UPA does not help either.)

Making IS-IS UPA explicit with a bit, sub-TLV, or whatever else is
(IMHO) not a significant cost, and completely eliminates this issue.
The only reason against it (that I can think of) is that the
advertisement might be a little bit larger;  a new sub-TLV or flag bit
should be completely invisible to existing implementations (= I don't
see how this would create compatibility or rollout problems.)

Cheers,


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

One more information:

The explicit solution, 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
 does not require all the nodes be upgraded simultaneously.

Aijun Wang
China Telecom

> On Nov 9, 2022, at 12:06, Peter Psenak  
> Using a new Sub-TLV to signal unreachability makes the solution non backward 
> compatible, and harder to deploy, for no good reason IMHO.
> 
> thanks,
> Peter
> 
> 
>> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
>> the only one to read it that way and that's a pretty important
>> errata?!?)
>> Cheers,
>> -David
> 
> ___
> 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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Acee Lindem (acee)]

Speaking as WG Participant:

Hi Bruno, David, 

I guess I'd like to understand what one would accomplish with further 
specification of prefix reachable? What
 requirement would this satisfy? For the use case UPA is designed to handle 
(triggering BGP PIC or other local
action) , I can't see that there would be any case where you wouldn’t want to 
take this action for an unreachable
prefix. 

Thanks,
Acee

On 11/9/22, 10:56 AM, "Lsr on behalf of bruno.decra...@orange.com" 
 wrote:

> From: Lsr  On Behalf Of David Lamparter
> Sent: Wednesday, November 9, 2022 10:45 AM
> Hi Peter, hi all,
> 
> 
> to iterate on the comment I made on the mic a few minutes ago, I
> apparently have a rather different understanding of existing IS-IS
> behaviour.  Reading 5305/5308,
> 
> ... "if a prefix is advertised with a metric larger
   > than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
   > considered during the normal Shortest Path First (SPF)
   > computation."
> 
> A prefix that is "not considered" is not an unreachable prefix.  It's a
> prefix that is in the DB but ignored entirely, as if it wasn't there at
> all.  A less specific prefix may cover it, and I would expect that to
> work normally.

+1

> The UPA draft is changing this such that now some values may mean that
> the prefix is in fact unreachable. 

+1


> I'd rather not do that and just add
> a sub-TLV for it.

I'm fine to use max_prefix as per RFC 5305 (prefix not considered during 
SPF) as this allow for incremental deployment.
But in my opinion, advertising the unreachability semantic requires an 
additional explicit signaling. (I'm proposing a prefix flag, but that seem like 
a detail at this point)

Thanks,
--Bruno

> 
> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
> the only one to read it that way and that's a pretty important
> errata?!?)
> 
> Cheers,
> 
> 
> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

Orange Restricted


_

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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Peter:

I think you over explain the meaning of “LSInfinity”. I concur with David:

>> A less specific prefix may cover it

Then, you conclusion that:

> when a prefix is "not considered during the normal Shortest Path First (SPF) 
> computation", the result will be that the prefix will become unreachable. I 
> guess we can agree on that

Is NOT correct.

“the result will be that the specific prefix isn’t existing within the FIB, but 
not unreachable——-because there may be one less specific prefix covers it.”

Then, let’s stick on the original statements about the meaning of “LSInfinity”, 
no more explanations, no more confusion then.

Aijun Wang
China Telecom

> On Nov 9, 2022, at 12:06, Peter Psenak  
> wrote:
> 
> Hi David,
> 
>> On 09/11/2022 11:44, David Lamparter wrote:
>> Hi Peter, hi all,
>> to iterate on the comment I made on the mic a few minutes ago, I
>> apparently have a rather different understanding of existing IS-IS
>> behaviour.  Reading 5305/5308,
>> ... "if a prefix is advertised with a metric larger
>>than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
>>considered during the normal Shortest Path First (SPF)
>>computation."
>> A prefix that is "not considered" is not an unreachable prefix.  It's a
>> prefix that is in the DB but ignored entirely, as if it wasn't there at
>> all.  A less specific prefix may cover it, and I would expect that to
>> work normally.
> 
> when a prefix is "not considered during the normal Shortest Path First (SPF) 
> computation", the result will be that the prefix will become unreachable. I 
> guess we can agree on that.
> 
> And I'm not sure what do you mean by "in the DB but ignored entirely". It 
> will not be ignored, it will be maintained similarly in the DB as any other 
> reachable prefix.
> 
>> The UPA draft is changing this such that now some values may mean that
>> the prefix is in fact unreachable.  I'd rather not do that and just add
>> a sub-TLV for it.
> 
> We are not changing anything in terms of meaning of the prefix metric higher 
> than 0xFE00 - and that is why this is backward compatible. If we would be 
> changing the meaning of the metric it would not be.
> 
> Using a new Sub-TLV to signal unreachability makes the solution non backward 
> compatible, and harder to deploy, for no good reason IMHO.
> 
> thanks,
> Peter
> 
> 
>> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
>> the only one to read it that way and that's a pretty important
>> errata?!?)
>> Cheers,
>> -David
> 
> ___
> 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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Peter Psenak]

Hi David,

On 09/11/2022 11:44, David Lamparter wrote:

Hi Peter, hi all,


to iterate on the comment I made on the mic a few minutes ago, I
apparently have a rather different understanding of existing IS-IS
behaviour.  Reading 5305/5308,

... "if a prefix is advertised with a metric larger
than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
considered during the normal Shortest Path First (SPF)
computation."

A prefix that is "not considered" is not an unreachable prefix.  It's a
prefix that is in the DB but ignored entirely, as if it wasn't there at
all.  A less specific prefix may cover it, and I would expect that to
work normally.


when a prefix is "not considered during the normal Shortest Path First 
(SPF) computation", the result will be that the prefix will become 
unreachable. I guess we can agree on that.


And I'm not sure what do you mean by "in the DB but ignored entirely". 
It will not be ignored, it will be maintained similarly in the DB as any 
other reachable prefix.




The UPA draft is changing this such that now some values may mean that
the prefix is in fact unreachable.  I'd rather not do that and just add
a sub-TLV for it.


We are not changing anything in terms of meaning of the prefix metric 
higher than 0xFE00 - and that is why this is backward compatible. If 
we would be changing the meaning of the metric it would not be.


Using a new Sub-TLV to signal unreachability makes the solution non 
backward compatible, and harder to deploy, for no good reason IMHO.


thanks,
Peter




(Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
the only one to read it that way and that's a pretty important
errata?!?)

Cheers,


-David



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[David Lamparter]

On Wed, Nov 09, 2022 at 10:55:38AM +, bruno.decra...@orange.com wrote:
> > From: Lsr  On Behalf Of David Lamparter
> > I'd rather not do that and just add
> > a sub-TLV for it.
> 
> I'm fine to use max_prefix as per RFC 5305 (prefix not considered
> during SPF) as this allow for incremental deployment.
> But in my opinion, advertising the unreachability semantic requires an
> additional explicit signaling. (I'm proposing a prefix flag, but that
> seem like a detail at this point)

ACK

(I was a bit muddy writing "sub-TLV", really meant just some type of
added explicit signal inside the max_prefix reachability.)


-David

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[bruno.decraene]

> From: Lsr  On Behalf Of David Lamparter
> Sent: Wednesday, November 9, 2022 10:45 AM
> Hi Peter, hi all,
> 
> 
> to iterate on the comment I made on the mic a few minutes ago, I
> apparently have a rather different understanding of existing IS-IS
> behaviour.  Reading 5305/5308,
> 
> ... "if a prefix is advertised with a metric larger
   > than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
   > considered during the normal Shortest Path First (SPF)
   > computation."
> 
> A prefix that is "not considered" is not an unreachable prefix.  It's a
> prefix that is in the DB but ignored entirely, as if it wasn't there at
> all.  A less specific prefix may cover it, and I would expect that to
> work normally.

+1
 
> The UPA draft is changing this such that now some values may mean that
> the prefix is in fact unreachable. 

+1


> I'd rather not do that and just add
> a sub-TLV for it.

I'm fine to use max_prefix as per RFC 5305 (prefix not considered during SPF) 
as this allow for incremental deployment.
But in my opinion, advertising the unreachability semantic requires an 
additional explicit signaling. (I'm proposing a prefix flag, but that seem like 
a detail at this point)

Thanks,
--Bruno

> 
> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
> the only one to read it that way and that's a pretty important
> errata?!?)
> 
> Cheers,
> 
> 
> -David
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

Orange Restricted

_

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

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

[Peter Psenak]

Hi Bruno,

please see inline (##PP2):


On 16/06/2022 12:01, bruno.decra...@orange.com wrote:

Hi Peter,

Thanks for your reply. Please see inline [Bruno2]



Orange Restricted


-Original Message-
From: Peter Psenak 
Sent: Thursday, June 16, 2022 11:22 AM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
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, bruno.decra...@orange.com 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

(0xFE00, 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 b

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

[bruno.decraene]

Hi Peter,

Thanks for your reply. Please see inline [Bruno2]



Orange Restricted

> -Original Message-
> From: Peter Psenak  
> Sent: Thursday, June 16, 2022 11:22 AM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> 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, bruno.decra...@orange.com 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
 
> 
> >  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
> > 
> > (0xFE00, 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)
 
> 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. 
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)."

> 
> > 
> > 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 pr

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

[Robert Raszuk]

Bruno,

Actually I like your flag suggestion for an additional and different
reason.

If someone does not need to flood UPAs in any remote area it is trivial to
filter those on the ABRs connecting those areas to the core. Otherwise such
filtering could be more difficult if at all possible.

Thx,
R.


[Bruno] I agree that the encoding for the explicit signaling is totally
> open to discussion.
>
> I proposed a flag since:
>
> - all we need is a binary information
>
> - given the use case, this RFC7794 sub-tlv (type 4) seems likely to be
> already present. (e.g. X or R flag, possibly N-flag)
>
>
>
> Thanks for your email and your contribution to this topic.
>
> Best regards,
>
> --Bruno
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Bruno,

thanks for your feedback, please see inline (##PP):

On 15/06/2022 16:09, bruno.decra...@orange.com 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




 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

(0xFE00, 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.


I'm not sure where did you get the "remove reachability for IP2".




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.


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.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[bruno.decraene]

Daniel, inline



Orange Restricted
From: Voyer, Daniel 
Sent: Wednesday, June 15, 2022 9:43 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Bruno, inline

From: Bruno Decraene 
mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 12:27 PM
To: Dan Voyer mailto:daniel.vo...@bell.ca>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [EXT]RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Daniel,

I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as 
"a use case"/informational.

My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I'm allowed, today, to advertise a prefix with 
MAX_PATH_METRIC for a purposes other than building the normal IP routing table..
-a) As per RFC5305/RFC5308, my reading is that such advertisement does not 
change the reachability of this prefix. IOW it's reachable if there is an 
aggregate prefix.
-b) draft-ppsenak-lsr-igp-ureach-prefix-announce would change that and hence 
would change existing behavior in my network. i.e. the existing prefixes 
advertised with MAX_PATH_METRIC would become unreachable, breaking existing 
services.

[DV] but if MAX_PATH_METRIC gets triggered, it means an existing service got 
broken or else MAX_PATH_METRIC doesn't get triggered.

[Bruno] Agreed in the context of your draft. I disagree in the general case as 
RFC5305/08 allows the use if MAX_PATH_METRIC even if the PE is up and fully 
functional.

The trigger could that that a PE is going on maintenance or .. just crashed - 
nonetheless that PE vanished and with summarization other PEs from other area 
won't get notified resulting in "breaking" service if MAX_PATH_METRIC is not 
triggered - "in this proposal". We are just reusing an existing idea.

I don't see the big deal of defining a new flag for advertising this 
unreachability: the use case defined in 
draft-ppsenak-lsr-igp-ureach-prefix-announce requires a new implementation on 
all (ingress) PEs and ABRs. Given this, what's the cost having those new 
implementation also advertising a sub-TLV/flag?

[DV] it only requires support for RFC5305/RFC5308 - hence why I am asking 
what's missing in those 2 RFC ? Basically, if I ignore 
"draft-ppsenak-lsr-igp-ureach-prefix-announce" since it's only informational, 
and wanted to do these RFCs - what's missing ?


[Bruno] There is nothing wrong with RFC5305/08.
To make it clear: on the receiver side, 
draft-ppsenak-lsr-igp-ureach-prefix-announce is not backward compatible with 
all/existing usages of MAX_PATH_METRIC as defined/allowed by RFC5305. E.g. the 
one I described in my original email.
Please review my above text and in particular the two cases "a" and "b" 
highlighted in yellow: For the same IGP advertisement from the egress (ABR) the 
behavior are different and even opposite: reachability UP for "a)"/RFC5305; 
reachability DOWN for "b)"/ draft-ppsenak-lsr-igp-ureach-prefix-announce. If 
you disagree with this reasoning, please explain why.
If you, as a network operator, wants to implement this non interoperable 
behavior in your network IGP, you are free to do so.
If an implementation that is deployed in a network that I care, implements this 
non interoperable behavior by default, and hence deliberately decide to break 
the existing behavior, for sure I'll complain to this vendor. Especially since 
the solution could easily be fixed at no cost.

Thanks,
Cheers,
--Bruno


Orange Restricted
From: Voyer, Daniel mailto:daniel.vo...@bell.ca>>
Sent: Wednesday, June 15, 2022 6:06 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno,

Thanks for your comment on the draft. I too, have a minor disagreement on your 
disagreement.

The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as "a use 
case"/informational. In this case, a PE being hidden from other area due to 
route summarization. The draft is not meant to "invent" something new, hence 
the reference to RFC5305/RFC5308.

If you jump to RFC5308 (as we are looking at IPv6 here), the advertising 
mechanism is well describe. What's missing from RFC5308 from your view point ?

Thanks
Dan

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

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 b

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

[bruno.decraene]

Hi Aijun,



Orange Restricted
From: Aijun Wang 
Sent: Thursday, June 16, 2022 1:59 AM
To: DECRAENE Bruno INNOV/NET 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi, Bruno:

I agree with your thoughts on the solutions to this questions.

Actually, this is the reason that we brought up the thread “Convergence of 
Prefixes Unreachable Announcement Proposal” and I think you can review the 
discussion of this thread again.

And, in the mail 
https://mailarchive.ietf.org/arch/msg/lsr/qZ87Kjc9RdSsNpXzpOu31g1dSR0/, we have 
the following statements:
“ Anyway, to make the UPA mechanism take effect, you will also require the 
router be upgraded. And the “Max-Value” solution doesn’t necessarily indicate 
the prefix is lost. We should announce such information explicitly.”


[Bruno] Yes we seem to be in agreement on this point.

Whether defining a new flag or use the prefix originator information(as adopt 
by  
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4)
  to indicate explicitly the prefix is unreachable can be further discussed.

[Bruno] I agree that the encoding for the explicit signaling is totally open to 
discussion.
I proposed a flag since:
- all we need is a binary information
- given the use case, this RFC7794 sub-tlv (type 4) seems likely to be already 
present. (e.g. X or R flag, possibly N-flag)

Thanks for your email and your contribution to this topic.
Best regards,
--Bruno

Aijun Wang
China Telecom


On Jun 15, 2022, at 22:09, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 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.

2)  IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, 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.
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.

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.
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr

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

[Aijun Wang]

Hi, Bruno:

I agree with your thoughts on the solutions to this questions.

Actually, this is the reason that we brought up the thread “Convergence of 
Prefixes Unreachable Announcement Proposal” and I think you can review the 
discussion of this thread again.

And, in the mail 
https://mailarchive.ietf.org/arch/msg/lsr/qZ87Kjc9RdSsNpXzpOu31g1dSR0/, we have 
the following statements:
“ Anyway, to make the UPA mechanism take effect, you will also require the 
router be upgraded. And the “Max-Value” solution doesn’t necessarily indicate 
the prefix is lost. We should announce such information explicitly.”

Whether defining a new flag or use the prefix originator information(as adopt 
by  
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4)
  to indicate explicitly the prefix is unreachable can be further discussed.

Aijun Wang
China Telecom

> On Jun 15, 2022, at 22:09, bruno.decra...@orange.com 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.
>  
> 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.
> IMO, the behavior defined in this draft is not backward compatible with the 
> specification of MAX_PATH_METRIC in an IP prefix.
>  
> RFC5305 says:
>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>(0xFE00, 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.
> 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.
>  
> 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.
> ___
> 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

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

[Voyer, Daniel]

Bruno, inline

From: Bruno Decraene 
Date: Wednesday, June 15, 2022 at 12:27 PM
To: Dan Voyer , "lsr@ietf.org" 
Subject: [EXT]RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Daniel,

I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as 
“a use case”/informational.

My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I’m allowed, today, to advertise a prefix with 
MAX_PATH_METRIC for a purposes other than building the normal IP routing table..
- As per RFC5305/RFC5308, my reading is that such advertisement does not change 
the reachability of this prefix. IOW it’s reachable if there is an aggregate 
prefix.
- draft-ppsenak-lsr-igp-ureach-prefix-announce would change that and hence 
would change existing behavior in my network. i.e. the existing prefixes 
advertised with MAX_PATH_METRIC would become unreachable, breaking existing 
services.

[DV] but if MAX_PATH_METRIC gets triggered, it means an existing service got 
broken or else MAX_PATH_METRIC doesn’t get triggered. The trigger could that 
that a PE is going on maintenance or .. just crashed – nonetheless that PE 
vanished and with summarization other PEs from other area won’t get notified 
resulting in “breaking” service if MAX_PATH_METRIC is not triggered – “in this 
proposal”. We are just reusing an existing idea.

I don’t see the big deal of defining a new flag for advertising this 
unreachability: the use case defined in 
draft-ppsenak-lsr-igp-ureach-prefix-announce requires a new implementation on 
all (ingress) PEs and ABRs. Given this, what’s the cost having those new 
implementation also advertising a sub-TLV/flag?

[DV] it only requires support for RFC5305/RFC5308 – hence why I am asking 
what’s missing in those 2 RFC ? Basically, if I ignore 
“draft-ppsenak-lsr-igp-ureach-prefix-announce” since it’s only informational, 
and wanted to do these RFCs – what’s missing ?

Thanks,
Cheers,
--Bruno


Orange Restricted
From: Voyer, Daniel 
Sent: Wednesday, June 15, 2022 6:06 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno,

Thanks for your comment on the draft. I too, have a minor disagreement on your 
disagreement.

The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as “a use 
case”/informational. In this case, a PE being hidden from other area due to 
route summarization. The draft is not meant to “invent” something new, hence 
the reference to RFC5305/RFC5308.

If you jump to RFC5308 (as we are looking at IPv6 here), the advertising 
mechanism is well describe. What’s missing from RFC5308 from your view point ?

Thanks
Dan

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

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.

2)IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, 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.
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 t

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

[bruno.decraene]

Hi Daniel,

I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as 
"a use case"/informational.

My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I'm allowed, today, to advertise a prefix with 
MAX_PATH_METRIC for a purposes other than building the normal IP routing table..
- As per RFC5305/RFC5308, my reading is that such advertisement does not change 
the reachability of this prefix. IOW it's reachable if there is an aggregate 
prefix.
- draft-ppsenak-lsr-igp-ureach-prefix-announce would change that and hence 
would change existing behavior in my network. i.e. the existing prefixes 
advertised with MAX_PATH_METRIC would become unreachable, breaking existing 
services.

I don't see the big deal of defining a new flag for advertising this 
unreachability: the use case defined in 
draft-ppsenak-lsr-igp-ureach-prefix-announce requires a new implementation on 
all (ingress) PEs and ABRs. Given this, what's the cost having those new 
implementation also advertising a sub-TLV/flag?

Thanks,
Cheers,
--Bruno


Orange Restricted
From: Voyer, Daniel 
Sent: Wednesday, June 15, 2022 6:06 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno,

Thanks for your comment on the draft. I too, have a minor disagreement on your 
disagreement.

The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as "a use 
case"/informational. In this case, a PE being hidden from other area due to 
route summarization. The draft is not meant to "invent" something new, hence 
the reference to RFC5305/RFC5308.

If you jump to RFC5308 (as we are looking at IPv6 here), the advertising 
mechanism is well describe. What's missing from RFC5308 from your view point ?

Thanks
Dan

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

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.

2)IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, 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.
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.

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 me

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

[Voyer, Daniel]

Hi Bruno,

Thanks for your comment on the draft. I too, have a minor disagreement on your 
disagreement.

The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as “a use 
case”/informational. In this case, a PE being hidden from other area due to 
route summarization. The draft is not meant to “invent” something new, hence 
the reference to RFC5305/RFC5308.

If you jump to RFC5308 (as we are looking at IPv6 here), the advertising 
mechanism is well describe. What’s missing from RFC5308 from your view point ?

Thanks
Dan

From: Lsr  on behalf of Bruno Decraene 

Date: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org" 
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

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.
  2.  IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, 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.
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.

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