Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

The WG adoption call has completed and there is more than sufficient support 
for adoption. 
What’s more, vendors are implementing and operators are planning of deploying 
the extensions. 
Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00. 

A couple of WG members, while acknowledging the use case, thought that it would 
be better satisfied outside of the IGPs. 
In fact, they both offered other viable alternatives. However, with the 
overwhelming support and commitment to implementation
and deployment, we are going forward with WG adoption of this document. As the 
Co-Chair managing the adoption, I don’t see
this optional mechanism as fundamentally changing the IGPs. 

There was also quite vehement opposition from the authors of 
draft-wang-lsr-prefix-unreachable-annoucement. This draft
purports to support the same use case as well as others (the archives can be 
consulted for the discussion). Further discussion
of this other draft and the use cases it addresses should be in the context of 
draft-wang-lsr-prefix-unreachable-annoucement
and not the WG draft.

Thanks,
Acee 

> On Aug 23, 2023, at 3:58 PM, Acee Lindem  wrote:
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee


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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

Hi Aijun, 

I think we are repeating ourselves here. However, let me add a couple points. 
The fact that you added the BGP PIC use case to your draft when the WG 
indicated that was the problem to be solved doesn’t make you the owner of the 
use case. Additionally, the fact that you were offered authorship on the draft 
under adoption is a recognition that you did have a draft the addressed IGP 
unreachability. However, you declined. Finally, even after appropriating some 
of the elements of the draft under adoption (e.g., unreachable metrics and 
configuration of LSA life) your draft is now a superset of the former draft 
and, IMO, unimplementable.

Thanks,
Acee 


