Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt

[Adrian Farrel <[e-mail]>]

Hi Gyan,

 

Long after you did your review of version 11 of this document, I have been trying to apply your changes to my working copy of version 14.

 

Many of the changes are simple editorial things and are easily accepted. A few of those are rejected as matters of personal style or RFC Editor practice.

 

A number of clarifications or expansions were also easy to deal with.

 

That leaves us with a few larger issues.

 

The biggest one was whether to change the draft from “Overview and Principles of Internet Traffic Engineering” to “Overview and Principles of Traffic Engineering”. I raised this at IETF-112 and said I would take silence as meaning “don’t make the change.” I don’t think I saw anything on the list as a result, an I believe that means we stay as we are and continue the use of the term originally present in RFC 3272.

 

That position has consequences for some of your more detailed comments. In particular you wanted to “to be inclusive of public internet and close or restricted mpls domain private traffic engineering.” Personally, I think this is interpreting “Internet traffic engineering” the wrong way: it is not supposed to mean “traffic engineering that only operates across the whole Internet,” but to mean “traffic engineering techniques used within any part or parts of the Internet.” I think this is clarified near the top of the Introduction with “Even though Internet traffic engineering is most effective when applied end-to-end, the focus of this document is traffic engineering within a given domain (such as an autonomous system).” 

 

This cuts into your proposed change to the Abstract, but there you also suggested a change from “The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking,” to say that the “The document is intended to promote a better understanding of the issues surrounding traffic engineering of customer IP flow forensics and the transport networks that support these IP flows.”  I don’t know how you would traffic engineer an IP flow forensic. Maybe that word is stray, and you just mean “traffic engineering of customer IP flows” but I think that is looking at traffic flows and TE wrongly – the TE process doesn’t care whether the traffic is a customer flow or anything else: it is just traffic flows.

 

In the Introduction you also wanted to move away from “TE in the Internet” to list out the different networks in which you can use TE. I think we stay as we are: we are Internet Engineering Task Force.

 

You proposed some pretty sizeable changes to the first two paragraphs of Section 1.1. I don’t find anything factually incorrect in what you have written, but it doesn’t seem the right place to be saying it. This section is a fairly abstract discussion of what TE is, while you have set out some specific descriptions of how routing and TE work with references to protocols, etc. I tried to find a better place in the document for your text, but it didn’t seem to sit comfortably anywhere.

 

In the RSVP section  (was 4.1.3) you say: “Maybe worth mentioning that one of the scalability issues that lead to the advent of SR intent based traffic steering and elimination of state. L3 VPN / VRF to RSVP-TE tunnel mapping requiring a loopback and next hop re-write with a static routing to map a VRF to a RSVP-TE tunnel which does not scale.  With SR SR-TE we now have scalable per VRF and per flow steering capability.” Without debating what you say or denigrating any implementations, I think that the purpose of these sections is to describe the basic functions of each of the techniques, not to trade off one against the other. It is possible that we could find a home for this text in the section on “Overview of Contemporary TE Practices in Operational IP Networks,” but that section is quite pithy and to the point, so what I have done is reduce this to the simple “and this may have configuration and operational scaling benefits” in the paragraph on SR.

 

For the section on Differentiated Services (was 4.1.4) I have not put in discussion of DiffServ-TE and the various pipe models because this section is about just DiffServ. I have, however, put in a pointer to the section on DiffServ-TE.

 

Your comment about the MPLS section (was 4.1.6) is long and shows your experience using MPLS in the real world. The section is intended to introduce the basic concepts of MPLS, provide references for more detail, and then observe why MPLS is a useful tool for TE. You suggested adding two points:

1.	The first point is about MPLS signaling protocols and how RSVP-TE is preferred over LDP for path steering and IGP bypass. The current text references the requirements for TE over MPLS and points at RSVP-TE. I think that’s enough and we really don’t need to talk about other signaling for MPLS networks that doesn’t provide a tool for TE. We could, of course, look to the section on “Recommendations for Internet Traffic Engineering” and see whether there is something extra we can say there (although I still don’t think that mentioning non-TE mechanisms is something we need to do).
2.	The second point is about the softwire mesh framework (RFC 5565). Unless I am mistaken, softwires form an overlay of virtual adjacencies. There is no TE control in the underlay, but the overlay may select between softwires using any form of routing, configuration, or TE. The selection policies offered in 5565 are fairly simple, but there is a note that more complicated policies could be used, so I suppose TE in the overlay is possible, but I’m not sure that that is any different from TE in that overlay network in the case where the softwires are replaced by physical links: and that, of course, is already covered in the document.

 

