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

From: Gyan Mishra <[email-masked]>
Date: Sat, 1 May 2021 14:50:01 -0400

Hi Adrian

I reviewed the latest revision 11 and it looks excellent and well done by
all the feedback from WG thus far.

I am still in the process of building some minor updates as it relates to
design and architectural flavors of TE deployments as within Verizon we
have a variety of deployments and the goals are different in each
environment public internet or private MPLS / SR or internal
implementations.

The major difference in implementation is the goal of congestion control
and avoidance versus traffic flow bandwidth management as the goals and
objectives are very different and there is also as well a mixture hybrid of
both concepts as well.  Also some thoughts on what works well and what does
not and the critical component of overall good network capacity planning
and based on the congestion control or avoidance design that if your have
enough of capacity for high bw flows the amount of TE is minimal if any.
Also idea of leveraging IGP based metrics to provide bandwidth delay
framework which eliminates that function to be provided by TE concept
framework which also limits the amount of TE necessary.

I should be completed in about a week maybe less.

Kind Regards

Gyan

On Fri, Apr 9, 2021 at 5:56 AM Adrian Farrel <[email-masked]> wrote:

> Come one, come all [1]
>
>
>
> Yes. Let’s set end of April for everyone. Then I can do an update and then
> the chairs can last call it.
>
>
>
> Adrian
>
>
>
> [1] Moto of the No 253 (Hyderabad State) Squadron, Royal Air Force.
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* 09 April 2021 03:46
> *To:* [email-masked]
> *Cc:* TEAS WG Chairs <[email-masked]>; [email-masked]
> *Subject:* Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt
>
>
>
>
>
> Hi Adrian
>
>
>
> End of April works for me better as well if you are good.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Thu, Apr 8, 2021 at 10:42 PM Gyan Mishra <[email-masked]> wrote:
>
>
>
> Hi Adrian
>
>
>
> I will plan to complete the review by tomorrow.
>
>
>
> Sorry for the delay.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Wed, Apr 7, 2021 at 3:24 PM Adrian Farrel <[email-masked]> wrote:
>
> 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
>
> --
>
>  <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [email-masked] <[email-masked]>*
>
> *M 301 502-1347*
>
>
>
> --
>
>  <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *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: "Adrian Farrel" <[email-masked]>
Date: Sat, 1 May 2021 21:51:51 +0100

Excellent. Thanks. Looking forward to seeing your thoughts.

Best,

Adrian

From: Gyan Mishra <[email-masked]> 
Sent: 01 May 2021 19:50
To: [email-masked]
Cc: TEAS WG Chairs <[email-masked]>; [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt

Hi Adrian

I reviewed the latest revision 11 and it looks excellent and well done by all the feedback from WG thus far.

I am still in the process of building some minor updates as it relates to design and architectural flavors of TE deployments as within Verizon we have a variety of deployments and the goals are different in each environment public internet or private MPLS / SR or internal implementations.  

The major difference in implementation is the goal of congestion control and avoidance versus traffic flow bandwidth management as the goals and objectives are very different and there is also as well a mixture hybrid of both concepts as well.  Also some thoughts on what works well and what does not and the critical component of overall good network capacity planning and based on the congestion control or avoidance design that if your have enough of capacity for high bw flows the amount of TE is minimal if any.  Also idea of leveraging IGP based metrics to provide bandwidth delay framework which eliminates that function to be provided by TE concept framework which also limits the amount of TE necessary.  

Kind Regards 

Gyan

On Fri, Apr 9, 2021 at 5:56 AM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Come one, come all [1]

Yes. Let’s set end of April for everyone. Then I can do an update and then the chairs can last call it.

Adrian

From: Gyan Mishra <[email-masked] <mailto:[email-masked]> > 
Sent: 09 April 2021 03:46
To: [email-masked] <mailto:[email-masked]> 
Cc: TEAS WG Chairs <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt

Hi Adrian 

Thanks 

Gyan 

On Thu, Apr 8, 2021 at 10:42 PM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Hi Adrian 

Sorry for the delay.

Kind Regards 

Gyan

On Wed, Apr 7, 2021 at 3:24 PM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Thanks,
Adrian

-----Original Message-----
From: I-D-Announce <[email-masked] <mailto:[email-masked]> > On Behalf Of
[email-masked] <mailto:[email-masked]> 
Sent: 07 April 2021 19:25
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: I-D Action: draft-ietf-teas-rfc3272bis-11.txt

Abstract:

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

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

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

-- 

Gyan Mishra

Network Solutions Architect 

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

M 301 502-1347

-- 

Gyan Mishra

Network Solutions Architect 

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

M 301 502-1347

-- 

Gyan Mishra

Network Solutions Architect 

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

M 301 502-1347

---

From: <[email-masked]>
Date: Mon, 3 May 2021 14:49:19 +0000

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
> 
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

_________________________________________________________________________________________________________________________

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: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 May 2021 19:17:03 +0100

Thanks Med,

I'm working on this now.

Imagine, hithub as a way of  exchanging a PDF version of Word mark-up
document :-)

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

> ftp://ftp.ietf.org/internet-drafts/

____________________________________________________________________________
_____________________________________________

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: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 May 2021 18:11:27 +0100

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, 

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 17 May 2021 15:47:17 +0000

Hi Adrian, 

Thank you for taking care of the comments. I appreciate in particular the new section about resource-based access control.  

As indicated in my review, I would restructure section because the logic for listing these techniques is not clear to me. Please find below a proposal for discussion.

I will send in a separate message a text proposal for the "Transport-based TE (was QUIC)" Section. 

(1)

OLD:
   5.  Review of TE Techniques . . . . . . . . . . . . . . . . . . .  28
     5.1.  Overview of IETF Projects Related to Traffic Engineering   28
       5.1.1.  Constraint-Based Routing  . . . . . . . . . . . . . .  29
       5.1.2.  Integrated Services . . . . . . . . . . . . . . . . .  31
       5.1.3.  RSVP  . . . . . . . . . . . . . . . . . . . . . . . .  31
       5.1.4.  Differentiated Services . . . . . . . . . . . . . . .  32
       5.1.5.  QUIC  . . . . . . . . . . . . . . . . . . . . . . . .  33
       5.1.6.  Multiprotocol Label Switching (MPLS)  . . . . . . . .  34
       5.1.7.  Generalized MPLS (GMPLS)  . . . . . . . . . . . . . .  34
       5.1.8.  IP Performance Metrics  . . . . . . . . . . . . . . .  35
       5.1.9.  Flow Measurement  . . . . . . . . . . . . . . . . . .  35
       5.1.10. Endpoint Congestion Management  . . . . . . . . . . .  36
       5.1.11. TE Extensions to the IGPs . . . . . . . . . . . . . .  36
       5.1.12. Link-State BGP  . . . . . . . . . . . . . . . . . . .  37
       5.1.13. Path Computation Element  . . . . . . . . . . . . . .  37
       5.1.14. Application-Layer Traffic Optimization  . . . . . . .  38
       5.1.15. Segment Routing with MPLS Encapsulation (SR-MPLS) . .  39
       5.1.16. Segment Routing Policy  . . . . . . . . . . . . . . .  40
       5.1.17. Network Virtualization and Abstraction  . . . . . . .  41
       5.1.18. Network Slicing . . . . . . . . . . . . . . . . . . .  41
       5.1.19. Deterministic Networking  . . . . . . . . . . . . . .  42
       5.1.20. Network TE State Definition and Presentation  . . . .  43
       5.1.21. System Management and Control Interfaces  . . . . . .  43

NEW:
   5.  Review of TE-Related Techniques
                   ^^^^^^^^ 
     5.1.  Overview of IETF Projects Related to Traffic Engineering
       5.1.1.  TE Mechanisms
           5.1.1.1. Integrated Services . . . . . . . . . . . . . . . .
           5.1.1.2. Differentiated Services with TE Extensions . . . . 
                    (was Differentiated Services)
           5.1.1.3. Segment Routing Policy  . . . . . . . . . . . . . .
           5.1.1.4. Transport-based TE (was QUIC) . . . . . . . . . . .
           5.1.1.5. Deterministic Networking  . . . . . . . . . . . . .

       5.1.2.  Approaches Relying on TE Mechanisms
           5.1.2.1. Application-Layer Traffic Optimization  . . . . . .
           5.1.2.2. Network Virtualization and Abstraction  . . . . . .
           5.1.2.3. Network Slicing . . . . . . . . . . . . . . . . . .

       5.1.3.  Techniques Used by TE Mechanisms
           5.1.3.1.  Constraint-Based Routing  . . . . . . . . . . . . 
           5.1.3.2.  RSVP  . . . . . . . . . . . . . . . . . . . . . . 
           5.1.3.3.  Multiprotocol Label Switching (MPLS)  . . . . . . 
           5.1.3.4.  Generalized MPLS (GMPLS)  . . . . . . . . . . . . 
           5.1.3.5.  IP Performance Metrics  . . . . . . . . . . . . . 
           5.1.3.6.  Flow Measurement  . . . . . . . . . . . . . . . . .
           5.1.3.7.  Endpoint Congestion Management  . . . . . . . . . .
           5.1.3.8.  TE Extensions to the IGPs . . . . . . . . . . . . .
           5.1.3.9.  Link-State BGP  . . . . . . . . . . . . . . . . . .
           5.1.3.10. Path Computation Element  . . . . . . . . . . . . .
           5.1.3.11. Segment Routing with MPLS Encapsulation (SR-MPLS) .
           5.1.3.12. Network TE State Definition and Presentation  . . .
           5.1.3.13. System Management and Control Interfaces  . . . . .

(2)

OLD:
   This section briefly reviews different traffic engineering approaches
   proposed and implemented in telecommunications and computer networks
   using IETF protocols and architectures.  The discussion is not
   intended to be comprehensive.  It is primarily intended to illuminate
   existing approaches to traffic engineering in the Internet.  A
   historic overview of traffic engineering in telecommunications
   networks is provided in Appendix A, while Appendix B describes
   approaches in other standards bodies.

NEW:
   This section briefly reviews different TE-related approaches proposed
   and implemented in telecommunications and computer networks using
   IETF protocols and architectures.  These approaches are organized
   into three categories: TE mechanisms which adhere to the definition
   provided in Section 1.2, approaches that rely upon TE mechanisms, and
   techniques that are used by TE mechanisms.

   The discussion is not intended to be comprehensive.  It is primarily
   intended to illuminate existing approaches to traffic engineering in
   the Internet.  A historic overview of traffic engineering in
   telecommunications networks is provided in Appendix A, while
   Appendix B describes approaches in other standards bodies.

(3)

Add a table to indicate whether mechanisms that are tagged as "TE are "partial TE" or "full TE" as per the discussion in 1.2. This can be captured by indicating which properties are supported by each of them. A table (to be completed) is provided below, fwiw: 

                   +---------------+---------------+---------------+
                   | Policy        | Path Steering | Resource      |
                   |               |               | Management    |
       +-----------+---------------+---------------+---------------+
       | IntServ   | TBC           | TBC           | TBC           |
       | DS-TE     | TBC           | TBC           | TBC           |
       | SR Policy | TBC           | TBC           | TBC           |
       | DetNet    | TBC           | TBC           | TBC           |
       +-----------+---------------+---------------+---------------+

Cheers,
Med

> De : Adrian Farrel [mailto:[email-masked]]
> Envoyé : samedi 15 mai 2021 19:11
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]
> Objet : RE: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt
> 
> Hi Med,
> 
> responses and I'll send it to you under separate cover (no need to
> spam the mailing list).
>

---

From: <[email-masked]>
Date: Tue, 18 May 2021 13:50:35 +0000

Hi Adrian, all,

>            5.1.1.4. Transport-based TE (was QUIC) . . . . . . . . . 

As promised, please find below a proposal fwiw:

======================
X.  Transport-based TE (was QUIC)

   In addition to IP-based TE mechanisms, transport-based TE approaches
   can be considered in specific deployment contexts (e.g., data
   centers, multi-homing).  For example, the 3GPP defines the
   Access Traffic Steering, Switching, and Splitting (ATSSS) service
   that is applicable between multiple access networks.  The ATSSS
   functions are described below:

   Access Traffic Steering:  is the selection of an access network for a
      new flow and the transfer of the traffic of that flow over the
      selected access network.

   Access Traffic Switching:  is the migration of all packets of an
      ongoing flow from one access network to another access network.
      Only one access network is in use at a time.

   Access Traffic Splitting:  is about forwarding the packets of a flow
      across multiple access networks simultaneously.

   Hosts and specific network devices are provided by means of the
   control plane with a set or policies that specify which flows are
   eligible to the ATSSS service.  The traffic that matches an ATSSS
   policy can be distributed among the available access networks
   following one of these modes:

   Active-Standby:   The traffic is forwarded via a specific access
      (called 'active access') and switched to another access (called
      'standby access') when the active access is unavailable.

   Priority-based:   Network accesses are assigned priority levels that
      indicate which network access to be used first.  The traffic
      associated with the matching flow will be steered on the network
      access with a high priority till congestion is detected, then the
      overflow will be forwarded over a low priority access.

   Load-Balancing:   The traffic is distributed among the available
      access networks following a distribution ratio (e.g., 75% via a
      first network access, 25% via a second network access).

   Smallest Delay:   The traffic is forwarded via the access that
      presents the smallest round-trip-time (RTT).

   For resource management purposes, hosts and involved network devices
   support means such as congestion control, RTT measurement, and packet
   scheduling.  

   For TCP traffic, Multipath TCP [RFC8684] and the 0-RTT
   Convert Protocol [RFC8803] are used to provide the ATSSS service.

   Note that for QUIC [I-D.ietf-quic-transport], it is possible to
   support the switching and steering functions, but splitting is not
   yet supported.  Indeed, QUIC supports a connection migration
   procedure which allows peers to change their transport coordinates
   (IP addresses, port numbers) without breaking the underlying QUIC
   connection.

   The reader may refer to Section 2.5 of [I-D.irtf-panrg-questions] for
   some research investigation areas.
===============

Cheers,
Med

---

From: <[email-masked]>
Date: Tue, 18 May 2021 15:00:33 +0000

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

> Envoyé : samedi 15 mai 2021 19:40
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Here's the file.
> Many thanks for looking at this.
> 
> Adrian
> 
> From: Adrian Farrel <[email-masked]>
> Sent: 15 May 2021 18:11
> To: [email-masked]' <[email-masked]>;
> [email-masked]' <[email-masked]>
> > 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
> >
> >    This document describes the principles of traffic engineering
> (TE)
> > in
> >    line with best current practices for Internet traffic
> engineering
> > and
> 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.

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 22 May 2021 11:26:08 -0400

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:

> * "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"
>
> * " 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
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 26 May 2021 23:52:34 -0400

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:

>> * " 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

-- 

*Gyan Mishra*

*M 301 502-1347*