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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 02 June 2021 21:00 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9083A1AE4 for <teas@ietfa.amsl.com>; Wed, 2 Jun 2021 14:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCKQZW63CLbc for <teas@ietfa.amsl.com>; Wed, 2 Jun 2021 14:00:42 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3A63A1AE2 for <teas@ietf.org>; Wed, 2 Jun 2021 14:00:42 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id k5so2376588pjj.1 for <teas@ietf.org>; Wed, 02 Jun 2021 14:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=66+IFz64b+SeFxaEtT1yd3DyQoJIcU8v5M5S4dGKeKI=; b=imoBWpjEFYqfeSNQwtYEHKwBvA4t/N49oyA0oG4Q65i452eD8zvNZxX0aUmgAvLzpt bhibBwR4X65woVpFEv1ik9RazI6tQKez+0lpN7X07YnorQMG0pHM3IRWKwYF1vQHgGUi 8+2GAwAqao6sp9+zLZRyOnm/moGRY0M+wPxVKMJHYcWXmthgTmGYVBzmcjPqqw6QtqY8 5Q1nmFA0DmPJBb/6tBwzRC28mhMIUfL/K58v+2NDOxIB6A6crgWGHPRWeENbGiBWjpaB 9D46ys19XP9/jSKrguT0A/dm0fZwMS9eGF+i+jpAE0s+2lXoWtnbIekXqXFB4l08snAE teHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=66+IFz64b+SeFxaEtT1yd3DyQoJIcU8v5M5S4dGKeKI=; b=h5QAWaxn/nluUhRW5KJvcOT894+DaHYWZekbRsnugfXjckXzyD2fG6GYiC7URrVTbo 9N6B1nprhb4VR4vgVi9wbdCBuBVjBcsWNESnKs7TgI6SBN0PTAbQ/PQKWmF+OQw/hteL 4s4L/BGHN/p5v4u63KKqHUFlnGohD9H9t9tLrtuhi9Bd7SrN9gFaWl5rOnzIoJCVmhqP I32+MihZ6LLF97lF5HDhwV192VxnsWKVSRZeXoLFuxwjlL6rjUoniPBLwK/Kbr1X/CCi z6Cx4ris3owIn5zU/Y9b0W94j28uR5TIQGiaCrIeflZKAMuegJuJsADK2EWFBSnPUcaN M6Pw==
X-Gm-Message-State: AOAM530EDlbQo97PhGYFx5wv6nmDkIFs8E9klS6hNS4DPWywkQI3PGtg 7LZ03SUfRd1Ev/IrQs/DRNM3sDeuQZP3SigpTfriXvUyy4zOoA==
X-Google-Smtp-Source: ABdhPJzkYsqcYEOsUDtbyT43hid/dJc+icn9SEdvI5JMa2B5sOelJ0xz0coPaJzC5HmXO913G+4LlzYZQOZOZm/B/Ts=
X-Received: by 2002:a17:90a:3c85:: with SMTP id g5mr7486128pjc.215.1622667641262; Wed, 02 Jun 2021 14:00:41 -0700 (PDT)
MIME-Version: 1.0
References: <161781991426.15865.4191431758501856588@ietfa.amsl.com> <06a201d72be3$8e1e9b20$aa5bd160$@olddog.co.uk> <2544_1620053359_60900D6F_2544_75_1_787AE7BB302AE849A7480A190F8B933035375DEC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0c1401d749b1$4ea76030$ebf62090$@olddog.co.uk> <14245_1621350034_60A3D692_14245_28_4_787AE7BB302AE849A7480A190F8B93303538A62A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CABNhwV3KtCQ_TPef6CPWgCBP8WRo+78Wg1VKtZn2xbKbJskjSA@mail.gmail.com> <CABNhwV1+_8acwEDB8fKLrep-XrQv-aAyUyOwKw_=hPsQGJ6wew@mail.gmail.com> <CABNhwV3axmOQq4Kx7OpGkqJ73XUbBV-qHuAjm7H6csHHWos_aA@mail.gmail.com> <28120_1622648051_60B7A4F3_28120_323_1_787AE7BB302AE849A7480A190F8B933035396565@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CABNhwV0jJQM4ekEwZHZRctuVSV-FbHBdLb7L7YbGNi01W6iAdg@mail.gmail.com> <18050_1622649918_60B7AC3E_18050_424_1_787AE7BB302AE849A7480A190F8B93303539659B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <18050_1622649918_60B7AC3E_18050_424_1_787AE7BB302AE849A7480A190F8B93303539659B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 2 Jun 2021 17:00:30 -0400
Message-ID: <CABNhwV1NaFCLeOqaDoo-bPwtO5LHoSBqut5tJEZsr5OSBFGeXQ@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000058953005c3cec017"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/__O89wy4cvPndgZXKL1xo0H2hI8>
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rfc3272bis-11.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 21:00:50 -0000

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>om>;
> > '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*