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

[Joel Halpern <[e-mail]>]

I would suggest removing the final phrase "primarily to decouple ... "  
Let us avoid speculating on why peopl emade the decision they did quite 
some time ago.

Yours,

Joel

On 7/4/2022 1:11 PM, Gyan Mishra wrote:
>
> Hi Adrian
>
> Here is the CR-LDP text for the appendix
>
> CR-LDP defined in RFC 3212 defines a means of setting up a constraint 
> based LSP using LDP signaling to traffic engineer a path to be 
> instantiated.  CR-LDP proposed an end to end setup mechanism of a 
> constraint-based loose or strict hop routed LSP initiated by the 
> ingress LSR that has an LDP based resource reservation as well as LSP 
> preemption capability for bandwidth management.  CR-LDP development 
> parallels RSVP-TE RFC 3209, and an industry decision was made to 
> continue the development and extensibility of RSVP-TE over CR-LDP, 
> primarily to decouple traffic steering constraint based routing  from 
> IGP SPF based LDP to a separate protocol known as “RSVP-TE”.
>
> 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 removed by sender. <http://www.verizon.com/>
>
>         *Gyan Mishra*
>
>         /Network Solutions Architect /
>
>         /Email [e-mail]/
>
>         /M 301 502-1347/
>
>     -- 
>
>     Image removed by sender. <http://www.verizon.com/>
>
>     *Gyan Mishra*
>
>     /Network Solutions Architect /
>
>     /Email [e-mail]/
>
>     /M 301 502-1347/
>
> -- 
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /Email [e-mail]//
> /
>
> /M 301 502-1347
>
> /
>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas