Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22

Gyan Mishra <hayabusagsm@gmail.com> Thu, 27 May 2021 21:57 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE9D3A14EF; Thu, 27 May 2021 14:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 lvR-kDIb3tIL; Thu, 27 May 2021 14:57:04 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 D09CA3A1439; Thu, 27 May 2021 14:57:03 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id f22so1677642pfn.0; Thu, 27 May 2021 14:57:03 -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=luEKiB1PCRqEfivH4L6JZQnaWKXO8v1KxBLz8K2UoVU=; b=Pn9litI2lPolHbXXTcbx9u2tT4jFMB/FzLj5n5PrWyNlth5Q+WJoC8ojHkedrce1df wj5BW9YtiqWihxd04wPv7uLDanUuN9kZxXhURpRUmqEgOPpRN74iOp21+bl+rp0LQyCl 4thc4Y0ZWrOm9dB+l6iYQvI9rCxpwENsfweI3B384dBrgnA02pw0uBqNabmKRh7Xd3S6 Up4Ys2iGa52Pu6V9ybcTA4vVJHLZdMPK3tu7tqLWe/FKsaXOsWVERYbvFhIsMXZUKSKK oXblpm0hEsl3ptjw4AiHl6N84FnOXH6rhfaboh25HBaGTVktfPaKzNasb4vH9yIxfA2x z5sA==
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=luEKiB1PCRqEfivH4L6JZQnaWKXO8v1KxBLz8K2UoVU=; b=oxf3doxC0RpgwDTohoKSKEsZx97dyoMQJrrfbNDpfyG/tLeGl21BBF2EGI87uRs55L Ff6DYJVP9/mzF+wpoXreiTpS2SFYLTnGLwi0UrUiErCak/8FQgLkB63hzGOhQn5icSvy E7q4I2Eg3Jzvnq2Khg8VCVzFyaO/I/TfoiQ0WWMBTZ/hm4ISgVKa9GZH9BGgXAICWrFK MqglDGIKJNaI1bYsAMCZ2vFcfGuBKS5zRDYwQo/+//HoQkklIu63E0frL5EV4sRIzSz+ ElRllm9bkjPHGCtPhli8HdvHd4u3j2fQsGKLZ6BoIgbjYucwTptsDfidVCU6hUuEbw8s hhcQ==
X-Gm-Message-State: AOAM532GtYtRbAIw1Aol1y5CJSsqc001VmxG9a8DPk7XmyBTBEcsOK8z /IyyefjQaCBXytXByODG9WIgzHCWzVmFw6JPAl06EqNsJ+Q=
X-Google-Smtp-Source: ABdhPJypVj31mtq2P50T2DjEMbWQ6x5S4qAnNgZphVW0XaRpx7RDH04XtiGSdfFXyBUZxlnVtXbR7wQNoVHUwCYFiWI=
X-Received: by 2002:a62:190e:0:b029:2e3:3522:2232 with SMTP id 14-20020a62190e0000b02902e335222232mr564531pfz.4.1622152621301; Thu, 27 May 2021 14:57:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESswK38j+PXQAJ4rDZSNSN-ZjutUSE=fSO0QvoYS3sLRgfA@mail.gmail.com> <CABNhwV2t-OUuYgF-xUsYgOoiDSnkN_NY2zxWHyBBoufaUOqA1g@mail.gmail.com> <CABNhwV3j8cZGKA1st_erTvQKWstrs_=5EgYUPyx0+Vg=p-Vwew@mail.gmail.com> <CAOj+MMG7xjONhGVXG10RK4n1SXJs4s+RtM7Z51UjjtP6W-YjHQ@mail.gmail.com> <CABNhwV2sKWQgr0Dxtc8MWFGsrx_xQHnrr8C4g3SE5XSCrN2o6g@mail.gmail.com> <CAOj+MMGZOtXBsOFqZbtsDfm_JtNWFB7OYxW3EUE+rYSeRmGhqQ@mail.gmail.com>
In-Reply-To: <CAOj+MMGZOtXBsOFqZbtsDfm_JtNWFB7OYxW3EUE+rYSeRmGhqQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 27 May 2021 17:56:50 -0400
Message-ID: <CABNhwV3gYz3g7ZiNgEr6Q77MZA7VVWLGwF1m3nLx+SKxgG2g3A@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, IDR List <idr@ietf.org>, Susan Hares <shares@ndzh.com>, draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c3a43305c356d6c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lHqKmjmnL7VLKYoPnBekvkuvNAM>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2021 21:57:09 -0000

Makes sense.

Looks like ORR has already been implemented by vendors.  Good news!! šŸ‘šŸ˜€

https://apps.juniper.net/feature-explorer/feature-info.html?fKey=7033&fn=BGP%20Optimal%20Route%20Reflection%20(BGP-ORR)

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/212881-border-gateway-protocol-bgp-optimal-ro.html



Kind Regards

Gyan

On Tue, May 25, 2021 at 11:35 AM Robert Raszuk <robert@raszuk.net> wrote:

> Hi Gyan,
>
> >  Has this feature been implemented by any vendor
>
>
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations
>
>
> >  I donā€™t think hot potato routing is ever desirable where the RR is
> making the best
> > path decision instead of the client is ever better in the case where the
> RR is not
> > in the forwarding plane.
>
> The reason for this comment is that traditionally (or I should rather say
> historically) when networks were doing hop by hop IP lookup Rs were
> strictly placed either in the POPs or on the IGP paths to the POPs (or
> areas). That sort of assured optimal enough path selection.
>
> However the moment RRs were moved to central locations - or moving to run
> as logical slices in the cloud this is were ORR really helps to make them
> distributed optimal paths to clients.
>
> Thx,
> R.
>
> On Tue, May 25, 2021 at 5:22 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>
>> Hi Robert
>>
>> This is an excellent optimization concept for RR scalability as well as
>> limiting the number of paths per prefix reflected to the clients which can
>> be enormous.
>>
>> Verizon as well as other internet providers can take advantage of this
>> solution and help reduce the number of paths being reflected to clients.
>>
>> I support advancement of this draft.
>>
>> Minor comments on the draft text below:
>>
>> Introduction paragraph 4 -
>> I donā€™t think hot potato routing is ever desirable where the RR is making
>> the best path decision instead of the client is ever better in the case
>> where the RR is not in the forwarding plane.
>>
>> The evolving model of intra-domain network design has enabled deployments of route reflectors outside of the forwarding path.
>>    Initially this model was only employed for new services, e.g.  IP
>>    VPNs [RFC4364 <https://datatracker.ietf.org/doc/html/rfc4364>], however it has been gradually       extended to other BGP services including IPv4 and IPv6 Internet.  In such environments, hot
>>    potato routing policy remains desirable.
>>
>>
>>
>> Has this feature been implemented by any vendor to test the viability and
>> CPU resources necessary related to multiple decision processes due to IGP
>> location change?
>>
>> Thanks
>>
>> Gyan
>> On Mon, May 24, 2021 at 12:25 PM Robert Raszuk <robert@raszuk.net> wrote:
>>
>>> Gyan,
>>>
>>> This solution selects optimal paths for a given net. As RD is part of
>>> the net we would not select paths between nets.
>>>
>>> Note that tp the best of my knowledge we still have a day one option-B
>>> problem where two or more ASBRs may give us same net and VPNv4 RRs may
>>> choose single one only before advertising to peers. ORR may help here a bit
>>> to give different paths to different clients.
>>>
>>> To your other comment sure ORR is not required if we use "add-paths all"
>>> or have full IBGP mesh. But I know about networks where for each net there
>>> is 100s of paths hence add-path all is not a practical starter.
>>>
>>> Cheers,
>>> R.
>>>
>>> On Sun, May 23, 2021 at 12:40 AM Gyan Mishra <hayabusagsm@gmail.com>
>>> wrote:
>>>
>>>> For VPN SAFI 128 can this solution be applied as with unique RD all
>>>> paths
>>>> get advertised by the RR and this solution would cut down on the paths
>>>> advertised to help with scalability and with many RRs and many exit
>>>> points.
>>>>
>>>> Thanks
>>>> Gyan
>>>>
>>>> On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <hayabusagsm@gmail.com>
>>>> wrote:
>>>>
>>>> > Dear Authors
>>>> >
>>>> > I have a few comments on this draft.
>>>> >
>>>> > This is a historical well known issue exists where a RR will compute
>>>> the
>>>> > best path based on IGP topology metric least cost to the exit point
>>>> and
>>>> > will advertise those paths based on the topological position of the
>>>> RR to
>>>> > the exit point.  The major issue is the best path reflected by the RR
>>>> > should be based on the Clients IGP shortest path to exit point and
>>>> the RRs
>>>> > shortest path.
>>>> >
>>>> > A workaround to this issue is RFC 7911 add paths where all paths are
>>>> > advertised to all Client PEs as well as all RR as mentioned in
>>>> section 4
>>>> > deployment considerations.  What is missing in the Section 4 verbiage
>>>> is
>>>> > the add path to both RRs and all clients so advertisement of all
>>>> paths are
>>>> > advertised  to all clients as well as RR.  So to  resolve the issue
>>>> with
>>>> > the RR making the best path decision the RR must have add paths send /
>>>> > receive MP Reach capability enabled to all clients and must select and
>>>> > advertise all paths to all clients so that each client can now make
>>>> the
>>>> > best path decision based on its best path lowest IGP metric to the
>>>> exit
>>>> > point.
>>>> >
>>>> > Using RFC 7911 add paths to all clients the hot potato issue is
>>>> resolved.
>>>> >
>>>> > The caveat with add paths is if you have many RRs and many exist
>>>> points
>>>> > you end up with many paths per prefix in the BGP RIB.
>>>> >
>>>> > With modern high end routers these days this does not impact
>>>> scalability
>>>> > issues that I am aware of.
>>>> >
>>>> > With this draft it seems the goal is to only advertise the pertinent
>>>> paths
>>>> > based on the client IGP location rooted topological path to the exit
>>>> point
>>>> > and not advertise all paths.  This would cut down on the number of
>>>> paths
>>>> > advertised by the RR so all paths are not flooded to the clients as
>>>> the
>>>> > current solution today to the hot potato issue.
>>>> >
>>>> > Am I reading this correctly?
>>>> >
>>>> > Kind Regards
>>>> >
>>>> > Gyan
>>>> >
>>>> > On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <aretana.ietf@gmail.com
>>>> >
>>>> > wrote:
>>>> >
>>>> >> Dear authors:
>>>> >>
>>>> >>
>>>> >> Thank you for your work on this document.  I know that the draft and
>>>> >> the related ideas have been around for a long time.
>>>> >>
>>>> >> I have a couple of significant issues that I want to highlight
>>>> >> upfront, and many comments inline (see below).  In general, my focus
>>>> >> is to make sure that the specification of this mechanism is clear,
>>>> not
>>>> >> just to the experienced reader, but to the casual one as well.  I
>>>> >> believe that all the issues should be easy to resolve.
>>>> >>
>>>> >> (1) Terminology.  Please use the terminology already defined in
>>>> >> rfc4271/rfc4456 instead of creating new one by indirection.  My first
>>>> >> inline comment is about the use of "best path", which is not what
>>>> >> rfc4271 uses -- there are other occurrences later on.
>>>> >>
>>>> >> (2) Deployment Considerations.  Ā§6 says that a compliant
>>>> >> implementation is one that allows the operator to configure "a
>>>> logical
>>>> >> location from which the best path will be computed, on the basis of
>>>> >> either a peer, a peer group, or an entire routing instance".  Please
>>>> >> spend some time providing guidance so an operator can decide what
>>>> best
>>>> >> works for their network.  [I pointed below to other places there
>>>> >> operational guidance would be ideal.]
>>>> >>
>>>> >> (3) I don't think that Ā§5 (CPU and Memory Scalability) and Appendix A
>>>> >> (alternative solutions with limited applicability) should be part of
>>>> >> this document.  To start, comparisons are never good and the work has
>>>> >> already been through the WG so there's no need to keep justifying it
>>>> >> by comparing it to other work.  Both sections contain several claims
>>>> >> (e.g. "extra cost in terms of CPU", "implemented efficiently",
>>>> >> "expected to be higher but comparable", "large amount of BGP state
>>>> and
>>>> >> churn", "result in tens of paths for each prefix") that don't have
>>>> >> references, and could be considered subjective because they are
>>>> >> clearly relative and can change depending on the specific deployment
>>>> >> and configuration of the network.  I am not saying that the claims
>>>> are
>>>> >> false, simply requesting to take these two sections out.
>>>> >>
>>>> >>
>>>> >> Thanks!
>>>> >>
>>>> >> Alvaro.
>>>> >>
>>>> >>
>>>> >> [Line numbers from idnits.]
>>>> >>
>>>> >> ...
>>>> >> 17      Abstract
>>>> >>
>>>> >> 19         This document defines an extension to BGP route
>>>> reflectors.
>>>> >> On route
>>>> >> 20         reflectors, BGP route selection is modified in order to
>>>> choose
>>>> >> the
>>>> >> 21         best path from the standpoint of their clients, rather
>>>> than
>>>> >> from the
>>>> >> 22         standpoint of the route reflectors.  Multiple types of
>>>> >> granularity
>>>> >> 23         are proposed, from a per client BGP route selection or to
>>>> a
>>>> >> per peer
>>>> >> 24         group, depending on the scaling and precision
>>>> requirements on
>>>> >> route
>>>> >> 25         selection.  This solution is particularly applicable in
>>>> >> deployments
>>>> >> 26         using centralized route reflectors, where choosing the
>>>> best
>>>> >> route
>>>> >> 27         based on the route reflector IGP location is suboptimal.
>>>> This
>>>> >> 28         facilitates, for example, best exit point policy (hot
>>>> potato
>>>> >> 29         routing).
>>>> >>
>>>> >> [major] "best path"  rfc4271 doesn't use the term "best path".  The
>>>> >> terminology used in this document should, at the very least, match
>>>> >> what the base spec defines.  Let's please not create new terminology
>>>> >> by indirection using the "definition of terms" section.
>>>> >>
>>>> >>
>>>> >> [minor] "proposed"  This document is in line to be come an RFC; we're
>>>> >> far beyond proposing things.  There are a couple of places later on
>>>> >> where this same wording is used.  Please change it to specified or at
>>>> >> least described (the latter probably fits best in this specific
>>>> case).
>>>> >>
>>>> >>
>>>> >> [nit] s/from a per client BGP route selection or to a per peer
>>>> >> group/from per client BGP route selection or per peer group
>>>> >>
>>>> >>
>>>> >> [nit] s/precision requirements on route selection./precision
>>>> requirements.
>>>> >>
>>>> >>
>>>> >> [nit] s/route reflector IGP location/route reflector's IGP location
>>>> >>
>>>> >>
>>>> >> [major] "IGP location"  Before I forget -- please clearly define (not
>>>> >> in the Abstract of course) what an "IGP location" is.
>>>> >>
>>>> >>
>>>> >> ...
>>>> >> 70         1.  Definitions of Terms Used in This Memo  . . . . . . .
>>>> . .
>>>> >> . .   2
>>>> >> 71         2.  Introduction  . . . . . . . . . . . . . . . . . . . .
>>>> . .
>>>> >> . .   3
>>>> >>
>>>> >> [nit] It would be nice if the Introduction came up before the
>>>> terminology.
>>>> >>
>>>> >>
>>>> >> ...
>>>> >> 91      1.  Definitions of Terms Used in This Memo
>>>> >>
>>>> >> [minor] To avoid repeating some terms, it is good practice to
>>>> indicate
>>>> >> which other RFCs the reader should be familiar with.  In this case
>>>> >> rfc4271 and rfc4456 come to mind.
>>>> >>
>>>> >>
>>>> >> ...
>>>> >> 132     2.  Introduction
>>>> >> ...
>>>> >> 153        Section 11 of [RFC4456] describes a deployment approach
>>>> and a
>>>> >> set of
>>>> >> 154        constraints which, if satisfied, would result in the
>>>> >> deployment of
>>>> >> 155        route reflection yielding the same results as the IBGP
>>>> full
>>>> >> mesh
>>>> >> 156        approach.  This deployment approach makes route reflection
>>>> >> compatible
>>>> >> 157        with the application of hot potato routing policy.  In
>>>> >> accordance
>>>> >> 158        with these design rules, route reflectors have
>>>> traditionally
>>>> >> often
>>>> >> 159        been deployed in the forwarding path and carefully placed
>>>> on
>>>> >> the POP
>>>> >> 160        to core boundaries.
>>>> >>
>>>> >> [nit] s/have traditionally often/have often
>>>> >> Redundant...
>>>> >>
>>>> >>
>>>> >> 162        The evolving model of intra-domain network design has
>>>> enabled
>>>> >> 163        deployments of route reflectors outside of the forwarding
>>>> path.
>>>> >> 164        Initially this model was only employed for new address
>>>> >> families, e.g.
>>>> >> 165        L3VPNs and L2VPNs, however it has been gradually extended
>>>> to
>>>> >> other
>>>> >> 166        BGP address families including IPv4 and IPv6 Internet
>>>> using
>>>> >> either
>>>> >> 167        native routing or 6PE.  In such environments, hot potato
>>>> >> routing
>>>> >> 168        policy remains desirable.
>>>> >>
>>>> >> [minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
>>>> >> the name of the AFs.  Maybe call them new services.
>>>> >>
>>>> >>
>>>> >> [minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6;
>>>> again,
>>>> >> you probably mean service/application.
>>>> >>
>>>> >>
>>>> >> [nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
>>>> >> to me that you can save some ink by ending the sentence after
>>>> >> "Internet".
>>>> >>
>>>> >>
>>>> >> ...
>>>> >> 194     3.  Modifications to BGP Best Path selection
>>>> >>
>>>> >> 196        The core of this solution is the ability for an operator
>>>> to
>>>> >> specify
>>>> >> 197        the IGP location for which the route reflector should
>>>> calculate
>>>> >> 198        routes.  This can be done on a per route reflector basis,
>>>> per
>>>> >> peer/
>>>> >> 199        update group basis, or per peer basis.  This ability
>>>> enables
>>>> >> the
>>>> >> 200        route reflector to send to a given set of clients routes
>>>> with
>>>> >> 201        shortest distance to the next hops from the position of
>>>> the
>>>> >> selected
>>>> >> 202        IGP location.  This provides for freedom of route
>>>> reflector
>>>> >> physical
>>>> >> 203        location, and allows transient or permanent migration of
>>>> this
>>>> >> network
>>>> >> 204        control plane function to an arbitrary location.
>>>> >>
>>>> >> [major] "ability for an operator to specify the IGP location for
>>>> which
>>>> >> the route reflector should calculate routes.  This can be done on a
>>>> >> per route reflector basis, per peer/update group basis, or per peer
>>>> >> basis."
>>>> >>
>>>> >> When should an operator choose per RR vs per peer group vs per peer?
>>>> >> Choice is good, but providing guidance for the deployment is much
>>>> >> better.  Please consider adding text to Ā§6 about the considerations
>>>> to
>>>> >> chose one or the other.
>>>> >>
>>>> >>
>>>> >> [minor] "peer/update group"  Where is this defined?  Is there a
>>>> >> reference to a non-implementation-specific definition?  Can it be
>>>> >> called "a group of peers"?  Maybe you also want to include it in the
>>>> >> definitions in Ā§1.
>>>> >>
>>>> >>
>>>> >> ...
>>>> >> 215        o  it can, and usually will, have a different position in
>>>> the
>>>> >> IGP
>>>> >> 216           topology, and
>>>> >>
>>>> >> [] "usually will"   The position in the topology will *always* be
>>>> >> different!
>>>> >>
>>>> >>
>>>> >> ...
>>>> >> 222        This document defines, on BGP Route Reflectors [RFC4456],
>>>> two
>>>> >> changes
>>>> >> 223        to the BGP Best Path selection algorithm:
>>>> >>
>>>> >> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route
>>>> Reflectors
>>>> >>
>>>> >>
>>>> >> ...
>>>> >> 235        A route reflector can implement either or both of the
>>>> >> modifications
>>>> >> 236        in order to allow it to choose the best path for its
>>>> clients
>>>> >> that the
>>>> >> 237        clients themselves would have chosen given the same set of
>>>> >> candidate
>>>> >> 238        paths.
>>>> >>
>>>> >> [major] Please provide guidance for the operator to consider then one
>>>> >> or both should be used in their network.
>>>> >>
>>>> >>
>>>> >> 240        A significant advantage of these approaches is that the
>>>> route
>>>> >> 241        reflector clients do not need to run new software or
>>>> hardware
>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*