Subject: Re: [spring] 答复: Updating the SPRING WG Charter

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Jun 2018 15:24:41 +0000

Hi Jie,

Thanks for your follow-up.

I am ok with the text in the "current" Charter. That is because the "current" text does NOT assume a solution. By converting the current text

Current Charter Text: Some types of network virtualization, including multi-topology networks and the partitioning of network resources for VPNs.

To

New WG work-item/ milestone: "Using SR as the mechanism to identify sets of resources in networks with SR-MPLS and SRv6 dataplanes"

The new text is assuming a solution (as reasoned in my earlier email, e.g., a (fully) controller-based solution will not require "mechanism to identify sets of resources in networks").

I would suggest the following change:
"Using SR as the mechanism for partitioning network resources with SR-MPLS and SRv6 data planes."

Secondly, the earlier the text was part of the charter and not a milestone. Hence, my previous comment on the logic of adding this task to the "work items" list still applies. And if we include this as a work-items, why did we drop a few items raised by many (before/ during IETF in London and as part of the review of the charter draft) on the list for inclusion in the "work items" list. I am hoping for consistency in making such determination in the final version of the charter.

Thanks

Regards … Zafar

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Friday, June 15, 2018 at 11:13 AM
To: "Zafar Ali (zali)" <[email-masked]>, "Zafar Ali (zali)" <zali=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: SPRING WG List <[email-masked]>, Rob Shakir <robjs=[email-masked]>
Subject: 答复: [spring] Updating the SPRING WG Charter

Hi Zafar,

I’d like to remind you that in the current SPRING charter there is already one work item as below:

 o    Some types of network virtualization, including multi-
       topology networks and the partitioning of network
       resources for VPNs

IMO the work item you are referring to is not a new one, actually it is an update or rephrasing of the previous one. Thus it is not relevant to the logic of adding new work items. The VPN+ drafts are just piece of work matching with this existing work item.

I believe there is consistent rules of adding new work items to the charter, and it would be very helpful to concentrate on constructive discussion of those topics.

Best regards,
Jie

发件人: Zafar Ali (zali) [mailto:[email-masked]]
发送时间: 2018年6月14日 19:44
收件人: Dongjie (Jimmy) <[email-masked]>; Zafar Ali (zali) <zali=[email-masked]>; [email-masked]
抄送: SPRING WG List <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Zafar Ali (zali) <[email-masked]>
主题: Re: [spring] Updating the SPRING WG Charter

Hi Jie,

While I look forward to reviewing the draft, at the moment of writing the charter no such details were available. At the moment we do not know if this would be an architecturally correct option to adopt in segment routing; what type of complexity, statefulness and scalability concerns it brings to the table. We also don't know if this is a matter of local implementation or are we better off if it is entirely done at the controller, etc.

The work you are doing is already in the charter by the virtue of "SPRING WG serves as a forum to discuss SPRING networks operations, define new applications, and specify extensions of Segment Routing technologies."

What puzzles me is the logic of adding this task to the "work items" list. And if we go with the same logic, why did we drop a few items raised by many (before/ during IETF in London and as part of the review of the charter draft) on the list for inclusion in the "work items" list. I am hoping for consistency in making such determination in the final version of the charter.

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 13, 2018 at 11:26 PM
To: "Zafar Ali (zali)" <zali=[email-masked]<mailto:zali=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Zafar,

As mentioned in my previous mail, the VPN+ drafts and this work item require new functionality to be added to SR, which is to associate SR with particular allocated resources and treatment. IMO this is not covered by existing SR mechanisms. It is different from Diffserv QoS, and it is not pure controller-based accounting, because in the data plane some mechanism is needed to make sure different services will be treated accordingly and not impact each other.

Thanks for the comments in London, we are working on the updates of the VPN+ drafts, hopefully they will be published for open review soon.

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, June 13, 2018 11:30 PM
To: [email-masked]<mailto:[email-masked]>; Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Bruno,

I am aware of the VPN+ draft but IMO this document or Slicing, in general, is an informational use-case document (E.g., similarly SD-WAN does not have a milestone in the Charter). I do not think that there is any new behavior needed beyond SRTE, SRVPN, Flex-Algo, Diffserv QoS and SR SFC, etc. What is missing is the controller doing the bandwidth (resource) accounting but this outside the scope of IETF. Furthermore, the specifics in the VPN+ specifics draft against this milestone are missing. The same comments were also raised when draft-dong-spring-sr-for-enhanced-vpn was presented to the Spring WG in London.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 12, 2018 at 12:13 PM
To: "Zafar Ali (zali)" <zali=[email-masked]<mailto:zali=[email-masked]>>
Cc: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Updating the SPRING WG Charter

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:

  *   Using SR as the mechanism to identify sets of resources in networks with SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft associated with this milestone beyond what is already covered by other milestones (e.g., by “Segment Routing policies and the associated steering and traffic engineering mechanisms”). What specific deliverable you have in mind? Is there an individual(s) draft against this milestone? Please advise.

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Date: Friday, June 1, 2018 at 12:07 PM
To: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

