Re: [Lsr] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02

[liu.yao71]

Hi Acee,

Thanks for reading the draft.

Yes, the main purpose of this draft is to carry the segment segment information 
via IGP so only one node per AS need to be connected with the controller 
through BGP-LS.

With the existing BGP-LS extension draft, it is certainly one solution to 
configure BGP sessions between all the service function nodes and controller, 
and each node sends the SF information to the controller individually.

And if I get you right, we can also select one node to have a BGP session with 
the controller and configure BGP sessions between the selected node and SF 
nodes.

But how the selected node get the SF information from SF nodes via BGP needs to 
be solved, since BGP-LS is typically used for exchanging information between 
the south and north rather than nodes of the same level, and there's no other 
existing BGP extension for distribute SIDs information between nodes .

This draft aims to provide an alternate way if the operators prefer running IGP 
on SF nodes.

So we would like to collect comments on the WG session to see how others think 
about it.






Regards,


Yao















原始邮件



发件人：AceeLindem(acee) 
收件人：刘尧00165286;zzhang_i...@hotmail.com ;
抄送人：lsr@ietf.org ;
日 期 ：2020年07月29日 01:53
主 题 ："IGP Extensions for Segment Routing Service Segment" 
-draft-lz-lsr-igp-sr-service-segments-02




Speaking as WG member:


 


It seems the sole purpose of this draft is to get service segment information 
from nodes in the IGP domain to the IGP node that has a BGP session with the 
controller. You don’t need to put this information
 into the IGP in order to do this. Simply configure BGP sessions for the BGP-LS 
AF between the nodes with service functions and the node selected to have a BGP 
session with the controller.


 


Speaking as WG Chair – please let me know if we can omit this draft from the 
agenda.


 


Thanks,


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

[Lsr] "IGP Extensions for Segment Routing Service Segment" - draft-lz-lsr-igp-sr-service-segments-02

[Acee Lindem (acee)]

Speaking as WG member:

It seems the sole purpose of this draft is to get service segment information 
from nodes in the IGP domain to the IGP node that has a BGP session with the 
controller. You don’t need to put this information into the IGP in order to do 
this. Simply configure BGP sessions for the BGP-LS AF between the nodes with 
service functions and the node selected to have a BGP session with the 
controller.

Speaking as WG Chair – please let me know if we can omit this draft from the 
agenda.

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

[Lsr] I-D Action: draft-ietf-lsr-yang-isis-reverse-metric-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : YANG Module for IS-IS Reverse Metric
Author  : Christian Hopps
Filename: draft-ietf-lsr-yang-isis-reverse-metric-01.txt
Pages   : 15
Date: 2020-07-28

Abstract:
   This document defines a YANG module for managing the reverse metric
   extension to the the intermediate system to intermediate system
   routeing protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-yang-isis-reverse-metric-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-yang-isis-reverse-metric-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-yang-isis-reverse-metric-01


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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

[bruno.decraene]

From: Acee Lindem (acee) [mailto:a...@cisco.com]


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

From: Bruno Decraene 
mailto:bruno.decra...@orange.com>>
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>, Acee Lindem 
mailto:a...@cisco.com>>
Cc: Aijun Wang mailto:wang...@chinatelecom.cn>>, Zhibo 
Hu mailto:huzh...@huawei.com>>, Yaqun Xiao 
mailto:xiaoya...@huawei.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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

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

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: Aijun Wang mailto:wang...@chinatelecom.cn>>; Zhibo 
Hu mailto:huzh...@huawei.com>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>; 
lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

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

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

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

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

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

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

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

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

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

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn> 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
 

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

[Acee Lindem (acee)]

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

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

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

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

--Bruno

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

Hello Acee,

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

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

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

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

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

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

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

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

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

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn> 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 mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
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

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

[Acee Lindem (acee)]

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

On 7/27/20, 10:03 PM, "Huzhibo"  wrote:

Hi Acee:

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