> On Sep 6, 2023, at 01:56, Aijun Wang  wrote:
> 
> Hi, Acee:
>  
> AGAIN, before making some assertions, please check the following fact:
> Have you noticed the 00 version of 
> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ 
> was submitted on July 5, 2021?
> But the description about the short lived notification in 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
>  was on March 26, 2021.
> Then, which draft was the first?
>  
> For the adoption call or merge efforts, I think the WG should consider the 
> following facts:
> 1) Which draft is the first to provide the use cases? 
> 2) Which draft is the first to propose explicit signaling for unreachable 
> information?
> 3) Which draft is the first to propose short lived notification?
> 4) Which explicit signaling mechanism is simpler?
> 5) Which draft provides more mechanisms to cover more scenarios?
>  
> The base document should be selected based on the answers of the above 
> questions. 
> Select the base document doesn’t mean that it can’t be changed before the 
> adoption(I haven’t said “Without Change” is the merge condition). 
> Actually, we welcome more authors to join us to finalize the document and 
> solution.
>  
> As one of the most important WG within IETF, I think LSR WG should respect 
> the original contributions to the WG.
> It is too hurry to consider or adopt only the draft that you prefer, 
> especially the follower draft.
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> 发件人: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> 
> [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
> 发送时间: 2023年9月6日 0:56
> 收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
> 抄送: Robert Raszuk mailto:rob...@raszuk.net>>; Les 
> Ginsberg (ginsberg)  <mailto:ginsberg=40cisco@dmarc.ietf.org>>; Huzhibo 
>  <mailto:huzhibo=40huawei@dmarc.ietf.org>>; Peter Psenak 
> mailto:ppse...@cisco.com>>; linchangwang 
> mailto:linchangwang.04...@h3c.com>>; lsr 
> mailto:lsr@ietf.org>>
> 主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" 
> - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
>  
>  
> Hi Aijun, 
>  
> When the WG discussion first indicated that this was a use case that needed 
> to be addressed, I don’t dispute that you immediately added it to your draft. 
> I have no doubt you would have purported support of any use case under 
> discussion. 
>  
> However, the first draft to address this use case with a short-lived 
> notification was  
> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/
> Based on WG feedback and collaboration of multiple vendors, this draft 
> evolved to draft-ppsenak-lsr-igp-ureach-prefix-announce. 
>  
> While you’ve incorporated elements of the draft under discussion, your draft 
> still includes pieces (sometimes conflicting) from previous use cases.
>  
> There was an effort to merge the drafts but you declined unless your draft 
> was used (without change) as the base. I’m not sure your motivation. 
>  
> Thanks,
> Acee
>  
>  
> 
> 
>> On Sep 1, 2023, at 20:25, Aijun Wang > <mailto:wangai...@tsinghua.org.cn>> wrote:
>>  
>> Hi, Acee:
>>  
>> Act as LSR chair, I think you should be more responsible to make any 
>> unfounded assertions:
>>  
>> We have described the previous statements in
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7,
>>  March 26, 2021, one year before the 00 version of draft-ppsenak(March 
>> 25,2022)
>>  
>> Then, which draft copy or incorporate which draft?
>>  
>> Aijun Wang
>> China Telecom
>> 
>> 
>>> On Sep 1, 2023, at 20:05, Acee Lindem >> <mailto:acee.i...@gmail.com>> wrote:
>>> 
>>> Hi Aijun, 
>>> 
>>> 
>>>> On Aug 31, 2023, at 23:36, Aijun W

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

Hi Aijun, 

When the WG discussion first indicated that this was a use case that needed to 
be addressed, I don’t dispute that you immediately added it to your draft. 
I have no doubt you would have purported support of any use case under 
discussion. 

However, the first draft to address this use case with a short-lived 
notification was  
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/
Based on WG feedback and collaboration of multiple vendors, this draft evolved 
to draft-ppsenak-lsr-igp-ureach-prefix-announce. 

While you’ve incorporated elements of the draft under discussion, your draft 
still includes pieces (sometimes conflicting) from previous use cases.

There was an effort to merge the drafts but you declined unless your draft was 
used (without change) as the base. I’m not sure your motivation. 

Thanks,
Acee



> On Sep 1, 2023, at 20:25, Aijun Wang  wrote:
> 
> Hi, Acee:
> 
> Act as LSR chair, I think you should be more responsible to make any 
> unfounded assertions:
> 
> We have described the previous statements in
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7,
>  March 26, 2021, one year before the 00 version of draft-ppsenak(March 
> 25,2022)
> 
> Then, which draft copy or incorporate which draft?
> 
> Aijun Wang
> China Telecom
> 
>> On Sep 1, 2023, at 20:05, Acee Lindem  wrote:
>> 
>> Hi Aijun, 
>> 
>>> On Aug 31, 2023, at 23:36, Aijun Wang  wrote:
>>> 
>>> Hi，Acee:
>>>  
>>> Please read 
>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
>>>  before making misguide assertions:
>>>  
>>> “The advertisement of PUAM message should only last one configurable period 
>>> to allow the services that run on the failure prefixes are switchovered.”
>> 
>> 
>> I guess I haven’t kept up with all the elements of the draft under adoption 
>> that you continue to incorporate into your draft. This has been a continuing 
>> theme since initial discussed of the application signaling use case. While I 
>> have no interest in improving your draft, making the LSP/LSA short-lived 
>> conflicts with the other scenarios your draft purports to address. 
>> 
>> Acee
>> 
>> 
>>>  
>>> Best Regards
>>>  
>>> Aijun Wang
>>> China Telecom
>>>  
>>> 发件人: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> 
>>> [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
>>> 发送时间: 2023年9月1日 0:50
>>> 收件人: Robert Raszuk mailto:rob...@raszuk.net>>
>>> 抄送: Les Ginsberg (ginsberg) >> <mailto:ginsberg=40cisco....@dmarc.ietf.org>>; Huzhibo 
>>> >> <mailto:huzhibo=40huawei@dmarc.ietf.org>>; Peter Psenak 
>>> mailto:ppse...@cisco.com>>; linchangwang 
>>> mailto:linchangwang.04...@h3c.com>>; lsr 
>>> mailto:lsr@ietf.org>>
>>> 主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
>>> Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
>>>  
>>>  
>>> 
>>> 
>>>> On Aug 31, 2023, at 12:32, Robert Raszuk >>> <mailto:rob...@raszuk.net>> wrote:
>>>>  
>>>> Hi Acee,
>>>>  
>>>>> In any case, one will need to update the signaling routers and the 
>>>>> routers acting on the signal. 
>>>>  
>>>> I guess this is clear to all. 
>>>>  
>>>>> Additionally, your request for the adoption was that the draft have a 
>>>>> stronger statement about the mechanism being used for solely for 
>>>>> signaling for applications (e.g., BGP PIC).
>>>>  
>>>> As to the applicability my comment was that either draft should state in 
>>>> strong normative language that this is applicable only to applications 
>>>> which data plane uses encapsulation to the next hop. 
>>>>  
>>>> Said this draft-wang introduces the additional signalling, sort of trying 
>>>> to assure that all nodes in an area understand the new messages - but I am 
>>>> not sure if even advertising PUAM capability means that it will be 
>>>> actually used for all destinations ? 
>>>  
>>> No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral 
>>> signal which the WG agreed was a valid use case, in the other draft, the 
>>> LSAs are long-lived and are also may be used for other purposed than 
>>> signaling (e.g., reread both se

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee:Act as LSR chair, I think you should be more responsible to make any unfounded assertions:We have described the previous statements inhttps://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7, March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)Then, which draft copy or incorporate which draft?Aijun WangChina TelecomOn Sep 1, 2023, at 20:05, Acee Lindem  wrote:Hi Aijun, On Aug 31, 2023, at 23:36, Aijun Wang  wrote:Hi，Acee: Please read https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7 before making misguide assertions: “The advertisement of PUAM message should only last one configurable period to allow the services that run on the failure prefixes are switchovered.”I guess I haven’t kept up with all the elements of the draft under adoption that you continue to incorporate into your draft. This has been a continuing theme since initial discussed of the application signaling use case. While I have no interest in improving your draft, making the LSP/LSA short-lived conflicts with the other scenarios your draft purports to address. Acee Best Regards Aijun WangChina Telecom 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem发送时间: 2023年9月1日 0:50收件人: Robert Raszuk <rob...@raszuk.net>抄送: Les Ginsberg (ginsberg) <ginsberg=40cisco@dmarc.ietf.org>; Huzhibo <huzhibo=40huawei@dmarc.ietf.org>; Peter Psenak <ppse...@cisco.com>; linchangwang <linchangwang.04...@h3c.com>; lsr <lsr@ietf.org>主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04  On Aug 31, 2023, at 12:32, Robert Raszuk <rob...@raszuk.net> wrote: Hi Acee, In any case, one will need to update the signaling routers and the routers acting on the signal.  I guess this is clear to all.  Additionally, your request for the adoption was that the draft have a stronger statement about the mechanism being used for solely for signaling for applications (e.g., BGP PIC). As to the applicability my comment was that either draft should state in strong normative language that this is applicable only to applications which data plane uses encapsulation to the next hop.  Said this draft-wang introduces the additional signalling, sort of trying to assure that all nodes in an area understand the new messages - but I am not sure if even advertising PUAM capability means that it will be actually used for all destinations ?  No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral signal which the WG agreed was a valid use case, in the other draft, the LSAs are long-lived and are also may be used for other purposed than signaling (e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting with a whole different use case but selectively added mechanisms from ppsenak-lsr…  I seem to recall you were a strong proponent of limiting the scope.   By responding to this Email inline, some may believe you support the assertion that we should start the adoption of both drafts. Please be clarify this. Well the way I see this is that adoption call is a bit more formal opportunity for WG members to express their opinion on any document. But maybe LSR (for good reasons) have different internal rules to decide which document should be subject to WG adoption and does sort of pre-filtering.  If adoption call proves document has negative comments or lacks cross vendor support it simply does not get adopted.  Maybe I am just spoiled looking at how IDR WG process works :-)  You replied to an Email inline suggesting adoption of both drafts. That is what I think could have been misconstrued - especially by those who didn’t follow the discussion until now who think you are agreeing with this recommendation.    As for your other comment that this could be accomplished with BGP or an out-of-bound mechanism, that is true but that could be true of many problem. However, the solution under adoption has running code and wide vendor support.  Right ... As I wrote to Peter - perhaps this is just a pragmatic approach and flooding is what link state uses so be it.  As you know I did try in the past to propose BGP Aggregate withdraw but then feedback of the community was that PEs do not go down that often to justify the extension.  Hmm… We seem to have broad support for the LSR application signaling use case.  Thanks,Acee  Best,Robert  ___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

Hi Aijun, 

> On Aug 31, 2023, at 23:36, Aijun Wang  wrote:
> 
> Hi，Acee:
>  
> Please read 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
>  before making misguide assertions:
>  
> “The advertisement of PUAM message should only last one configurable period 
> to allow the services that run on the failure prefixes are switchovered.”


I guess I haven’t kept up with all the elements of the draft under adoption 
that you continue to incorporate into your draft. This has been a continuing 
theme since initial discussed of the application signaling use case. While I 
have no interest in improving your draft, making the LSP/LSA short-lived 
conflicts with the other scenarios your draft purports to address. 

Acee


>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> 发件人: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> 
> [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
> 发送时间: 2023年9月1日 0:50
> 收件人: Robert Raszuk mailto:rob...@raszuk.net>>
> 抄送: Les Ginsberg (ginsberg)  <mailto:ginsberg=40cisco@dmarc.ietf.org>>; Huzhibo 
>  <mailto:huzhibo=40huawei@dmarc.ietf.org>>; Peter Psenak 
> mailto:ppse...@cisco.com>>; linchangwang 
> mailto:linchangwang.04...@h3c.com>>; lsr 
> mailto:lsr@ietf.org>>
> 主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" 
> - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
>  
>  
> 
> 
>> On Aug 31, 2023, at 12:32, Robert Raszuk > <mailto:rob...@raszuk.net>> wrote:
>>  
>> Hi Acee,
>>  
>>> In any case, one will need to update the signaling routers and the routers 
>>> acting on the signal. 
>>  
>> I guess this is clear to all. 
>>  
>>> Additionally, your request for the adoption was that the draft have a 
>>> stronger statement about the mechanism being used for solely for signaling 
>>> for applications (e.g., BGP PIC).
>>  
>> As to the applicability my comment was that either draft should state in 
>> strong normative language that this is applicable only to applications which 
>> data plane uses encapsulation to the next hop. 
>>  
>> Said this draft-wang introduces the additional signalling, sort of trying to 
>> assure that all nodes in an area understand the new messages - but I am not 
>> sure if even advertising PUAM capability means that it will be actually used 
>> for all destinations ? 
>  
> No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral 
> signal which the WG agreed was a valid use case, in the other draft, the LSAs 
> are long-lived and are also may be used for other purposed than signaling 
> (e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting 
> with a whole different use case but selectively added mechanisms from 
> ppsenak-lsr… 
>  
> I seem to recall you were a strong proponent of limiting the scope. 
>  
> 
> 
>>  
>>> By responding to this Email inline, some may believe you support the 
>>> assertion that we should start the adoption of both drafts. Please be 
>>> clarify this.
>>  
>> Well the way I see this is that adoption call is a bit more formal 
>> opportunity for WG members to express their opinion on any document. But 
>> maybe LSR (for good reasons) have different internal rules to decide which 
>> document should be subject to WG adoption and does sort of pre-filtering. 
>>  
>> If adoption call proves document has negative comments or lacks cross vendor 
>> support it simply does not get adopted. 
>>  
>> Maybe I am just spoiled looking at how IDR WG process works :-) 
>  
> You replied to an Email inline suggesting adoption of both drafts. That is 
> what I think could have been misconstrued - especially by those who didn’t 
> follow the discussion until now who think you are agreeing with this 
> recommendation.  
>  
> 
> 
>>  
>>> As for your other comment that this could be accomplished with BGP or an 
>>> out-of-bound mechanism, that is true but that could be true of many 
>>> problem. However, the solution under adoption has running code and wide 
>>> vendor support.
>>  
>>  Right ... As I wrote to Peter - perhaps this is just a pragmatic approach 
>> and flooding is what link state uses so be it. 
>>  
>> As you know I did try in the past to propose BGP Aggregate withdraw but then 
>> feedback of the community was that PEs do not go down that often to justify 
>> the extension. 
>  
> Hmm… We seem to have broad support for the LSR application signaling use 
> case. 
>  
> Thanks,
> Acee
>  
> 
> 
>>  
>> Best,
>> Robert
>>  
> 
>  
> ___
> Lsr mailing list
> Lsr@ietf.org <mailto: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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

> On Aug 31, 2023, at 12:32, Robert Raszuk  wrote:
> 
> Hi Acee,
> 
>> In any case, one will need to update the signaling routers and the routers 
>> acting on the signal.
> 
> I guess this is clear to all. 
> 
>> Additionally, your request for the adoption was that the draft have a 
>> stronger statement about the mechanism being used for solely for signaling 
>> for applications (e.g., BGP PIC).
> 
> As to the applicability my comment was that either draft should state in 
> strong normative language that this is applicable only to applications which 
> data plane uses encapsulation to the next hop. 
> 
> Said this draft-wang introduces the additional signalling, sort of trying to 
> assure that all nodes in an area understand the new messages - but I am not 
> sure if even advertising PUAM capability means that it will be actually used 
> for all destinations ? 

No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral 
signal which the WG agreed was a valid use case, in the other draft, the LSAs 
are long-lived and are also may be used for other purposed than signaling 
(e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting 
with a whole different use case but selectively added mechanisms from 
ppsenak-lsr… 

I seem to recall you were a strong proponent of limiting the scope. 


> 
>> By responding to this Email inline, some may believe you support the 
>> assertion that we should start the adoption of both drafts. Please be 
>> clarify this.
> 
> Well the way I see this is that adoption call is a bit more formal 
> opportunity for WG members to express their opinion on any document. But 
> maybe LSR (for good reasons) have different internal rules to decide which 
> document should be subject to WG adoption and does sort of pre-filtering. 
> 
> If adoption call proves document has negative comments or lacks cross vendor 
> support it simply does not get adopted. 
> 
> Maybe I am just spoiled looking at how IDR WG process works :-) 

You replied to an Email inline suggesting adoption of both drafts. That is what 
I think could have been misconstrued - especially by those who didn’t follow 
the discussion until now who think you are agreeing with this recommendation.  


>  
>> As for your other comment that this could be accomplished with BGP or an 
>> out-of-bound mechanism, that is true but that could be true of many problem. 
>> However, the solution under adoption has running code and wide vendor 
>> support.
> 
>  Right ... As I wrote to Peter - perhaps this is just a pragmatic approach 
> and flooding is what link state uses so be it. 
> 
> As you know I did try in the past to propose BGP Aggregate withdraw but then 
> feedback of the community was that PEs do not go down that often to justify 
> the extension. 

Hmm… We seem to have broad support for the LSR application signaling use case. 

Thanks,
Acee


> 
> Best,
> Robert
> 

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Huzhibo]

Object its adoption.

https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ 
(PUA) covering all use cases and scenarios in this document, the PUA describes 
additional more useful use cases and scenarios, including:
1. PUA solves area/domain partition, which is necessary because it often occurs 
on the network.
2. PUA describes a detailed solution to the number of unreachable prefixes that 
exceed the limit.
3. PUA describes the rules for selecting reachable prefixes and unreachable 
prefixes.
I think this content is very useful and necessary. It is recommended that the 
LSR working group adopt a more mature and comprehensive solution.

Thank you.
Zhibo Hu

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Thursday, August 24, 2023 4:07 AM
> To: lsr 
> Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> Subject: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed
> draft name)
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
> 
> Thanks,
> Acee
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Peter Psenak]

Robert,

On 29/08/2023 02:54, Robert Raszuk wrote:


Ok so you are saying it is still perfectly fine to flood domain wide per 
node MSDs and completely ground breaking to flood per the very same 
amount of nodes one loopback prefix ... Interesting.


I'm not saying you should flood MSD domain wide. You claimed "PE may 
find useful to know them". All I sad was that MSDs are orthogonal to the 
summarization.



thanks,
Peter


Thx.
R.


On Tue, Aug 29, 2023 at 11:52 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote:


Robert,

On 29/08/2023 02:23, Robert Raszuk wrote:
 >
 > Well takeMSDs ... I would think remote PE may find useful to know
them
 > (ie. what is the capability of egress PE). Why those would not be
needed
 > outside of an area I do not get.

MSDs are advertise per node or per link, nothing to do with prefixes
and
summarization.

thanks,
Peter

 >
 > Thx,
 > R.
 >
 > On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak mailto:ppse...@cisco.com>
 > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>> wrote:
 >
 >     Robert,
 >
 >     On 28/08/2023 14:19, Robert Raszuk wrote:
 >      > Daniel,
 >      >
 >      >  > [DV] No, there’s no need to leak and advertise
 >      >
 >      > You mean there is no need for RFC9352 in your network. If
so - great.
 >      >
 >      > I was however asking the question: if network needs to
advertise
 >     any of
 >      > the information defined in RFC9352 would it still benefit
from UPA ?
 >
 >     ISIS SIDs are not needed outside of its area. Service SIDs are
 >     advertised by BGP.
 >
 >     thanks,
 >     Peter
 >      >
 >      > Thx,
 >      > R.
 >      >
 >      >
 >      >
 >      > On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel
 >     mailto:daniel.vo...@bell.ca>
<mailto:daniel.vo...@bell.ca <mailto:daniel.vo...@bell.ca>>
 >      > <mailto:daniel.vo...@bell.ca <mailto:daniel.vo...@bell.ca>
<mailto:daniel.vo...@bell.ca <mailto:daniel.vo...@bell.ca>>>> wrote:
 >      >
 >      >     Hi Robert, inlines
 >      >
 >      >     __ __
 >      >
 >      >     __ __
 >      >
 >      >     *From: *Lsr mailto:lsr-boun...@ietf.org>
 >     <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>
<mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>
 >     <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>>> on
 >      >     behalf of Robert Raszuk mailto:rob...@raszuk.net>
 >     <mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>
<mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>
 >     <mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>>>
 >      >     *Date: *Monday, August 28, 2023 at 12:00 PM
 >      >     *To: *"Hassan, Shehzad"
 >     mailto:40bell...@dmarc.ietf.org>
 >     <mailto:40bell...@dmarc.ietf.org
<mailto:40bell...@dmarc.ietf.org>>
 >      >     <mailto:40bell...@dmarc.ietf.org
<mailto:40bell...@dmarc.ietf.org>
 >     <mailto:40bell...@dmarc.ietf.org
<mailto:40bell...@dmarc.ietf.org>>>>, Daniel Bernier
 >      >     mailto:daniel.bern...@bell.ca> <mailto:daniel.bern...@bell.ca
<mailto:daniel.bern...@bell.ca>>
 >     <mailto:daniel.bern...@bell.ca
<mailto:daniel.bern...@bell.ca> <mailto:daniel.bern...@bell.ca
<mailto:daniel.bern...@bell.ca>>>>
 >      >     *Cc: *lsr mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
 >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>>,
 >      >     "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
<mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
 >     <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
<mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>
 >      >   
  <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org

<mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
 >     <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
    <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>>"
 >      >     mailto:draft-ppsenak-lsr-igp-ureach-pref

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Ok so you are saying it is still perfectly fine to flood domain wide per
node MSDs and completely ground breaking to flood per the very same amount
of nodes one loopback prefix ... Interesting.

Thx.
R.


On Tue, Aug 29, 2023 at 11:52 AM Peter Psenak  wrote:

> Robert,
>
> On 29/08/2023 02:23, Robert Raszuk wrote:
> >
> > Well takeMSDs ... I would think remote PE may find useful to know them
> > (ie. what is the capability of egress PE). Why those would not be needed
> > outside of an area I do not get.
>
> MSDs are advertise per node or per link, nothing to do with prefixes and
> summarization.
>
> thanks,
> Peter
>
> >
> > Thx,
> > R.
> >
> > On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak  > <mailto:ppse...@cisco.com>> wrote:
> >
> > Robert,
> >
> > On 28/08/2023 14:19, Robert Raszuk wrote:
> >  > Daniel,
> >  >
> >  >  > [DV] No, there’s no need to leak and advertise
> >  >
> >  > You mean there is no need for RFC9352 in your network. If so -
> great.
> >  >
> >  > I was however asking the question: if network needs to advertise
> > any of
> >  > the information defined in RFC9352 would it still benefit from
> UPA ?
> >
> > ISIS SIDs are not needed outside of its area. Service SIDs are
> > advertised by BGP.
> >
> > thanks,
> > Peter
> >  >
> >  > Thx,
> >  > R.
> >  >
> >  >
> >  >
> >  > On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel
> > mailto:daniel.vo...@bell.ca>
> >  > <mailto:daniel.vo...@bell.ca <mailto:daniel.vo...@bell.ca>>>
> wrote:
> >  >
> >  > Hi Robert, inlines
> >  >
> >  > __ __
> >  >
> >  > __ __
> >  >
> >  > *From: *Lsr  > <mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>>> on
> >  > behalf of Robert Raszuk  > <mailto:rob...@raszuk.net> <mailto:rob...@raszuk.net
> > <mailto:rob...@raszuk.net>>>
> >  > *Date: *Monday, August 28, 2023 at 12:00 PM
> >  > *To: *"Hassan, Shehzad"
> >  > <mailto:40bell...@dmarc.ietf.org>
> >  > <mailto:40bell...@dmarc.ietf.org
> > <mailto:40bell...@dmarc.ietf.org>>>, Daniel Bernier
> >  > mailto:daniel.bern...@bell.ca>
> > <mailto:daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>>>
> >  > *Cc: *lsr mailto:lsr@ietf.org>
> > <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>,
> >  > "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> >     <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
> >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>"
> >  >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
> >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>>
> >  > *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP
> > Unreachable
> >  > Prefix Announcement" -
> >  > draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft
> > name)
> >  >
> >  > __ __
> >  >
> >  > Hi Shehzad & Daniel,
> >  >
> >  > 
> >  >
> >  > I support this work as it is key for summarization in an
> >  > SRv6/IPv6 network.
> >  >
> >  > __ __
> >  >
> >  > Are you not going to advertise and leak across your IGP
> > domain any
> >  > of the SRv6 extensions as described in
> >  > https://datatracker.ietf.org/doc/rfc9352/
> > <https://datatracker.ietf.org/doc/rfc9352/>
> >  > <https://datatracker.ietf.org/doc/rfc9352/
> > <https://datatracker.ietf.org/doc/rfc9352/>> for the PEs ? 
> >  >
> >  > [DV] No, there’s no need to leak and advertise. For an SRv6
> > network,
> >  > we are summa

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Peter Psenak]

