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

[Gyan Mishra <[e-mail]>]

Hi Adrian

Sure will do for both points.

Thanks

Gyan

On Sun, Jul 3, 2022 at 5:15 PM Adrian Farrel <[e-mail]> wrote:

> Hi Gyan,
>
>
>
> Answering both of your emails in one place.
>
>
>
> Working with Dhruv, we now have a new RSVP-TE section at 5.1.3.4.
>
> Considering that no section of this document provides a detailed
> description of all of the mechanisms and features available with the
> technology covered by the section, please suggest text (not just points to
> be covered).
>
>
>
> As far as CR-LDP is concerned, it could merit a two or three line
> paragraph in Appendix A although I would not think it crucial. Again, send
> text.
>
>
>
> Cheers,
>
> Adrian
>
>
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* 03 July 2022 20:04
> *To:* [e-mail]
> *Cc:* Don Fedyk <[e-mail]>; TEAS WG <[e-mail]>; TEAS WG
> Chairs <[e-mail]>; Vishnu Pavan Beeram <[e-mail]>
> *Subject:* Re: [Teas] WG Last Call: draft-ietf-teas-rfc3272bis-16
>
>
>
>
>
> Hi Adrian
>
>
>
> RFC 3212 CR-LSP is historical and I don’t think it was implemented or
> deployed but could be something added to the appendix A / B section.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sun, Jul 3, 2022 at 2:54 PM Gyan Mishra <[e-mail]> wrote:
>
> 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 <[e-mail]>
> wrote:
>
> Hey Don,
>
>
>
> Thanks for the review.
>
>
>
> Responses in line.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Teas <[e-mail]> *On Behalf Of *Don Fedyk
> *Sent:* 23 June 2022 17:44
> *To:* 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
>
>
>
> 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 <[e-mail]> *On Behalf Of *Vishnu Pavan Beeram
> *Sent:* Thursday, June 16, 2022 8:58 AM
> *To:* TEAS WG <[e-mail]>
> *Cc:* TEAS WG Chairs <[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]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*