Re: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16

[Adrian Farrel <[e-mail]>]

Thanks Don,

 

Not sure how to take this forward.

 

More inline as [AF2]

 

To be clear, I am editor of this document, not author. I do not propose to draft new text or changes to the current text. But I will work with practical contribution and wordsmith them into the document (cf. Gyan’s recent contributions).

 

Cheers,

Adrian

 

 

 

The Appendixes A and B seem to stop at describing 25-year-old technology.  

If they are not going to be updated, I would recommend removing them. 

 

[AF] The history is that the text used to be in the main body of RFC 3272, but was moved out as a distraction.

 

[AF] I certainly don’t mind removing them. I don’t hear an outcry to do that.

 

[AF] It is certainly meant to be “historic” and I think the split is that material is either in the main text or in the appendix. So balancing acts we can take include:

 

[AF] – Move things from the main body to the Appendixes

[AF] – Fill any lacunae between the main text and the Appendixes

 

[AF] I think that discussion plays into the rest of the email.

 

In the Appendix A the document points out that TE is evolutionary but stops at A.3.1 with the Overlay Model and 25-year-old technology.

I like this appendix and think it is important, but the evolution continued with MPLS displacing ATM etc. 

As pointed out, in the main body many TE mechanisms were developed to improve or address issues with earlier TE mechanisms.  

I think this Appendix should be updated. 

 

[AF] MPLS is discussed a fair bit in the body of the document. So the challenges for you are:

 

[AF] – How to decide what material moves from the main body to the Appendix? I would say that MPLS TE is current technology in as much as it is currently deployed and used in a lot of networks.

[AF] – Who is going to answer your request to update the text? Anyone is free to contribute!

 

[Don] I think trying to cover 25 years in an appendix is going to do injustice to some technology.  What I expected was to find pointers back to the main text and highlighting the evolution. Not moving material into the appendix.  Also, the appendix should acknowledge it somewhat objective depending on the industry .  

 

[AF2] I think we have to make a call here:

--> Does anyone think the right approach is to remove Appendix A?

--> If we are to make the changes Don suggests, who will propose the substance of those changes?

 

An important backdrop to TE Evolution is technology evolution: 

More powerful processing has allowed more optimal placement of traffic. 

 

[AF] I think this might be an indirect consequence. The processing allows some more sophisticated algorithms to be run, but it’s been possible to run them (in real time) for 20 years. So what would we add, and where?

 

[Don] Well I was thinking that really where you run the technologies has changed due to the change in processing and link speeds.   This is just more background for the evolution.  Being able to run the algorithms on a router versus get a network to change to the new path quickly has certainly changed in the last 20 years.  In fact one of the main drivers for MPLS was simplified forwarding because of limitations.  

 

[AF2] Well, that assessment of MPLS may be true, although by the time MPLS was actually built, that reason had largely disappeared.

But maybe we shouldn’t have that historical debate in this thread?

The question is, what (if any) changes to the text should be made?

 

More powerful forwarding hardware/software has allowed more elaborate queueing and traffic management. 

 

[AF] This is certainly true compared with fifty years ago, and the ECN knowledge has improved. But what to say, and where?

 

[Don] I think the queuing evolution was two queues, multiple queues,  traffic classes (aggregated queues) ,  per flow queues and to determinism for some traffic..  Again you don’t have to go into detail but highlighingis was a set of technologies.  and there are probably textbooks that can say it better.  But I think is an essential background that complements TE.  With sophisticated queueing I have seen people argue no TE is needed.  But it complements TE. 

 

[AF2] OK, I think I see the thrust of what you want the draft to say, but as editor I need to know what text you want to include. Then we can debate the words and get something there is agreement on.

 

TE deployment runs in cycles where the network is bandwidth constrained and the use of TE is important then the link rates jump an order of magnitude and TE can become a burden. 

Fast forward a couple of years, and now the network utilization is increasing and the choice of adding bandwidth or adding TE to use the resources more efficiently re-emerges. 

 

[AF] That’s an interesting point. Do you want to suggest text and where it should be placed in the document?

 

[Don] My thought was this could be highlighted in Appendix A. Appendix is Historic, but it should include pointers to the main body. 

 

[AF2] Yes, I get that. Do you want to suggest text?

 

In Append B Overview of Traffic Engineering Related Work in Other SDOs  <-  Not what is in this section.  

I suggest removing or renaming this appendix. 

 

[AF] Same thing about removal. I have no objection, the text was inherited but moved out of the main body, no one else has asked for removal.

 

[AF] Renaming it to what? 

 

[Don]  Well there is lots of TE work in other SDOs.  I suggest you don’t want to go there, you won’t do it justice etc.   

Historically in 3272 this section was there because as TE was evolving, Telephone Traffic engineering was the baseline that IP packet-based TE had to meet. 

But what is listed here is limited and outdated.  

ITU E.490.1 Is far better IMHO  that what you have listed, and I found it in 2 minutes.  It is a broader coverage of Traffic engineering including the series of  documents listed. 

In IEEE 802.1Q has traffic engineering using SRP, PBB, and SPB again I don’t think you want characterize it here but 802.1Q has “Traffic Engineering” and “Reservation” key words and covers the concepts. 

As a concept and appendix say there is Traffic engineering outside the IETF and the many of the people worked in multiple SDOs. 

I’m sure there are other bodies that have done traffic engineering too that I’ve not looked at. 

 

My suggestion is just to say in this appendix Traffic engineering can be developed for many technologies not just the IP related ones.  True GMPLS has been used for some Optical gear. This document has covered IETF related subjects.  Similar concepts have been used in other SDOs.  Whether you provide pointers of just list the bodies Names I don’t think it matters. 

 

[AF2] Are you suggesting replacing the current Appendix B with that, or supplementing it? If replacing, I think we might as well delete the appendix and move that statement into the body of the text (probably into Section 2.1). In either case, what is the list of SDOs?