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 <hayabusagsm@gmail.com> 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 <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*
>
> --

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