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

From: Christian Hopps <[email-masked]>
Date: Thu, 15 Oct 2020 02:15:21 -0400

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.

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 14 Oct 2020 23:17:39 -0700

Yes/support

Regards,
Jeff

> On Oct 14, 2020, at 23:16, Christian Hopps <[email-masked]> wrote:
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 15 Oct 2020 08:39:08 +0000

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 <[email-masked]> 
Sent: 15 October 2020 11:45
To: [email-masked]
Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Authors,

Thanks,
Chris.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 15 Oct 2020 09:50:57 +0000

Hi Chris, 

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

Best regards,
Jie

> From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
> Sent: Thursday, October 15, 2020 2:15 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; Christian Hopps <[email-masked]>
> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Oct 2020 10:12:23 +0000

I am not aware of any IPR. 
Thanks,
Acee

On 10/15/20, 2:15 AM, "Christian Hopps" <[email-masked]> wrote:

    Authors,

    Thanks,
    Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Oct 2020 10:32:52 +0000

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

On 10/15/20, 6:12 AM, "Acee Lindem (acee)" <[email-masked]> wrote:

        Authors,

        Thanks,
        Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 15 Oct 2020 16:33:28 +0000

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

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Wednesday, October 14, 2020 11:15 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; lsr-
> [email-masked]; Christian Hopps <[email-masked]>

---

From: John E Drake <[email-masked]>
Date: Thu, 15 Oct 2020 18:33:00 +0000

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

> From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
> Sent: Thursday, October 15, 2020 12:33 PM
> To: Christian Hopps <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-lsr-ospf-prefix-
> [email-masked]
> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> [External Email. Be cautious of content]
> 
> 
> 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.
> > Cc: [email-masked];
> > [email-masked]; lsr- [email-masked]; Christian Hopps
> > <[email-masked]>
> > 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,
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
> Lc$

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 15 Oct 2020 14:28:20 -0700

+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake <jdrake=[email-masked]> wrote:
> 
> Hi,
>

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 16 Oct 2020 09:21:04 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Hopps

Authors,

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

Thanks,
Chris.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 16 Oct 2020 09:51:20 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake <jdrake=[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

+1

Regards,
Jeff

>> Cc: [email-masked]; [email-masked]; 
>> draft-ietf-lsr-ospf-prefix- [email-masked]
>> 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.
>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq
>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 16 Oct 2020 00:41:24 -0400

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 <[email-masked]>
wrote:

> 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.
> 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
>
>
>
> Jeff Tantsura
> Cc: Christian Hopps <[email-masked]>; [email-masked]; Les
> Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> > 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
> >
> >
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 16 Oct 2020 05:04:05 +0000

Hi Gyan,

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

From: Gyan Mishra <[email-masked]>
Sent: 16 October 2020 10:11
To: Aijun Wang <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Jeff Tantsura <[email-masked]>; John E Drake <jdrake=[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Les, John and Jeff:

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jeff Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <jdrake=[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
>> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
>> To: Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>> draft-ietf-lsr-ospf-prefix- [email-masked]<mailto:[email-masked]>
>>> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Christian Hopps
>>> To: [email-masked]<mailto:[email-masked]>
>>> Cc: [email-masked]<mailto:[email-masked]>;
>>> [email-masked]<mailto:[email-masked]>; lsr- [email-masked]<mailto:[email-masked]>; Christian Hopps
>>> <[email-masked]<mailto:[email-masked]>>
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-i>
>>> et
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/3448/__>;!
>>> !NEt6yMaO-
>> [email-masked]<mailto:[email-masked]>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr>
>> __;!!NEt
>> 6yMaO-
> [email-masked]<mailto:[email-masked]>

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

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 16 Oct 2020 05:51:17 +0000

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

> From: Aijun Wang <[email-masked]>
> Sent: Thursday, October 15, 2020 6:51 PM
> To: 'Jeff Tantsura' <[email-masked]>; 'John E Drake'
> <[email-masked]>
> Cc: 'Christian Hopps' <[email-masked]>; [email-masked]; Les Ginsberg
> (ginsberg) <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> Hi, Les, John and Jeff:
> 
> 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.
> 
> 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.
> 
> Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg
> (ginsberg) <ginsberg=[email-masked]>; [email-masked]; lsr-
> [email-masked]; [email-masked]
> > On Oct 15, 2020, at 11:33, John E Drake
> <jdrake=[email-masked]> 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
> >
> >

---

From: Christian Hopps <[email-masked]>
Date: Fri, 16 Oct 2020 03:15:45 -0400

> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> Aijun -
> 

[As WG member]

I find this very compelling and so support the removal of the referred to non-normative appendices.

Thanks,
Chris.

---

From: Aijun Wang <[email-masked]>
Date: Fri, 16 Oct 2020 16:47:52 +0800

Hi, Les and experts in LSR:

I am open to the removal of the this appendix to forward this draft.
But as stated in previous mail, providing this can assist the user/reader of the draft. We often encounter the questions in the mail list that what the usage of protocol/bit definition in some drafts.

Actually, we did not expand the discussion of this part in this draft. The description of this part is very concise.

If you insist this, I can update the draft in recent days, together with other comments on this draft.

Other comments are welcome also!

Aijun Wang
China Telecom

> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Aijun -
> 
>> Such discussion in the mail list and statements in the doc

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 16 Oct 2020 09:58:15 -0400

Agreed.  Also as use cases go that does delve into implementation aspects
of which can vary significantly.

So to your point as Les and Chris mentioned the focus of LSR and drafts
published is on the protocol extension.  How it’s used is out of scope and
could be a draft in another WG.  In this case moreso not pertinent since
the primary use case gets into the weeds on a TEAS or PCE topiic.

Thanks

Gyan

On Fri, Oct 16, 2020 at 1:04 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> *From:* Gyan Mishra <[email-masked]>
> *Sent:* 16 October 2020 10:11
> *To:* Aijun Wang <[email-masked]>
> *Cc:* Christian Hopps <[email-masked]>; Jeff Tantsura <
> [email-masked]>; John E Drake <jdrake=
> [email-masked]>; Les Ginsberg (ginsberg) <ginsberg=
> [email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> *[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
>
>
>
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-i>
> >>> et
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/3448/__>;!
> >>> !NEt6yMaO-
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr>
> >> __;!!NEt
> >> 6yMaO-
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>*Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

*Gyan Mishra*

---

From: 王爱俊 <[email-masked]>
Date: Fri, 16 Oct 2020 22:37:53 +0800 (GMT+08:00)

Hi, Chris: Originally, the appendix part is within the document, which is the start point/main motivation to extend the prefix origin.
There may exists other usages of this information. Pack these examples into some short sentences or introduction is viable, but expand some of them is also helpful.As I known, when we want to do protocol extension, we should  always convince other the reason/motivation/prospects to do so. On the other hand, the use case described in the current appendix is very prominent for operator to accomplish the TE task in multi-area environment.

Aijun Wang

在2020-10-16，Christian Hopps &lt;[email-masked]&gt;写道:
 -----原始邮件-----
 发件人： Christian Hopps &lt;[email-masked]&gt;
 发件时间: 2020年10月16日 星期五
 写道: [&quot;Les Ginsberg (ginsberg)&quot; &lt;ginsberg=[email-masked]&gt;]
 主题： Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

 [As WG member]

 Thanks,
 Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 16 Oct 2020 14:42:12 +0000

> From: Lsr <[email-masked]> On Behalf Of Aijun Wang
> Sent: Friday, October 16, 2020 1:48 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: John E Drake <[email-masked]>; Christian Hopps
> <[email-masked]>; [email-masked]; [email-masked]; Jeff Tantsura
> <[email-masked]>; [email-masked]; lsr-
> [email-masked]

[Les:] Great!! Please do so.

   Les

> But as stated in previous mail, providing this can assist the user/reader of the
> draft. We often encounter the questions in the mail list that what the usage
> of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. The
> description of this part is very concise.
> 
> > 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
> >
> >
> >> And, before adopting one work, we have often intense discussion for
> what's
> >> their usages.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 16 Oct 2020 10:47:13 -0400

Isn't this just adding an analogous extension that already exists in RFC7794?

I don't think we need to do a lot of convincing at this point. I agree with Les, if you want to talk about use cases (especially ones that are controversial!) then the correct place for that is in a new informative draft. Otherwise, especially if the cases are controversial, this can be seen as doing an "end-run" to avoid the debate b/c people want the extension, but maybe don't agree with your use case. Legislators do this sometimes adding things they want personally to popular bills, that other people may not want, but since people want the main bill they vote for it anyway, in the US it's called "adding pork" or "pork barrel politics". :)

Thanks,
Chris.

> On Oct 16, 2020, at 10:37 AM, 王爱俊 <[email-masked]> wrote:
> 
> 
> Hi, Chris:
> Originally, the appendix part is within the document, which is the start point/main motivation to extend the prefix origin.
> There may exists other usages of this information. Pack these examples into some short sentences or introduction is viable, but expand some of them is also helpful.
> As I known, when we want to do protocol extension, we should  always convince other the reason/motivation/prospects to do so. On the other hand, the use case described in the current appendix is very prominent for operator to accomplish the TE task in multi-area environment.
> 
> Aijun Wang
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 19 Oct 2020 10:08:00 +0800

Hi, Chris:

I think we have "put the cart before the horse". For protocol extension draft, the origin is the use case. 
And I think we will not expand OSPF protocol, just because it lack something as compared with ISIS, right?

As I stated before, the use case in current appendix is the main motivation of this draft, you can see this in main body of the earlier version of this draft(from version 0 to version 5). 
The reason that we move this part to the appendix, as that you said, is to let person focus on the protocol extension itself.

Moving this part to appendix is acceptable, but removing it from the draft will erase the origin of this document. 
Is it reasonable that one document discusses the "origin"(of the prefix), can't keep its origin?

More replies inline below[WAJ].

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Friday, October 16, 2020 10:47 PM
To: 王爱俊 <[email-masked]>
Cc: John E Drake <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; Jeff Tantsura <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Isn't this just adding an analogous extension that already exists in RFC7794?
[WAJ] No. RFC7794 is just one example that to illustrate, as the companion IGP protocol, OSPF can also accomplish this. And, actually, there are differences consideration in this draft for the protocol extension.

I don't think we need to do a lot of convincing at this point. I agree with Les, if you want to talk about use cases (especially ones that are controversial!) then the correct place for that is in a new informative draft. 
[WAJ] we have discussed the use case before and state the discussion results at the appendix part. We will not emphasis and expand the use case more. If one does not agree the statement of this appendix, we can discuss online or offline. We just need to make the statement in appendix is correct. 

Otherwise, especially if the cases are controversial, this can be seen as doing an "end-run" to avoid the debate b/c people want the extension, but maybe don't agree with your use case. 
[WAJ] One should point out which statement in the appendix is controversial, we can correct it. This use case is the origin of this draft, not the results.

Legislators do this sometimes adding things they want personally to popular bills, that other people may not want, but since people want the main bill they vote for it anyway, in the US it's called "adding pork" or "pork barrel politics". :)
[WAJ] The appendix is not added later, but exist at the first beginning. This is the origin of the bills. 

Thanks,
Chris.

> 写道: [&quot;Les Ginsberg (ginsberg)&quot; 
> &lt;ginsberg=[email-masked]&gt;]
> >> (ginsberg) <[email-masked]>; [email-masked]; [email-masked]; 
> >> draft-ietf- [email-masked]
> >> 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.
> >> what's their usages.
> >> 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
> >>
> >>
> >>
> >> Ginsberg
> >> (ginsberg) <ginsberg=[email-masked]>; [email-masked]; 
> >> lsr- [email-masked]; [email-masked]
> >> and there is no reason to include speculation about its use for 
> >>>> The Appendices define and discuss deriving topology information 
> >>>> from prefix advertisements - which is flawed and should not be done.
> >>>> 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.
> >>>> If the authors do not agree to do this, I would encourage this 
> >>>> point to be discussed during IESG review.
> >>>>
> >>>>  Les
> >>>>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 19 Oct 2020 10:45:45 +0800

Hi, Gyan:

Thanks for your considerations.

The use case in the appendix is the start point of this draft,  not the application of it.  

Putting it into the appendix just want to let the reader focus on the protocol extension itself. For the usages of the protocol extension, the reader can refer the description in the appendix.  

We have discussed the contents in appendix before. The discussion results are stated in the appendix now. 

For operators in SDN era, there are strong motivations to accomplish e2e service assurance. To achieve this, the overall e2e topology is the prerequisite information.  Knowing the originator of the prefixes can deduce the inter-area topology which is hidden by ABR.  We don’t preclude other use cases of this extension, but they are not prominent as this case.

Best Regards

Aijun Wang

China Telecom

From: Gyan Mishra [mailto:[email-masked]] 
Sent: Friday, October 16, 2020 9:58 PM
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Christian Hopps <[email-masked]>; Jeff Tantsura <[email-masked]>; John E Drake <jdrake=[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Agreed.  Also as use cases go that does delve into implementation aspects of which can vary significantly. 

So to your point as Les and Chris mentioned the focus of LSR and drafts published is on the protocol extension.  How it’s used is out of scope and could be a draft in another WG.  In this case moreso not pertinent since the primary use case gets into the weeds on a TEAS or PCE topiic.

Thanks 

Gyan

On Fri, Oct 16, 2020 at 1:04 AM Ketan Talaulikar (ketant) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Gyan,

From: Gyan Mishra <[email-masked] <mailto:[email-masked]> > 
Sent: 16 October 2020 10:11
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Christian Hopps <[email-masked] <mailto:[email-masked]> >; Jeff Tantsura <[email-masked] <mailto:[email-masked]> >; John E Drake <jdrake=[email-masked] <mailto:[email-masked]> >; Les Ginsberg (ginsberg) <ginsberg=[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Thanks,

Ketan

Kind Regards 

Gyan

On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Les, John and Jeff:

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Jeff Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake <jdrake=[email-masked] <mailto:[email-masked]> >
Cc: Christian Hopps <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Les Ginsberg (ginsberg) <ginsberg=[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
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 <jdrake=[email-masked] <mailto:[email-masked]> > wrote:
> 
> Hi,
> 
>> From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Les Ginsberg (ginsberg)
>> To: Christian Hopps <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
>> Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 
>> draft-ietf-lsr-ospf-prefix- [email-masked] <mailto:[email-masked]> 
>>> From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Christian Hopps
>>> To: [email-masked] <mailto:[email-masked]> 
>>> Cc: [email-masked] <mailto:[email-masked]> ;
>>> [email-masked] <mailto:[email-masked]> ; lsr- [email-masked] <mailto:[email-masked]> ; Christian Hopps 
>>> <[email-masked] <mailto:[email-masked]> >
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-i> 
>>> et 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__ <https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/3448/__> ;!
>>> !NEt6yMaO-
>> [email-masked] <mailto:[email-masked]> 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr> 
>> __;!!NEt
>> 6yMaO-
> [email-masked] <mailto:[email-masked]> 

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

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

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>  
Silver Spring, MD <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> 

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 19 Oct 2020 06:14:46 +0000

Aijun -

The "use case" for the protocol extensions is clearly stated in the Introduction:

"The primary use case for the extensions proposed in this document is
   to be able to identify the originator of the prefix in the network.
   In cases where multiple prefixes are advertised by a given router, it
   is also useful to be able to associate all these prefixes with a
   single router even when prefixes are advertised outside of the area
   in which they originated.  It also helps to determine when the same
   prefix is being originated by multiple routers across areas."

This is equivalent to language in RFC 7794 which defines the analogous extensions for IS-IS.

Everything you have in the Appendix is not related to the primary use case - and is fact a use case which many of us have objected to.

You are entitled to write another draft advocating for your new use case if you wish, but requiring that the protocol extensions in support of the primary use case not go forward without your new use case is - as Chris has stated very clearly - holding approval of the protocol extensions hostage to your new use case.

I am asking you (yet again) not to do this.

I cannot support the document moving forward with the content in the Appendices included.

   Les

> Sent: Sunday, October 18, 2020 7:08 PM
> To: 'Christian Hopps' <[email-masked]>
> Cc: 'John E Drake' <[email-masked]>; [email-masked]; 'Les Ginsberg
> (ginsberg)' <ginsberg=[email-masked]>; [email-masked]; 'Jeff
> Tantsura' <[email-masked]>; draft-ietf-lsr-ospf-prefix-
> [email-masked]; [email-masked]
> As I stated before, the use case in current appendix is the main motivation of
> this draft, you can see this in main body of the earlier version of this
> draft(from version 0 to version 5).
> The reason that we move this part to the appendix, as that you said, is to let
> person focus on the protocol extension itself.
> 
> <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]>; [email-masked]; Jeff Tantsura
> [WAJ] No. RFC7794 is just one example that to illustrate, as the companion
> IGP protocol, OSPF can also accomplish this. And, actually, there are
> differences consideration in this draft for the protocol extension.
> 
> I don't think we need to do a lot of convincing at this point. I agree with Les, if
> you want to talk about use cases (especially ones that are controversial!)
> then the correct place for that is in a new informative draft.
> [WAJ] we have discussed the use case before and state the discussion
> results at the appendix part. We will not emphasis and expand the use case
> more. If one does not agree the statement of this appendix, we can discuss
> online or offline. We just need to make the statement in appendix is correct.
> 
> Otherwise, especially if the cases are controversial, this can be seen as doing
> an "end-run" to avoid the debate b/c people want the extension, but maybe
> don't agree with your use case.
> [WAJ] One should point out which statement in the appendix is
> controversial, we can correct it. This use case is the origin of this draft, not
> the results.
> 
> Legislators do this sometimes adding things they want personally to popular
> bills, that other people may not want, but since people want the main bill
> they vote for it anyway, in the US it's called "adding pork" or "pork barrel
> politics". :)
> > Originally, the appendix part is within the document, which is the start
> point/main motivation to extend the prefix origin.
> > There may exists other usages of this information. Pack these examples
> into some short sentences or introduction is viable, but expand some of
> them is also helpful.
> > As I known, when we want to do protocol extension, we should  always
> convince other the reason/motivation/prospects to do so. On the other
> hand, the use case described in the current appendix is very prominent for
> operator to accomplish the TE task in multi-area environment.
> >
> > Aijun Wang
> >
> > > On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]> wrote:
> > >
> > > Aijun -
> > >

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 19 Oct 2020 15:06:13 +0800

Hi, Les:

As I stated clearly before, the appendix described in the draft is not the new use case. It is the start point of this draft.
Have you noticed that the introduction part is not the final usage of such protocol extension information? 
Certainly, we will not expand all the possible use cases in very detail, but putting some of them(some interesting, prominent use cases) in the appendix will not hamper the protocol extension itself.

If the statements/descriptions in the appendix are not correct, we can fix it, or remove it finally.  If not, why not let it be for reference to the user of such protocol extension?
For the body part of this draft, we are also welcome comments.

More replies inline below[WAJ]

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, October 19, 2020 2:15 PM
To: Aijun Wang <[email-masked]>; 'Christian Hopps' <[email-masked]>
Cc: 'John E Drake' <[email-masked]>; [email-masked]; 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>; [email-masked]; 'Jeff Tantsura' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Aijun -

Everything you have in the Appendix is not related to the primary use case - and is fact a use case which many of us have objected to.
[WAJ] Very glad to know the false statements in the appendix.

You are entitled to write another draft advocating for your new use case if you wish, but requiring that the protocol extensions in support of the primary use case not go forward without your new use case is - as Chris has stated very clearly - holding approval of the protocol extensions hostage to your new use case.
[WAJ] It is not new use case. As I sated before, I am open to this part, but should on the conditions that the statements in this part are incorrect.    

I cannot support the document moving forward with the content in the Appendices included.
[WAJ] Would like to hear more technical analysis.

   Les

> Cc: 'John E Drake' <[email-masked]>; [email-masked]; 'Les 
> Ginsberg (ginsberg)' <ginsberg=[email-masked]>; 
> [email-masked]; 'Jeff Tantsura' <[email-masked]>; 
> draft-ietf-lsr-ospf-prefix- [email-masked]; [email-masked]
> I think we have "put the cart before the horse". For protocol 
> extension draft, the origin is the use case.
> As I stated before, the use case in current appendix is the main 
> motivation of this draft, you can see this in main body of the earlier 
> version of this draft(from version 0 to version 5).
> The reason that we move this part to the appendix, as that you said, 
> is to let person focus on the protocol extension itself.
> 
> Moving this part to appendix is acceptable, but removing it from the 
> draft will erase the origin of this document.
> <[email-masked]>; 
> [email-masked]; lsr- [email-masked]
> [WAJ] No. RFC7794 is just one example that to illustrate, as the 
> companion IGP protocol, OSPF can also accomplish this. And, actually, 
> there are differences consideration in this draft for the protocol extension.
> 
> I don't think we need to do a lot of convincing at this point. I agree 
> with Les, if you want to talk about use cases (especially ones that 
> are controversial!) then the correct place for that is in a new informative draft.
> results at the appendix part. We will not emphasis and expand the use 
> case more. If one does not agree the statement of this appendix, we 
> can discuss online or offline. We just need to make the statement in appendix is correct.
> 
> Otherwise, especially if the cases are controversial, this can be seen 
> as doing an "end-run" to avoid the debate b/c people want the 
> extension, but maybe don't agree with your use case.
> controversial, we can correct it. This use case is the origin of this 
> draft, not the results.
> 
> Legislators do this sometimes adding things they want personally to 
> popular bills, that other people may not want, but since people want 
> the main bill they vote for it anyway, in the US it's called "adding 
> pork" or "pork barrel politics". :) [WAJ] The appendix is not added 
> later, but exist at the first beginning. This is the origin of the 
> bills.
> 
> Thanks,
> Chris.
> 
> into some short sentences or introduction is viable, but expand some 
> of them is also helpful.
> hand, the use case described in the current appendix is very prominent 
> for operator to accomplish the TE task in multi-area environment.
> >
> > Aijun Wang
> >
> be Standards track as adhering to the normative statements in the 
> draft are necessary for interoperability.
> > >
> there are strong opinions on both sides as to whether this is an 
> appropriate use case or not.
> difference of opinion on this use case. I simply want the protocol 
> extension to move forward so that we have another tool available.
> > >
> 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.
> > >
> prefix advertisements to derive topology by adding it to a draft that 
> is (and should be) focused on simple protocol extensions.
> >
> > [As WG member]
> >
> > I find this very compelling and so support the removal of the 
> > referred to
> non-normative appendices.
> >
> > Thanks,
> > Chris.
> >
> > >
> > > Thanx.
> > >
> > >   Les
> > >
> > >
> > >> protocol extension, but their usages in the network deployment. 
> > >> As I known, almost all the IETF documents following this style.
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> 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
> > >>
> > >>
> > >>
> > >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d
> > >>>>> ra
> > >>>>> ft-i
> > >>>>> et
> > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin
> > >>>> fo
> > >>>> /lsr
> > >>>> __;!!NEt
> > >>>> 6yMaO-
> > >>>>
> > >>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 19 Oct 2020 07:32:28 +0000

Aijun -

I am not going to continue these side discussions with you.

The primary purpose of the protocol extensions are as stated in the draft Introduction. This is analogous to the use cases for the equivalent extensions for IS-IS already approved in RFC 7794. We need the equivalent in OSPF.

You can show that you are listening to the concerns of WG members by removing the Appendices - in which case you have (I believe) broad support for moving the draft forward.
You can then write a separate draft to discuss other use cases and allow the WG to discuss those other use cases w/o preventing the extensions from being approved and deployed for the use cases which have already been demonstrated as useful by IS-IS.

If you remove the Appendices I can support the draft.
If you do not remove the Appendices I cannot support the draft.

Please discuss this with your co-authors and come to consensus on your next step.

   Les

> Sent: Monday, October 19, 2020 12:06 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; 'Christian Hopps'
> <[email-masked]>
> Cc: 'John E Drake' <[email-masked]>; [email-masked]; [email-masked];
> 'Jeff Tantsura' <[email-masked]>; draft-ietf-lsr-ospf-prefix-
> As I stated clearly before, the appendix described in the draft is not the new
> use case. It is the start point of this draft.
> Certainly, we will not expand all the possible use cases in very detail, but
> putting some of them(some interesting, prominent use cases) in the
> appendix will not hamper the protocol extension itself.
> 
> If the statements/descriptions in the appendix are not correct, we can fix it,
> or remove it finally.  If not, why not let it be for reference to the user of such
> protocol extension?
> Everything you have in the Appendix is not related to the primary use case -
> and is fact a use case which many of us have objected to.
> You are entitled to write another draft advocating for your new use case if
> you wish, but requiring that the protocol extensions in support of the
> primary use case not go forward without your new use case is - as Chris has
> stated very clearly - holding approval of the protocol extensions hostage to
> your new use case.
> [WAJ] It is not new use case. As I sated before, I am open to this part, but
> should on the conditions that the statements in this part are incorrect.
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 19 Oct 2020 11:13:37 +0200

Aijun,

> You can show that you are listening to the concerns of WG members by removing the Appendices - in which case you have (I believe) broad support for moving the draft forward.

I agree with Les.

As a co-author, I have asked you several times to get rid of the use 
case described in appendix. Trying to use prefix advertisement to derive 
topological data is simply broken. The reason we are adding the prefix 
originator extension to OSPF is NOT the broken use case in the appendix 
of the draft.

thanks,
Peter

---

From: Aijun Wang <[email-masked]>
Date: Mon, 19 Oct 2020 18:10:38 +0800

Hi. Peter, Les:

We have defined many extensions for protocol, but only a small part of them are deployed. Have you ever considered the reason?

Adding more contents for their  potential usages can certainly be helpful for their influences, or else, they will just stay at the IETF repository.

More replies inline below.

Aijun Wang
China Telecom

> On Oct 19, 2020, at 17:14, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Aijun,
> 
> As a co-author, I have asked you several times to get rid of the use case described in appendix.
[WAJ] Moving the expansion of this use case from body part of this draft to its appendix is our initial consensus, not remove it totally. We have discussed intensely for its application in vary situations. The discussion results are stated clearly in the appendix.
Wish to hear more technical analysis/comments for the current statements of this part from other experts, or from you if you have fresh consideration.

> Trying to use prefix advertisement to derive topological data is simply broken. The reason we are adding the prefix originator extension to OSPF is NOT the broken use case in the appendix of the draft.
> 
> thanks,
> Peter
> 
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 19 Oct 2020 12:31:31 +0200

Hi Aijun,

please see inline:

> Adding more contents for their  potential usages can certainly be helpful for their influences, or else, they will just stay at the IETF repository.

I disagree. RFCs are not deployment or use case documents. They exists 
to address the interoperability.

> [WAJ] Moving the expansion of this use case from body part of this draft to its appendix is our initial consensus, not remove it totally. We have discussed intensely for its application in vary sit…

just because you insisted and did not listen to rest of us.

> Wish to hear more technical analysis/comments for the current statements of this part from other experts, or from you if you have fresh consideration.

we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan, 
myself) are telling you that using IP address advertisement to derive 
topological data is broken and you keep repeating it is valid use case 
and ask for more reasoning.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 19 Oct 2020 12:34:04 +0200

Aijun,

Regarding your appendix A -

* How can we "rebuild" topology based on comparison of prefixes and rtr-id
?

* If link between S1 & S2 is not in LSDB there may be a valid operational
reasons for it. "Rebuilding it" will be actually harmful from all points of
view.

* You should be exporting topology from all areas not just from backbone
and guessing the topology based on the prefix to rtr_id associations

* Imaging someone is using multiaccess in areas. Are you also going to
rebuild DR & BDR ?

I must agree with comments from Peter & Les here.

Cheers,
R.

On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang <[email-masked]> wrote:

> Hi. Peter, Les:
>
> We have defined many extensions for protocol, but only a small part of
> them are deployed. Have you ever considered the reason?
>
> Adding more contents for their  potential usages can certainly be helpful
> for their influences, or else, they will just stay at the IETF repository.
>
> >> The primary purpose of the protocol extensions are as stated in the
> draft Introduction. This is analogous to the use cases for the equivalent
> extensions for IS-IS already approved in RFC 7794. We need the equivalent
> in OSPF.
> >> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support
> for moving the draft forward.
> >
> > I agree with Les.
> >
> case described in appendix.
> [WAJ] Moving the expansion of this use case from body part of this draft
> to its appendix is our initial consensus, not remove it totally. We have
> discussed intensely for its application in vary situations. The discussion
> results are stated clearly in the appendix.
> Wish to hear more technical analysis/comments for the current statements
> of this part from other experts, or from you if you have fresh
> consideration.
>
> > Trying to use prefix advertisement to derive topological data is simply
> broken. The reason we are adding the prefix originator extension to OSPF is
> NOT the broken use case in the appendix of the draft.
> >
> > thanks,
> > Peter
> >
> >
> >
> >> You can then write a separate draft to discuss other use cases and
> allow the WG to discuss those other use cases w/o preventing the extensions
> from being approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> >>> Have you noticed that the introduction part is not the final usage of
> such
> >>> protocol extension information?
> >>> Ginsberg (ginsberg)
> >>>> are controversial!) then the correct place for that is in a new
> informative
> >>> draft.
> >>>> (e.g., TEAS). The merits of using prefix advertisements to build a
> topology
> >>> could then be discussed on its own.
> >>>>>>
> >>>>>>> with large amount of unnumbered links. But for others, the
> heuristic
> >>> applies.
> >>>>>>>
> >>>>>>> Best Regards
> >>>>>>>
> >>>>>>> Aijun Wang
> >>>>>>> China Telecom
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ;!

---

From: Aijun Wang <[email-masked]>
Date: Mon, 19 Oct 2020 19:20:49 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Oct 19, 2020, at 18:34, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> * How can we "rebuild" topology based on comparison of prefixes and rtr-id ? 

[WAJ]: The two ends of the link will advertise the same prefixes. The collector of BGP-LS can compare them and interconnect the two ends, which are identified by the originator of the said prefixes.
> 
> * If link between S1 & S2 is not in LSDB there may be a valid operational reasons for it. "Rebuilding it" will be actually harmful from all points of view. 

[WAJ] The rebuild process will also omit this link.

> 
> * You should be exporting topology from all areas not just from backbone and guessing the topology based on the prefix to rtr_id associations 
> 
[WAJ] Exporting the topology from all areas requires the BGP-LS speakers in all areas, which is the burden of deployment.

> * Imaging someone is using multiaccess in areas. Are you also going to rebuild DR & BDR ? 
> 
[WAJ] For OSPF, the DR/BDR is the real node. There will be no difference for the topology retrieval. For ISIS, the pseudo-nodes can be identified/excluded via the circuit-ID of LSP.

---

From: John E Drake <[email-masked]>
Date: Mon, 19 Oct 2020 14:08:47 +0000

I agree w/ Les, who I think has been extremely reasonable throughout this discussion.

Yours Irrespectively,

John

> From: Les Ginsberg (ginsberg) <[email-masked]>
> Sent: Monday, October 19, 2020 3:32 AM
> Cc: John E Drake <[email-masked]>; [email-masked]; [email-masked]; 'Jeff
> The primary purpose of the protocol extensions are as stated in the draft
> Introduction. This is analogous to the use cases for the equivalent extensions for
> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
> 
> removing the Appendices - in which case you have (I believe) broad support for
> moving the draft forward.
> You can then write a separate draft to discuss other use cases and allow the WG
> to discuss those other use cases w/o preventing the extensions from being
> approved and deployed for the use cases which have already been
> > Cc: 'John E Drake' <[email-masked]>; [email-masked];
> > As I stated clearly before, the appendix described in the draft is not
> > the new use case. It is the start point of this draft.
> > such protocol extension information?
> > Certainly, we will not expand all the possible use cases in very
> > detail, but putting some of them(some interesting, prominent use
> > cases) in the appendix will not hamper the protocol extension itself.
> >
> > If the statements/descriptions in the appendix are not correct, we can
> > fix it, or remove it finally.  If not, why not let it be for reference
> > to the user of such protocol extension?
> > Les Ginsberg (ginsberg)
> > Everything you have in the Appendix is not related to the primary use
> > case - and is fact a use case which many of us have objected to.
> > You are entitled to write another draft advocating for your new use
> > case if you wish, but requiring that the protocol extensions in
> > support of the primary use case not go forward without your new use
> > case is - as Chris has stated very clearly - holding approval of the
> > protocol extensions hostage to your new use case.
> > [WAJ] It is not new use case. As I sated before, I am open to this
> > part, but should on the conditions that the statements in this part are
> incorrect.
> >
> > > motivation of this draft, you can see this in main body of the
> > > earlier version of this draft(from version 0 to version 5).
> > > companion IGP protocol, OSPF can also accomplish this. And,
> > > actually, there are differences consideration in this draft for the protocol
> extension.
> > >
> > > I don't think we need to do a lot of convincing at this point. I
> > > agree with Les, if you want to talk about use cases (especially ones
> > > that are controversial!) then the correct place for that is in a new
> > > informative
> > draft.
> > > results at the appendix part. We will not emphasis and expand the
> > > use case more. If one does not agree the statement of this appendix,
> > > we can discuss online or offline. We just need to make the statement
> > > in
> > appendix is correct.
> > >
> > > Otherwise, especially if the cases are controversial, this can be
> > > seen as doing an "end-run" to avoid the debate b/c people want the
> > > controversial, we can correct it. This use case is the origin of
> > > this draft, not the results.
> > >
> > > convince other the reason/motivation/prospects to do so. On the
> > > other hand, the use case described in the current appendix is very
> > > prominent for operator to accomplish the TE task in multi-area environment.
> > > >
> > > > Aijun Wang
> > > >
> > > 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
> > > prefix advertisements to derive topology by adding it to a draft
> > > that is (and should be) focused on simple protocol extensions.
> > > >
> > > > [As WG member]
> > > >
> > > > >> "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.
> > > > >>
> > > > >> lsr- [email-masked];
> > > > >> [email-masked]
> > > > >>>> 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.
> > > > >>>> If the authors do not agree to do this, I would encourage
> > > > >>>> this point to be discussed during IESG review.
> > > > >>>>
> > > > >>>>  Les
> > > > >>>>
> > > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
> > > > >>> nfo/lsr__;!!NEt6yMaO-
> gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV
> > > > >>> 9UMD54R3w20E_CXC5-bVuZr-c$
> > > > >>
> > > > >> fo/lsr__;!!NEt6yMaO-
> gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9U
> > > > >> MD54R3w20E_CXC5-bVuZr-c$
> > > > >
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
> > > > > o/lsr__;!!NEt6yMaO-
> gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD
> > > > > 54R3w20E_CXC5-bVuZr-c$
> > > >
> > > >
> > > >
> > >
> > >
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls
> > > r__;!!NEt6yMaO-
> gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD54R3w20E
> > > _CXC5-bVuZr-c$
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-
> gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD54R3w20E_CXC
> > 5-bVuZr-c$

---

From: John E Drake <[email-masked]>
Date: Mon, 19 Oct 2020 14:14:35 +0000

Aijun,

What part of "using IP address advertisement to derive topological data is broken" do you not understand?

Yours Irrespectively,

John

> From: Peter Psenak <[email-masked]>
> Sent: Monday, October 19, 2020 6:32 AM
> To: Aijun Wang <[email-masked]>; Peter Psenak
> <ppsenak=[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Aijun Wang
> <[email-masked]>; Christian Hopps <[email-masked]>; John E
> Drake <[email-masked]>; [email-masked]; [email-masked]; Jeff Tantsura
> > We have defined many extensions for protocol, but only a small part of them
> are deployed. Have you ever considered the reason?
> >
> > Adding more contents for their  potential usages can certainly be helpful for
> their influences, or else, they will just stay at the IETF repository.
> 
> I disagree. RFCs are not deployment or use case documents. They exists to
> address the interoperability.
> 
> >
> >> On Oct 19, 2020, at 17:14, Peter Psenak
> <ppsenak=[email-masked]> wrote:
> >>
> >> Aijun,
> >>
> > [WAJ] Moving the expansion of this use case from body part of this draft to its
> appendix is our initial consensus, not remove it totally. We have discussed
> intensely for its application in vary situations. The discussion results are stated
> clearly in the appendix.
> 
> > Wish to hear more technical analysis/comments for the current statements of
> this part from other experts, or from you if you have fresh consideration.
> 
> myself) are telling you that using IP address advertisement to derive topological
> data is broken and you keep repeating it is valid use case and ask for more
> reasoning.
> 
> thanks,
> Peter
> 
> >
> broken. The reason we are adding the prefix originator extension to OSPF is NOT
> the broken use case in the appendix of the draft.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>
> >>> You can then write a separate draft to discuss other use cases and allow the
> WG to discuss those other use cases w/o preventing the extensions from being
> >>>> As I stated clearly before, the appendix described in the draft is
> >>>> not the new use case. It is the start point of this draft.
> >>>> If the statements/descriptions in the appendix are not correct, we
> >>>> can fix it, or remove it finally.  If not, why not let it be for
> >>>> reference to the user of such protocol extension?
> >>>> Everything you have in the Appendix is not related to the primary
> >>>> use case - and is fact a use case which many of us have objected to.
> >>>> case is - as Chris has stated very clearly - holding approval of
> >>>> the protocol extensions hostage to your new use case.
> >>>>> The reason that we move this part to the appendix, as that you
> >>>>> said, is to let person focus on the protocol extension itself.
> >>>>>
> >>>>> Moving this part to appendix is acceptable, but removing it from
> >>>>> the draft will erase the origin of this document.
> >>>>> agree with Les, if you want to talk about use cases (especially
> >>>>> ones that are controversial!) then the correct place for that is
> >>>>> in a new informative
> >>>> draft.
> >>>>> [WAJ] we have discussed the use case before and state the
> >>>>> discussion results at the appendix part. We will not emphasis and
> >>>>> expand the use case more. If one does not agree the statement of
> >>>>> this appendix, we can discuss online or offline. We just need to
> >>>>> make the statement in
> >>>> appendix is correct.
> >>>>>
> >>>>> Legislators do this sometimes adding things they want personally
> >>>>> to popular bills, that other people may not want, but since people
> >>>>> want the main bill they vote for it anyway, in the US it's called
> >>>>> "adding pork" or "pork barrel politics". :) [WAJ] The appendix is
> >>>>> not added later, but exist at the first beginning. This is the
> >>>>> origin of the bills.
> >>>>>
> >>>>> Thanks,
> >>>>> Chris.
> >>>>>
> >>>>> into some short sentences or introduction is viable, but expand
> >>>>> some of them is also helpful.
> >>>>> 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
> >>>>>>>> for the head-end router that located in one area that different from
> the tail- end router.
> >>>>>>>>
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml
> >>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$
> >>>>>>>>
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9
> >>>>>>>> TvoAZwe64fnzVvizNujmq1M$
> >>>>>>>
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv
> >>>>>>> oAZwe64fnzVvizNujmq1M$
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> >>>>> lsr__;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw
> >>>>> e64fnzVvizNujmq1M$
> >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
> >>>> sr__;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6
> >>>> 4fnzVvizNujmq1M$
> >>
> >> __;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz
> >> VvizNujmq1M$
> >
> >
> >

---

From: Christian Hopps <[email-masked]>
Date: Mon, 19 Oct 2020 13:06:31 -0400

> On Oct 16, 2020, at 4:47 AM, Aijun Wang <[email-masked]> wrote:
> 

That's good news, thank you Aijun.

Speaking for the chairs,

We believe we have reached WG consensus (seems better than just rough even with some authors asking for the change) at this point on the removal of the disputed use-case appendices.

Could you please republish the document w/o the disputed sections?

Thanks,
Chris.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 19 Oct 2020 17:19:09 +0000

Speaking as WG chair: 

    Speaking for the chairs,

    Thanks,
    Chris.

I'll add that RFC 7221, section 1.2 https://tools.ietf.org/html/rfc7221#section-1.2  includes a very good description of the IETF process for WG document ownership and consensus. 

Thanks,
Acee

---

From: "Baalajee S (basurend)" <[email-masked]>
Date: Tue, 20 Oct 2020 05:18:27 +0000

Hello authors,

I have a couple of comments.

1.
   A received Prefix Originator Sub-TLV that has an invalid length (not
   4 or 16) or a Reachable Address containing an invalid IPv4 or IPv6
   address (dependent on address family of the associated prefix) MUST
   be considered invalid and ignored.  Additionally, reception of such
   Sub-TLV SHOULD be logged as an error (subject to rate-limiting).

Shouldn’t that be “Router address”?

2.
   If the originating node is advertising an OSPFv2 Router Address TLV
   [RFC3630<https://tools.ietf.org/html/rfc3630>] or an OSPFv3 Router IPv6 Address TLV [RFC5329<https://tools.ietf.org/html/rfc5329>], then that
   value is set in the Router Address field of the Prefix Originator
   Sub-TLV.  When the orignating node is not advertising such an

Wang, et al.             Expires January 1, 2021                [Page 5]
________________________________

Internet-Draft      OSPF Prefix Originator Extensions          June 2020

   address, implementations MAY support mechanisms to determine a
   reachable address belonging to the originating node to set in the
   Router Address field.  Such mechanisms are outside the scope of this
   document.

Originating -> originating

I assume that the “Router address” picked by a router could be one of the addresses advertised by it with “N-bit” (Node SID) set or some other reachable address which uniquely identifies the router.

Regards,

S. Baalajee

On 15/10/20, 11:46 AM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

    Authors,

    Thanks,

    Chris.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 20 Oct 2020 07:09:57 +0000

Hi Baalajee,

Thanks for you review and comments. We’ll incorporate these fixes/clarifications in the upcoming update.

Thanks,
Ketan

From: Baalajee S (basurend) <[email-masked]>
Sent: 20 October 2020 10:48
To: Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Hello authors,

1.

2.

Regards,

S. Baalajee

On 15/10/20, 11:46 AM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

    Authors,

    Thanks,

    Chris.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 20 Oct 2020 11:00:59 +0000

Hi Chris/All,

We've just posted the v07 of the draft with the contentious appendix sections removed and also addressing some comments received on the list.

https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-07 

Thanks,
Ketan (on behalf on co-authors)

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: 19 October 2020 22:37
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; John E Drake <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]; [email-masked]; Jeff Tantsura <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Speaking for the chairs,

Thanks,
Chris.

>>> protocol extension, but their usages in the network deployment. As I 
>>> known, almost all the IETF documents following this style.