Robert,

On 29/08/2023 02:23, Robert Raszuk wrote:


Well takeMSDs ... I would think remote PE may find useful to know them 
(ie. what is the capability of egress PE). Why those would not be needed 
outside of an area I do not get.


MSDs are advertise per node or per link, nothing to do with prefixes and 
summarization.


thanks,
Peter



Thx,
R.

On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote:


Robert,

On 28/08/2023 14:19, Robert Raszuk wrote:
 > Daniel,
 >
 >  > [DV] No, there’s no need to leak and advertise
 >
 > You mean there is no need for RFC9352 in your network. If so - great.
 >
 > I was however asking the question: if network needs to advertise
any of
 > the information defined in RFC9352 would it still benefit from UPA ?

ISIS SIDs are not needed outside of its area. Service SIDs are
advertised by BGP.

thanks,
Peter
 >
 > Thx,
 > R.
 >
 >
 >
 > On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel
mailto:daniel.vo...@bell.ca>
 > <mailto:daniel.vo...@bell.ca <mailto:daniel.vo...@bell.ca>>> wrote:
 >
 >     Hi Robert, inlines
 >
 >     __ __
 >
 >     __ __
 >
 >     *From: *Lsr mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>>> on
 >     behalf of Robert Raszuk mailto:rob...@raszuk.net> <mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net>>>
 >     *Date: *Monday, August 28, 2023 at 12:00 PM
 >     *To: *"Hassan, Shehzad"
