Re: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Peter Psenak]

Aijun,

On 19/02/2019 03:01 , Aijun Wang wrote:

Hi, Peter and Dirk:

Thanks for your comments and the previous explanation.

For the use case related to the topology retrieval, I have the following
consideration, please point out if I have some misunderstandings for the
OSPF LSA procedure:
1) For prefix that is rooted at only one router, such as the loopback
address, only one originator for the prefix will be added by the ABR.
2) For prefix that is connected two nodes, such as the prefix that
identifies the link between them, the originator information will be added
twice for this prefix. Doing so does not the contradict with actual physical
deployment.


what you are proposing is to list all prefix originators, regardless of 
which one is contributing to best path to the prefix on the ABR. I 
personally do not like that idea.




The originator information will be added by the ABR when it receives the
Router LSA, as described in section 5 of the draft.
When the ABR receives such information, it may not begin the SPF calculation
and can't decide which side is closer to the ABR.


ABR MUST run SPF and determine whether the prefix is reachable and what 
is the best path metric to reach it in the original area. Such 
information is used when generating Type-3 LSA to other connected areas.


thanks,
Peter




Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-邮件原件-
发件人: Peter Psenak [mailto:ppse...@cisco.com]
发送时间: 2019年2月18日 22:02
收件人: Goethals, Dirk (Nokia - BE/Antwerp); Acee Lindem (acee);
lsr@ietf.org
主题: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

On 18/02/2019 14:37 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

I agree with Peter.
For this to work, the ABR would need to add ALL originators, while I
had the impression that we only had 1 originator per prefix, i.e. the
originator which was found to be the closed to the ABR and for which
the ABR installed a route.


above is exactly right.

thanks,
Peter



Dirk


On 2/18/2019 14:15, Peter Psenak wrote:

Support as coauthor, although I never really agreed with the usage of
the prefix originator for topology construction as described  in
section 3 and 5. I would prefer that part to be removed.

thanks,
Peter


On 13/02/2019 14:25 , Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-
lsr-ospf-prefix-originator-ext


It is listed multiple times but references the same CN201810650141.



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

.



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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[zhang.zheng]

Support the adoption.






Thanks,


Sandy











原始邮件



发件人：AceeLindem(acee) 
收件人：lsr@ietf.org ;
日 期 ：2019年02月13日 21:26
主 题 ：[Lsr] Working Group Adoption Poll for "OSPF Extension for 
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01


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

  

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.


 


All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext


It is listed multiple times but references the same CN201810650141.


 


Thanks,


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

Re: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Les Ginsberg (ginsberg)]

Aijun –

The fact that you have acknowledged the limitations pointed out by others 
(notably Peter) is a good thing – but it doesn’t alter the fact that what you 
have proposed cannot be trusted.
Routers outside of an area have no way of knowing whether the area in question 
has unnumbered links or has true LANs – so of what value is the information 
which is advertised?

Your argument seems to be – “well at least some of the time an area may have 
only numbered links/no true LANs and therefore it is OK to use the topology 
information and hope the assumptions hold” – but for many of us this is exactly 
what makes the idea unappealing – that it cannot be relied upon and there is no 
way to know when it can be relied upon.

Look, you have one very good idea – add support for source router-id. Let’s 
please move forward with that.

If you still feel that you want to pursue the topology retrieval idea write a 
separate draft and allow the WG to make a decision on that independently.

I do not like my vote in favor of a proven idea (source router id) to be held 
hostage by coupling it with an idea (topology discovery) whose shortcomings 
have been clearly identified.

   Les


From: Lsr  On Behalf Of Aijun Wang
Sent: Monday, February 18, 2019 6:40 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Hi, Les:

Thanks for your comments.
After the previous discussion within WG list, I had changed the description 
about the inter-area topology retrieval scenario, which is the original source 
of this draft that is different from RFC7794.
We point out such use case can be applied where each link between routers is 
assigned a unique prefix, which is very common within the operator network(in 
Appendix B. “Special consideration on Inter-Area Topology Retrieval ”).

Would you like to point out the situation that such process can’t be applied 
and the current draft has not mentioned yet?  Or we can discuss it after its 
adoption.
We can remove such part before its publication if the situation you referred is 
common to the operator or enterprise network.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2019年2月18日 21:22
收件人: Acee Lindem (acee); lsr@ietf.org
主题: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

To the extent that the draft defines functionality equivalent to that defined 
in IS-IS RFC 7794 – specifically a means to advertise the source router-id of a 
given advertisement – it defines a necessary and useful extension to the OSPF 
protocol – and I support that work.

However, in its current form the draft discusses use of this mechanism for 
inter-area topology discovery. This idea is seriously flawed – as has been 
discussed extensively on the WG list.
The draft also discusses uses cases related to ERLD, the direction for which is 
very much uncertain at this time.

I therefore feel that the current content of the draft is not what I would 
expect to see approved by the WG as an RFC and therefore have significant 
reservations about moving forward with the existing content.

I do want to see a draft addressing the source router-id advertisement gap move 
forward – and if this draft is reduced to focus on that then I can 
enthusiastically support adoption – but in its current form I cannot indicate 
support.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, February 13, 2019 5:26 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

[Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Aijun Wang]

Hi, Les:

 

Thanks for your comments.

After the previous discussion within WG list, I had changed the description 
about the inter-area topology retrieval scenario, which is the original source 
of this draft that is different from RFC7794.

We point out such use case can be applied where each link between routers is 
assigned a unique prefix, which is very common within the operator network(in 
Appendix B. “Special consideration on Inter-Area Topology Retrieval ”).   

 

Would you like to point out the situation that such process can’t be applied 
and the current draft has not mentioned yet?  Or we can discuss it after its 
adoption.

We can remove such part before its publication if the situation you referred is 
common to the operator or enterprise network.

 

 

Best Regards.

 

Aijun Wang

Network R and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
发送时间: 2019年2月18日 21:22
收件人: Acee Lindem (acee); lsr@ietf.org
主题: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

 

To the extent that the draft defines functionality equivalent to that defined 
in IS-IS RFC 7794 – specifically a means to advertise the source router-id of a 
given advertisement – it defines a necessary and useful extension to the OSPF 
protocol – and I support that work.

 

However, in its current form the draft discusses use of this mechanism for 
inter-area topology discovery. This idea is seriously flawed – as has been 
discussed extensively on the WG list.

The draft also discusses uses cases related to ERLD, the direction for which is 
very much uncertain at this time.

 

I therefore feel that the current content of the draft is not what I would 
expect to see approved by the WG as an RFC and therefore have significant 
reservations about moving forward with the existing content.

 

I do want to see a draft addressing the source router-id advertisement gap move 
forward – and if this draft is reduced to focus on that then I can 
enthusiastically support adoption – but in its current form I cannot indicate 
support.

 

   Les

 

 

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, February 13, 2019 5:26 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

 

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019. 

 

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft 

 =draft-wang-lsr-ospf-prefix-originator-ext

It is listed multiple times but references the same CN201810650141.

 

Thanks,

Acee

 

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

[Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Aijun Wang]

Hi, Peter and Dirk:

Thanks for your comments and the previous explanation.

For the use case related to the topology retrieval, I have the following
consideration, please point out if I have some misunderstandings for the
OSPF LSA procedure:
1) For prefix that is rooted at only one router, such as the loopback
address, only one originator for the prefix will be added by the ABR.
2) For prefix that is connected two nodes, such as the prefix that
identifies the link between them, the originator information will be added
twice for this prefix. Doing so does not the contradict with actual physical
deployment.

The originator information will be added by the ABR when it receives the
Router LSA, as described in section 5 of the draft. 
When the ABR receives such information, it may not begin the SPF calculation
and can't decide which side is closer to the ABR.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-邮件原件-
发件人: Peter Psenak [mailto:ppse...@cisco.com] 
发送时间: 2019年2月18日 22:02
收件人: Goethals, Dirk (Nokia - BE/Antwerp); Acee Lindem (acee);
lsr@ietf.org
主题: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

On 18/02/2019 14:37 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
> I agree with Peter.
> For this to work, the ABR would need to add ALL originators, while I 
> had the impression that we only had 1 originator per prefix, i.e. the 
> originator which was found to be the closed to the ABR and for which 
> the ABR installed a route.

above is exactly right.

thanks,
Peter

