Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

Aijun -

The point I am making is very focused.

This draft is defining a protocol extension. As such it is necessary that this 
be Standards track as adhering to the normative statements in the draft are 
necessary for interoperability.

What is discussed in the Appendix is a use case. It is not normative and there 
are strong opinions on both sides as to whether this is an appropriate use case 
or not.
In the context of this draft, I have no interest in trying to resolve our 
difference of opinion on this use case. I simply want the protocol extension to 
move forward so that we have another tool available.

If you want to write a draft on the use case discussed in the Appendix please 
feel free to do so. That draft may very well not be normative - Informational 
or BCP may be more appropriate - because it will be discussing a deployment 
scenario and a proposal to use defined protocol extensions as one way to solve 
problems in that deployment scenario. Such a draft might also be more 
appropriate in another WG (e.g., TEAS). The merits of using prefix 
advertisements to build a topology could then be discussed on its own. 

Please do not try to avoid having a full discussion of the merits of using 
prefix advertisements to derive topology by adding it to a draft that is (and 
should be) focused on simple protocol extensions.

Thanx.

   Les


> -Original Message-
> From: Aijun Wang 
> Sent: Thursday, October 15, 2020 6:51 PM
> To: 'Jeff Tantsura' ; 'John E Drake'
> 
> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les Ginsberg
> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; draft-ietf-
> lsr-ospf-prefix-origina...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les, John and Jeff:
> 
> Let's reply you all together.
> In my POV, The standard document should not define solely the protocol
> extension, but their usages in the network deployment. As I known, almost
> all the IETF documents following this style.
> And, before adopting one work, we have often intense discussion for what's
> their usages.
> Such discussion in the mail list and statements in the document can certainly
> assist the reader/user of the document get the essence of the standard, and
> follow them unambiguously.
> 
> Regarding the contents of appendices, as stated in the section, "The
> Appendix A heuristic to rebuild the topology can normally be used if all links
> are numbered." I think this can apply almost most of the operator's network,
> and facilitate the inter-area TE path calculation for central controller, or 
> even
> for the head-end router that located in one area that different from the tail-
> end router.
> 
> Keeping the contents of appendices does not have the negative impact of
> the protocol extension, it is just one reference for the usage of this
> extension.
> One can select not refer to it, if their networks are deployed with large
> amount of unnumbered links. But for others, the heuristic applies.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff
> Tantsura
> Sent: Friday, October 16, 2020 5:28 AM
> To: John E Drake 
> Cc: Christian Hopps ; lsr-cha...@ietf.org; Les Ginsberg
> (ginsberg) ; lsr@ietf.org; lsr-
> a...@ietf.org; draft-ietf-lsr-ospf-prefix-origina...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> +1
> 
> Regards,
> Jeff
> 
> > On Oct 15, 2020, at 11:33, John E Drake
>  wrote:
> >
> > Hi,
> >
> > I agree with Les.  This is a simple protocol extension for a specific 
> > purpose
> and there is no reason to include speculation about its use for other
> purposes, particularly when it is inherently not suited for them.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> >> Sent: Thursday, October 15, 2020 12:33 PM
> >> To: Christian Hopps ; lsr@ietf.org
> >> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org;
> >> draft-ietf-lsr-ospf-prefix- origina...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> I support moving this document forward.
> >> Similar functionality in IS-IS has proved useful.
> >>
> >> I would however like to repeat comments I made earlier in the review
> >> of this document.
> >> The content of the Appendices should be removed.
> >> The Appendices define and discuss deriving topology information from
> >> prefix advertisements - which is flawed and should not be done.
> >> Perhaps more relevant, the purpose of the document is to define
> >> protocol extensions supporting advertisement of the originators of a
> >> prefix advertisement. There is no need to discuss how this mechanism
> >> might be used to build topology information.
> >> This document should confine 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your review and feedback. Please check inline below.

From: Gyan Mishra 
Sent: 16 October 2020 10:11
To: Aijun Wang 
Cc: Christian Hopps ; Jeff Tantsura 
; John E Drake ; 
Les Ginsberg (ginsberg) ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr@ietf.org; lsr-...@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

I support advancement of the draft.

This draft follows along the lines of ISIS RFC 7794 to provide an extension to 
identify the prefix originator attribute using an originating router TLV and a 
reachable prefix.  A node in ospf is represented by a router-id which 
technically can be a random 4 octet prefix that does not have to be reachable 
entry in the IGP RIB.

The reachability prefix is important in cases where the originator router-id is 
not  in the RIB or in traffic engineering inter as path instantiation use case 
where the router-id originator node is advertised, however since the TEDs 
database link attributes are not known inter-as,having the reachability address 
is important as defined in the draft.  This feature can also be used  
identifying the prefix originator in a normal user case other then the traffic 
engineering scenario such as for troubleshooting which is common to view all 
the prefixes advertised by a node by Prefix type.

There maybe cases where you need to create  a database filter or policy and if 
you can use this feature as a means of controlling prefix advertisements based 
on source node that can be powerful and could have ubiquitous use cases.

With regards to the appendix it does appear to be pertinent, as the use case 
appears to be the primary focal point and reason for the draft by the authors.  
I don’t think that having the appendix  precluding other use cases by any means.
[KT] The Introduction section of the draft does touch upon some of the primary 
use-cases that authors believe have more wide-spread applicability. You have 
also alluded to some of them and then you have also brought out some newer 
use-cases/applications of the extensions in this draft. There were other 
use-cases in previous versions like ELC which later went away based on how we 
addressed that in draft-ietf-ospf/isis-mpls-elc documents. I am sure there will 
be newer use-cases. The focus of the draft is primary to capture the protocol 
extensions since that is what we work on in LSR. The scope of the use-cases may 
be beyond LSR and in other areas (e.g. TEAS perhaps for the one in the appendix 
?). Regarding the use-case in the appendix, it would be fair to say that it was 
primary focal point for some of the authors.

I will leave it to the WG consensus on what content we should be sending to the 
IESG.

Thanks,
Ketan

Kind Regards

Gyan

On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Les, John and Jeff:

Let's reply you all together.
In my POV, The standard document should not define solely the protocol 
extension, but their usages in the network deployment. As I known, almost all 
the IETF documents following this style.
And, before adopting one work, we have often intense discussion for what's 
their usages.
Such discussion in the mail list and statements in the document can certainly 
assist the reader/user of the document get the essence of the standard, and 
follow them unambiguously.

Regarding the contents of appendices, as stated in the section, "The Appendix A 
heuristic to rebuild the topology can normally be used if all links are 
numbered." I think this can apply almost most of the operator's network, and 
facilitate the inter-area TE path calculation for central controller, or even 
for the head-end router that located in one area that different from the 
tail-end router.

Keeping the contents of appendices does not have the negative impact of the 
protocol extension, it is just one reference for the usage of this extension.
One can select not refer to it, if their networks are deployed with large 
amount of unnumbered links. But for others, the heuristic applies.

Best Regards

Aijun Wang
China Telecom



-Original Message-
From: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] On Behalf Of Jeff 
Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake 
mailto:40juniper@dmarc.ietf.org>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org; Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; lsr-...@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake 
> mailto:40juniper@dmarc.ietf.org>> 
> wrote:
>
> Hi,
>
> I agree with Les.  This is a simple protocol 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Gyan Mishra]

I support advancement of the draft.

This draft follows along the lines of ISIS RFC 7794 to provide an extension
to identify the prefix originator attribute using an originating router TLV
and a reachable prefix.  A node in ospf is represented by a router-id which
technically can be a random 4 octet prefix that does not have to be
reachable entry in the IGP RIB.

The reachability prefix is important in cases where the originator
router-id is not  in the RIB or in traffic engineering inter as path
instantiation use case where the router-id originator node is advertised,
however since the TEDs database link attributes are not known
inter-as,having the reachability address is important as defined in the
draft.  This feature can also be used  identifying the prefix originator in
a normal user case other then the traffic engineering scenario such as for
troubleshooting which is common to view all the prefixes advertised by a
node by Prefix type.

There maybe cases where you need to create  a database filter or policy and
if you can use this feature as a means of controlling prefix advertisements
based on source node that can be powerful and could have ubiquitous use
cases.

