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

[Adrian Farrel <[e-mail]>]

Thanks, I’ll work on that.

 

A

 

From: Gyan Mishra <[e-mail]> 
Sent: 04 July 2022 18:12
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 

 

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] <mailto:[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] <mailto:[e-mail]> > 
Sent: 03 July 2022 20:04
To: [e-mail] <mailto:[e-mail]> 
Cc: Don Fedyk <[e-mail] <mailto:[e-mail]> >; TEAS WG <[e-mail] <mailto:[e-mail]> >; TEAS WG Chairs <[e-mail] <mailto:[e-mail]> >; Vishnu Pavan Beeram <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]> > wrote:

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.

 

   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] <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)

_______________________________________________
Teas mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/teas

-- 

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

Gyan Mishra

Network Solutions Architect 

Email [e-mail] <mailto:[e-mail]> 

M 301 502-1347

 

-- 

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

Gyan Mishra

Network Solutions Architect 

Email [e-mail] <mailto:[e-mail]> 

M 301 502-1347

 

-- 

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

Gyan Mishra

Network Solutions Architect 

Email [e-mail] <mailto:[e-mail]> 

M 301 502-1347