Thanks

Zhibo Hu

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

Speaking as an LSR Working Group member:

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

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  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

[Acee Lindem (acee)]

Hi Aijun,

You did misunderstand me so let me be brief.


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

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


Hi, Acee:

Let me try to answer your concerns.

Please see the below inline.

If I missed your comments, please correct me.



Best Regards



Aijun Wang

China Telecom



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



Speaking as an LSR Working Group member:



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

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



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

[WAJ] section 3 of this 
draft
 has demonstrated the problem/scenarios that needs to be addressed. We think 
this will be normal phenomena in the IPv6 era.



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

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



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

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



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

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to 
another ABR, when such ABR router can reach the specified prefix.  But this 
additional mechanism will be used only when the ABR all reach the PUA limit. If 
not, the PUA mechanism described in section 
4
 can be used to guide the traffic.



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

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



Acee



On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20wang...@chinatelecom.cn>>
 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 mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>

Subject: New Version Noti

[Lsr] Protocol Action: 'Invalid TLV Handling in IS-IS' to Proposed Standard (draft-ietf-lsr-isis-invalid-tlv-03.txt)

[The IESG]

The IESG has approved the following document:
- 'Invalid TLV Handling in IS-IS'
  (draft-ietf-lsr-isis-invalid-tlv-03.txt) as Proposed Standard

This document is the product of the Link State Routing Working Group.

The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah
Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/





Technical Summary

   Key to the extensibility of the Intermediate System to Intermediate
   System (IS-IS) protocol has been the handling of unsupported and/or
   invalid Type/Length/Value (TLV) tuples.  Although there are explicit
   statements in existing specifications, deployment experience has
   shown that there are inconsistencies in the behavior when a TLV which
   is disallowed in a particular Protocol Data Unit (PDU) is received.

   This document discusses such cases and makes the correct behavior
   explicit in order to ensure that interoperability is maximized.


Working Group Summary

   The document was well received and the process straight forward.

Document Quality

   Most implementations already follow what this document specifies. The
   implementations that do not must be updated.

Personnel

   Document Shepherd: Christian Hopps
   Responsible AD: Alvaro Retana

___
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

[bruno.decraene]

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

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

--Bruno

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

Hello Acee,

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

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

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

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

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

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

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

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

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

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn> 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 mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
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:   

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

[Robert Raszuk]

Hello Acee,

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

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

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

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

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

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

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

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee)  wrote:

> Speaking as an LSR Working Group member:
>
> Asking the WG precisely how to advertise prefix unreachability is the
> wrong question - it is analogous to asking whether to use a car or truck to
> drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with
> these complex and unnecessary mechanisms, it would be better to address the
> requirement in your network design. Note that the unreachability of a given
> summarized prefix is only relevant if it is reachable through another ABR..
> In this case, the network design should provide adequate intra-area
> redundancy to provide communications between the ABRs. If this cannot be
> accomplished, an intra-area adjacency should be established over a tunnel
> between the ABRs in the backbone. Contrary to section 6.1, Looping is
> normally not a problem as ABRs should add back hole routes for their
> advertised summaries.
>
> Acee
>
> On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  on behalf of wang...@chinatelecom.cn> 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 htm

[Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Thomas.Graf]

Dear lsr,

I presented the following draft

Export of MPLS Segment Routing Label Type Information in IP Flow Information 
Export (IPFIX)
https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04

at the spring working group at IETF 108 yesterday
https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf

and today at OPSAWG where I call for adoption.

This draft adds additional segment routing code points for in the IANA IPFIX 
registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain 
further insights into the MPLS-SR forwarding-plane.

I have been asked to not only gather feedback from spring and opsawg but also 
from lsr and mpls working groups since these code points are related to link 
state routing protocols and mpls data plane.

I am looking forward to your feedback and input.

Best Wishes
Thomas Graf


smime.p7s
Description: S/MIME Cryptographic Signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr