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

2019-02-20 Thread Dongjie (Jimmy) 
Yes, I support the adoption.

Best regards,
Jie

发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2019年2月13日 21:26
收件人: lsr@ietf.org
主题: [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

2019-02-19 Thread Acee Lindem (acee) 
Also, speaking as WG member:

I support adoption.

Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Tuesday, February 19, 2019 at 10:19 AM
To: "Les Ginsberg (ginsberg)" , Aijun Wang 
, "lsr@ietf.org" 
Subject: Re: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for 
Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Speaking as WG member:

Hi Les, Aijun, et al,

After much discussion, we made the discovery all non-normative. If this is not 
the case, we’ll certainly fix this prior to publication. Given that the use 
case is a single OSPF routing domain that is under a single administrative 
control, there is no reason that the constraints (nothing but numbered P2P 
links) could not be imposed as deployment policies.

The LSR working is currently “flooded” with contention and I don’t see that 
this is even worth arguing about.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Monday, February 18, 2019 at 11:43 PM
To: Aijun Wang , Acee Lindem , 
"lsr@ietf.org" 
Subject: RE: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for 
Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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<mailto: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 O

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

2019-02-19 Thread Acee Lindem (acee) 
Speaking as WG member:

Hi Les, Aijun, et al,

After much discussion, we made the discovery all non-normative. If this is not 
the case, we’ll certainly fix this prior to publication. Given that the use 
case is a single OSPF routing domain that is under a single administrative 
control, there is no reason that the constraints (nothing but numbered P2P 
links) could not be imposed as deployment policies.

The LSR working is currently “flooded” with contention and I don’t see that 
this is even worth arguing about.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Monday, February 18, 2019 at 11:43 PM
To: Aijun Wang , Acee Lindem , 
"lsr@ietf.org" 
Subject: RE: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for 
Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

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

2019-02-18 Thread 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 Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-18 Thread 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<mailto: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<mailto: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

2019-02-18 Thread 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

2019-02-18 Thread 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