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

Hi Adrian

“ Waiting to see whether Don (or anyone else) wishes to propose text to
address Don’s points. At this time “we are all authors”. I am just the
editor and will edit in new text if supplied, but I will not craft the new
text from scratch. “

In-line some feedback

On Mon, Jun 27, 2022 at 11:55 AM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hey Don,
>
>
>
> Thanks for the review.
>
>
>
> Responses in line.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Don Fedyk
> *Sent:* 23 June 2022 17:44
> *To:* Vishnu Pavan Beeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>
> *Cc:* TEAS WG Chairs <teas-chairs@ietf.org>
> *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.
>

   Gyan> So the challenge of what stays in the body versus Appendix
section, I don’t think we should move MPLS TE as it’s our current TE
technology to the appendix.  Appendix A and B can either be kept or
removed, but I don’t think we need to move or replicate current MPLS TE
technology from the body to the Appendix.

> [AF] – Who is going to answer your request to update the text? Anyone is
> free to contribute!
>
>  Gyan> Leave Appendix A and B as is or remove
>
> 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?
>
>  Gyan> I think maybe we should add a section ther dives deep into  details
> of RSVP-TE itself and call it “RSVP-TE” and add to section 5.1.1 as RSVP-TE
> is a IETF TE mechanism so seems to be the appropriate spot.  So bandwidth
> management algorithms auto bandwidth, LSP setup and hold priorities to bump
> LSP, re-optimization.  Also talk about why MPLS-TP used for transport
> modernization did not take off ad well due to only supporting Co-routed
> bidirectional LSP and why RSVP-TE extension for bidirectional Co-routed
> path RFC 7551 knob so that both classic unidirectional LSP and
> bidirectional LSPs are supported.
>
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?
>
>
>
> 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?
>
> Gyan> The new “RSVP-TE” section added can also address this point as well.
>
    I would be happy to build the “RSVP-TE” section

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.
>
> Gyan> I am fine with keeping or removing but not in favor of moving
> current technologies in body to appendix.
>
> [AF] Renaming it to what?
>
>
>
>
>
>
>
> Cheers
>
> Don
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Vishnu Pavan Beeram
> *Sent:* Thursday, June 16, 2022 8:58 AM
> *To:* TEAS WG <teas@ietf.org>
> *Cc:* TEAS WG Chairs <teas-chairs@ietf.org>
> *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 <
> vishnupavan@gmail.com> 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)
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*