>
> Dirk
>
>
> On 2/18/2019 14:15, Peter Psenak wrote:
>> Support as coauthor, although I never really agreed with the usage of 
>> the prefix originator for topology construction as described  in 
>> section 3 and 5. I would prefer that part to be removed.
>>
>> thanks,
>> Peter
>>
>>
>> On 13/02/2019 14:25 , Acee Lindem (acee) wrote:
>>> This begins a two week adoption poll for the subject draft. Please 
>>> send your comments to this list before 12:00 AM UTC on Thursday, 
>>> February 28^th , 2019.
>>>
>>>
>>>
>>> All authors have responded to the IPR poll and there is one 
>>> >> -lsr-ospf-prefix-originator-ext> 
>>> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-
>>> lsr-ospf-prefix-originator-ext
>>>
>>>
>>> It is listed multiple times but references the same CN201810650141.
>>>
>>>
>>>
>>> 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

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Lizhenbin]

Yes/support.

Best Regards,
Zhenbin (Robin)


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, February 13, 2019 5:26 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Zhuangshunwan]

Support.

Thanks,
Shunwan


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, February 13, 2019 5:26 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Naiming Shen (naiming)]

I support.

- Naiming

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, February 13, 2019 20:26
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

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] Moving Forward [Re: Flooding Reduction Draft Redux]

[Peter Psenak]

Hi Huaimo,

On 18/02/2019 16:28 , Huaimo Chen wrote:

Hi Peter,


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Thursday, February 14, 2019 2:30 AM
To: Huaimo Chen ; Acee Lindem (acee) ; 
Christian Hopps ; lsr@ietf.org
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

On 13/02/2019 22:50 , Huaimo Chen wrote:

Hi Peter,

My explanations/answers are in line below with prefix [HC].

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, February 6, 2019 4:58 AM
To: Huaimo Chen ; Acee Lindem (acee)
; Christian Hopps ; lsr@ietf.org
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

On 03/02/2019 17:58 , Huaimo Chen wrote:

Hi Acee,



I agree with you on keeping the signaling for two modes. The
other parts for the distributed solution need to be removed.


optimized flooding is not only about algorithm to calculate the flooding 
topology and the way
it is distributed/computed. It is also about local rules to make sure the 
flooding remains consistent.
These are _independent_ of centralized/distributed modes. And it make no sense 
to specify
these rules in two drafts.


[HC] The rules/procedures/behaviors that are common to both the centralized and 
distributed
solution/mode should be in one document. These common parts will be used by 
both solutions/modes.
They are described in the two drafts and should be merged based on technical 
merits.

In addition to the common parts, there are still some 
rules/procedures/behaviors that are
different from one mode to another mode. For example, the rule/procedure for 
fault tolerance
to failures used in the centralized solution/mode will be different from that 
used in the distributed
solution/mode.


I don't think there is any significant difference needed. And I believe 
these local rules for both modes should reside in a single document as 
most of them are applicable to both modes.



In the distributed solution/mode, there will be a set of 
rules/procedures/behaviors
that are common to the algorithms for computing flooding topology and specific 
to the
distributed solution/mode. For example, a specific procedure for scheduling an 
algorithm
to compute a flooding topology will be used on every node for the distributed 
solution/mode.


scheduling a distributed versus centralized computation is not something 
that makes the behavior different. Sure, you can put a scheduling 
details for a particular algorithm in the document that describes the 
distributed algorithm itself.


thanks,
Peter







There are no "other" parts specific for the distributed solution.

[HC] Some behaviors for the distributed solution/mode are described in 
draft-li-dynamic-flooding.
For example, there are a few of places from page 27 to 30, which define the 
behaviors specific
for the distributed solution/mode.


I strongly disagree. The fact that we say in centralized mode area leader 
recomputes and in distributed
mode all nodes recompute make no difference in behavior.


[HC] It seems better for some of them to be more general.

Best Regards,
Huaimo


thanks,
Peter

.



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

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Huaimo Chen]

Hi Peter,

>-Original Message-
>From: Peter Psenak [mailto:ppse...@cisco.com] 
>Sent: Thursday, February 14, 2019 2:30 AM
>To: Huaimo Chen ; Acee Lindem (acee) ; 
>Christian Hopps ; lsr@ietf.org
>Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
>Hi Huaimo,
>
>On 13/02/2019 22:50 , Huaimo Chen wrote:
>> Hi Peter,
>>
>> My explanations/answers are in line below with prefix [HC].
>>
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, February 6, 2019 4:58 AM
>> To: Huaimo Chen ; Acee Lindem (acee) 
>> ; Christian Hopps ; lsr@ietf.org
>> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>>
>> Hi Huaimo,
>>
>> On 03/02/2019 17:58 , Huaimo Chen wrote:
>>> Hi Acee,
>>>
>>>
>>>
>>> I agree with you on keeping the signaling for two modes. The 
>>> other parts for the distributed solution need to be removed.
>
>optimized flooding is not only about algorithm to calculate the flooding 
>topology and the way 
>it is distributed/computed. It is also about local rules to make sure the 
>flooding remains consistent. 
>These are _independent_ of centralized/distributed modes. And it make no sense 
>to specify 
>these rules in two drafts.

[HC] The rules/procedures/behaviors that are common to both the centralized and 
distributed 
solution/mode should be in one document. These common parts will be used by 
both solutions/modes. 
They are described in the two drafts and should be merged based on technical 
merits.  

In addition to the common parts, there are still some 
rules/procedures/behaviors that are 
different from one mode to another mode. For example, the rule/procedure for 
fault tolerance 
to failures used in the centralized solution/mode will be different from that 
used in the distributed 
solution/mode.  In the distributed solution/mode, there will be a set of 
rules/procedures/behaviors 
that are common to the algorithms for computing flooding topology and specific 
to the 
distributed solution/mode. For example, a specific procedure for scheduling an 
algorithm 
to compute a flooding topology will be used on every node for the distributed 
solution/mode.

>>
>> There are no "other" parts specific for the distributed solution.
>>
>> [HC] Some behaviors for the distributed solution/mode are described in 
>> draft-li-dynamic-flooding. 
>>For example, there are a few of places from page 27 to 30, which define the 
>>behaviors specific 
>>for the distributed solution/mode.
>
>I strongly disagree. The fact that we say in centralized mode area leader 
>recomputes and in distributed 
>mode all nodes recompute make no difference in behavior.

[HC] It seems better for some of them to be more general. 

Best Regards,
Huaimo

>thanks,
>Peter

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Goethals, Dirk (Nokia - BE/Antwerp)]

I think we are in sync, i.e.
without this draft there is no use-case for node T1 to send an
AS-scoped router info LSA without being ASBR.
Please correct if you know of an existing use-case.
Thx,
Dirk

On 2/18/2019 15:01, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 14:47 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
Hi Peter,
and you use these when you send a traffic to some of the prefixes that
T1 originates

If T1 is not ASBR,  and this draft is not implemented, how are the nodes
in the
other area's going to know that the prefixes belong to T1?

that is exactly what this draft is trying to address. Today there is no way to 
determine the originator of the prefix in the remote area. We are adding that 
functionality in this draft.

thanks,
Peter

Dirk


On 2/18/2019 14:34, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 14:27 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
support +1

1 question:

When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label
stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

yes, that is a possibility.


If so, should T1 be ASBR as to be able to send this AS-scoped LSA?

I would not think so.
DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.

if the T1 advertises some properties in it's AS-scoped LSA and you use
these when you send a traffic to some of the prefixes that T1
originates, then you don't really need to know where it is located,
you only care about its properties.





I guess it was needed before as to enforce  the ABR to create the T4
LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

not sure how you reached the above conclusion. Can you please clarify?
DG> Since the ABR is adding the originator, one can indirectly learn
that
the originator is also reachable via this ABR.

well, I don't think we want to replace the Type-4 LSA functionality
with the Prefix-Originator.

thanks,
Peter


thanks,
Peter




Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one


https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext



It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Peter Psenak]

On 18/02/2019 14:37 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

I agree with Peter.
For this to work, the ABR would need to add ALL originators, while I
had the impression that we only had 1 originator per prefix,
i.e. the originator which was found to be the closed to the ABR and
for which the ABR installed a route.


above is exactly right.

thanks,
Peter



Dirk


On 2/18/2019 14:15, Peter Psenak wrote:

Support as coauthor, although I never really agreed with the usage of
the prefix originator for topology construction as described  in
section 3 and 5. I would prefer that part to be removed.

thanks,
Peter


On 13/02/2019 14:25 , Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please send
your comments to this list before 12:00 AM UTC on Thursday, February
28^th , 2019.



All authors have responded to the IPR poll and there is one

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext


It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Peter Psenak]

Hi Dirk,

On 18/02/2019 14:47 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

Hi Peter,

and you use these when you send a traffic to some of the prefixes that
T1 originates


If T1 is not ASBR,  and this draft is not implemented, how are the nodes
in the
other area's going to know that the prefixes belong to T1?


that is exactly what this draft is trying to address. Today there is no 
way to determine the originator of the prefix in the remote area. We are 
adding that functionality in this draft.


thanks,
Peter


Dirk


On 2/18/2019 14:34, Peter Psenak wrote:

Hi Dirk,

On 18/02/2019 14:27 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:

Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

support +1

1 question:


When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label
stack
   at the ingress node S1 for the traffic destined to Lt1.


How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?


yes, that is a possibility.



If so, should T1 be ASBR as to be able to send this AS-scoped LSA?


I would not think so.

DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.


if the T1 advertises some properties in it's AS-scoped LSA and you use
these when you send a traffic to some of the prefixes that T1
originates, then you don't really need to know where it is located,
you only care about its properties.







I guess it was needed before as to enforce  the ABR to create the T4
LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.


not sure how you reached the above conclusion. Can you please clarify?

DG> Since the ABR is adding the originator, one can indirectly learn
that
the originator is also reachable via this ABR.


well, I don't think we want to replace the Type-4 LSA functionality
with the Prefix-Originator.

thanks,
Peter



thanks,
Peter





Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:


This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one


https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext



It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Goethals, Dirk (Nokia - BE/Antwerp)]

Hi Peter,
and you use these when you send a traffic to some of the prefixes that T1 
originates

If T1 is not ASBR,  and this draft is not implemented, how are the nodes in the
other area's going to know that the prefixes belong to T1?
Dirk


On 2/18/2019 14:34, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 14:27 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
support +1

1 question:

When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label
stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

yes, that is a possibility.


If so, should T1 be ASBR as to be able to send this AS-scoped LSA?

I would not think so.
DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.

if the T1 advertises some properties in it's AS-scoped LSA and you use these 
when you send a traffic to some of the prefixes that T1 originates, then you 
don't really need to know where it is located, you only care about its 
properties.





I guess it was needed before as to enforce  the ABR to create the T4
LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

not sure how you reached the above conclusion. Can you please clarify?
DG> Since the ABR is adding the originator, one can indirectly learn that
the originator is also reachable via this ABR.

well, I don't think we want to replace the Type-4 LSA functionality with the 
Prefix-Originator.

thanks,
Peter


thanks,
Peter




Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext


It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Goethals, Dirk (Nokia - BE/Antwerp)]

I agree with Peter.
For this to work, the ABR would need to add ALL originators, while I
had the impression that we only had 1 originator per prefix,
i.e. the originator which was found to be the closed to the ABR and
for which the ABR installed a route.

Dirk


On 2/18/2019 14:15, Peter Psenak wrote:
Support as coauthor, although I never really agreed with the usage of the 
prefix originator for topology construction as described  in section 3 and 5. I 
would prefer that part to be removed.

thanks,
Peter


On 13/02/2019 14:25 , Acee Lindem (acee) wrote:
This begins a two week adoption poll for the subject draft. Please send
your comments to this list before 12:00 AM UTC on Thursday, February
28^th , 2019.



All authors have responded to the IPR poll and there is one

 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext

It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Peter Psenak]

Hi Dirk,

On 18/02/2019 14:27 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:

Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

support +1

1 question:


When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label
stack
   at the ingress node S1 for the traffic destined to Lt1.


How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?


yes, that is a possibility.



If so, should T1 be ASBR as to be able to send this AS-scoped LSA?


I would not think so.

DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.


if the T1 advertises some properties in it's AS-scoped LSA and you use 
these when you send a traffic to some of the prefixes that T1 
originates, then you don't really need to know where it is located, you 
only care about its properties.








