Subject: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

From: "Aijun Wang" <[email-masked]>
Date: Mon, 27 Jul 2020 09:32:49 +0800

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?

Wish to hear comments and suggestions on the above issues. We will also have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu <[email-masked]>; Aijun Wang <[email-masked]>; Yaqun Xiao <[email-masked]>
Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF repository.

Name:		draft-wang-lsr-prefix-unreachable-annoucement
Revision:	03
Title:		Prefix Unreachable Announcement
Document date:	2020-07-27
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Status:         https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:       https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03

Abstract:
   This document describes the mechanism that can be used to announce
   the unreachable prefixes for service fast convergence.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 27 Jul 2020 17:51:02 +0000

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong question - it is analogous to asking whether to use a car or truck to drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex and unnecessary mechanisms, it would be better to address the requirement in your network design. Note that the unreachability of a given summarized prefix is only relevant if it is reachable through another ABR. In this case, the network design should provide adequate intra-area redundancy to provide communications between the ABRs. If this cannot be accomplished, an intra-area adjacency should be established over a tunnel between the ABRs in the backbone. Contrary to section 6.1, Looping is normally not a problem as ABRs should add back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" <[email-masked] on behalf of [email-masked]> wrote:

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom 

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] 
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <[email-masked]>; Aijun Wang <[email-masked]>; Yaqun Xiao <[email-masked]>
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    The IETF Secretariat

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 28 Jul 2020 09:56:26 +0800

Hi, Acee:

Let me try to answer your concerns.

Please see the below inline.

If I missed your comments, please correct me.

Best Regards

Aijun Wang

China Telecom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang <[email-masked]>; [email-masked]
Cc: 'Zhibo Hu' <[email-masked]>; 'Yaqun Xiao' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Asking the WG precisely how to advertise prefix unreachability is the wrong question - it is analogous to asking whether to use a car or truck to drive off the edge of a cliff.

[WAJ] Let’s confirm it is not cliff J, but traffic black hole that should be notified and repaired. 

Rather than messing up OSPF and IS-IS with these complex and unnecessary mechanisms, it would be better to address the requirement in your network design.

[WAJ] section 3 of this draft <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>  has demonstrated the problem/scenarios that needs to be addressed. We think this will be normal phenomena in the IPv6 era. 

Note that the unreachability of a given summarized prefix is only relevant if it is reachable through another ABR. 

[WAJ] it is not the unreachability of a given summarized prefix, but the more specific prefix that within the summary address.

In this case, the network design should provide adequate intra-area redundancy to provide communications between the ABRs. 

[WAJ] Even there is adequate intra-area redundancy communication between the ABRs, the failure of one specific prefix within the summary address that advertised by the ABR will lead to traffic black hole.

If this cannot be accomplished, an intra-area adjacency should be established over a tunnel between the ABRs in the backbone. 

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to another ABR, when such ABR router can reach the specified prefix.  But this additional mechanism will be used only when the ABR all reach the PUA limit. If not, the PUA mechanism described in section 4 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-4>  can be used to guide the traffic. 

Contrary to section 6.1, Looping is normally not a problem as ABRs should add back hole routes for their advertised summaries. 

[WAJ] Yes, you are right. Normally the ABR will drop the traffic that it can’t reach.  But there is situation that when the tunnel that is pre-established among ABRs, and each tunnel claim it can reach the specified prefix, the traffic loop may arise if the received ABR send traffic via another tunnel.  

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" < <mailto:[email-masked][email-masked]> [email-masked] on behalf of [email-masked]> wrote:

    Hi, LSR experts:

    Best Regards

    Aijun Wang

    China Telecom 

    -----Original Message-----

    From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]] 

    To: Zhibo Hu < <mailto:[email-masked]> [email-masked]>; Aijun Wang < <mailto:[email-masked]> [email-masked]>; Yaqun Xiao < <mailto:[email-masked]> [email-masked]>

 

    Revision: 03

    Pages:              11

    URL:             <https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt> https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Status:          <https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/

    Htmlized:        <https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03

    Htmlized:        <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement

    Diff:            <https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03

    Abstract:

 

    The IETF Secretariat

    Lsr mailing list

     <mailto:[email-masked]> [email-masked]

     <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

Lsr mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

---

From: Huzhibo <[email-masked]>
Date: Tue, 28 Jul 2020 02:03:04 +0000

Hi Acee:

In fact, we have meet some scenarios where redundant paths cannot be deployed within a area. Especially when the access area uses the nearby access principle, ABRs form disordered combinations, which makes it difficult to deploy physical or tunnel connections. In addition, advertising unreachable prefixes can prevent traffic detours. Of course, This draft also has some other attempts to use Segment Routing to automatically establish connections between ABRs.

Thanks

Zhibo Hu

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang <[email-masked]>; [email-masked]
Cc: Huzhibo <[email-masked]>; Xiaoyaqun <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Acee

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom 

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] 
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <[email-masked]>; Aijun Wang <[email-masked]>; Yaqun Xiao <[email-masked]>
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Jul 2020 11:17:32 +0200

Hello Acee,

I would like to question your assessment that signalling unreachable routes
is unnecessary.

Imagine hierarchical network with areas. Under no failures area 1
advertises to area 0 summary LSA with 1.1.1.0/24. That block covers PE's
loopbacks which within the area are /32s. Those loopbacks are also BGP next
hops.

Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP reconverges all paths
advertised by this PE with 1.1.1.1/32 are still valid as this next hop is
still reachable entire network wide. That means that traffic is being sent
to this failed PE1 for relatively long period of time.

It seems natural that without breaking benefits of summarization across
areas or domains in the above scenario we could continue to advertise
1.1.1.0/24 - 1.1.1.1/32. That is when I see most benefits of advertising
unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives -
you will see a proposal where the above mechanism can be done within BGP
itself with no touch to the IGP - just using a bit of twisted next hop
validation steps and BGP native recursion. I am not going to make any
judgements here which method is better or easier - naturally I personally
like BGP one more :).

But I hope this is clear why at least discussion on the subject is
important. It also illustrates why the below statement is not
necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant
if it is reachable through another ABR. "

Kind regards,
Robert.

On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Asking the WG precisely how to advertise prefix unreachability is the
> wrong question - it is analogous to asking whether to use a car or truck to
> drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with
> these complex and unnecessary mechanisms, it would be better to address the
> requirement in your network design. Note that the unreachability of a given
> summarized prefix is only relevant if it is reachable through another ABR.
> In this case, the network design should provide adequate intra-area
> redundancy to provide communications between the ABRs. If this cannot be
> accomplished, an intra-area adjacency should be established over a tunnel
> between the ABRs in the backbone. Contrary to section 6.1, Looping is
> normally not a problem as ABRs should add back hole routes for their
> advertised summaries.
>
> Acee
>
> On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" <[email-masked]
> on behalf of [email-masked]> wrote:
>
>     Hi, LSR experts:
>
>     We have uploaded the new version of this PUA(Prefix Unreachable
> Announcement) draft. The main updates are the followings:
>     1) Describes the solution that using tunnel to redirect traffic among
> ABRs, when all ABRs reaches the PUA limit.
>     Wish to hear comments and suggestions on the above issues. We will
> also have the presentation on the coming IETF LSR meeting.
>
>     Best Regards
>
>     Aijun Wang
>     China Telecom
>
>     Subject: New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>     A new version of I-D,
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>     URL:
> https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>     Status:
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
>     Htmlized:
> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
>     Htmlized:
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
>     Diff:
> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03
>
>     Abstract:
>     Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
>     The IETF Secretariat
>
>
>

---

From: <[email-masked]>
Date: Tue, 28 Jul 2020 09:51:28 +0000

Another data point about advertising more detailed reachability/unreachability: https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) <acee=[email-masked]>
Cc: Aijun Wang <[email-masked]>; Zhibo Hu <[email-masked]>; Yaqun Xiao <[email-masked]>; [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to area 0 summary LSA with 1.1.1.0/24<http://1.1.1.0/24>. That block covers PE's loopbacks which within the area are /32s. Those loopbacks are also BGP next hops.

Now imagine PE1 with 1.1.1.1/32<http://1.1.1.1/32> fails. Well till BGP reconverges all paths advertised by this PE with 1.1.1.1/32<http://1.1.1.1/32> are still valid as this next hop is still reachable entire network wide. That means that traffic is being sent to this failed PE1 for relatively long period of time.

It seems natural that without breaking benefits of summarization across areas or domains in the above scenario we could continue to advertise 1.1.1.0/24<http://1.1.1.0/24> - 1.1.1.1/32<http://1.1.1.1/32>. That is when I see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you will see a proposal where the above mechanism can be done within BGP itself with no touch to the IGP - just using a bit of twisted next hop validation steps and BGP native recursion. I am not going to make any judgements here which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if it is reachable through another ABR. "

Kind regards,
Robert.

On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
Speaking as an LSR Working Group member:

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom

    -----Original Message-----
    From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Yaqun Xiao <[email-masked]<mailto:[email-masked]>>
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf..org<http://tools.ietf.org>.

    The IETF Secretariat

    _______________________________________________
    Lsr mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

_________________________________________________________________________________________________________________________

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Jul 2020 13:21:55 +0000

Hi Aijun,

You did misunderstand me so let me be brief.

  1.  By summarized prefix, I mean an unreachable prefix subsumed by the summary advertisement. I thought this would be clear from the context of your draft. So my point is that signaling unreachability from one ABR is only useful if the subsumed prefix is reachable though another ABR.
  2.  What I’m suggesting is provide connectivity between the ABRs. For example, you use the tunneling defining in section 6.1 whenever a subsumed prefix is unreachable. Please don’t come back with another circular argument.
Thanks,
Acee

From: Aijun Wang <[email-masked]>
Date: Monday, July 27, 2020 at 9:57 PM
To: Acee Lindem <[email-masked]>, 'Aijun Wang' <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 'Zhibo Hu' <[email-masked]>, 'Yaqun Xiao' <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi, Acee:

Best Regards

Aijun Wang

China Telecom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang <[email-masked]>; [email-masked]
Cc: 'Zhibo Hu' <[email-masked]>; 'Yaqun Xiao' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[WAJ] Let’s confirm it is not cliff ☺, but traffic black hole that should be notified and repaired.

[WAJ] section 3 of this draft<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3> has demonstrated the problem/scenarios that needs to be addressed. We think this will be normal phenomena in the IPv6 era.

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to another ABR, when such ABR router can reach the specified prefix.  But this additional mechanism will be used only when the ABR all reach the PUA limit. If not, the PUA mechanism described in section 4<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-4> can be used to guide the traffic.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

    Hi, LSR experts:

    Best Regards

    Aijun Wang

    China Telecom

    -----Original Message-----

    From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

    Revision: 03

    Pages:              11

    Abstract:

    The IETF Secretariat

    Lsr mailing list

Lsr mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Jul 2020 13:23:55 +0000

See my response to Aijun... Please provide topologies where the section 6.1 solution doesn't work. 
Acee

On 7/27/20, 10:03 PM, "Huzhibo" <[email-masked]> wrote:

    Hi Acee:

    Thanks

    Zhibo Hu

    -----Original Message-----
    From: Acee Lindem (acee) [mailto:[email-masked]] 
    Sent: Tuesday, July 28, 2020 1:51 AM
    To: Aijun Wang <[email-masked]>; [email-masked]
    Cc: Huzhibo <[email-masked]>; Xiaoyaqun <[email-masked]>
    Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Acee

        Hi, LSR experts:

        Best Regards

        Aijun Wang
        China Telecom 

        -----Original Message-----
        From: [email-masked] [mailto:[email-masked]] 
        Sent: Monday, July 27, 2020 9:16 AM
        To: Zhibo Hu <[email-masked]>; Aijun Wang <[email-masked]>; Yaqun Xiao <[email-masked]>
        Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

        Abstract:

        The IETF Secretariat

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Jul 2020 13:27:55 +0000

An interesting encoding – note that the draft doesn’t use it for forwarding.
Acee

From: Bruno Decraene <[email-masked]>
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk <[email-masked]>, Acee Lindem <[email-masked]>
Cc: Aijun Wang <[email-masked]>, Zhibo Hu <[email-masked]>, Yaqun Xiao <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

--Bruno

Hello Acee,

Kind regards,
Robert.

Acee

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom

    -----Original Message-----
    From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Yaqun Xiao <[email-masked]<mailto:[email-masked]>>
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    The IETF Secretariat

Thank you.

---

From: <[email-masked]>
Date: Tue, 28 Jul 2020 14:17:55 +0000

An interesting encoding – note that the draft doesn’t use it for forwarding.
[Bruno] Agreed that the distinction between routing and reachability information is a key point.
--Bruno
Acee

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>, Zhibo Hu <[email-masked]<mailto:[email-masked]>>, Yaqun Xiao <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>; Zhibo Hu <[email-masked]<mailto:[email-masked]>>; Yaqun Xiao <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

Kind regards,
Robert.

Acee

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom

    -----Original Message-----
    From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Yaqun Xiao <[email-masked]<mailto:[email-masked]>>
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    The IETF Secretariat

Thank you.

---

From: Huzhibo <[email-masked]>
Date: Wed, 29 Jul 2020 08:01:26 +0000

Hi Acee:

    In the scenario mentioned by Robert, the section 6.1 solution doesn't work. When BGP needs to detect the reachability of the next hop to trigger BGP convergence.

Thanks
Zhibo Hu

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2020 9:24 PM
To: Huzhibo <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]
Cc: Xiaoyaqun <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Hi Acee:

    Thanks

    Zhibo Hu

    -----Original Message-----
    From: Acee Lindem (acee) [mailto:[email-masked]] 
    Sent: Tuesday, July 28, 2020 1:51 AM
    To: Aijun Wang <[email-masked]>; [email-masked]
    Cc: Huzhibo <[email-masked]>; Xiaoyaqun <[email-masked]>
    Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Acee

        Hi, LSR experts:

        Best Regards

        Aijun Wang
        China Telecom 

        -----Original Message-----
        From: [email-masked] [mailto:[email-masked]] 
        Sent: Monday, July 27, 2020 9:16 AM
        To: Zhibo Hu <[email-masked]>; Aijun Wang <[email-masked]>; Yaqun Xiao <[email-masked]>
        Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

        Abstract:

        The IETF Secretariat

---

From: Huzhibo <[email-masked]>
Date: Wed, 29 Jul 2020 08:07:33 +0000

Hi Robert:

    BGP next hop validation can solve some but not all problems. In your example, if PE1 has learned only 1.1.1.0/24 but not 1.1.1.1/32, BGP cannot detect the reachability of 1.1.1.1/32.

Thanks

Zhibo Hu
From: Robert Raszuk [mailto:[email-masked]]
Sent: Tuesday, July 28, 2020 5:18 PM
To: Acee Lindem (acee) <acee=[email-masked]>
Cc: Aijun Wang <[email-masked]>; [email-masked]; Huzhibo <[email-masked]>; Xiaoyaqun <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

Kind regards,
Robert.

Acee

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom

    -----Original Message-----
    From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Yaqun Xiao <[email-masked]<mailto:[email-masked]>>
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

    The IETF Secretariat

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 29 Jul 2020 16:54:19 +0800

Hi, Acee:

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2020 9:22 PM
To: Aijun Wang <[email-masked]>; 'Aijun Wang' <[email-masked]>; [email-masked]
Cc: 'Zhibo Hu' <[email-masked]>; 'Yaqun Xiao' <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun, 

[WAJ] Signaling unreachability is also useful when the specified prefix isn’t reachable through all of ABRs.

[WAJ] Zhibo has answered this in another mail.  Tunnel solution can’t solve BGP route convergence scenario.

Thanks,
Acee

From: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Monday, July 27, 2020 at 9:57 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, 'Aijun Wang' <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: 'Zhibo Hu' <[email-masked] <mailto:[email-masked]> >, 'Yaqun Xiao' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi, Acee:

Best Regards

Aijun Wang

China Telecom

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: 'Zhibo Hu' <[email-masked] <mailto:[email-masked]> >; 'Yaqun Xiao' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Acee

    Hi, LSR experts:

    Best Regards

    Aijun Wang

    China Telecom 

    -----Original Message-----

 

    Revision: 03

    Pages:              11

    Abstract:

 

    The IETF Secretariat

    Lsr mailing list

Lsr mailing list

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 29 Jul 2020 17:09:17 +0800

Interesting but complex/not efficient solution.  How to solve the problem in IPv6 network?

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2020 10:18 PM
To: Acee Lindem (acee) <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Zhibo Hu <[email-masked]>; Yaqun Xiao <[email-masked]>; [email-masked]
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

--Bruno

Acee

From: Bruno Decraene <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >, Acee Lindem <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >, Zhibo Hu <[email-masked] <mailto:[email-masked]> >, Yaqun Xiao <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) <acee=[email-masked] <mailto:acee=[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >; Zhibo Hu <[email-masked] <mailto:[email-masked]> >; Yaqun Xiao <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

Imagine hierarchical network with areas. Under no failures area 1 advertises to area 0 summary LSA with  <http://1.1.1.0/24> 1.1.1.0/24. That block covers PE's loopbacks which within the area are /32s. Those loopbacks are also BGP next hops. 

Now imagine PE1 with  <http://1.1.1.1/32> 1.1.1.1/32 fails. Well till BGP reconverges all paths advertised by this PE with  <http://1.1.1.1/32> 1.1.1.1/32 are still valid as this next hop is still reachable entire network wide. That means that traffic is being sent to this failed PE1 for relatively long period of time. 

It seems natural that without breaking benefits of summarization across areas or domains in the above scenario we could continue to advertise  <http://1.1.1.0/24> 1.1.1.0/24 -  <http://1.1.1.1/32> 1.1.1.1/32. That is when I see most benefits of advertising unreachability aka negative routing. 

Kind regards,
Robert.

On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) <acee= <mailto:[email-masked]> [email-masked]> wrote:

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" < <mailto:[email-masked]> [email-masked] on behalf of  <mailto:[email-masked]> [email-masked]> wrote:

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom 

    -----Original Message-----
    From:  <mailto:[email-masked]> [email-masked] [mailto: <mailto:[email-masked]> [email-masked]] 
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu < <mailto:[email-masked]> [email-masked]>; Aijun Wang < <mailto:[email-masked]> [email-masked]>; Yaqun Xiao < <mailto:[email-masked]> [email-masked]>
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at  <http://tools.ietf.org> tools.ietf..org.

    The IETF Secretariat

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 29 Jul 2020 17:12:26 +0800

Hi, Robert:

Agree with you J

Best Regards

Aijun Wang

China Telecom

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2020 5:18 PM
To: Acee Lindem (acee) <acee=[email-masked]>
Cc: Aijun Wang <[email-masked]>; [email-masked]; Zhibo Hu <[email-masked]>; Yaqun Xiao <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

Imagine hierarchical network with areas. Under no failures area 1 advertises to area 0 summary LSA with 1.1.1.0/24 <http://1.1.1.0/24> . That block covers PE's loopbacks which within the area are /32s. Those loopbacks are also BGP next hops. 

Now imagine PE1 with 1.1.1.1/32 <http://1.1.1.1/32>  fails. Well till BGP reconverges all paths advertised by this PE with 1.1.1.1/32 <http://1.1.1.1/32>  are still valid as this next hop is still reachable entire network wide. That means that traffic is being sent to this failed PE1 for relatively long period of time. 

It seems natural that without breaking benefits of summarization across areas or domains in the above scenario we could continue to advertise 1.1.1.0/24 <http://1.1.1.0/24>  - 1.1.1.1/32 <http://1.1.1.1/32> . That is when I see most benefits of advertising unreachability aka negative routing. 

Kind regards,
Robert.

On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) <acee=[email-masked] <mailto:[email-masked]> > wrote:

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" <[email-masked] <mailto:[email-masked]>  on behalf of [email-masked] <mailto:[email-masked]> > wrote:

    Hi, LSR experts:

    Best Regards

    Aijun Wang
    China Telecom 

    -----Original Message-----
    From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] 
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Yaqun Xiao <[email-masked] <mailto:[email-masked]> >
    Subject: New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Abstract:

    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .

    The IETF Secretariat

    _______________________________________________
    Lsr mailing list
    [email-masked] <mailto:[email-masked]> 
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 29 Jul 2020 11:13:34 +0200

Not sure I follow your below comment or how it relates to my
deployment scenario ... I specifically said that 1.1.1.1/32 will be a
negative route (there is "-" minus there) advertised in BGP.

If you mean that reception of negative routes in the presence of summary
requires changes to RIB route tracking (or local RIB twist) it sure does.

Thx,
R.

On Wed, Jul 29, 2020 at 10:07 AM Huzhibo <[email-masked]> wrote:

> Hi Robert:
>
>
>
>     BGP next hop validation can solve some but not all problems. In your
> example, if PE1 has learned only 1.1.1.0/24 but not 1.1.1.1/32, BGP
> cannot detect the reachability of 1.1.1.1/32.
>
>
>
> Thanks
>
>
>
> Zhibo Hu
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Tuesday, July 28, 2020 5:18 PM
> *To:* Acee Lindem (acee) <acee=[email-masked]>
> *Cc:* Aijun Wang <[email-masked]>; [email-masked]; Huzhibo <
> [email-masked]>; Xiaoyaqun <[email-masked]>
> *Subject:* Re: [Lsr] New Version Notification for
> Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP reconverges all
> paths advertised by this PE with 1.1.1.1/32 are still valid as this next
> hop is still reachable entire network wide. That means that traffic is
> being sent to this failed PE1 for relatively long period of time.
>
>
>
> "Note that the unreachability of a given summarized prefix is only
> relevant if it is reachable through another ABR. "
>
>
>
> Kind regards,
> Robert.
>
>
>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 11:20:50 +0200

Hi Ajun,

one additional problem on top of others that have been mentioned is how 
are you going to get rid of "old" un-reachability announcements/

Let's imagine you have the following prefixes in your area 1:

- 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses
- 10.10.1.0/30 - 10.10.10.252/32 - used for transit links

For simplicity your summary for area 1 is 10.0.0.0/16

1. Everything is up, you generate 10.0.0.0/16 on the ABR that connects 
to area 1 to all remaining connected areas

2. A router in area 1 with loopback 10.10.0.25/32 goes down.

3. ABR in area 1 generates un-reachable announcement for 10.0.0.25/32 to 
all other connected areas

4. When does ABR stop generating the un-reachable announcement for 
10.0.0.25/32? In section 6 you mention that "The receiver router should 
keep the black hole routes for PUA as one configurable time(MAX_T_PUA)", 
but the draft does not say anything about when the un-reachability 
announcements should be removed by ABR. We can not rely on 10.10.0.25/32 
ever coming back, as the user may have simply removed it for good. 
Keeping the "stale" un-reachability announcements may result in the LSDB 
growth over the period of time.

thanks,
Peter

---

From: Aijun Wang <[email-masked]>
Date: Thu, 30 Jul 2020 19:44:26 +0800

Hi, Peter:
Currently, we have the following consideration:
1. If not all of the ABRs announce the unreachability of the specified prefix(the specified prefix is still up), such PUA information will continue advertising by the unreachable ABRs.
2. If all of the ABRs announce the PUA of the specified prefix, such information will be announced for a configurable duration, to make sure other protocol(for example BGP) that based on the specified prefix has converged.
How about the above consideration and 
Do you have other thoughts ?

Aijun Wang
China Telecom

> On Jul 30, 2020, at 17:21, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Ajun,
> 
> one additional problem on top of others that have been mentioned is how are you going to get rid of "old" un-reachability announcements/
> 
> 1. Everything is up, you generate 10.0.0.0/16 on the ABR that connects to area 1 to all remaining connected areas
> 
> 3. ABR in area 1 generates un-reachable announcement for 10.0.0.25/32 to all other connected areas
> 
> 4. When does ABR stop generating the un-reachable announcement for 10.0.0.25/32? In section 6 you mention that "The receiver router should keep the black hole routes for PUA as one configurable time(MAX_T_PUA)", but the draft does not say anything about when the un-reachability announcements should be removed by ABR. We can not rely on 10.10.0.25/32 ever coming back, as the user may have simply removed it for good. Keeping the "stale" un-reachability announcements may result in the LSDB growth over the period of time.
> 
> 
> thanks,
> Peter
> 
> 
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 14:00:10 +0200

Hi Aijun,

> 1. If not all of the ABRs announce the unreachability of the specified prefix(the specified prefix is still up), such PUA information will continue advertising by the unreachable ABRs.

so the behavior of ABR is going to be dependent on the behavior of the 
the other ABR(s)? That is a very thin ice you are dancing on.

> 2. If all of the ABRs announce the PUA of the specified prefix, such information will be announced for a configurable duration, to make sure other protocol(for example BGP) that based on the specif…

well, the problem is that no mater what is your configured time to 
advertise the un-reachability, you have no way of knowing whether the 
resource that became unreachable have done so intentionally and whether 
it will ever come back. And guessing based on the timer is not going to 
make it much better I'm afraid.

thanks,
Peter

---

From: Aijun Wang <[email-masked]>
Date: Thu, 30 Jul 2020 20:28:37 +0800

Hi, Peter:

Aijun Wang
China Telecom

> On Jul 30, 2020, at 20:00, Peter Psenak <[email-masked]> wrote:
> 
> Hi Aijun,
> 
> so the behavior of ABR is going to be dependent on the behavior of the the other ABR(s)? That is a very thin ice you are dancing on.

[WAJ] it is easy for ABR to get these information and make the judgment. All ABRs locate within the same area.

> well, the problem is that no mater what is your configured time to advertise the un-reachability, you have no way of knowing whether the resource that became unreachable have done so intentionally and whether it will ever come back. And guessing based on the timer is not going to make it much better I'm afraid.
> 

[WAJ] We need not care bout the reason for the unreachability. When ABR get the PUA information from also all other ABRs, it will start one timer to count the duration of following PUA message. After the duration, all ABRs will stop the advertisement.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 14:41:50 +0200

Aijun,

> [WAJ] it is easy for ABR to get these information and make the judgment. All ABRs locate within the same area.

having that info is not the issue. The cyclic dependency is the one.

> [WAJ] We need not care bout the reason for the unreachability. When ABR get the PUA information from also all other ABRs, it will start one timer to count the duration of following PUA message. Aft…

once you stop advertising the un-reachability, you are back to square 
one as you were with the summary only.

thanks,
peter

---

From: Huzhibo <[email-masked]>
Date: Thu, 30 Jul 2020 12:49:38 +0000

Hi peter：

> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior of an ABR is not affected by the transient status of other ABRs. The condition for canceling PUA advertisement is that all ABRs advertise the PUA information with a certain prefix for 30 minutes.
> 
>>

once you stop advertising the un-reachability, you are back to square one as you were with the summary only.
> [HZB] There are two scenarios: First: The node is actually Down. In this case, upper-layer services will be converged 30 minutes earlier. Even if the PUA is canceled, the problem will not occur. Second: If the node is not Down and only an ABR is unreachable, the ABR will continuously advertises PUA.

thanks,
peter

> 
> 
>> thanks,
>> Peter
>>
>>
>>> How about the above consideration and Do you have other thoughts ?
>>> Aijun Wang
>>> China Telecom
>>>> one additional problem on top of others that have been mentioned is 
>>>> how are you going to get rid of "old" un-reachability 
>>>> announcements/
>>>>
>>>> 1. Everything is up, you generate 10.0.0.0/16 on the ABR that 
>>>> connects to area 1 to all remaining connected areas
>>>>
>>>> 3. ABR in area 1 generates un-reachable announcement for 
>>>> 10.0.0.25/32 to all other connected areas
>>>>
>>>>> To: Zhibo Hu <[email-masked]>; Aijun Wang 
>>>>> <[email-masked]>; Yaqun Xiao <[email-masked]>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 15:02:24 +0200

Huzhibo,

>> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior of an ABR is not affected by the transient status of other ABRs. The condition for canceling PUA advertisement is that al…

you have not convinced me with the above statement. You are making a 
dependency on the ABR behavior based on the other ABRs' behavior. That's 
a call for a trouble.

>> [HZB] There are two scenarios: First: The node is actually Down. In this case, upper-layer services will be converged 30 minutes earlier. 

once you stop the unreachable advertisement, the resource will be seen 
as reachable outside of its area, even when it is down. That is a 
problem that you are trying to solve in a first place.

thanks,
Peter

Even if the PUA is canceled, the problem will not occur. Second: If the 
node is not Down and only an ABR is unreachable, the ABR will 
continuously advertises PUA.

---

From: Huzhibo <[email-masked]>
Date: Thu, 30 Jul 2020 13:18:49 +0000

HI Peter：

1：No problem is a problem that never can be proved.

2：For bgp example，when the pe node down，the bgp peer must down within 30 mintus，It will not get it up via cancle advertise pua.

ZHIBO

--------------------------------------------------
胡志波 Hu Zhibo
Mobile: +86-18618192287<tel:+86-18618192287>
Email: [email-masked]<mailto:[email-masked]>

发件人：Peter Psenak <[email-masked]>
收件人：Huzhibo <[email-masked]>;Aijun Wang <[email-masked]>
抄 送：Aijun Wang <[email-masked]>;lsr <[email-masked]>;Xiaoyaqun <[email-masked]>
时 间：2020-07-30 21:02:49
主 题：Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Huzhibo,

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 15:32:22 +0200

Hi Zhibo,

On 30/07/2020 15:18, Huzhibo wrote:
> 2：For bgp example，when the pe node down，the bgp peer must down within 
> 30 mintus，It will not get it up via cancle advertise pua.

for the above it is sufficient to advertise the unreachability for few 
seconds from each ABR independently. That would be a much more solid 
proposal.

thanks,
Peter

> Mobile: +86-18618192287 <tel:+86-18618192287>
> Email: [email-masked] <mailto:[email-masked]>
> 
> *发件人：*Peter Psenak <[email-masked]>
> *收件人：*Huzhibo <[email-masked]>;Aijun Wang <[email-masked]>
> *抄 送：*Aijun Wang <[email-masked]>;lsr 
> <[email-masked]>;Xiaoyaqun <[email-masked]>
> *时 间：*2020-07-30 21:02:49
> *主 题：*Re: [Lsr] New Version Notification for

---

From: Huzhibo <[email-masked]>
Date: Thu, 30 Jul 2020 13:38:21 +0000

HI Peter：

sure，we will cansider all the possible better solution.thanks for your suggestion.

zhibo

时 间：2020-07-30 21:32:45

Hi Zhibo,

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Jul 2020 16:14:16 +0200

> seconds from each ABR independently. That would be a much more solid

Not sure about "few seconds" ... IBGP def hold time in number of
implementations is 180 sec :) .. but few minutes will work for sure.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 16:21:12 +0200

> implementations is 180 sec :) .. but few minutes will work for sure.

depends how you use it.

If you can use the unreachable info in a smart way, it's sufficient if 
it is present for a very short time interval.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Jul 2020 16:30:27 +0200

Hey Peter,

Not sure how smart you really want to be here but keep in mind that BGP say
option C may never hear about it all the way to the egress PE in other
domain or area ... It is almost always incongruent with IGP.

So if the BGP path is installed it will indeed be at risk to resolve via
less specific when it is still active BGP path and you too quickly remove
info about unreachability.

Thx
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 16:34:06 +0200

On 30/07/2020 16:30, Robert Raszuk wrote:
> Hey Peter,
> 
> Not sure how smart you really want to be here but keep in mind that BGP 
> say option C may never hear about it all the way to the egress PE in 
> other domain or area ... It is almost always incongruent with IGP.
> 
> less specific when it is still active BGP path and you too quickly 
> remove info about unreachability.

again, if you are smart you can use this info to your advantage, even 
without putting it in the forwarding and leaving the less specific stuff 
intact.

Peter

> 
> Thx
> R.
> 
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >      > 2：For bgp example，when the pe node down，the bgp peer
>     must down
>      >     within
>      >      > 30 mintus，It will not get it up via cancle advertise pua.
>      >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2020 16:03:35 +0000

So, how do we define a reachable route - is it any route subsumed by the summary LSA that we knew about in the past that becomes unreachable? When the PUA is withdrawn, how do we know whether it is because of expiration of the interval or the route becoming reachable again? This is a slippery slope. 
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Peter

    >      >      > 2：For bgp example，when the pe node down，the bgp peer
    >     must down
    >      >     within

---

From: Huzhibo <[email-masked]>
Date: Thu, 30 Jul 2020 16:08:33 +0000

HI acee：

PUA does not advertise reachable or unreachable details, it advertise events with prefix from up to down.

thanks

Zhibo

发件人：Acee Lindem (acee) <[email-masked]>
收件人：Peter Psenak <ppsenak=[email-masked]>;Robert Raszuk <[email-masked]>
抄 送：Aijun Wang <[email-masked]>;Xiaoyaqun <[email-masked]>;Huzhibo <[email-masked]>;Aijun Wang <[email-masked]>;lsr <[email-masked]>
时 间：2020-07-31 00:04:02
主 题：Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

    Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jul 2020 18:17:46 +0200

> So, how do we define a reachable route - is it any route subsumed by the summary LSA that we knew about in the past that becomes unreachable? When the PUA is withdrawn, how do we know whether it is…

I'm not suggesting the unreachable stuff to affect forwarding in any way.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Jul 2020 18:17:48 +0200

Hi,

Imagine I have two ABRs connecting area 1 to area 0. One is signalling
transition to down for subset of summary and the other does not .. maybe it
is slow ... maybe it does not support this new feature.

So all routers in the area 0 are receiving a full summary from one ABR and
a summary with hole from the other one. Should that be logical AND or OR ?

Then on the other side there is area 2. Should the transition to down be
leaked ? If so in a nicely stable network we may see instead of few /20
summaries jump to 1M transitions to down yet summary continues - would that
not have a bit negative effect on the entire network ? Where would ABR
remove summary itself - when all atomic routes subsumed by the summary
transition to down ?

- - -

I am supportive of the idea to signal unreachable network elements. But I
am not sure if we should do it in IGP and BGP or only in BGP.

Thx,
R.

On Thu, Jul 30, 2020 at 6:08 PM Huzhibo <[email-masked]> wrote:

> Mobile: +86-18618192287
> Email: [email-masked]
> *发件人：*Acee Lindem (acee) <[email-masked]>
> *收件人：*Peter Psenak <ppsenak=[email-masked]>;Robert Raszuk <
> [email-masked]>
> *抄 送：*Aijun Wang <[email-masked]>;Xiaoyaqun <[email-masked]>;Huzhibo
> <[email-masked]>;Aijun Wang <[email-masked]>;lsr <
> [email-masked]>
> *时 间：*2020-07-31 00:04:02
> So, how do we define a reachable route - is it any route subsumed by the
> summary LSA that we knew about in the past that becomes unreachable? When
> the PUA is withdrawn, how do we know whether it is because of expiration of
> the interval or the route becoming reachable again? This is a slippery
> slope.
> Thanks,
> Acee
>
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" <
> [email-masked] on behalf of ppsenak=[email-masked]>
> wrote:
>
>     > <mailto:[email-masked] <[email-masked]>>> wrote:
>     >

---

From: Huzhibo <[email-masked]>
Date: Thu, 30 Jul 2020 16:33:27 +0000

hi：

if abr1 advertise pua but abr2 not，other node will think the prefix is reachable via abr2. and will not advertise pua to other area.

I am not idea how bgp can work？keepalive expire？bfd？maybe bfd can work.local policy verification？some usecase maybe yes.

发件人：Robert Raszuk <[email-masked]>
收件人：Huzhibo <[email-masked]>
抄 送：Acee Lindem (acee) <[email-masked]>;Peter Psenak <ppsenak=[email-masked]>;Aijun Wang <[email-masked]>;Xiaoyaqun <[email-masked]>;Aijun Wang <[email-masked]>;lsr <[email-masked]>
时 间：2020-07-31 00:18:27
主 题：Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi,

Imagine I have two ABRs connecting area 1 to area 0. One is signalling transition to down for subset of summary and the other does not .. maybe it is slow ... maybe it does not support this new feature.

So all routers in the area 0 are receiving a full summary from one ABR and a summary with hole from the other one. Should that be logical AND or OR ?

Then on the other side there is area 2. Should the transition to down be leaked ? If so in a nicely stable network we may see instead of few /20 summaries jump to 1M transitions to down yet summary continues - would that not have a bit negative effect on the entire network ? Where would ABR remove summary itself - when all atomic routes subsumed by the summary transition to down ?

- - -

I am supportive of the idea to signal unreachable network elements. But I am not sure if we should do it in IGP and BGP or only in BGP.

Thx,
R.

On Thu, Jul 30, 2020 at 6:08 PM Huzhibo <[email-masked]<mailto:[email-masked]>> wrote:

HI acee：

thanks

Zhibo

发件人：Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
收件人：Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>>;Robert Raszuk <[email-masked]<mailto:[email-masked]>>
抄 送：Aijun Wang <[email-masked]<mailto:[email-masked]>>;Xiaoyaqun <[email-masked]<mailto:[email-masked]>>;Huzhibo <[email-masked]<mailto:[email-masked]>>;Aijun Wang <[email-masked]<mailto:[email-masked]>>;lsr <[email-masked]<mailto:[email-masked]>>
时 间：2020-07-31 00:04:02
主 题：Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" <[email-masked]<mailto:[email-masked]> on behalf of ppsenak=[email-masked]<mailto:[email-masked]>> wrote:

    Peter

    >
    > Thx
    > R.
    >
    > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak <[email-masked]<mailto:[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2020 16:24:38 +0000

Hi Zhibo,

From: Lsr <[email-masked]> on behalf of Huzhibo <[email-masked]>
Date: Thursday, July 30, 2020 at 12:14 PM
To: Acee Lindem <[email-masked]>, Peter Psenak <ppsenak=[email-masked]>, Robert Raszuk <[email-masked]>
Cc: lsr <[email-masked]>, Aijun Wang <[email-masked]>, Xiaoyaqun <[email-masked]>, Aijun Wang <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

HI acee：

I don’t see the distinction here and it is not described in the latest version of the draft (posted Monday). You must be envisioning some protocol behavior that is yet to be documented.

Thanks,
Acee

thanks

Zhibo

    Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2020 17:30:04 +0000

On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

That would be better. Also, as I stated offline, it would also be better to use encodings that would be ignored by routers that don't support the extension. I tried to dissuade the authors of PUA not to overload the prefix-originator LSA but was unsuccessful. 

Thanks,
Acee

    thanks,
    Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2020 17:45:12 +0000

On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" <[email-masked] on behalf of acee=[email-masked]> wrote:

Of course, I meant prefix-originator Sub-TLV and the existing LSAs indicating reachability - https://www.ietf.org/id/draft-ietf-lsr-ospf-prefix-originator-06.txt

Thanks,
Acee

    Thanks,
    Acee

        thanks,
        Peter

---

From: Aijun Wang <[email-masked]>
Date: Fri, 31 Jul 2020 08:16:39 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 00:23, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi,
> 

[WAJ] It should be OR. All routers in the area 0 should prefer to the ABR that not advertising PUA to forward traffic.
> 
> Then on the other side there is area 2. Should the transition to down be leaked ?

[WAJ] The PUA should be leaked.

> If so in a nicely stable network we may see instead of few /20 summaries jump to 1M transitions to down yet summary continues - would that not have a bit negative effect on the entire network ? Where would ABR remove summary itself - when all atomic routes subsumed by the summary transition to down ? 

[WAJ] https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-6 has described the extreme conditions for advertising PUA+Summary, Detail Reachable Prefixes only, or Summary Address with Max metric.
Is there any other graceful advertising in these conditions? 

> I am supportive of the idea to signal unreachable network elements. But I am not sure if we should do it in IGP and BGP or only in BGP. 

[WAJ] Such information is for underlay link state and should be flooded via IGP? The ambiguity arises from IGP summary behavior and should be solved by itself?

---

From: Aijun Wang <[email-masked]>
Date: Fri, 31 Jul 2020 08:37:18 +0800

Hi, Acee:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 01:45, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 

[WAJ] The ultimate aim of PUA is to notify the router to bypass the advertising ABR. If not affecting the forwarding, how to avoid the traffic black hole?

>    That would be better. Also, as I stated offline, it would also be better to use encodings that would be ignored by routers that don't support the extension. I tried to dissuade the authors of PU…
[WAJ] We can discuss this later.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 Jul 2020 12:20:36 +0200

>
> [WAJ] Such information is for underlay link state and should be flooded
> via IGP? The ambiguity arises from IGP summary behavior and should be
> solved by itself?
>

Well if we look at this problem from a distance while on surface it seems
like an IGP issue (not to mention some which use BGP as IGP :) IMO it is
only hurting when you have some service overlay on top utilizing the IGP.

So typically today if I am running any service with BGP I do count on BGP
to remove routes which are no longer reachable. IGP just tells me how to
get to the next hop, which direction to go and not if the endpoint (service
CPE or PE connected to given CE) is up or down.

So today smart BGP implementations in good network design can use RD based
withdraws to very fast (milliseconds) remove the affected service routes.
When I said should we do it in BGP I meant to ask WG if this is good enough
to quickly remove service routes. If not maybe we should send such affected
next hop in BGP to even faster invalidate all routes with such next hop as
failing PE.

Bottom line if you think the problem is IGP then I think Acee's comments
apply.

Last - See today you are bringing the case to signal transition to DOWN ...
but for some people and applications it may be not enough. In fact UP/DOWN
they can get via BGP. But if you have two ABRs and one will due to topology
changes in its area suddenly will be forced to reach atomic destination
covered by summary over much higher metric path that for applications
running above may be much more severe case and not acceptable one too.

And BGP will not remove service routes nor modify best path in any way as
summary is masking the real metric to some next hops. So while in the
network you may have alternate better native transit paths with a lot of
free capacity if you only switch to a different bgp next hop (not talking
about any TE at all) you are stuck offering much worse service to your
customers.

Those cases are starting to be solved by performance routing both at the
service itself or at BGP nh levels. Should IGP assist here ... I am not
sure.

Many thx,
R.