With regards to the appendix it does appear to be pertinent, as the use
case appears to be the primary focal point and reason for the draft by the
authors.  I don’t think that having the appendix  precluding other use
cases by any means.


Kind Regards

Gyan

On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang 
wrote:

> Hi, Les, John and Jeff:
>
> Let's reply you all together.
> In my POV, The standard document should not define solely the protocol
> extension, but their usages in the network deployment. As I known, almost
> all the IETF documents following this style.
> And, before adopting one work, we have often intense discussion for what's
> their usages.
> Such discussion in the mail list and statements in the document can
> certainly assist the reader/user of the document get the essence of the
> standard, and follow them unambiguously.
>
> Regarding the contents of appendices, as stated in the section, "The
> Appendix A heuristic to rebuild the topology can normally be used if all
> links are numbered." I think this can apply almost most of the operator's
> network, and facilitate the inter-area TE path calculation for central
> controller, or even for the head-end router that located in one area that
> different from the tail-end router.
>
> Keeping the contents of appendices does not have the negative impact of
> the protocol extension, it is just one reference for the usage of this
> extension.
> One can select not refer to it, if their networks are deployed with large
> amount of unnumbered links. But for others, the heuristic applies.
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
>
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> Jeff Tantsura
> Sent: Friday, October 16, 2020 5:28 AM
> To: John E Drake 
> Cc: Christian Hopps ; lsr-cha...@ietf.org; Les
> Ginsberg (ginsberg) ; lsr@ietf.org;
> lsr-...@ietf.org; draft-ietf-lsr-ospf-prefix-origina...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>
> +1
>
> Regards,
> Jeff
>
> > On Oct 15, 2020, at 11:33, John E Drake  40juniper@dmarc.ietf.org> wrote:
> >
> > Hi,
> >
> > I agree with Les.  This is a simple protocol extension for a specific
> purpose and there is no reason to include speculation about its use for
> other purposes, particularly when it is inherently not suited for them.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> >> -Original Message-
> >> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> >> Sent: Thursday, October 15, 2020 12:33 PM
> >> To: Christian Hopps ; lsr@ietf.org
> >> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org;
> >> draft-ietf-lsr-ospf-prefix- origina...@ietf.org
> >> Subject: Re: [Lsr] WG Last Call
> >> draft-ietf-lsr-ospf-prefix-originator-06
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> I support moving this document forward.
> >> Similar functionality in IS-IS has proved useful.
> >>
> >> I would however like to repeat comments I made earlier in the review
> >> of this document.
> >> The content of the Appendices should be removed.
> >> The Appendices define and discuss deriving topology information from
> >> prefix advertisements - which is flawed and should not be done.
> >> Perhaps more relevant, the purpose of the document is to define
> >> protocol extensions supporting advertisement of the originators of a
> >> prefix advertisement. There is no need to discuss how this mechanism
> >> might be used to build topology information.
> >> This document should confine itself to defining the protocol
> >> extensions - similar the RFC 7794.
> >>
> >> If the authors do not agree to do this, I would encourage this point
> >> to be discussed during IESG review.
> >>
> >>   Les
> >>
> >>> 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi, Les, John and Jeff:

Let's reply you all together.
In my POV, The standard document should not define solely the protocol 
extension, but their usages in the network deployment. As I known, almost all 
the IETF documents following this style. 
And, before adopting one work, we have often intense discussion for what's 
their usages. 
Such discussion in the mail list and statements in the document can certainly 
assist the reader/user of the document get the essence of the standard, and 
follow them unambiguously.

Regarding the contents of appendices, as stated in the section, "The Appendix A 
heuristic to rebuild the topology can normally be used if all links are 
numbered." I think this can apply almost most of the operator's network, and 
facilitate the inter-area TE path calculation for central controller, or even 
for the head-end router that located in one area that different from the 
tail-end router.

Keeping the contents of appendices does not have the negative impact of the 
protocol extension, it is just one reference for the usage of this extension. 
One can select not refer to it, if their networks are deployed with large 
amount of unnumbered links. But for others, the heuristic applies.

Best Regards

Aijun Wang
China Telecom



-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff 
Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake 
Cc: Christian Hopps ; lsr-cha...@ietf.org; Les Ginsberg 
(ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake  
> wrote:
> 
> Hi,
> 
> I agree with Les.  This is a simple protocol extension for a specific purpose 
> and there is no reason to include speculation about its use for other 
> purposes, particularly when it is inherently not suited for them.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Thursday, October 15, 2020 12:33 PM
>> To: Christian Hopps ; lsr@ietf.org
>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; 
>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org
>> Subject: Re: [Lsr] WG Last Call 
>> draft-ietf-lsr-ospf-prefix-originator-06
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> I support moving this document forward.
>> Similar functionality in IS-IS has proved useful.
>> 
>> I would however like to repeat comments I made earlier in the review 
>> of this document.
>> The content of the Appendices should be removed.
>> The Appendices define and discuss deriving topology information from 
>> prefix advertisements - which is flawed and should not be done.
>> Perhaps more relevant, the purpose of the document is to define  
>> protocol extensions supporting advertisement of the originators of a 
>> prefix advertisement. There is no need to discuss how this mechanism 
>> might be used to build topology information.
>> This document should confine itself to defining the protocol 
>> extensions - similar the RFC 7794.
>> 
>> If the authors do not agree to do this, I would encourage this point 
>> to be discussed during IESG review.
>> 
>>   Les
>> 
>>> -Original Message-
>>> From: Lsr  On Behalf Of Christian Hopps
>>> Sent: Wednesday, October 14, 2020 11:15 PM
>>> To: lsr@ietf.org
>>> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org;
>>> lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps 
>>> 
>>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
>>> 
>>> 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
>>> et 
>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq
>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>> 
>>> The following IPR has been filed
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
>>> !NEt6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
>>> 5KtUHQ$
>>> 
>>> Authors,
>>> 
>>>  Please indicate to the list, your knowledge of any other IPR 
>>> related to this work.
>>> 
>>> Thanks,
>>> Chris.
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt
>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
>> Lc$
> 
> ___
> 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] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Aijun Wang]

Hi, Chris:

I support the forwarding of this document and as author, I am not aware of
other IPR except the disclosed one. 

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
Christian Hopps
Sent: Thursday, October 15, 2020 2:15 PM
To: lsr@ietf.org
Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org;
lsr-...@ietf.org; Christian Hopps 
Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related to
this work.

Thanks,
Chris.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Jeff Tantsura]

+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake  
> wrote:
> 
> Hi,
> 
> I agree with Les.  This is a simple protocol extension for a specific purpose 
> and there is no reason to include speculation about its use for other 
> purposes, particularly when it is inherently not suited for them.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Thursday, October 15, 2020 12:33 PM
>> To: Christian Hopps ; lsr@ietf.org
>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-ospf-prefix-
>> origina...@ietf.org
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> I support moving this document forward.
>> Similar functionality in IS-IS has proved useful.
>> 
>> I would however like to repeat comments I made earlier in the review of this
>> document.
>> The content of the Appendices should be removed.
>> The Appendices define and discuss deriving topology information from prefix
>> advertisements - which is flawed and should not be done.
>> Perhaps more relevant, the purpose of the document is to define  protocol
>> extensions supporting advertisement of the originators of a prefix
>> advertisement. There is no need to discuss how this mechanism might be used 
>> to
>> build topology information.
>> This document should confine itself to defining the protocol extensions - 
>> similar
>> the RFC 7794.
>> 
>> If the authors do not agree to do this, I would encourage this point to be
>> discussed during IESG review.
>> 
>>   Les
>> 
>>> -Original Message-
>>> From: Lsr  On Behalf Of Christian Hopps
>>> Sent: Wednesday, October 14, 2020 11:15 PM
>>> To: lsr@ietf.org
>>> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org;
>>> lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps
>>> 
>>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
>>> 
>>> 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLqhK
>>> 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>> 
>>> The following IPR has been filed
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
>>> !NEt6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
>>> 5KtUHQ$
>>> 
>>> Authors,
>>> 
>>>  Please indicate to the list, your knowledge of any other IPR related
>>> to this work.
>>> 
>>> Thanks,
>>> Chris.
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
>> Lc$
> 
> ___
> 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] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[John E Drake]

Hi,