mailto:40bell...@dmarc.ietf.org>
 >     <mailto:40bell...@dmarc.ietf.org
<mailto:40bell...@dmarc.ietf.org>>>, Daniel Bernier
 >     mailto:daniel.bern...@bell.ca>
<mailto:daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>>>
 >     *Cc: *lsr mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>,
 >     "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
<mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
 >     <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
<mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>"
 >     mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
 >     <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
<mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>>
 >     *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP
Unreachable
 >     Prefix Announcement" -
 >     draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft
name)
 >
 >     __ __
 >
 >     Hi Shehzad & Daniel,
 >
 >     
 >
 >         I support this work as it is key for summarization in an
 >         SRv6/IPv6 network.
 >
 >     __ __
 >
 >     Are you not going to advertise and leak across your IGP
domain any
 >     of the SRv6 extensions as described in
 > https://datatracker.ietf.org/doc/rfc9352/
<https://datatracker.ietf.org/doc/rfc9352/>
 >     <https://datatracker.ietf.org/doc/rfc9352/
<https://datatracker.ietf.org/doc/rfc9352/>> for the PEs ? 
 >
 >     [DV] No, there’s no need to leak and advertise. For an SRv6
network,
 >     we are summarizing locators and loopback (should be derived from
 >     locator 0). This makes the routing domain “opaque”.
 >
 >     __ __
 >
 >     And if you do, is there still some use case for UPA ? 
 >
 >     __ __
 >
 >     Perhaps I am missing something but how would those extensions
 >     survive summarization ? 
 >
 >     __ __
 >
 >     __ __
 >
 >     Thx,
 >     Robert
 >
 >     Cheers,
 >
 >     Dan
 >
 >     __ __
 >
 >          > On Aug 23, 2023, at 4:07 PM, Acee Lindem
