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

Hi Adrian

Just checking if you had a chance to review my updates after Meds, I
believe it was in early June.

Kind Regards

Gyan

On Wed, Jun 2, 2021 at 5:00 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Agreed.  I agree with your counter proposal using  IP/MPLS in abstract and
> not diving in till the introduction and beyond.
>
> Kind Regards
>
> Gyan
>
>
>
> On Wed, Jun 2, 2021 at 12:05 PM <mohamed.boucadair@orange.com> wrote:
>
>> 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:teas-bounces@ietf.org] *De la part de* Gyan Mishra
>> *Envoyé :* mercredi 2 juin 2021 17:51
>>
>>
>> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
>> *Cc :* adrian@olddog.co.uk; teas@ietf.org
>> *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 <mohamed.boucadair@orange.com> 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:teas-bounces@ietf.org] *De la part de* Gyan Mishra
>> *Envoyé :* mercredi 2 juin 2021 04:19
>> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
>> *Cc :* adrian@olddog.co.uk; teas@ietf.org
>>
>>
>> *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 <hayabusagsm@gmail.com>
>> 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 <hayabusagsm@gmail.com>
>> 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 <mohamed.boucadair@orange.com> 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:adrian@olddog.co.uk]
>> > Envoyé : samedi 15 mai 2021 19:40
>> > À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
>> > 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 <adrian@olddog.co.uk>
>> > Sent: 15 May 2021 18:11
>> > To: 'mohamed.boucadair@orange.com' <mohamed.boucadair@orange.com>;
>> > 'teas@ietf.org' <teas@ietf.org>
>> > Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
>> > 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: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
>> > Sent: 03 May 2021 15:49
>> > To: adrian@olddog.co.uk; teas@ietf.org
>> > Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
>> > 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:teas-bounces@ietf.org] De la part de Adrian
>> > Farrel
>> > > Envoyé : mercredi 7 avril 2021 21:24 À : teas@ietf.org Cc : 'TEAS
>> > WG
>> > > Chairs' <teas-chairs@ietf.org> 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 <i-d-announce-bounces@ietf.org> On Behalf Of
>> > > internet-drafts@ietf.org
>> > > Sent: 07 April 2021 19:25
>> > > To: i-d-announce@ietf.org
>> > > Cc: teas@ietf.org
>> > > 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.
>> > >
>> > > Internet-Drafts are also available by anonymous FTP at:
>> > > ftp://ftp.ietf.org/internet-drafts/
>> > >
>> > >
>> > > _______________________________________________
>> > > I-D-Announce mailing list
>> > > I-D-Announce@ietf.org
>> > > 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
>> > > Teas@ietf.org
>> > > 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
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *M 301 502-1347*
>>
>>
>>
>>
>>
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *M 301 502-1347*
>>
>>
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *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://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *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://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*