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

[[e-mail]]

Re-,

I see. Thanks.

Assuming we do have a clear definition of each of the domains you mentioned (and I must admit I have troubles with some of them) and that we are able to call out TE specifics for each of them, then it is definitely worth to discuss them in the core of the document.

I don’t think the abstract is the right place to dive into this and catch subtleties, hence the counter proposal in my previous message to just refer to single domain + inter-domain.

Cheers,
Med

De : Teas [mailto:[e-mail]] De la part de Gyan Mishra
Envoyé : mercredi 2 juin 2021 17:51
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt


Hi Med

In the proposal I defined the three types of networks and the one aspect where they greatly differ is that the internet is not a closed domain where the other two are closed domains and so the problems being solved as well as solutions vary greatly.  I added quite a bit of verbiage in the proposal into the abstract as well as introduction to further define the three network types.

I think if it was just semantics then I agree IP/MPLS would cover but as I am definitely there real world cases that operators have to deal with I think it’s better to spell out explicitly.

Kind Regards

Gyan

On Wed, Jun 2, 2021 at 11:34 AM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

I’m not Adrian but I have one quick comment about your proposal to tweak the abstract to: “This document describes the principles of traffic engineering (TE) in the public internet domain, private domain with public customers , and internal intranet domain…”. I do agree with you that the use of “Internet TE” in the document is confusing but I’m afraid that “public Internet domain” and “internal intranet domain” may not help increasing clarity. Instead I would suggest something such as the following:

“This document describes the principles of traffic engineering (TE) in IP/MPLS networks. These principles can be applied within limited domains (e.g., an autonomous system) or span multiple domains (e.g., Internet)…“

The title can be updated as well.

Cheers,
Med

De : Teas [mailto:[e-mail]<mailto:[e-mail]>] De la part de Gyan Mishra
Envoyé : mercredi 2 juin 2021 04:19
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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

Hi Adrian

Just checking if you had any questions related to the feedback on my review.

Thank you

Gyan

On Wed, May 26, 2021 at 11:52 PM Gyan Mishra <[e-mail]<mailto:[e-mail]>> wrote:
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://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347



--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347


_________________________________________________________________________________________________________________________



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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347


_________________________________________________________________________________________________________________________

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.