mailto:acee.i...@gmail.com>
 >         <mailto:acee.i...@gmail.com
<mailto:acee.i...@gmail.com>>> wrote:
 >          >
 >          > LSR Working Group,
 >          >
 >          > This begins the working group adoption call for “IGP
 >         Unreachable Prefix Announcement” -
 >         draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
 >          > Please indicate your support or objection on this list
prior
 >         to September 7th, 2023.
 >          >
 >          > Thanks,
 &

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Well takeMSDs ... I would think remote PE may find useful to know them (ie.
what is the capability of egress PE). Why those would not be needed outside
of an area I do not get.

Thx,
R.

On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak  wrote:

> Robert,
>
> On 28/08/2023 14:19, Robert Raszuk wrote:
> > Daniel,
> >
> >  > [DV] No, there’s no need to leak and advertise
> >
> > You mean there is no need for RFC9352 in your network. If so - great.
> >
> > I was however asking the question: if network needs to advertise any of
> > the information defined in RFC9352 would it still benefit from UPA ?
>
> ISIS SIDs are not needed outside of its area. Service SIDs are
> advertised by BGP.
>
> thanks,
> Peter
> >
> > Thx,
> > R.
> >
> >
> >
> > On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel  > <mailto:daniel.vo...@bell.ca>> wrote:
> >
> > Hi Robert, inlines
> >
> > __ __
> >
> > __ __
> >
> > *From: *Lsr mailto:lsr-boun...@ietf.org>> on
> > behalf of Robert Raszuk mailto:rob...@raszuk.net
> >>
> > *Date: *Monday, August 28, 2023 at 12:00 PM
> > *To: *"Hassan, Shehzad"  > <mailto:40bell...@dmarc.ietf.org>>, Daniel Bernier
> > mailto:daniel.bern...@bell.ca>>
> > *Cc: *lsr mailto:lsr@ietf.org>>,
> >     "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> >     <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>"
> >  > <mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>
> > *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable
> > Prefix Announcement" -
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft
> name)
> >
> > __ __
> >
> > Hi Shehzad & Daniel,
> >
> > 
> >
> > I support this work as it is key for summarization in an
> > SRv6/IPv6 network.
> >
> > __ __
> >
> > Are you not going to advertise and leak across your IGP domain any
> > of the SRv6 extensions as described in
> > https://datatracker.ietf.org/doc/rfc9352/
> > <https://datatracker.ietf.org/doc/rfc9352/> for the PEs ? 
> >
> > [DV] No, there’s no need to leak and advertise. For an SRv6 network,
> > we are summarizing locators and loopback (should be derived from
> > locator 0). This makes the routing domain “opaque”.
> >
> > __ __
> >
> > And if you do, is there still some use case for UPA ? 
> >
> > __ __
> >
> > Perhaps I am missing something but how would those extensions
> > survive summarization ? 
> >
> > __ __
> >
> > __ __
> >
> > Thx,
> > Robert
> >
> > Cheers,
> >
> > Dan
> >
> > __ __
> >
> >  > On Aug 23, 2023, at 4:07 PM, Acee Lindem  > <mailto:acee.i...@gmail.com>> wrote:
> >  >
> >  > LSR Working Group,
> >  >
> >  > This begins the working group adoption call for “IGP
> > Unreachable Prefix Announcement” -
> > draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> >  > Please indicate your support or objection on this list prior
> > to September 7th, 2023.
> >  >
> >  > Thanks,
> >  > Acee
> >  >
> >
>  
> --
> >  > External Email: Please use caution when opening links and
> > attachments / Courriel externe: Soyez prudent avec les liens et
> > documents joints
> >  >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org <mailto:Lsr@ietf.org>
> > https://www.ietf.org/mailman/listinfo/lsr
> > <https://www.ietf.org/mailman/listinfo/lsr>
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Martin.Horneffer]

Support from my side as well! I think it’s essential for a large-scale 
operator’s network when using SRv6.

Best regards, Martin

Von: Lsr  im Auftrag von Gyan Mishra 

Datum: Dienstag, 29. August 2023 um 01:27
An: Acee Lindem 
Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org 
, lsr 
Betreff: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)

I support adoption and not aware of any undisclosed IPRs.

This draft is extremely valuable for SRv6 locator summarization in multi area / 
multi level networks and being able to used for BGP PIC edge activation by 
tracking BGP next hop reachability via UPA.

As SRv6 uses the IPv6 data plane this can be useful in any native IPv4 or IPv6 
network.

This draft can also be useful for MPLS inter area extension RFC 5283 so LPM 
summarization can work and being able to track the component prefixes.

In the latest update two new flags were added to the draft to signal UPA.

Thank you

Gyan

On Wed, Aug 23, 2023 at 4:07 PM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023.

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

[Das Bild wurde vom Absender entfernt.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Peter Psenak]

Robert,

On 28/08/2023 14:19, Robert Raszuk wrote:

Daniel,

 > [DV] No, there’s no need to leak and advertise

You mean there is no need for RFC9352 in your network. If so - great.

I was however asking the question: if network needs to advertise any of 
the information defined in RFC9352 would it still benefit from UPA ?


ISIS SIDs are not needed outside of its area. Service SIDs are 
advertised by BGP.


thanks,
Peter


Thx,
R.



On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel <mailto:daniel.vo...@bell.ca>> wrote:


Hi Robert, inlines

__ __

__ __

*From: *Lsr mailto:lsr-boun...@ietf.org>> on
behalf of Robert Raszuk mailto:rob...@raszuk.net>>
*Date: *Monday, August 28, 2023 at 12:00 PM
*To: *"Hassan, Shehzad" mailto:40bell...@dmarc.ietf.org>>, Daniel Bernier
mailto:daniel.bern...@bell.ca>>
*Cc: *lsr mailto:lsr@ietf.org>>,
"draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
<mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>"
mailto:draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>>
    *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable
Prefix Announcement" -
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

__ __

Hi Shehzad & Daniel,



I support this work as it is key for summarization in an
SRv6/IPv6 network.

__ __

Are you not going to advertise and leak across your IGP domain any
of the SRv6 extensions as described in
https://datatracker.ietf.org/doc/rfc9352/
<https://datatracker.ietf.org/doc/rfc9352/> for the PEs ? 

[DV] No, there’s no need to leak and advertise. For an SRv6 network,
we are summarizing locators and loopback (should be derived from
locator 0). This makes the routing domain “opaque”.

__ __

And if you do, is there still some use case for UPA ? 

__ __

Perhaps I am missing something but how would those extensions
survive summarization ? 

__ __

__ __

Thx,
Robert

Cheers,

Dan

__ __

 > On Aug 23, 2023, at 4:07 PM, Acee Lindem mailto:acee.i...@gmail.com>> wrote:
 >
 > LSR Working Group,
 >
 > This begins the working group adoption call for “IGP
Unreachable Prefix Announcement” -
draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
 > Please indicate your support or objection on this list prior
to September 7th, 2023.
 >
 > Thanks,
 > Acee
 >

--
 > External Email: Please use caution when opening links and
attachments / Courriel externe: Soyez prudent avec les liens et
documents joints
 >
___
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>



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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Aijun Wang]

Hi, Ketan:Which part in https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ is not workable?I want to remind you again that it is the above draft initiates the problem first, insists that the explicit signaling was the direction, covers more scenarios that draft-ppsenak lacks stillSo, what’s the reason to adopt the follower, sub-optimal solution?Aijun WangChina TelecomOn Aug 28, 2023, at 20:20, Ketan Talaulikar  wrote:Hi Acee/All,I support the adoption of this document by the WG. Several WG members have been actively involved in the development of this document for over a year now. The authors have included the feedback and as a result the solution has evolved very well.While there is another document [1] that tries to address the same problem statement, the solution in there is still not workable despite the feedback provided to its authors over the years. We need a workable IGP based solution.Overall, I find that the solution in draft-ppsenak:- is an IGP based solution and therefore in the charter or LSR WG- is a backward compatible solution that does not break existing IGP deployments running older software versions; it allows for incremental deployment/rollout- includes explicit indication of UPA which is more robust and more appropriate semanticallyGiven that the problem scenario is well acknowledged, there is running code for this solution, and we have feedback from operators who are interested in deploying this solution, I believe it is the time for the WG to adopt this document.Thanks,Ketan [1] https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/On Thu, Aug 24, 2023 at 1:37 AM Acee Lindem  wrote:LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 2023. 

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

___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Gyan Mishra]

I support adoption and not aware of any undisclosed IPRs.

This draft is extremely valuable for SRv6 locator summarization in multi
area / multi level networks and being able to used for BGP PIC edge
activation by tracking BGP next hop reachability via UPA.

As SRv6 uses the IPv6 data plane this can be useful in any native IPv4 or
IPv6 network.

This draft can also be useful for MPLS inter area extension RFC 5283 so LPM
summarization can work and being able to track the component prefixes.

In the latest update two new flags were added to the draft to signal UPA.

Thank you

Gyan

On Wed, Aug 23, 2023 at 4:07 PM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Daniel,

> [DV] No, there’s no need to leak and advertise

You mean there is no need for RFC9352 in your network. If so - great.

I was however asking the question: if network needs to advertise any of the
information defined in RFC9352 would it still benefit from UPA ?

Thx,
R.



On Mon, Aug 28, 2023 at 11:05 PM Voyer, Daniel  wrote:

> Hi Robert, inlines
>
>
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Monday, August 28, 2023 at 12:00 PM
> *To: *"Hassan, Shehzad" , Daniel
> Bernier 
> *Cc: *lsr , "
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" <
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>
> *Subject: *[EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable
> Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
> (Fixed draft name)
>
>
>
> Hi Shehzad & Daniel,
>
>
>
> I support this work as it is key for summarization in an SRv6/IPv6 network.
>
>
>
> Are you not going to advertise and leak across your IGP domain any of the
> SRv6 extensions as described in https://datatracker.ietf.org/doc/rfc9352/
> for the PEs ?
>
> [DV] No, there’s no need to leak and advertise. For an SRv6 network, we
> are summarizing locators and loopback (should be derived from locator 0).
> This makes the routing domain “opaque”.
>
>
>
> And if you do, is there still some use case for UPA ?
>
>
>
> Perhaps I am missing something but how would those extensions survive
> summarization ?
>
>
>
>
>
> Thx,
> Robert
>
> Cheers,
>
> Dan
>
>
>
> > On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> >
> > LSR Working Group,
> >
> > This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> > Please indicate your support or objection on this list prior to
> September 7th, 2023.
> >
> > Thanks,
> > Acee
> >
> --
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
> >
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Voyer, Daniel]

Hi Robert, inlines


From: Lsr  on behalf of Robert Raszuk 
Date: Monday, August 28, 2023 at 12:00 PM
To: "Hassan, Shehzad" , Daniel Bernier 

Cc: lsr , "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" 

Subject: [EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)

Hi Shehzad & Daniel,

I support this work as it is key for summarization in an SRv6/IPv6 network.

Are you not going to advertise and leak across your IGP domain any of the SRv6 
extensions as described in https://datatracker.ietf.org/doc/rfc9352/ for the 
PEs ?
[DV] No, there’s no need to leak and advertise. For an SRv6 network, we are 
summarizing locators and loopback (should be derived from locator 0). This 
makes the routing domain “opaque”.

And if you do, is there still some use case for UPA ?

Perhaps I am missing something but how would those extensions survive 
summarization ?


Thx,
Robert
Cheers,
Dan

> On Aug 23, 2023, at 4:07 PM, Acee Lindem 
> mailto:acee.i...@gmail.com>> wrote:
>
> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023.
>
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
>
___
Lsr mailing list
Lsr@ietf.org<mailto: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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Luay Jalil]

I support Working Group adoption

Regards,
Luay

On Wed, Aug 23, 2023 at 3:07 PM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Dhamija, Amit]

Hi Acee and WG,

IGP UPA is imperative to solve the BGP PIC convergence problem in an SRv6 
deployment with prefix summarization.

>From Rakuten's side, we support the adoption of the draft.

Brgds
Amit D
Rakuten

From: Acee Lindem 
Date: Thursday, 24 August 2023 at 1:37 AM
To: lsr 
Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org 

Subject: Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)
[EXTERNAL] This message comes from an external organization.

LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023.

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Hi Shehzad & Daniel,


> I support this work as it is key for summarization in an SRv6/IPv6 network.
>

Are you not going to advertise and leak across your IGP domain any of the
SRv6 extensions as described in https://datatracker.ietf.org/doc/rfc9352/
for the PEs ?

And if you do, is there still some use case for UPA ?

Perhaps I am missing something but how would those extensions survive
summarization ?


Thx,
Robert


> On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> >
> > LSR Working Group,
> >
> > This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> > Please indicate your support or objection on this list prior to
> September 7th, 2023.
> >
> > Thanks,
> > Acee
> >
> --
> > External Email: Please use caution when opening links and attachments /
> Courriel externe: Soyez prudent avec les liens et documents joints
> >
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Hassan, Shehzad]

I support this work as it is key for summarization in an SRv6/IPv6 network.

Shehzad Hassan
Bell Canada



> On Aug 23, 2023, at 4:07 PM, Acee Lindem  wrote:
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Kamran Raza (skraza)]

I support the adoption of this key draft as it helps achieve BGP PIC along with 
IP prefix summarization in SRv6 networks.
--
Kamran

From: Lsr  on behalf of Hassen, Clayton 

Date: Monday, August 28, 2023 at 10:18 AM
To: Acee Lindem 
Cc: lsr , draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org 

Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft 
name)
I support.

This is a key requirement for large scale deployment models using summarization 
in SRv6 networks

—CH

> On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
>
> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023.
>
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
>
___
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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Hassen, Clayton]

I support.

This is a key requirement for large scale deployment models using summarization 
in SRv6 networks

—CH

> On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> --
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Hi Peter,

> The version -04 does not contain normative MUST that UPA shall only be
> > used to trigger invalidation when end to end encapsulation is used for
> > subject application(s). So as written is in fact quite undeployable in a
> > mixed vendor and legacy node(s) environment doing hop by hop routing. We
> > can't just hope that this is all about configuring the network in a
> > proper way.
>
> above looks more like a comment that can easily be addressed by
> additional text, which I'm willing to add, rather than an objection to
> draft becoming a WG document. Please let me know if you think otherwise.
>

Ok if you are willing to add such restriction to the spec then I can remove
my concern #1.

> The solution is too pragmatic ...
>
> Isn't that a good thing, isn't it? :)
>

:)

Yes and it does assure that we can have some mechanism like this before
we all retire !

But you know once you have an interim solution it is much harder to
convince
folks to work on a more optimal one.


> It does not look at the problem
> > holistically. Yes I still think the problem is worth solving but outside
> > of link state IGP doing UPA blast flooding everywhere domain wide even
> > if no nodes need that info. As discussed at length it could be done via
> > either BGP indirection or via PUB-SUB model (as proposed).
>
> I don't object to solve this problem in BGP, or elsewhere. But given
> that the problem we are trying to solve is created by the IGP
> summarization and the ultimate source of the prefix reachability or
> unreachibility comes from IGPs, having a solution in IGPs seems like a
> natural choice.


That is all correct. But I really do not like to use domain wide flooding
for it.

For example if you would contain the solution within IGP but from local or
remote
ABRs unicast by UDP to subscribers that given PE or POP is down that would
also
contain the solution to IGP.  Yes it is a bit more difficult as you would
need to solve
subscription problem first as opposed to the blast or spray approach, but
the current draft
does not even leave any room for such apparatus.

So my concern here is not that the proposal is broken. It is just
suboptimal IMHO.

And as we spoke a few weeks back in SF I think it is harmless, but is this
enough ?

Lastly, I think PEs do not accidentally go down that often, and for any
planned
maintenance there are other ways to drain the box.

With that said, consider my objection to be a soft one based on the above.

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Ketan Talaulikar]

Hi Acee/All,

I support the adoption of this document by the WG. Several WG members have
been actively involved in the development of this document for over a year
now. The authors have included the feedback and as a result the solution
has evolved very well.

While there is another document [1] that tries to address the same problem
statement, the solution in there is still not workable despite the feedback
provided to its authors over the years. We need a workable IGP based
solution.

Overall, I find that the solution in draft-ppsenak:
- is an IGP based solution and therefore in the charter or LSR WG
- is a backward compatible solution that does not break existing IGP
deployments running older software versions; it allows for incremental
deployment/rollout
- includes explicit indication of UPA which is more robust and more
appropriate semantically