After the discussions on the list and in London relating to the charter, Bruno and I have been working to propose a new charter for the WG with Martin, and the other routing ADs. The text for this suggested charter is below. We would like to solicit WG feedback on the charter text prior to Martin taking to the IESG. We'd like to try and get the charter agreed prior to IETF 102 in Montréal.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as
a forum to discuss SPRING networks operations, define new applications, and
specify extensions of Segment Routing technologies.

The SPRING WG defines procedures that allow a node to steer a packet through an
SR Policy instantiated as an ordered list of instructions called segments and
without the need for per-path state information to be held at transit nodes.
Full explicit control (through loose or strict path specification) can be
achieved in a network comprising only SPRING nodes, however SPRING nodes must
inter-operate through loose routing in existing networks and may find it
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and
multi-AS environments. Segment Routing operates within a trusted domain; as
described in the architecture, a node imposing a segment list is assumed to be
allowed to do so. Nonetheless, the SPRING WG must strive to identify and
address security considerations brought up by the technologies it defines.  The
technologies SPRING WG defines may be applicable to both centralised and
distributed path computation.

SPRING WG should avoid modification to existing data planes that would make
them incompatible with existing deployments. Where possible, existing control
and management plane protocols must be used within existing architectures to
implement the SPRING function. Any modification of - or extension to - existing
architectures, data planes, or control or management plane protocols should be
carried out in the WGs responsible for the architecture, data plane, or control
or management plane protocol being modified and in coordination with the SPRING
WG, but may be done in SPRING WG after agreement with all the relevant WG
chairs and responsible Area Directors.

The SPRING WG will manage its specific work items by milestones agreed with the
responsible Area Director.

The work-items of the SPRING WG include functional specifications for:

o Segment Routing policies and the associated steering and traffic engineering
  mechanisms.

o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes.

o SRv6 network programming for the underlay networks and overlay services, and
  including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in
  networks with SR-MPLS and SRv6 data planes in the case where SR introduces
  specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6
  data planes in the case where SR introduces specificities compared to MPLS or
  IPv6 technologies.

o The inter-working between SRv6 and SR-MPLS.

o Using SR as the mechanism to identify sets of resources in networks with
  SR-MPLS and SRv6 dataplanes.

Any of the above may require architectural extensions.

The work-items of SPRING WG also include:

o Specification of management models (YANG) for Segment Routing applications,
  services and networks with SR-MPLS and SRv6 dataplanes.

The SPRING WG will coordinate and collaborate with other WGs as needed. Specific
expected interactions include (but may not be limited to):

* mpls on the MPLS dataplane and OAM extensions,
* 6man on the IPv6 dataplane for SR and associated OAM extensions
* lsr on OSPF and IS-IS extensions to flood SPRING-related information
        * idr for BGP extensions
* bess for VPN control plane
* pce on extensions to communicate with an external entity to compute and program SPRING paths
* teas on generic traffic engineering architecture

Please comment on the contents of the charter text on the list.

Thanks,
Bruno & Rob

_________________________________________________________________________________________________________________________

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: Rob Shakir <[email-masked]>
Date: Mon, 18 Jun 2018 08:39:52 -0700

Zafar,

I'm not sure I agree with this statement:

*> The new text is assuming a solution (as reasoned in my earlier email,
e.g., a (fully) controller-based solution will not require "mechanism to
identify sets of resources in networks"). *

If the forwarding resource to be used is more granular than a link then we
do not have a way that this can be exposed to a controller today. Equally,
in all practical deployments today, using Adj-SID stacks is not actually
possible at a controller. The intention of this bullet was to cover such
scenarios.

That said -- yes, we would like to be consistent in what should be added to
the list here. This seems an open area that is of interest to folks in the
WG; it does not look to be addressable with the current set of mechanisms
that are defined in the architecture; and does not appear to be outside of
the general areas that we defined in the original charter. This was the bar
we've tried to apply across work items. An analogue here would be the
stateless service chaining bullet.

Note that this bullet is *not* a milestone. No milestones are in the text
that I shared. The intention of this list is to provide a focused set of
things to work on within the next iteration of work within SPRING.

I encourage debate of the technical point around whether the existing
mechanisms can achieve the use cases that Jie is raising -- please fork the
thread for this!

Thanks,
r.

On Mon, Jun 18, 2018 at 8:25 AM Zafar Ali (zali) <zali=
[email-masked]> wrote:

> I am ok with the text in the "current" Charter. That is because the
> "current" text does NOT assume a solution. By converting the current text
>
>
>
> Current Charter Text: Some types of network virtualization, including
> multi-topology networks and the partitioning of network resources for VPNs.
>
>
>
> To
>
>
>
> New WG work-item/ milestone: "Using SR as the mechanism to identify sets
> of resources in networks with SR-MPLS and SRv6 dataplanes"
>
>
>
> The new text is assuming a solution (as reasoned in my earlier email,
> e.g., a (fully) controller-based solution will not require "mechanism to
> identify sets of resources in networks").
>
>
>
> Secondly, the earlier the text was part of the charter and not a
> milestone. Hence, my previous comment on the logic of adding this task to
> the "work items" list still applies. And if we include this as a
> work-items, why did we drop a few items raised by many (before/ during IETF
> in London and as part of the review of the charter draft) on the list for
> inclusion in the "work items" list. I am hoping for consistency in making
> such determination in the final version of the charter.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *"Dongjie (Jimmy)" <[email-masked]>
> *Date: *Friday, June 15, 2018 at 11:13 AM
> *To: *"Zafar Ali (zali)" <[email-masked]>, "Zafar Ali (zali)" <zali=
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *SPRING WG List <[email-masked]>, Rob Shakir <robjs=
> [email-masked]>
> *Subject: *答复: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Zafar,
>
>
>
> IMO the work item you are referring to is not a new one, actually it is an
> update or rephrasing of the previous one. Thus it is not relevant to the
> logic of adding new work items. The VPN+ drafts are just piece of work
> matching with this existing work item.
>
>
>
> I believe there is consistent rules of adding new work items to the
> charter, and it would be very helpful to concentrate on constructive
> discussion of those topics.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *发**件人**:* Zafar Ali (zali) [mailto:[email-masked]]
> *发**送**时间**:* 2018年6月14日 19:44
> *收件人**:* Dongjie (Jimmy) <[email-masked]>; Zafar Ali (zali) <zali=
> [email-masked]>; [email-masked]
> *抄送**:* SPRING WG List <[email-masked]>; Rob Shakir <robjs=
> [email-masked]>; Zafar Ali (zali) <[email-masked]>
> *主**题**:* Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Jie,
>
>
>
> While I look forward to reviewing the draft, at the moment of writing the
> charter no such details were available. At the moment we do not know if
> this would be an architecturally correct option to adopt in segment
> routing; what type of complexity, statefulness and scalability concerns it
> brings to the table. We also don't know if this is a matter of local
> implementation or are we better off if it is entirely done at the
> controller, etc.
>
>
>
> The work you are doing is already in the charter by the virtue of "SPRING
> WG serves as a forum to discuss SPRING networks operations, define new
> applications, and specify extensions of Segment Routing technologies."
>
>
>
> What puzzles me is the logic of adding this task to the "work items" list.
> And if we go with the same logic, why did we drop a few items raised by
> many (before/ during IETF in London and as part of the review of the
> charter draft) on the list for inclusion in the "work items" list. I am
> hoping for consistency in making such determination in the final version of
> the charter.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *spring <[email-masked]> on behalf of "Dongjie (Jimmy)" <
> [email-masked]>
> *Date: *Wednesday, June 13, 2018 at 11:26 PM
> *To: *"Zafar Ali (zali)" <zali=[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Cc: *SPRING WG List <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>,
> Rob Shakir <robjs=[email-masked]>
> *Subject: *Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Zafar,
>
>
>
> As mentioned in my previous mail, the VPN+ drafts and this work item
> require new functionality to be added to SR, which is to associate SR with
> particular allocated resources and treatment. IMO this is not covered by
> existing SR mechanisms. It is different from Diffserv QoS, and it is not
> pure controller-based accounting, because in the data plane some mechanism
> is needed to make sure different services will be treated accordingly and
> not impact each other.
>
>
>
> Thanks for the comments in London, we are working on the updates of the
> VPN+ drafts, hopefully they will be published for open review soon.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* spring [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Zafar Ali (zali)
> *Sent:* Wednesday, June 13, 2018 11:30 PM
> *To:* [email-masked]; Zafar Ali (zali) <
> zali=[email-masked]>
> *Cc:* SPRING WG List <[email-masked]>; Zafar Ali (zali) <[email-masked]>;
> Rob Shakir <robjs=[email-masked]>
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Bruno,
>
>
>
> I am aware of the VPN+ draft but IMO this document or Slicing, in general,
> is an informational use-case document (E.g., similarly SD-WAN does not have
> a milestone in the Charter). I do not think that there is any new behavior
> needed beyond SRTE, SRVPN, Flex-Algo, Diffserv QoS and SR SFC, etc. What is
> missing is the controller doing the bandwidth (resource) accounting but
> this outside the scope of IETF. Furthermore, the specifics in the VPN+
> specifics draft against this milestone are missing. The same comments were
> also raised when draft-dong-spring-sr-for-enhanced-vpn was presented to the
> Spring WG in London.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *"[email-masked]" <[email-masked]>
> *Date: *Tuesday, June 12, 2018 at 12:13 PM
> *To: *"Zafar Ali (zali)" <zali=[email-masked]>
> *Cc: *"Zafar Ali (zali)" <[email-masked]>, Rob Shakir <
> robjs=[email-masked]>, SPRING WG List <[email-masked]>
> *Subject: *RE: [spring] Updating the SPRING WG Charter
>
>
>
> Dear Zafar,
>
>
>
> *From:* spring [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Zafar Ali (zali)
> *Sent:* Tuesday, June 12, 2018 3:45 PM
> *To:* Rob Shakir; SPRING WG List
> *Cc:* Zafar Ali (zali)
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
>
>
> Dear Rob, Bruno,
>
>
>
>    - Using SR as the mechanism to identify sets of resources in networks
>    with SR-MPLS and SRv6 dataplanes.
>
>
>
> I do not know of any specific use-case, requirement or an individual draft
> associated with this milestone beyond what is already covered by other
> milestones (e.g., by “Segment Routing policies and the associated steering
> and traffic engineering mechanisms”). What specific deliverable you have in
> mind? Is there an individual(s) draft against this milestone? Please advise.
>
>
>
> *From: *spring <[email-masked]> on behalf of Rob Shakir <
> robjs=[email-masked]>
> *Date: *Friday, June 1, 2018 at 12:07 PM
> *To: *SPRING WG List <[email-masked]>
> *Subject: *[spring] Updating the SPRING WG Charter
>
>
>
> Hi SPRING,
>
>
>
> After the discussions on the list and in London relating to the charter,
> Bruno and I have been working to propose a new charter for the WG with
> Martin, and the other routing ADs. The text for this suggested charter is
> below. We would like to solicit WG feedback on the charter text prior to
> Martin taking to the IESG. We'd like to try and get the charter agreed
> prior to IETF 102 in Montréal.
>
>
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Jun 2018 21:38:45 +0000

Hi Rob,
Technical specifics on what is missing in the current specifications and how that information will be used in missing in this area; hence the question and suggestion for modifying the text (Using SR as the mechanism for partitioning network resources with SR-MPLS and SRv6 data planes) such that it do not contain hint for a solution. For the rest, we can have discussion off this tread.
Thanks

Regards … Zafar

From: Rob Shakir <[email-masked]>
Date: Monday, June 18, 2018 at 11:40 AM
To: "Zafar Ali (zali)" <zali=[email-masked]>
Cc: "Dongjie (Jimmy)" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, "[email-masked]" <[email-masked]>, SPRING WG List <[email-masked]>
Subject: Re: 答复: [spring] Updating the SPRING WG Charter

Zafar,

> The new text is assuming a solution (as reasoned in my earlier email, e.g., a (fully) controller-based solution will not require "mechanism to identify sets of resources in networks").

If the forwarding resource to be used is more granular than a link then we do not have a way that this can be exposed to a controller today. Equally, in all practical deployments today, using Adj-SID stacks is not actually possible at a controller. The intention of this bullet was to cover such scenarios.

That said -- yes, we would like to be consistent in what should be added to the list here. This seems an open area that is of interest to folks in the WG; it does not look to be addressable with the current set of mechanisms that are defined in the architecture; and does not appear to be outside of the general areas that we defined in the original charter. This was the bar we've tried to apply across work items. An analogue here would be the stateless service chaining bullet.

Note that this bullet is *not* a milestone. No milestones are in the text that I shared. The intention of this list is to provide a focused set of things to work on within the next iteration of work within SPRING.

I encourage debate of the technical point around whether the existing mechanisms can achieve the use cases that Jie is raising -- please fork the thread for this!

Thanks,
r.

On Mon, Jun 18, 2018 at 8:25 AM Zafar Ali (zali) <zali=[email-masked]<mailto:[email-masked]>> wrote:
Hi Jie,

To

Thanks

Regards … Zafar

From: "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 15, 2018 at 11:13 AM
To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <zali=[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, Rob Shakir <robjs=[email-masked]<mailto:[email-masked]>>
Subject: 答复: [spring] Updating the SPRING WG Charter

Hi Zafar,

Best regards,
Jie

发件人: Zafar Ali (zali) [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2018年6月14日 19:44
收件人: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <zali=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
抄送: SPRING WG List <[email-masked]<mailto:[email-masked]>>; Rob Shakir <robjs=[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
主题: Re: [spring] Updating the SPRING WG Charter

Hi Jie,

Thanks

Regards … Zafar

Hi Zafar,

Best regards,
Jie

Hi Bruno,

Thanks

Regards … Zafar

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.