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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Feb 2019 13:25:39 +0000

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&id=draft-wang-lsr-ospf-prefix-originator-ext>  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 18 Feb 2019 08:31:36 +0000

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.

Thanks,
Acee

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 18 Feb 2019 08:42:12 +0000

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

G/

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

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

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Mon, 18 Feb 2019 14:15:04 +0100

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&id=draft-wang-lsr-ospf-prefix-originator-ext> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext
>
> [email-masked]

---

From: Peter Psenak <[email-masked]>
Date: Mon, 18 Feb 2019 14:18:59 +0100

Hi Dirk,

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

> it's not needed anymore when this draft is implemented.

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

thanks,
Peter

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 18 Feb 2019 13:21:58 +0000

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 <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, February 13, 2019 5:26 AM
To: [email-masked]
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Thanks,
Acee

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 18 Feb 2019 13:27:13 +0000

Hi Peter,
See inline DG>.
Dirk

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

1 question:

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.

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

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

Thanks,

Acee

---

From: Peter Psenak <[email-masked]>
Date: Mon, 18 Feb 2019 14:34:03 +0100

Hi Dirk,

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

> 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

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

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 18 Feb 2019 13:37:19 +0000

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

Thanks,

Acee

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 18 Feb 2019 13:47:33 +0000

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,

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.

I would not think so.

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.

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

thanks,
Peter

thanks,
Peter

Regards,
Dirk

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

Thanks,

Acee

---

From: Peter Psenak <[email-masked]>
Date: Mon, 18 Feb 2019 15:01:35 +0100

Hi Dirk,

> 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

>> originates, then you don't really need to know where it is located,
>> you only care about its properties.
>>
>>
>>
>>>>
>>>>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 18 Feb 2019 15:02:20 +0100

> for which the ABR installed a route.

above is exactly right.

thanks,
Peter

>> the prefix originator for topology construction as described  in
>> section 3 and 5. I would prefer that part to be removed.
>>
>> thanks,
>> Peter
>>
>>

---

From: "Goethals, Dirk (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 18 Feb 2019 14:07:49 +0000

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

1 question:

I would not think so.

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

Thanks,

Acee

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Mon, 18 Feb 2019 20:19:26 +0000

I support.

- Naiming

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

Thanks,
Acee

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 19 Feb 2019 01:33:41 +0000

Support.

Thanks,
Shunwan

Thanks,
Acee

---

From: Lizhenbin <[email-masked]>
Date: Tue, 19 Feb 2019 01:34:47 +0000

Yes/support.

Best Regards,
Zhenbin (Robin)

Thanks,
Acee

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 19 Feb 2019 10:01:48 +0800

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&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-----邮件原件-----
发件人: Peter Psenak [mailto:[email-masked]] 
发送时间: 2019年2月18日 22:02
收件人: Goethals, Dirk (Nokia - BE/Antwerp); Acee Lindem (acee);
[email-masked]
主题: 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:
> 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

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 19 Feb 2019 10:40:07 +0800

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

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

   Les

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

Thanks,

Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 19 Feb 2019 04:43:42 +0000

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 <[email-masked]> On Behalf Of Aijun Wang
Sent: Monday, February 18, 2019 6:40 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Hi, Les:

Best Regards.

Aijun Wang

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

   Les

Thanks,
Acee

---

From: <[email-masked]>
Date: Tue, 19 Feb 2019 14:14:50 +0800 (CST)

Support the adoption.

Thanks,

Sandy

原始邮件

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

 

 

Thanks,

Acee

---

From: Peter Psenak <[email-masked]>
Date: Tue, 19 Feb 2019 08:25:41 +0100

Aijun,

> twice for this prefix. Doing so does not the contradict with actual physical

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.

> 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

> .

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 19 Feb 2019 15:17:48 +0000

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)" <[email-masked]>
Date: Monday, February 18, 2019 at 11:43 PM
To: Aijun Wang <[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Aijun –

   Les

Hi, Les:

Best Regards.

Aijun Wang

   Les

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 19 Feb 2019 15:20:26 +0000

Also, speaking as WG member:

I support adoption.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Acee Lindem <[email-masked]>
Date: Tuesday, February 19, 2019 at 10:19 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]>, Aijun Wang <[email-masked]>, "[email-masked]" <[email-masked]>
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,

Thanks,
Acee

