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

2020-07-30 Thread Aijun Wang
Hi, Acee:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 01:45, Acee Lindem (acee)  wrote:
> 
> 
> On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" 
>  wrote:
> 
> 
> 
>On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" 
>  wrote:
> 
>>On 30/07/2020 18:03, Acee Lindem (acee) wrote:
>> 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.
> 
>I'm not suggesting the unreachable stuff to affect forwarding in any 
> way.

[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 PUA not to overload the 
> prefix-originator LSA but was unsuccessful. 
> 
[WAJ] We can discuss this later.

> 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
> 
> 
>> Thanks,
>> Acee
>> 
>> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" > on behalf of ppsenak=40cisco@dmarc.ietf.org> wrote:
>> 
>> 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.
>>> 
>>> 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.
>> 
>> 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.

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


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

2020-07-30 Thread Aijun Wang
Hi, Robert:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 00:23, Robert Raszuk  wrote:
> 
> 
> 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 ? 

[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?
> 
> Thx,
> R.
> 
> 
>> On Thu, Jul 30, 2020 at 6:08 PM Huzhibo  wrote:
>> HI acee:
>> 
>> PUA does not advertise reachable or unreachable details, it advertise events 
>> with prefix from up to down.
>> 
>> 
>> 
>> thanks
>> 
>> Zhibo
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> 胡志波 Hu Zhibo
>> Mobile: +86-18618192287
>> Email: huzh...@huawei.com
>> 
>> 发件人:Acee Lindem (acee) 
>> 收件人:Peter Psenak ;Robert Raszuk 
>> 
>> 抄 送:Aijun Wang ;Xiaoyaqun 
>> ;Huzhibo ;Aijun Wang 
>> ;lsr 
>> 时 间:2020-07-31 00:04:02
>> 主 题:Re: [Lsr] New Version Notification for 
>> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>> 
>> 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" > on behalf of ppsenak=40cisco@dmarc.ietf.org> wrote:
>> 
>> 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.
>> > 
>> > 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.
>> 
>> 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 > > > wrote:
>> > 
>> > On 30/07/2020 16:14, Robert Raszuk 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.
>> >  >
>> >  >
>> >  > Not sure about "few seconds" ... IBGP def hold time in number of
>> >  > 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
>> > 
>> >  >
>> >  > Thx,
>> >  > R.
>> >  >
>> > 
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
___
Lsr mailing list
Lsr@ietf.org

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

2020-07-30 Thread Acee Lindem (acee)

On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" 
 wrote:



On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak"  wrote:

On 30/07/2020 18:03, Acee Lindem (acee) wrote:
> 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.

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

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. 

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


> Thanks,
> Acee
> 
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" 
 wrote:
> 
>  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.
>  >
>  > 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.
> 
>  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   > > wrote:
>  >
>  > On 30/07/2020 16:14, Robert Raszuk 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.
>  >  >
>  >  >
>  >  > Not sure about "few seconds" ... IBGP def hold time in 
number of
>  >  > 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
>  >
>  >  >
>  >  > Thx,
>  >  > R.
>  >  >
>  >
> 
>  ___
>  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

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-07-30 Thread Les Ginsberg (ginsberg)
Bruno -

Regarding the A-flag...
It may not matter much whichever way we decide - but the A-flag was invented 
because at the time (prior to RFC 7794) there was no way to determine from 
looking at a prefix reachability advertisement whether it was originated by the 
advertising node or had been leaked from another area.
If RFC 7794 had existed when the SR-MPLS draft was first being developed there 
would have been no need for the A-flag.

As regards Area-SID, there is no prefix to be leaked - so I do not see that the 
A-flag serves any useful purpose.
If you want it to be set just to be consistent with its use in PSP logic - OK - 
but I think this is unnecessary.

   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:46 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

  A new flag is defined:

 T-flag: The SID directs traffic to an area.  (Bit 5)

 When T-flag is set:

M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside 
edge routers. Based on this, I would argue that the  A flag could and SHOULD be 
set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the 
A bit in order to signal that the prefixes and SIDs advertised in the SID/Label 
Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) 
[RFC8667], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as 
redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and 
https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the 
behaviour for respectively Prefix-SID propagation and P and E flags handling, 
so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a 
reachability advertisement originated by another IS-IS speaker, the router MUST 
set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV 
RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per 
https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best 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] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread tony . li

Hi Bruno,

Thank you for your comments.


> On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com wrote:
> 
> Hi Tony,
>  
> Thanks for the updated draft.
>  
> “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
>represents the entirety of the Inside Area to the Outside Area.  This
>sub-TLV is learned by all of the Inside Edge Nodes who should consume
>this SID at forwarding time.”
>  
> Excellent, from my perspective.
>  
> Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.
>  
> “When SR is enabled, it may be useful to advertise an Area SID which
>will direct traffic to any of the Inside Edge Routers.  The Binding/
>MT Binding TLVs described in RFC 8667 Section 2.4 
>  are used to
>advertise such a SID.
>  
>The following extensions to the Binding TLV are defined in order to
>support Area SID:
>  
>   A new flag is defined:
>  
>  T-flag: The SID directs traffic to an area.  (Bit 5) »
>  
>  
> This works.


Excellent.


> However I may have a different deployment environment than the one you have 
> in mind. Even if those issues may be mine, allow me to share them with you.
> In many WAN networks than I’m used to, there are routers from different 
> vendors, platforms, software, generations. Requiring all those routers to 
> support the new Binding SID TLV T-Flag will take time. Some platform may even 
> be end of engineering (evolutions) so would never support such new features.
> In my environment, ideally, I would prefer a solution which do not require 
> any new feature on external L2 nodes, while all existing L2 features keep 
> working, in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would 
> require the Proxy LSP to be not (significantly) different than the LSP of a 
> vanilla L2 node.


First off, the Area SID is 100% optional. If you choose not to use it, then the 
Proxy LSP should be 100% compatible with a standard L2 node. 

I cannot claim that we’ve exhaustively tested our implementation against all of 
the features that you cite, so there may still be corner cases, but our intent 
is to make that doable.  For exaple, the Proxy LSP can still contain a node 
SID, adjacency SID, and prefix SID as before. There’s no change there.


> For SR, I think that this would require this Proxy LSP to advertise a 
> Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID 
> is advertised with an IP address that would need to be provisioned.


That’s certainly doable and requires no new protocol machinery. If the WG 
prefers this mode of operation, I’m not opposed.

 
> Both approaches are not mutually exclusives. I’d be happy enough with an 
> option for the Proxy LSP to advertise an Area Node SID with the Area SID 
> attached.
>  
> Finally, there is no requirement to make me happy ;-) . The above could also 
> be a local implementation knob not mentioned in the draft.


Our goal is to make as many customers as happy as possible.  ;-)

Tony

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


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

2020-07-30 Thread Acee Lindem (acee)


On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak"  wrote:

On 30/07/2020 18:03, Acee Lindem (acee) wrote:
> 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.

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

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


> Thanks,
> Acee
> 
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" 
 wrote:
> 
>  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.
>  >
>  > 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.
> 
>  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   > > wrote:
>  >
>  > On 30/07/2020 16:14, Robert Raszuk 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.
>  >  >
>  >  >
>  >  > Not sure about "few seconds" ... IBGP def hold time in 
number of
>  >  > 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
>  >
>  >  >
>  >  > Thx,
>  >  > R.
>  >  >
>  >
> 
>  ___
>  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] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread Les Ginsberg (ginsberg)
Bruno –

One of the reasons to use the Binding TLV to advertise the Area SID was that it 
has been suggested that other use cases for Area SID – unrelated to Area Proxy 
– may come along.
Therefore tying the advertisement to an Area Proxy TLV seems not the best 
option if we want to allow for these other use cases (admittedly currently 
unknown).

Thoughts??

   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:22 AM
To: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.


  *   - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name: draft-ietf-lsr-isis-area-proxy
Revision: 02
Title:Area Proxy for IS-IS
Document date:  2020-07-25
Group: lsr
Pages:  20
URL:
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02

Abstract:
  Link state routing protocols have hierarchical abstraction 

[Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-07-30 Thread bruno.decraene
Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

  A new flag is defined:

 T-flag: The SID directs traffic to an area.  (Bit 5)

 When T-flag is set:

M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside 
edge routers. Based on this, I would argue that the  A flag could and SHOULD be 
set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the 
A bit in order to signal that the prefixes and SIDs advertised in the SID/Label 
Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) 
[RFC8667], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as 
redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and 
https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the 
behaviour for respectively Prefix-SID propagation and P and E flags handling, 
so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a 
reachability advertisement originated by another IS-IS speaker, the router MUST 
set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV 
RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per 
https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best 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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Acee Lindem (acee)
Hi Zhibo,

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


HI acee:

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

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







--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com
发件人:Acee Lindem (acee) 
收件人:Peter Psenak ;Robert Raszuk 

抄 送:Aijun Wang ;Xiaoyaqun 
;Huzhibo ;Aijun Wang 
;lsr 
时 间:2020-07-31 00:04:02
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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"  wrote:

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

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  > wrote:
>
> On 30/07/2020 16:14, Robert Raszuk 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.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > 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
>
>  >
>  > Thx,
>  > R.
>  >
>