In the GMPLS section (was 4.1.7) you suggest mentioning MPLS-TP. I wonder what specifically needs to be mentioned in this context. If what you are after is a note that GMPLS control protocols support packet-switched networks, then that is already there. If, on the other hand, you want to call out MPLS-TP as a variant of MPLS, we should probably put that in the MPLS section. But, and for whatever my opinion is worth, I don’t think MPLS-TP ever amounted to more than an operational way of viewing MPLS networks with a combination of configuration, enhanced OAM, and enhanced control planes. While “MPLS-TP” seems to be mentioned in more than 80 RFCs, is it ever anything except “using MPLS to provide a transport for other protocols in a way that looks like a lower-layer transport network”?

 

In the section on Routing Recommendations (was 6.2) you say (for the bullet on ECMP).

*	“Mention IPv4 is based on uneven flow based load balancing which is subject to polarization of flow due to high bandwidth flows being hashed to the same path.”
Isn’t this exactly what the paragraph in the document says about general hash-based load balancing?

The other comments on this section have been incorporated.

 

For the section on Protection Options (was 6.5.2), but possibly applicable across the whole of the section on Network Survivability (was section 6.5), you say: “Maybe worth mentioning the technology RSVP-TE & SR and its protection schemes available as we as IGP unicast routing local protection via IP-LFA, RLFA, TI-LFA.”

*	MPLS-FRR is already mentioned higher up. It is definitely a form of TE.
*	I’ve added a mention and reference for TI-LFA at around the same place.
*	Are the local protection schemes in the IGPs actually forms of TE, or are they IGP alternate routes? I’m not really sure.

 

That all looks like a lot of negative stuff, but that is because I’ve only commented on the things not done. Lots of good stuff folded in.

 

Cheers,

Adrian

 

 

From: Gyan Mishra <[e-mail]> 
Sent: 27 May 2021 04:53
To: Mohamed BOUCADAIR <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt

 

Hi Adrian

 

Attached is the review of 3272bis version 11  word document with comments along the side.

 

I added some verbiage in the abstract & introduction section describing the three operator environments that exist 1. Public internet, 2. Private domain with external customers, 3. Internal corporate intranet domain

Throughout the draft I changed "internet traffic engineering" to "traffic engineering" as there are three unique use cases of traffic engineering which I described each in detail.   

 

Also once "traffic engineering (TE) referred to traffic engineering as "TE"  is noted I believe my comment is in the intro section that we should not have to spell TE out explicitly each time throughout the draft except when a sentence starts with "traffic engineering".  

 

Some minor comments throughout the draft.  

 

Under the protection section I mentioned local protection which I think should be mentioned LFA, RLFA, TI-LFA.  

 

Section 6.2 - I had some comments related to ECMP that if you would like I can do a write-up on ECMP.  

 

Under 4.1.16 SR-MPLS is mentioned but not SRv6 so I thought it may be worthwhile to mention SRv6 as uses SR-TE steering even though not mpls based but as another form of steering using IPv6 data plane. 

 

Lastly,

 

I noticed Multicast was not mentioned under IETF projects section or anywhere else in the draft. I can add some verbiage to a section and talk about P2MP TE & replication sid.  I did not comment on this in the draft as no multicast section exists.

 

Kind Regards

 

Gyan

 

On Sat, May 22, 2021 at 11:26 AM Gyan Mishra <[e-mail] <mailto:[e-mail]> > wrote:

 

Hi Adrian 

 

I see you published a version 12.  I went through all of MEDs updates in version 11 and ensured that my updates are mutually exclusive no overlap of MEDs updates.  

 

I built my updated on version 11.  I am almost done and will send out tomorrow night.

 

Thanks 

 

Gyan

 

On Tue, May 18, 2021 at 11:00 AM <[e-mail] <mailto:[e-mail]> > wrote:

Hi Adrian, 

Thank you for the replies. Here is some few follow-up points:

* s/within the control plane or by controllers/within the control or management plane

* "I'm not clear about the term "resource-based access control". Do you mean "policing"? If so, yes. Policing is mentioned just two sentences later"

I actually meant resource-based admission control. This is now covered by the new section you added. Thanks. 

* " The word "economically" is, I think, giving you a different meaning to what is intended. I think the word is not intended to just mean "financially economical", but also to mean "not wasteful or profligate." This is similar to "efficient", but not the same. In this context, "economically" would certainly apply to power use, money, and any other resource.
I spent a little time trying to think of an equivalent word (because if it is causing you unrest, it will do the same for other readers), but I was unable to think of one.": 

The concern I had is that the observed behavior is conditioned by the metrics/attributes/information that can be disseminated and acted upon. Optimizing the forwarding with a set of metrics as inputs does not guarantee that the overall forwarding is economically-optimized. That's why I provided the example of power-consumption. Such optimization is not currently supported at the level of a network (despite that some optimization can be made at the node/card level).

Cheers,
Med

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[e-mail] <mailto:[e-mail]> ]
> Envoyé : samedi 15 mai 2021 19:40
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail] <mailto:[e-mail]> >
> Objet : RE: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt
> 
> Here's the file.
> 
> Many thanks for looking at this.
> 
> Adrian
> 
> -----Original Message-----
> From: Adrian Farrel <[e-mail] <mailto:[e-mail]> >
> Sent: 15 May 2021 18:11
> To: '[e-mail] <mailto:[e-mail]> ' <[e-mail] <mailto:[e-mail]> >;
> '[e-mail] <mailto:[e-mail]> ' <[e-mail] <mailto:[e-mail]> >
> Cc: 'TEAS WG Chairs' <[e-mail] <mailto:[e-mail]> >
> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt
> 
> Hi Med,
> 
> Thanks for all of your comments.
> 
> Nearly everything is accepted and included.
> 
> Not sure the best way to respond to your Word file, so I embedded my
> responses and I'll send it to you under separate cover (no need to
> spam the mailing list).
> 
> There'll be a -12 along soon to capture your improvements.
> 
> Best,
> Adrian
> 
> -----Original Message-----
> From: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
> Sent: 03 May 2021 15:49
> To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
> Cc: 'TEAS WG Chairs' <[e-mail] <mailto:[e-mail]> >
> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt
> 
> Hi Adrian, all,
> 
> FWIW, you may find some comments at:
> * pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-
> ietf-teas
> -rfc3272bis-11-rev%20Med.pdf
> * doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-
> ietf-teas-
> rfc3272bis-11-rev%20Med.docx
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Teas [mailto:[e-mail] <mailto:[e-mail]> ] De la part de Adrian
> Farrel
> > Envoyé : mercredi 7 avril 2021 21:24 À : [e-mail] <mailto:[e-mail]>  Cc : 'TEAS
> WG
> > Chairs' <[e-mail] <mailto:[e-mail]> > Objet : Re: [Teas] I-D Action:
> > draft-ietf-teas-rfc3272bis-11.txt
> >
> > With this version I have filled in the remaining TBDs:
> > - small section on intent-based network
> > - small section on multi-layer TE (thanks, Lou, for the suggestion)
> > - change log from 3272
> >
> > As far as I'm concerned this document is complete modulo review
> > comments.
> >
> > It *really* needs review, but I can't force you!
> > Maybe you can look at the sections of special interest to you?
> > Maybe the original Design Team could take another look?
> >
> > Otherwise: time for WG last call?
> >
> > Thanks,
> > Adrian
> >
> > -----Original Message-----
> > From: I-D-Announce <[e-mail] <mailto:[e-mail]> > On Behalf Of
> > [e-mail] <mailto:[e-mail]> 
> > Sent: 07 April 2021 19:25
> > To: [e-mail] <mailto:[e-mail]> 
> > Cc: [e-mail] <mailto:[e-mail]> 
> > Subject: I-D Action: draft-ietf-teas-rfc3272bis-11.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Traffic Engineering Architecture
> and
> > Signaling WG of the IETF.
> >
> >         Title           : Overview and Principles of Internet
> Traffic
> > Engineering
> >         Author          : Adrian Farrel
> >     Filename        : draft-ietf-teas-rfc3272bis-11.txt
> >     Pages           : 91
> >     Date            : 2021-04-07
> >
> > Abstract:
> >    This document describes the principles of traffic engineering
> (TE)
> > in
> >    the Internet.  The document is intended to promote better
> >    understanding of the issues surrounding traffic engineering in
> IP
> >    networks and the networks that support IP networking, and to
> > provide
> >    a common basis for the development of traffic engineering
> >    capabilities for the Internet.  The principles, architectures,
> and
> >    methodologies for performance evaluation and performance
> > optimization
> >    of operational networks are also discussed.
> >
> >    This work was first published as RFC 3272 in May 2002.  This
> > document
> >    obsoletes RFC 3272 by making a complete update to bring the text
> in
> >    line with best current practices for Internet traffic
> engineering
> > and
> >    to include references to the latest relevant work in the IETF.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-teas-rfc3272bis/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-teas-rfc3272bis-11
> > https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc3272bis-11
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rfc3272bis-11
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org <http://tools.ietf.org> .
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail] <mailto:[e-mail]> 
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail] <mailto:[e-mail]> 
> > https://www.ietf.org/mailman/listinfo/teas
> 
> _____________________________________________________________________
> _______
> _____________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
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