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

[Aijun Wang <[e-mail]>]

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:[e-mail]] 
Sent: Friday, October 16, 2020 9:58 PM
To: Ketan Talaulikar (ketant) <[e-mail]>
Cc: Aijun Wang <[e-mail]>; Christian Hopps <[e-mail]>; Jeff Tantsura <[e-mail]>; John E Drake <jdrake=[e-mail]>; Les Ginsberg (ginsberg) <ginsberg=[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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) <[e-mail] <mailto:[e-mail]> > wrote:

Hi Gyan,

 

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

 

From: Gyan Mishra <[e-mail] <mailto:[e-mail]> > 
Sent: 16 October 2020 10:11
To: Aijun Wang <[e-mail] <mailto:[e-mail]> >
Cc: Christian Hopps <[e-mail] <mailto:[e-mail]> >; Jeff Tantsura <[e-mail] <mailto:[e-mail]> >; John E Drake <jdrake=[e-mail] <mailto:[e-mail]> >; Les Ginsberg (ginsberg) <ginsberg=[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
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 <[e-mail] <mailto:[e-mail]> > 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: [e-mail] <mailto:[e-mail]>  [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf Of Jeff Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake <jdrake=[e-mail] <mailto:[e-mail]> >
Cc: Christian Hopps <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; Les Ginsberg (ginsberg) <ginsberg=[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
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=[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Thursday, October 15, 2020 12:33 PM
>> To: Christian Hopps <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
>> Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; 
>> draft-ietf-lsr-ospf-prefix- [e-mail] <mailto:[e-mail]> 
>> 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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Christian Hopps
>>> Sent: Wednesday, October 14, 2020 11:15 PM
>>> To: [e-mail] <mailto:[e-mail]> 
>>> Cc: [e-mail] <mailto:[e-mail]> ;
>>> [e-mail] <mailto:[e-mail]> ; lsr- [e-mail] <mailto:[e-mail]> ; Christian Hopps 
>>> <[e-mail] <mailto:[e-mail]> >
>>> 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 <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/__ <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
>> [e-mail] <mailto:[e-mail]> 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr> 
>> __;!!NEt
>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
>> Lc$
> 
> _______________________________________________
> Lsr mailing list
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/lsr

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

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

-- 

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

Gyan Mishra

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>  
Silver Spring, MD <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> 

 

-- 

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

Gyan Mishra

Network Solutions Architect 

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