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

[Don Fedyk <[e-mail]>]

Hi Adrian

I just realized you had some questions back to me.

Inline [Don]

Cheers
Don

From: Adrian Farrel <[e-mail]>
Sent: Monday, June 27, 2022 11:55 AM
To: Don Fedyk <[e-mail]>; 'Vishnu Pavan Beeram' <[e-mail]>; 'TEAS WG' <[e-mail]>
Cc: 'TEAS WG Chairs' <[e-mail]>
Subject: RE: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16

Hey Don,

Thanks for the review.

Responses in line.

Cheers,
Adrian

From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Don Fedyk
Sent: 23 June 2022 17:44
To: Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16

Hi

I have reviewed the document and think the main body provides good coverage of TE mechanisms.

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 .
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.

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.

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.

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.




Cheers
Don

From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, June 16, 2022 8:58 AM
To: TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16

Thanks to everyone who reviewed and sent in their comments!

We are extending the last call to June 24th to allow for a few more reviews.

Regards,
-Pavan

On Tue, May 24, 2022 at 10:51 PM Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>> wrote:
All,

This starts working group last call on
https://datatracker.ietf.org/doc/draft-ietf-teas-rfc3272bis/

Given the size of the document, this will be an extended
LC (3 weeks). The working group last call ends on June 14th.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Pavan (Co-Chair & Doc Shepherd)