I agree with Les.  This is a simple protocol extension for a specific purpose 
and there is no reason to include speculation about its use for other purposes, 
particularly when it is inherently not suited for them.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Thursday, October 15, 2020 12:33 PM
> To: Christian Hopps ; lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-ospf-prefix-
> origina...@ietf.org
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> I support moving this document forward.
> Similar functionality in IS-IS has proved useful.
> 
> I would however like to repeat comments I made earlier in the review of this
> document.
> The content of the Appendices should be removed.
> The Appendices define and discuss deriving topology information from prefix
> advertisements - which is flawed and should not be done.
> Perhaps more relevant, the purpose of the document is to define  protocol
> extensions supporting advertisement of the originators of a prefix
> advertisement. There is no need to discuss how this mechanism might be used to
> build topology information.
> This document should confine itself to defining the protocol extensions - 
> similar
> the RFC 7794.
> 
> If the authors do not agree to do this, I would encourage this point to be
> discussed during IESG review.
> 
>Les
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Christian Hopps
> > Sent: Wednesday, October 14, 2020 11:15 PM
> > To: lsr@ietf.org
> > Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org;
> > lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps
> > 
> > Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> >
> > This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> >
> >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> > f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLqhK
> > 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
> >
> > The following IPR has been filed
> > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
> > !NEt6yMaO-
> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
> > 5KtUHQ$
> >
> > Authors,
> >
> >   Please indicate to the list, your knowledge of any other IPR related
> > to this work.
> >
> > Thanks,
> > Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
> Lc$

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Les Ginsberg (ginsberg)]

I support moving this document forward.
Similar functionality in IS-IS has proved useful.

I would however like to repeat comments I made earlier in the review of this 
document.
The content of the Appendices should be removed.
The Appendices define and discuss deriving topology information from prefix 
advertisements - which is flawed and should not be done.
Perhaps more relevant, the purpose of the document is to define  protocol 
extensions supporting advertisement of the originators of a prefix 
advertisement. There is no need to discuss how this mechanism might be used to 
build topology information.
This document should confine itself to defining the protocol extensions - 
similar the RFC 7794.

If the authors do not agree to do this, I would encourage this point to be 
discussed during IESG review.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Wednesday, October 14, 2020 11:15 PM
> To: lsr@ietf.org
> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; lsr-
> a...@ietf.org; Christian Hopps 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>   Please indicate to the list, your knowledge of any other IPR related to this
> work.
> 
> Thanks,
> Chris.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Acee Lindem (acee)]

Also, speaking as WG member and co-author, I support publication. 
Thanks,
Acee

On 10/15/20, 6:12 AM, "Acee Lindem (acee)"  wrote:

I am not aware of any IPR. 
Thanks,
Acee

On 10/15/20, 2:15 AM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related 
to this work.

Thanks,
Chris.


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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Acee Lindem (acee)]

I am not aware of any IPR. 
Thanks,
Acee

On 10/15/20, 2:15 AM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related to 
this work.

Thanks,
Chris.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Dongjie (Jimmy)]

Hi Chris, 

I support the publication of this document, and as co-author I am not aware of 
any undisclosed IPR.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, October 15, 2020 2:15 PM
> To: lsr@ietf.org
> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org;
> lsr-...@ietf.org; Christian Hopps 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>   Please indicate to the list, your knowledge of any other IPR related to this
> work.
> 
> Thanks,
> Chris.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Peter Psenak]

Hi Chris,

I am not aware of any undisclosed IPRs.

thanks,
Peter

On 15/10/2020 08:15, Christian Hoppsprotocol= application/pgp-signature 
wrote:

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

   https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

   Please indicate to the list, your knowledge of any other IPR related to this 
work.

Thanks,
Chris.



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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hello,

I support the progression to publication and as co-author, I am not aware of 
any undisclosed IPR.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 15 October 2020 11:45
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; lsr-...@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related to this 
work.

Thanks,
Chris.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Jeff Tantsura]

Yes/support

Regards,
Jeff

> On Oct 14, 2020, at 23:16, Christian Hopps  wrote:
> 
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>  Please indicate to the list, your knowledge of any other IPR related to this 
> work.
> 
> Thanks,
> Chris.
> ___
> 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] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Christian Hopps]

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related to this 
work.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr