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

2019-02-28 Thread Acee Lindem (acee) 
The adoption call has completed and there is sufficient support for adoption. 
There was some skepticism regarding the limitations on the non-normative 
topology discovery. However, I believe these can be worked out.

Please republish the draft as draft-ietf-lsr-ospf-prefix-originator-00.txt.

Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Wednesday, February 13, 2019 at 8:25 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&id=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-21 Thread Aijun Wang 
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  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)  
>> wrote:
>> 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  
>> Sent: Thursday, February 21, 2019 3:27 PM
>> To: John E Drake 
>> Cc: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
>> ; lsr@ietf.org
>> Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for 
>> Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>> 
>>  
>> 
>> 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 
>>  wrote:
>> 
>> 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  On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Monday, February 18, 2019 8:22 AM
>> To: Acee Lindem (acee) ; lsr@ietf.org
>> 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

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

2019-02-21 Thread Aijun Wang 
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)  wrote:
> 
> 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  
> Sent: Thursday, February 21, 2019 3:27 PM
> To: John E Drake 
> Cc: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
> ; lsr@ietf.org
> Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
> Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>  
> 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 
>  wrote:
> 
> 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  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, February 18, 2019 8:22 AM
> To: Acee Lindem (acee) ; lsr@ietf.org
> 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  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

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

2019-02-21 Thread Tony Przygienda 
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) 
wrote:

> 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 
> *Sent:* Thursday, February 21, 2019 3:27 PM
> *To:* John E Drake 
> *Cc:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>; lsr@ietf.org
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for
> Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>
>
>
> 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=40juniper@dmarc.ietf.org> wrote:
>
> 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  *On Behalf Of *Les Ginsberg (ginsberg)
> *Sent:* Monday, February 18, 2019 8:22 AM
> *To:* Acee Lindem (acee) ; lsr@ietf.org
> *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

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

2019-02-21 Thread Les Ginsberg (ginsberg) 
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 
Sent: Thursday, February 21, 2019 3:27 PM
To: John E Drake 
Cc: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:
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 mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Monday, February 18, 2019 8:22 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
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 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&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

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

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

2019-02-21 Thread Aijun Wang 
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 
>  wrote:
> 
> 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  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Monday, February 18, 2019 8:22 AM
> To: Acee Lindem (acee) ; lsr@ietf.org
> 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  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&id=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

2019-02-21 Thread John E Drake 
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  On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, February 18, 2019 8:22 AM
To: Acee Lindem (acee) ; lsr@ietf.org
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 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&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

___
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 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<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&id=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-18 Thread 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<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&id=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-18 Thread 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<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&id=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<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

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

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

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

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

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

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

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

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

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

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

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

2019-02-18 Thread 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&id=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-18 Thread 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&id=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] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-13 Thread Acee Lindem (acee) 
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
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