Aijun –

   Les

Hi, Les:

Best Regards.

Aijun Wang

   Les

Thanks,
Acee

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 20 Feb 2019 14:54:40 +0000

Yes, I support the adoption.

Best regards,
Jie

发件人: Lsr [mailto:[email-masked]] 代表 Acee Lindem (acee)
发送时间: 2019年2月13日 21:26
收件人: [email-masked]
主题: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Thanks,
Acee

---

From: John E Drake <[email-masked]>
Date: Thu, 21 Feb 2019 15:41:41 +0000

Hi,

I agree with Les.  I think the draft should be recast to indicate that it is providing OSPF parity with RFC 7794.
Can’t topology discovery be done using RFC 7770?

Yours Irrespectively,

John

From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, February 18, 2019 8:22 AM
To: Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

   Les

All authors have responded to the IPR poll and there is one  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dwang-2Dlsr-2Dospf-2Dprefix-2Doriginator-2Dext&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=yONjTFGQ4o2Kn4-71l1WNkaIh-ck54I626wsy_xfbfM&s=QSvTQLLyqhq6OcKx4iGyD3Xp7jvD_Hc_t03Lvct3CJE&e=>
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

---

From: Aijun Wang <[email-masked]>
Date: Fri, 22 Feb 2019 07:26:54 +0800

Hi, John:

Thanks for your review and comments.
The use cases and original thought in this draft are different from that  described in RFC7794. We have pointed out that RFC7794 has the similar extension for ISIS and indicated that the extension for ISIS can also be used in the use cases described in our draft. What’ other content do you think it is needed further?
RFC 7770  solves mainly the advertising of router’s capabilities, it shouldn’t be used for transmitting the information about the prefixes.

Best Regards.

Aijun Wang
China Telecom

> On Feb 21, 2019, at 23:41, John E Drake <jdrake=[email-masked]> wrote:
> 
> Hi,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 22 Feb 2019 05:56:32 +0000

Aijun –

Controllers already have a reliable way to learn topology information for all areas.
There is therefore no need for the topology discovery solution you propose – and all the more so because your proposal does not work in all cases and you have no definition of how a controller could tell when the information can be trusted and when it can’t.

The only thing which is needed is to define a way to identify the source router-id of prefixes which are leaked between areas – which is what I have asked you to limit the draft to do.

The mention of ELC/ERLD/MSD in your draft is spurious since you actually haven’t defined any way to advertise that information between areas (nor do I want you to do so).  It should be removed.

I say again, this draft in its current form is not ready to be adopted.

   Les

From: Aijun Wang <[email-masked]>
Sent: Thursday, February 21, 2019 3:27 PM
To: John E Drake <jdrake=[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Hi, John:

Best Regards.

Aijun Wang
China Telecom

On Feb 21, 2019, at 23:41, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:
Hi,

Yours Irrespectively,

John

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, February 18, 2019 8:22 AM
To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

   Les

Thanks,
Acee

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 21 Feb 2019 22:42:59 -0800

I read it during some mildly boring phone conference here ;-) I do
(unsuprisingly) tend to agree with Mr. Ginsberg here. Putting originator on
prefix, well, ok, I understand how people got there instead of having a
clean router LSA with its loopback hanging of it (which would be IMO the
right abstraction but alas, IP decided originally that interfaces have
addresses and routers, well, don't. Overall not the best architecture
remedied by loopback hacks since forever then. I digress ...). So putting
router-id on type-3 loopback serves its purpose of "how do I get to this
node across topology abstractions [areas]". Allows central entities
(controllers and such) to get to every node in the topology without
violating abstractions (too much ;-). Cleaner solutions would be thinkable
but more complex obviously. But coming back to this draft, alas, trying to
build the whole topology distribution tails-up, i.e. redistribute topology
view behind prefixes which are really leafs-of-topology strikes me just
another confused slippery slope just like re-encoding one protocol's native
formats into another protocol :-P ... And if the authors suffer from mild
bout of over-creativity I suggest to split that part into an informational
draft ...

--- tony

On Thu, Feb 21, 2019 at 9:56 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> There is therefore no need for the topology discovery solution you propose
> – and all the more so because your proposal does not work in all cases and
> you have no definition of how a controller could tell when the information
> can be trusted and when it can’t.
>
>
>
> The only thing which is needed is to define a way to identify the source
> router-id of prefixes which are leaked between areas – which is what I have
> asked you to limit the draft to do.
>
>
>
> The mention of ELC/ERLD/MSD in your draft is spurious since you actually
> haven’t defined any way to advertise that information between areas (nor do
> I want you to do so).  It should be removed.
>
>
>
> *From:* Aijun Wang <[email-masked]>
> *Sent:* Thursday, February 21, 2019 3:27 PM
> *To:* John E Drake <jdrake=[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for
> Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>
>
>
> Hi, John:
>
>
>
> The use cases and original thought in this draft are different from that
>  described in RFC7794. We have pointed out that RFC7794 has the similar
> extension for ISIS and indicated that the extension for ISIS can also be
> used in the use cases described in our draft. What’ other content do you
> think it is needed further?
>
> RFC 7770  solves mainly the advertising of router’s capabilities, it
> shouldn’t be used for transmitting the information about the prefixes.
>
>
>
> Best Regards.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
> On Feb 21, 2019, at 23:41, John E Drake <
> jdrake=[email-masked]> wrote:
>
> Hi,
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Les Ginsberg (ginsberg)
> *Sent:* Monday, February 18, 2019 8:22 AM
> *To:* Acee Lindem (acee) <[email-masked]>; [email-masked]
> *Subject:* 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 <[email-masked]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Wednesday, February 13, 2019 5:26 AM
> *To:* [email-masked]
> *Subject:* [Lsr] Working Group Adoption Poll for "OSPF Extension for
> Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>
>
>
> your comments to this list before 12:00 AM UTC on Thursday, February 28th,
> 2019.
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dwang-2Dlsr-2Dospf-2Dprefix-2Doriginator-2Dext&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=yONjTFGQ4o2Kn4-71l1WNkaIh-ck54I626wsy_xfbfM&s=QSvTQLLyqhq6OcKx4iGyD3Xp7jvD_Hc_t03Lvct3CJE&e=>
>

---

From: Aijun Wang <[email-masked]>
Date: Fri, 22 Feb 2019 14:47:59 +0800

Hi, Les:

The method to retrieve the topology information for inter-area scenario that described in the current draft is more easily deployment and less requirements for the connections between the controller and underlying routers.
The ELC, ERLD and MSD are capabilities of the routers and can be flooded via the mechanisms described in RFC7770. If there is no draft described the details process, we can cooperate to write one.

Acee has pointed out that these OSPF areas are often under one administrative scope, and they know the address allocation philosophy of their underlying networks, then can assure the reliability of the retrieved topology.

Anyway, the aim of this draft is to let reader know how to use the introduced extension, not merely the extension itself. 

Best Regards 

Aijun Wang
China Telecom

> On Feb 22, 2019, at 13:56, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Aijun –
>

---

From: Aijun Wang <[email-masked]>
Date: Fri, 22 Feb 2019 15:20:34 +0800

Hi, Tony:
Not got well all your comments :(
Wish the explanation in previous mail to Les can change your impression to this draft a bit.

Best Regards.

Aijun Wang
China Telecom

> On Feb 22, 2019, at 14:42, Tony Przygienda <[email-masked]> wrote:
> 
> I read it during some mildly boring phone conference here ;-) I do (unsuprisingly) tend to agree with Mr. Ginsberg here. Putting originator on prefix, well, ok, I understand how people got there instead of having a clean router LSA with its loopback hanging of it (which would be IMO the right abstraction but alas, IP decided originally that interfaces have addresses and routers, well, don't. Overall not the best architecture remedied by loopback hacks since forever then. I digress ...). So putting router-id on type-3 loopback serves its purpose of "how do I get to this node across topology abstractions [areas]". Allows central entities (controllers and such) to get to every node in the topology without violating abstractions (too much ;-). Cleaner solutions would be thinkable but more complex obviously. But coming back to this draft, alas, trying to build the whole topology distribution tails-up, i.e. redistribute topology view behind prefixes which are really leafs-of-topology strikes me just another confused slippery slope just like re-encoding one protocol's native formats into another protocol :-P ... And if the authors suffer from mild bout of over-creativity I suggest to split that part into an informational draft ... 
> 
> --- tony 
> 
>> On Thu, Feb 21, 2019 at 9:56 PM Les Ginsberg (ginsberg) <[email-masked]> wrote:
>> Aijun –
>> 
>>  
>>