Given that the problem scenario is well acknowledged, there is running code
for this solution, and we have feedback from operators who are interested
in deploying this solution, I believe it is the time for the WG to adopt
this document.

Thanks,
Ketan

[1]
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/


On Thu, Aug 24, 2023 at 1:37 AM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Bernier, Daniel]

Hi all, 

I support working group adoption

Dan Bernier

On 2023-08-23, 4:07 PM, "Acee Lindem" mailto:acee.i...@gmail.com>> wrote:


LSR Working Group,


This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 


Thanks,
Acee
--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints





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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Peter Psenak]

Hi Robert,

please see inline:

On 23/08/2023 14:48, Robert Raszuk wrote:

Dear LSR WG,

I object on two basis ...

1)

The version -04 does not contain normative MUST that UPA shall only be 
used to trigger invalidation when end to end encapsulation is used for 
subject application(s). So as written is in fact quite undeployable in a 
mixed vendor and legacy node(s) environment doing hop by hop routing. We 
can't just hope that this is all about configuring the network in a 
proper way.


above looks more like a comment that can easily be addressed by 
additional text, which I'm willing to add, rather than an objection to 
draft becoming a WG document. Please let me know if you think otherwise.





2)

The solution is too pragmatic ... 


Isn't that a good thing, isn't it? :)

It does not look at the problem 
holistically. Yes I still think the problem is worth solving but outside 
of link state IGP doing UPA blast flooding everywhere domain wide even 
if no nodes need that info. As discussed at length it could be done via 
either BGP indirection or via PUB-SUB model (as proposed).


I don't object to solve this problem in BGP, or elsewhere. But given 
that the problem we are trying to solve is created by the IGP 
summarization and the ultimate source of the prefix reachability or 
unreachibility comes from IGPs, having a solution in IGPs seems like a 
natural choice.


thanks,
Peter



Regards,
Robert


On Wed, Aug 23, 2023 at 10:07 PM Acee Lindem > wrote:


LSR Working Group,

This begins the working group adoption call for “IGP Unreachable
Prefix Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to
September 7th, 2023.

Thanks,
Acee
___
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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Acee Lindem]

Hi Hannes, 

> On Aug 24, 2023, at 6:16 AM, Hannes Gredler  wrote:
> 
> +1.
> 
> Changing the semantics of a 20 year+ deployed protocol is most always a bad 
> idea
> and for sure will lead into unanticipated side-effects.
> 
> FWIW - I do no dispute the usefulness of an "unreachable prefix",
> but would strongly advocate for a dedicated protocol extension.

So you don’t see the flags defined explicitly for planned/unplanned 
unreachability as a dedicated protocol extension? This was added based on WG 
feedback and perhaps you didn’t reread the most recent version of the draft. 

Thanks,
Acee



> 
> /hannes
> 
> On Wed, Aug 23, 2023 at 02:09:46PM -0700, Tony Li wrote:
> | 
> | I object. This solution is a poor way of addressing the issues.  My reasons 
> have been discussed to death already.
> | 
> | Tony
> | 
> | 
> | > On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
> | > 
> | > LSR Working Group,
> | > 
> | > This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> | > Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> | > 
> | > Thanks,
> | > Acee
> | > ___
> | > 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Acee Lindem]

Speaking as WG member: 

> On Aug 24, 2023, at 04:59, Aijun Wang  wrote:
> 
> Object its adoption.
> 
> The reasons are the followings:
> 1) It is not the initial draft to describe the problem and provide the 
> solution.
> 2) The problem and the explicit signaling mechanism is firstly provided by 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
>  in its 00 version(October,2019), far earlier than the current proposal and 
> its 00 version(March, 2022).

Let me help you refresh your memory - the -00 version of this draft solved a 
completely different problem. The unreachability signaling to other 
applications (e.g., BGP PIC) was only added after publication of the draft 
under adoption. Over revisions, other aspects of the draft under adoption were 
also appropriated (e.g., using infinite metrics). So, your claims of being 
“first" are unfounded. Let’s stick to the technical differences between the 
drafts. 

Thanks,
Acee



> 3) Even after the proposed draft adopt the explicit signaling mechanism, it 
> still lacks other mechanisms that can cover more prefixes unreachable 
> scenarios, as stated in the 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> 
> The LSR WG should consider to adopt the more comprehensive and simple 
> solution, not the partial and complex design. 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -邮件原件-
> 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
> 发送时间: 2023年8月24日 4:07
> 收件人: lsr 
> 抄送: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> 主题: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
> draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Hannes Gredler]

+1.

Changing the semantics of a 20 year+ deployed protocol is most always a bad idea
and for sure will lead into unanticipated side-effects.

FWIW - I do no dispute the usefulness of an "unreachable prefix",
but would strongly advocate for a dedicated protocol extension.

/hannes

On Wed, Aug 23, 2023 at 02:09:46PM -0700, Tony Li wrote:
| 
| I object. This solution is a poor way of addressing the issues.  My reasons 
have been discussed to death already.
| 
| Tony
| 
| 
| > On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
| > 
| > LSR Working Group,
| > 
| > This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
| > Please indicate your support or objection on this list prior to September 
7th, 2023. 
| > 
| > Thanks,
| > Acee
| > ___
| > 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Stephane Litkowski (slitkows)]

Support, this is a useful solution.

-Original Message-
From: Acee Lindem  
Sent: Wednesday, August 23, 2023 10:07 PM
To: lsr 
Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Subject: Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name) 

LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Robert Raszuk]

Dear LSR WG,

I object on two basis ...

1)

The version -04 does not contain normative MUST that UPA shall only be used
to trigger invalidation when end to end encapsulation is used for subject
application(s). So as written is in fact quite undeployable in a mixed
vendor and legacy node(s) environment doing hop by hop routing. We can't
just hope that this is all about configuring the network in a proper way.

2)

The solution is too pragmatic ... It does not look at the problem
holistically. Yes I still think the problem is worth solving but outside of
link state IGP doing UPA blast flooding everywhere domain wide even if no
nodes need that info. As discussed at length it could be done via either
BGP indirection or via PUB-SUB model (as proposed).

Regards,
Robert


On Wed, Aug 23, 2023 at 10:07 PM Acee Lindem  wrote:

> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Tony Li]

I object. This solution is a poor way of addressing the issues.  My reasons 
have been discussed to death already.

Tony


> On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Les Ginsberg (ginsberg)]

I support WG adoption.
The problem is a useful problem to solve and the solution defined in the 
document has been implemented and proven to work.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Wednesday, August 23, 2023 1:07 PM
> To: lsr 
> Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> Subject: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed
> draft name)
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 7th,
> 2023.
> 
> Thanks,
> Acee
> ___
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Acee Lindem]

LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 

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