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

From: Gyan Mishra <[email-masked]>
Date: Tue, 1 Jun 2021 22:18:35 -0400

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 <[email-masked]> 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 <[email-masked]>
> 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 <[email-masked]> 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:[email-masked]]
>>> > Envoyé : samedi 15 mai 2021 19:40
>>> > À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
>>> > 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 <[email-masked]>
>>> > Sent: 15 May 2021 18:11
>>> > To: [email-masked]' <[email-masked]>;
>>> > [email-masked]' <[email-masked]>
>>> > Cc: 'TEAS WG Chairs' <[email-masked]>
>>> > 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: [email-masked] <[email-masked]>
>>> > Sent: 03 May 2021 15:49
>>> > To: [email-masked]; [email-masked]
>>> > Cc: 'TEAS WG Chairs' <[email-masked]>
>>> > 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:[email-masked]] De la part de Adrian
>>> > Farrel
>>> > > Envoyé : mercredi 7 avril 2021 21:24 À : [email-masked] Cc : 'TEAS
>>> > WG
>>> > > Chairs' <[email-masked]> 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 <[email-masked]> On Behalf Of
>>> > > [email-masked]
>>> > > Sent: 07 April 2021 19:25
>>> > > To: [email-masked]
>>> > > Cc: [email-masked]
>>> > > 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
>>> > > [email-masked]
>>> > > 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
>>> > > [email-masked]
>>> > > 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/teas
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [email-masked] <[email-masked]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [email-masked] <[email-masked]>*
>
>
>
> *M 301 502-1347*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Wed, 2 Jun 2021 15:34:09 +0000

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:[email-masked]] De la part de Gyan Mishra
Envoyé : mercredi 2 juin 2021 04:19
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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".

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Adrian,

* 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

> De : Adrian Farrel [mailto:[email-masked]<mailto:[email-masked]>]
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>
> From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
> Sent: 15 May 2021 18:11
> To: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
> Cc: 'TEAS WG Chairs' <[email-masked]<mailto:[email-masked]>>
> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> Sent: 03 May 2021 15:49
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: 'TEAS WG Chairs' <[email-masked]<mailto:[email-masked]>>
> > De : Teas [mailto:[email-masked]<mailto:[email-masked]>] De la part de Adrian
> Farrel
> > Envoyé : mercredi 7 avril 2021 21:24 À : [email-masked]<mailto:[email-masked]> Cc : 'TEAS
> WG
> > Chairs' <[email-masked]<mailto:[email-masked]>> Objet : Re: [Teas] I-D Action:
> > From: I-D-Announce <[email-masked]<mailto:[email-masked]>> On Behalf Of
> > [email-masked]<mailto:[email-masked]>
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > tools.ietf.org<http://tools.ietf.org>.
> >
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

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
[email-masked]<mailto:[email-masked]>
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 [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

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

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

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

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

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.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 2 Jun 2021 11:51:03 -0400

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 <[email-masked]> 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)…“
>
>
>
> *De :* Teas [mailto:[email-masked]] *De la part de* Gyan Mishra
> *Envoyé :* mercredi 2 juin 2021 04:19
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* [email-masked]; [email-masked]
>
>
> *Objet :* Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt
>
>
>
> Hi Adrian
>
>
>
> * " 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
> 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
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Wed, 2 Jun 2021 16:05:17 +0000

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

Envoyé : mercredi 2 juin 2021 17:51

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Cheers,
Med

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

Hi Adrian

Thank you

Gyan

Lastly,

Kind Regards

Gyan

Hi Adrian

Thanks

Gyan

Cheers,
Med

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

Thank you.
--

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 2 Jun 2021 17:00:30 -0400

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 <[email-masked]> 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
>
>
>
> *Envoyé :* mercredi 2 juin 2021 17:51
>
>

*Gyan Mishra*

*M 301 502-1347*