___
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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Huzhibo
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.


--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人:Robert Raszuk 
收件人:Huzhibo 
抄 送:Acee Lindem (acee) ;Peter Psenak 
;Aijun Wang 
;Xiaoyaqun ;Aijun Wang 
;lsr 
时 间: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 
mailto:huzh...@huawei.com>> wrote:

HI acee:

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


thanks

Zhibo




--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人:Acee Lindem (acee) mailto:a...@cisco.com>>
收件人:Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>;Robert 
Raszuk mailto:rob...@raszuk.net>>
抄 送:Aijun Wang 
mailto:wang...@chinatelecom.cn>>;Xiaoyaqun 
mailto:xiaoya...@huawei.com>>;Huzhibo 
mailto:huzh...@huawei.com>>;Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>;lsr 
mailto:lsr@ietf.org>>
时 间:2020-07-31 00:04:02
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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" 
mailto:lsr-boun...@ietf.org> on behalf of 
ppsenak=40cisco@dmarc.ietf.org> wrote:

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

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 
mailto:ppse...@cisco.com>
> > wrote:
>
> On 30/07/2020 16:14, Robert Raszuk 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.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > 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
>
>  >
>  > Thx,
>  > R.
>  >
>

___
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] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread bruno.decraene
Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.


Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name:   draft-ietf-lsr-isis-area-proxy
Revision:   02
Title: Area Proxy for IS-IS
Document date:2020-07-25
Group:  lsr
Pages:   20
URL:
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.




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.


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

2020-07-30 Thread Robert Raszuk
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  wrote:

> HI acee:
>
> PUA does not advertise reachable or unreachable details, it advertise
> events with prefix from up to down.
>
>
> thanks
>
> Zhibo
>
>
>
>
> --
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287
> Email: huzh...@huawei.com
> *发件人:*Acee Lindem (acee) 
> *收件人:*Peter Psenak ;Robert Raszuk <
> rob...@raszuk.net>
> *抄 送:*Aijun Wang ;Xiaoyaqun 
> ;Huzhibo
> ;Aijun Wang ;lsr <
> lsr@ietf.org>
> *时 间:*2020-07-31 00:04:02
> *主 题:*Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
> 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" <
> lsr-boun...@ietf.org on behalf of ppsenak=40cisco@dmarc.ietf.org>
> wrote:
>
> 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.
> >
> > 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.
>
> 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  > > wrote:
> >
> > On 30/07/2020 16:14, Robert Raszuk 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.
> >  >
> >  >
> >  > Not sure about "few seconds" ... IBGP def hold time in number
> of
> >  > 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
> >
> >  >
> >  > Thx,
> >  > R.
> >  >
> >
>
> ___
> 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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Peter Psenak

On 30/07/2020 18:03, Acee Lindem (acee) wrote:

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.


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

thanks,
Peter



Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  wrote:

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

 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  > wrote:
 >
 > On 30/07/2020 16:14, Robert Raszuk 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.
 >  >
 >  >
 >  > Not sure about "few seconds" ... IBGP def hold time in number of
 >  > 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
 >
 >  >
 >  > Thx,
 >  > R.
 >  >
 >

 ___
 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] Gather town hallway chats.

2020-07-30 Thread Christian Hopps
For the curious

To join gather.town goto the IETF 108 page: 
https://www.ietf.org/how/meetings/108/ 
and click "Join Gather".

Thanks,
Chris.

> On Jul 30, 2020, at 12:09 PM, Christian Hopps  wrote:
> 
> Hi,
> 
> If anyone would like to have a post meeting hallway chat now that our meeting 
> slot has ended, I'll be hanging out in the IETF gather.town for the next 20 
> minutes or so.
> 
> Thanks,
> Chris.



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[Lsr] Gather town hallway chats.

2020-07-30 Thread Christian Hopps
Hi,

If anyone would like to have a post meeting hallway chat now that our meeting 
slot has ended, I'll be hanging out in the IETF gather.town for the next 20 
minutes or so.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-07-30 Thread Huzhibo
HI acee:

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


thanks

Zhibo




--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人:Acee Lindem (acee) 
收件人:Peter Psenak ;Robert Raszuk 

抄 送:Aijun Wang ;Xiaoyaqun 
;Huzhibo ;Aijun Wang 
;lsr 
时 间:2020-07-31 00:04:02
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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"  wrote:

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

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  > wrote:
>
> On 30/07/2020 16:14, Robert Raszuk 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.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > 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
>
>  >
>  > Thx,
>  > R.
>  >
>

___
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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Acee Lindem (acee)
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"  wrote:

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

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  > wrote:
> 
> On 30/07/2020 16:14, Robert Raszuk 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.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > 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
> 
>  >
>  > Thx,
>  > R.
>  >
> 

___
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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Peter Psenak

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.


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.


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


On 30/07/2020 16:14, Robert Raszuk 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.
 >
 >
 > Not sure about "few seconds" ... IBGP def hold time in number of
 > 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

 >
 > Thx,
 > R.
 >



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


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

2020-07-30 Thread Robert Raszuk
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.

On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  wrote:

> On 30/07/2020 16:14, Robert Raszuk 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.
> >
> >
> > Not sure about "few seconds" ... IBGP def hold time in number of
> > 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
>
> >
> > Thx,
> > R.
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-07-30 Thread Peter Psenak

On 30/07/2020 16:14, Robert Raszuk 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.


Not sure about "few seconds" ... IBGP def hold time in number of 
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



Thx,
R.



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


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

2020-07-30 Thread Robert Raszuk
> > 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.


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


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

2020-07-30 Thread Huzhibo
HI Peter:

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


zhibo

--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com

发件人:Peter Psenak 
收件人:Huzhibo ;Aijun Wang 
抄 送:Aijun Wang ;lsr ;Xiaoyaqun 

时 间:2020-07-30 21:32:45
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Zhibo,

On 30/07/2020 15:18, Huzhibo wrote:
> 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.

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


>
>
> ZHIBO
>
> --
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287 
> Email: huzh...@huawei.com 
>
> *发件人:*Peter Psenak 
> *收件人:*Huzhibo ;Aijun Wang 
> *抄 送:*Aijun Wang ;lsr
> ;Xiaoyaqun 
> *时 间:*2020-07-30 21:02:49
> *主 题:*Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
> Huzhibo,
>
> On 30/07/2020 14:49, Huzhibo wrote:
>>
>> Hi peter:
>>
>> On 30/07/2020 14:28, Aijun Wang wrote:
>>> Hi, Peter:
>>>
>>> Aijun Wang
>>> China Telecom
>>>
 On Jul 30, 2020, at 20:00, Peter Psenak  wrote:

 Hi Aijun,

> On 30/07/2020 13:44, Aijun Wang wrote:
> 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.

 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.
>>
>> having that info is not the issue. The cyclic dependency is the one.
>>> [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.
>
> 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.
>
>
>>>

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

 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.
>>
>> 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.
>
> 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.
>>
>> thanks,
>> peter
>>
>>>
>>>
 thanks,
 Peter


> How about the above consideration and Do you have other thoughts ?
> Aijun Wang
> China Telecom
>>> On Jul 30, 2020, at 17:21, Peter Psenak 
>>>  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/
>>
>> 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 

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

2020-07-30 Thread Peter Psenak

Hi Zhibo,

On 30/07/2020 15:18, Huzhibo wrote:

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.


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





ZHIBO

--
胡志波 Hu Zhibo
Mobile: +86-18618192287 
Email: huzh...@huawei.com 

*发件人:*Peter Psenak 
*收件人:*Huzhibo ;Aijun Wang 
*抄 送:*Aijun Wang ;lsr 
;Xiaoyaqun 

*时 间:*2020-07-30 21:02:49
*主 题:*Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


Huzhibo,

On 30/07/2020 14:49, Huzhibo wrote:


Hi peter:

On 30/07/2020 14:28, Aijun Wang wrote:

Hi, Peter:

Aijun Wang
China Telecom


On Jul 30, 2020, at 20:00, Peter Psenak  wrote:

Hi Aijun,


On 30/07/2020 13:44, Aijun Wang wrote:
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.


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.


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

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


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.







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.


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.


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. 


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.


thanks,
peter





thanks,
Peter



How about the above consideration and Do you have other thoughts ?
Aijun Wang
China Telecom

On Jul 30, 2020, at 17:21, Peter Psenak  
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/

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





On 27/07/2020 03:32, Aijun Wang wrote:
Hi, LSR experts:
We have uploaded the new version of this PUA(Prefix Unreachable Announcement) 
draft. The 

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

2020-07-30 Thread Huzhibo
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
Email: huzh...@huawei.com

发件人:Peter Psenak 
收件人:Huzhibo ;Aijun Wang 
抄 送:Aijun Wang ;lsr ;Xiaoyaqun 

时 间:2020-07-30 21:02:49
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Huzhibo,

On 30/07/2020 14:49, Huzhibo wrote:
>
> Hi peter:
>
> On 30/07/2020 14:28, Aijun Wang wrote:
>> Hi, Peter:
>>
>> Aijun Wang
>> China Telecom
>>
>>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>>
>>> Hi Aijun,
>>>
 On 30/07/2020 13:44, Aijun Wang wrote:
 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.
>>>
>>> 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.
>
> having that info is not the issue. The cyclic dependency is the one.
>> [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.

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.


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

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.
>
> thanks,
> peter
>
>>
>>
>>> thanks,
>>> Peter
>>>
>>>
 How about the above consideration and Do you have other thoughts ?
 Aijun Wang
 China Telecom
>> On Jul 30, 2020, at 17:21, Peter Psenak 
>>  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/
>
> 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,

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

2020-07-30 Thread Peter Psenak

Huzhibo,

On 30/07/2020 14:49, Huzhibo wrote:


Hi peter:

On 30/07/2020 14:28, Aijun Wang wrote:

Hi, Peter:

Aijun Wang
China Telecom


On Jul 30, 2020, at 20:00, Peter Psenak  wrote:

Hi Aijun,


On 30/07/2020 13:44, Aijun Wang wrote:
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.


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.


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

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


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.








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.


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.


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. 


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.


thanks,
peter





thanks,
Peter



How about the above consideration and Do you have other thoughts ?
Aijun Wang
China Telecom

On Jul 30, 2020, at 17:21, Peter Psenak  
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/

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





On 27/07/2020 03:32, Aijun Wang 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.
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: internet-dra...@ietf.org 

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

2020-07-30 Thread Huzhibo

Hi peter:

On 30/07/2020 14:28, Aijun Wang wrote:
> Hi, Peter:
> 
> Aijun Wang
> China Telecom
> 
>> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
>>
>> Hi Aijun,
>>
>>> On 30/07/2020 13:44, Aijun Wang wrote:
>>> 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.
>>
>> 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.

having that info is not the issue. The cyclic dependency is the one.
> [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.
> 
>>
>>> 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.
>>
>> 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.

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
> On Jul 30, 2020, at 17:21, Peter Psenak 
>  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/

 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




> On 27/07/2020 03:32, Aijun Wang 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.
> 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: 

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

2020-07-30 Thread Peter Psenak

Aijun,

On 30/07/2020 14:28, Aijun Wang wrote:

Hi, Peter:

Aijun Wang
China Telecom


On Jul 30, 2020, at 20:00, Peter Psenak  wrote:

Hi Aijun,


On 30/07/2020 13:44, Aijun Wang wrote:
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.


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.


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






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.


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.


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


thanks,
peter





thanks,
Peter



How about the above consideration and
Do you have other thoughts ?
Aijun Wang
China Telecom

On Jul 30, 2020, at 17:21, Peter Psenak  
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/

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





On 27/07/2020 03:32, Aijun Wang 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.
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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang ; Yaqun Xiao 

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:   

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

2020-07-30 Thread Aijun Wang
Hi, Peter:

Aijun Wang
China Telecom

> On Jul 30, 2020, at 20:00, Peter Psenak  wrote:
> 
> Hi Aijun,
> 
>> On 30/07/2020 13:44, Aijun Wang wrote:
>> 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.
> 
> 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.

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


> thanks,
> Peter
> 
> 
>> How about the above consideration and
>> Do you have other thoughts ?
>> Aijun Wang
>> China Telecom
 On Jul 30, 2020, at 17:21, Peter Psenak 
  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/
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
 On 27/07/2020 03:32, Aijun Wang 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.
 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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
 Sent: Monday, July 27, 2020 9:16 AM
 To: Zhibo Hu ; Aijun Wang ; 
 Yaqun Xiao 
 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:   
 

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

2020-07-30 Thread Peter Psenak

Hi Aijun,

On 30/07/2020 13:44, Aijun Wang wrote:

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.


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 specified prefix has converged.


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



How about the above consideration and
Do you have other thoughts ?

Aijun Wang
China Telecom


On Jul 30, 2020, at 17:21, Peter Psenak  
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/

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





On 27/07/2020 03:32, Aijun Wang 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.
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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang ; Yaqun Xiao 

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
___
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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Aijun Wang
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  
> 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/
> 
> 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
> 
> 
> 
> 
>> On 27/07/2020 03:32, Aijun Wang 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.
>> 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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>> Sent: Monday, July 27, 2020 9:16 AM
>> To: Zhibo Hu ; Aijun Wang ; 
>> Yaqun Xiao 
>> 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
>> ___
>> 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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Peter Psenak

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




On 27/07/2020 03:32, Aijun Wang 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.
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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang ; Yaqun Xiao 

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



___
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