I guess it was needed before as to enforce  the ABR to create the T4
LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.


not sure how you reached the above conclusion. Can you please clarify?

DG> Since the ABR is adding the originator, one can indirectly learn that
the originator is also reachable via this ABR.


well, I don't think we want to replace the Type-4 LSA functionality with 
the Prefix-Originator.


thanks,
Peter



thanks,
Peter





Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:


This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext


It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Goethals, Dirk (Nokia - BE/Antwerp)]

Hi Peter,
See inline DG>.
Dirk


On 2/18/2019 14:18, Peter Psenak wrote:
Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:
support +1

1 question:

When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

yes, that is a possibility.


If so, should T1 be ASBR as to be able to send this AS-scoped LSA?

I would not think so.
DG> What's the use of an AS-scoped LSA, if the receiver has no way
to identify/locate the advertising router? Making T1 an ASBR will
enforce the ABR to create a T4 LSA.


I guess it was needed before as to enforce  the ABR to create the T4 LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

not sure how you reached the above conclusion. Can you please clarify?
DG> Since the ABR is adding the originator, one can indirectly learn that
the originator is also reachable via this ABR.

thanks,
Peter




Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one

 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext

It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Les Ginsberg (ginsberg)]

To the extent that the draft defines functionality equivalent to that defined 
in IS-IS RFC 7794 – specifically a means to advertise the source router-id of a 
given advertisement – it defines a necessary and useful extension to the OSPF 
protocol – and I support that work.

However, in its current form the draft discusses use of this mechanism for 
inter-area topology discovery. This idea is seriously flawed – as has been 
discussed extensively on the WG list.
The draft also discusses uses cases related to ERLD, the direction for which is 
very much uncertain at this time.

I therefore feel that the current content of the draft is not what I would 
expect to see approved by the WG as an RFC and therefore have significant 
reservations about moving forward with the existing content.

I do want to see a draft addressing the source router-id advertisement gap move 
forward – and if this draft is reduced to focus on that then I can 
enthusiastically support adoption – but in its current form I cannot indicate 
support.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, February 13, 2019 5:26 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Peter Psenak]

Hi Dirk,

On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote:

support +1

1 question:


When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label stack
   at the ingress node S1 for the traffic destined to Lt1.


How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?


yes, that is a possibility.



If so, should T1 be ASBR as to be able to send this AS-scoped LSA?


I would not think so.



I guess it was needed before as to enforce  the ABR to create the T4 LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.


not sure how you reached the above conclusion. Can you please clarify?

thanks,
Peter





Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:


This begins a two week adoption poll for the subject draft. Please
send your comments to this list before 12:00 AM UTC on Thursday,
February 28^th , 2019.



All authors have responded to the IPR poll and there is one

 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext

It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Peter Psenak]

Support as coauthor, although I never really agreed with the usage of 
the prefix originator for topology construction as described  in section 
3 and 5. I would prefer that part to be removed.


thanks,
Peter


On 13/02/2019 14:25 , Acee Lindem (acee) wrote:

This begins a two week adoption poll for the subject draft. Please send
your comments to this list before 12:00 AM UTC on Thursday, February
28^th , 2019.



All authors have responded to the IPR poll and there is one

 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext

It is listed multiple times but references the same CN201810650141.



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 Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

+1 for support.
Seems as a useful extension to have available in OSPF toolbox.

G/

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, February 13, 2019 20:26
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Goethals, Dirk (Nokia - BE/Antwerp)]

support +1

1 question:


When S1 in another area receives such LSA, it then can learn that
   prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD
   value according to its necessity, and construct the right label stack
   at the ingress node S1 for the traffic destined to Lt1.

How is S1 going to know the "ELC, ERLD, or MSD" of  node T1?
I guess, T1 will need to send an AS-scoped router info LSA?

If so, should T1 be ASBR as to be able to send this AS-scoped LSA?
I guess it was needed before as to enforce  the ABR to create the T4 LSAs,
so that others can learn which ABR to use to reach T4, but I guess
it's not needed anymore when this draft is implemented.

Regards,
Dirk


On 2/13/2019 14:25, Acee Lindem (acee) wrote:
This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one 

  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

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