Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

[Shunsuke Homma <[e-mail]>]

Hi Gyan,

Please see inline.

On Sun, Feb 28, 2021 at 3:37 AM Gyan Mishra <[e-mail]> wrote:

>
> Hi Shunsuke
>
> On Sat, Feb 27, 2021 at 9:06 AM Shunsuke Homma <
> [e-mail]> wrote:
>
>> Hi Gyan,
>>
>> Please see inline.
>>
>> On Sat, Feb 27, 2021 at 5:35 PM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>> Shunsuke
>>>
>>> On Sat, Feb 27, 2021 at 2:01 AM Shunsuke Homma <
>>> [e-mail]> wrote:
>>>
>>>> Thanks, Joel and Gyan.
>>>>
>>>> Yes, I agree that SFC classifier or tunnel endpoint can be a PE router.
>>>> Meanwhile, I assume there are cases that CF/VNE runs on non-PE/CE router.
>>>> For example, in case that SFC is performed within the provider's DC (e.g.,
>>>> 5G DN), the ingress GW or ToR switch will be a classifier. Then, the GW/ToR
>>>> can be called CE or PE?
>>>>
>>>> Certainly, in MPLS world, MPLS termination point is conventionally
>>>> called PE, but I feel PE/CE may not be generally used in DC or any other
>>>> field. Actually, Geneve termination point is called tunnel endpoint, and
>>>> VxLAN also use VTEP (VxLAN Tunnel End Point), not CE/PE. (Sorry if my
>>>> understanding is incorrect...)
>>>>
>>>
>>>    Gyan> Agreed no PE/CE handoff.  For any of the NOV3 overlay
>>> encapsulations  types the decapsulation happens on the leaf before packet
>>> is handed off to host endpoint.  Because it’s a host endpoint which would
>>>  be a server and not a customers  “CPE” gear CE switch or router as in the
>>> MPLS world or even with broadband BNG subscribers.  So that’s the big
>>> difference in the Data Center framework from an operators perspective that
>>> is all the operators domain.  You can think of if from a cloud perspective
>>> the network infrastructure is IAAS “infrastructure as a service” and server
>>> infrastructure is PAAS “platform as a service”.
>>>
>>
>> Shunsuke > Thank you for your elaboration. As you pointed out, frameworks
>> of NSP network and Data Center are different, and it may be difficult to
>>  manage with the same model. Meanwhile, in network slicing, it is needed to
>>  provide "E2E" connectivity guaranteed specific SLA/SLO, and network slice
>> will be sometimes deployed across both NSP network and Data Center. For
>> example, in a smart factory scenario, robots may be connected to their
>> operating server on NSP's cloud with Geneve-based network slice. Then, a
>> slice endpoint will be Geneve tunnel endpoint, neither CE nor PE.
>>
>
>     Gyan> In a DC NVO3 overlay / underlay model typical leaf/spine CLOS
> folded spine architecture, the  demarcation is clearly defined if you apply
> the MPLS parity to DC NVO3 directly.   In that framework the spine nodes
> are like the P routers performing in line data plane forwarding similar to
> P label switching leaf to leaf over the folded spine as well as termination
> of control plane and the leafs terminating NVO3 tunnel endpoint vtep for
> vxlan for example perform the encapsulation / decapsulation similar to PE
> label imposition and disposition.  So applying the same MPLS parity to NVO3
> the leaf would be the PE and the TOR connected switch would then be the
> CE.  So the same PE/CE nomenclature can still apply.
>
> For non NVO3 BGP only DC CLOS folded spine architecture we still have the
> leaf and spine nodes  and here also the leaf would be the PE and TOR
> hanging off the leaf would be the CE.
>
> I think in any model even in GMPLS mode for example where you have an
> peering adjacency such as inter-as tie that would be your NNI PE-PE
> relationship.
>
> As far as SFC classifier that would be on the leaf switch acting as the PE
> demarcation to the CE TOR switch.
>
> So you can really apply the PE/CE nomenclature ubiquitously to any
> scenario.
>

Shunsuke > Thank you very much. I understood that PE/CE model can be
applied in every network slice scenario from the aspect of traffic
handoffs. I agree with that, and it seems reasonable.

Then, my next concern is whether we should bring terms of MPLS world to
overlay world. (It depends on the realization, but I assume network slices
will be realized with overlay technologies in many cases.) NVO3 and other
 overlay technologies use "endpoint", and I feel it is more compatible to
network slice scenarios. NSE can be also applied to every network slice
scenario. As Reza mentioned, NSE is a logical entity of network slice layer
and will be mapped to (virtual/physical) node in technology layer such as
CE//PE for MPLS, VNE, VTEP, etc.

Also, I think some modification or extension of definitions of CE/PE for
these usage if we use CE/PE terms instead of NSE. As Kenichi pointed,
"customer" of CE actually means "consumer". PE may mean edge of IETF
technology-enabled domain, not provider network, in such usage.

Anyway, I don't see any serious problems whichever is chosen, and think
this is a matter of taste finally. Or we need more consideration from
different aspects.


>
>> For customers, it would be better that they can always request a slice
>> with the same information/data model whatever their target is. If there are
>> cases where CE/PE can't be fit, I think we should avoid using them as a
>> slice endpoint.
>> # If we focus on only transport (i.e., IP/MPLS based network) and never
>> extend the scope to other fields, it's ok to use CE/PE.
>>
>>
>>
>>>>
>>>> If PE/CE are conceptual entities and can be applied to any cases, not
>>>> only MPLS(SR) networks, I assume that NSE and PE/CE are the same. Whichever
>>>> is fine to me.
>>>>
>>>> Regards,
>>>>
>>>> Shunsuke
>>>>
>>>>
>>>>
>>>> On Sat, Feb 27, 2021 at 3:21 PM Gyan Mishra <[e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>> I agree that the PE / CE nomenclature can be used for any scenario
>>>>> where their is a customer handoff “demarcation” and only in those cases can
>>>>> apply the network slicing endpoint concept.
>>>>>
>>>>> Access - wireline/wireless
>>>>> Wireline
>>>>> MPLS/SR core VPN overlay - typical PE-CE demark
>>>>>
>>>>> MPLS/SR inter-as provider handoffs
>>>>>
>>>>> Wireless - RAN xHaul - 3GPP gateway to UE - fixed or mobile wireless
>>>>> 4G/5G -  UE to Gateway is the handoff point
>>>>>
>>>>> OTN-
>>>>> OTN GMPLS/MPLS-TP packet core - typically that is the operators
>>>>> infrastructure and so no customer handoff.
>>>>>
>>>>> Data Center-
>>>>> Data Center - typically no customer handoff
>>>>> Typical DC flavors -
>>>>> CLOS architecture BGP only DC
>>>>> NVO3 - leaf/spine - vxlan/nvgre/geneve
>>>>>
>>>>> Cloud - IAAS infrastructure as a service so no handoff
>>>>>
>>>>> Content provider- no handoff
>>>>>
>>>>> Web or content hosting - also no handoff paid for service offering
>>>>>
>>>>> So in summary the only two scenarios where you have a customer handoff
>>>>> is the operator access layer wireline and wireless above.
>>>>>
>>>>> So I think the PE / CE nomenclature fits the bill even with the
>>>>> network slicing paradigm shift.
>>>>>
>>>>> Kind Regards
>>>>>
>>>>> Gyan
>>>>>
>>>>> On Fri, Feb 26, 2021 at 11:59 PM Shunsuke Homma <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> I'm wondering if CE/PE can cover all cases.
>>>>>>
>>>>>> For example, can SFC CF/SFF (ref. RFC 7665) or Geneve tunnel
>>>>>> endpoint/NVE (ref. RFC8926)  put the internal of a provider network be an
>>>>>> endpoint of IETF network slice? And if so, can we call them CE or PE?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Shunsuke
>>>>>>
>>>>>> On Sat, Feb 27, 2021 at 9:43 AM Gyan Mishra <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> This is an interesting discussion.
>>>>>>>
>>>>>>> I understand their is a paradigm shift with Enhanced VPN  network
>>>>>>> slicing framework, however I think as John and Eric stated and I agree with
>>>>>>> their proposed update that “CE” replace “Network slice endpoint” and PE
>>>>>>> replace “Network Slice Realization Endpoint”.
>>>>>>>
>>>>>>> From an industry  perspective from an operators point of view,  I
>>>>>>> can see that maybe the Network slicing paradigm shift is being driven by 5G
>>>>>>> which has its key constructs of XHaul front back and mid haul vRAN and the
>>>>>>> mobile handset UE 3GPP user data plane and how much the CE is now aware of
>>>>>>> the underlay.
>>>>>>>
>>>>>>> As Adrian pointed out the CE based VPN versus PE based VPNs and the
>>>>>>> trade off for operators with CE based VPNs and how much knowledge are
>>>>>>> operators willing to give their customers about the underlay.
>>>>>>>
>>>>>>> As we all know that even though 5G is the industry driver of network
>>>>>>> slicing, the framework of network slicing as far as degree of isolation and
>>>>>>> steering is all based on the very overlay VPN concept now enhanced VPN+ to
>>>>>>> provide an improved user or SLA experience.   So the concept of network
>>>>>>> slicing  underpinned of overlay VPN with underlay resources and steering
>>>>>>> can be used for any use case with requirements of a higher grade SLA and
>>>>>>> not just 5G , such as DETNET or any content provider video streaming
>>>>>>> service offering or any service requiring a higher degree of isolation.
>>>>>>>
>>>>>>> Their are definitely trade off from an economics and value added
>>>>>>> service and ROI perspective  for CE versus PE based VPNs.
>>>>>>>
>>>>>>> Another point noted in this thread which I think is important and
>>>>>>> that is “confusion” related to changing the historical PE / CE terminology.
>>>>>>>
>>>>>>> That being said I do agree with John and Eric on their proposed
>>>>>>> change.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kind Regards
>>>>>>>
>>>>>>> Gyan
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 26, 2021 at 2:14 AM Dongjie (Jimmy) <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Indeed good discussion about the terms, and thanks to Adrian for
>>>>>>>> the explanation and summary of the PE-based and CE-based VPNs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In the two figures provided in [1], the realization of IETF network
>>>>>>>> slice in both the service layer and the tunnel layer are the same, the only
>>>>>>>> difference is the position the NSE represents.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thus I also support the proposal of using the well-known terms
>>>>>>>> CE/PE to describe the endpoints of IETF network slice.  This could help to
>>>>>>>> reduce the possible confusions caused by using one term to represent
>>>>>>>> different positions. This could also help to understand the mapping from
>>>>>>>> IETF network slice requirements to its realization, which could be based on
>>>>>>>> the architecture and technologies described in the enhanced VPN draft [3].
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Jie
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Teas [mailto:[e-mail]] *On Behalf Of *Adrian
>>>>>>>> Farrel
>>>>>>>> *Sent:* Thursday, February 25, 2021 6:52 PM
>>>>>>>> *To:* 'Young Lee' <[e-mail]>; 'Luis M. Contreras' <
>>>>>>>> [e-mail]>
>>>>>>>> *Cc:* 'Joel M. Halpern' <[e-mail]>; [e-mail];
>>>>>>>> 'Eric Gray' <[e-mail]>; 'John E Drake' <jdrake=
>>>>>>>> [e-mail]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <
>>>>>>>> [e-mail]>; [e-mail]
>>>>>>>> *Subject:* Re: [Teas] network Slice Endpoint in
>>>>>>>> draft-ietf-teas-ietf-network-slice-definition-00
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Good thread, and really good to see the debate on the WG list.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I’m piling in in response to Young, mainly because that’s the email
>>>>>>>> I happen to have open. But also because the perspective of Young and Luis
>>>>>>>> should be valuable to us in this context.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> While I think that the usage of “CE” and “PE” has a long history in
>>>>>>>> packet networks, I don’t believe the concepts are firmly linked only to
>>>>>>>> packet. They are pretty much what they call themselves: the PE is at the
>>>>>>>> edge of the “provider” == “underlay” network, and the CE is at the edge of
>>>>>>>> the “consumer” == “overlay” network.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I find that, as the discussion continues, we are still missing a
>>>>>>>> really clear figure to help us talk about what we are describing. But
>>>>>>>> Reza’s [1] is a much better start than anything previous. Here I see the
>>>>>>>> classic distinction between a CE-based VPN and a PE-based VPN [2], but we
>>>>>>>> have to ask ourselves carefully whether we **really** want the
>>>>>>>> CE-based approach in our network slicing:
>>>>>>>>
>>>>>>>> -          What are the considerations for how much knowledge of
>>>>>>>> the underlay network has to be shared to the CE?
>>>>>>>>
>>>>>>>> -          What are the considerations for how an underlay
>>>>>>>> distinguishes CE-originated slicing traffic?
>>>>>>>>
>>>>>>>> These are pretty much the same questions that CE-based VPNs have to
>>>>>>>> answer. Of course, the concept of a “provider-managed CE” muddies these
>>>>>>>> waters somewhat.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Conversely, the port-based PE-based VPN has none of these problems,
>>>>>>>> but does have to agree on the “Access Connection” encoding, and that is
>>>>>>>> either payload-sensitive (like in PWE3) or technology-aware (like in L3VPN).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> But my opinion of all of this is coloured by thinking about
>>>>>>>> enhanced VPNs (VPN+) [3] and IETF network slices as the same thing.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I also think that Luis’ point about contiguous or stitched segments
>>>>>>>> is important. There are, I think, two cases to be considered:
>>>>>>>>
>>>>>>>>    1. The multi-domain IETF network slice. Here the problem is
>>>>>>>>    very much the same as the multi-AS L3VPN. We have to consider how the
>>>>>>>>    “service request” is mapped from one domain to another. But it may help to
>>>>>>>>    recall that, for all our dreaming, end-to-end multi-AS MPLS-TE tunnels are
>>>>>>>>    not much of a thing: domains don’t like sharing information about or
>>>>>>>>    control of their network resources. Thus the “E-NNI” between slice domains
>>>>>>>>    may be as much of a service interface as the “UNI” between consumer and
>>>>>>>>    provider.
>>>>>>>>    2. The 5G architecture considers stitching slices from
>>>>>>>>    different technology networks to provide an end-to-end slice. From a
>>>>>>>>    consumer’s point of view, this is exactly what happens, but it is not clear
>>>>>>>>    to me whether this is really what happens in a deployment. Surely there is
>>>>>>>>    aggregation as we go down the technology layers and into the “transport”
>>>>>>>>    networks. That is, there may be very, very many micro slices in the RAN,
>>>>>>>>    but as this moves onto the IP transport, it is likely that the slicing is
>>>>>>>>    aggregated. That means that the stitching of slices actually follows a
>>>>>>>>    hierarchical model with recursion. The interface between slice domains is
>>>>>>>>    the “UNI”.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Net-net, I like John’s original proposal. I hope we can take that
>>>>>>>> as our base point and factor in further discussions.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://mailarchive.ietf.org/arch/msg/teas/ibycGzi5cxJUJSvRxm9OsQdDqn8/
>>>>>>>>
>>>>>>>> [2] RFC 4026
>>>>>>>>
>>>>>>>> [3] draft-ietf-teas-enhanced-vpn
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Teas <[e-mail]> *On Behalf Of *Young Lee
>>>>>>>> *Sent:* 24 February 2021 10:22
>>>>>>>> *To:* Luis M. Contreras <[e-mail]>
>>>>>>>> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>;
>>>>>>>> [e-mail]; Eric Gray <[e-mail]>; John E Drake <
>>>>>>>> jdrake=[e-mail]>; Joel M. Halpern <
>>>>>>>> [e-mail]>; [e-mail]
>>>>>>>> *Subject:* Re: [Teas] network Slice Endpoint in
>>>>>>>> draft-ietf-teas-ietf-network-slice-definition-00
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This is an interesting discussion. I am now in the mobile side and
>>>>>>>> reconginize that there are a number of scenarios that may need transport
>>>>>>>> network slices (which is now called IETF network slices). For instance,
>>>>>>>> possibly slices may be needed in the fronthaul, midhaul and backhaul as
>>>>>>>> well as within DC networks that host the functions. Other than backhaul
>>>>>>>> networks, the terms CE and PE may not be adequate because for the
>>>>>>>> aforementioned transport networks except the backhaul, CE and PE
>>>>>>>> terminology would not easily apply. For each of the aforementioned
>>>>>>>> transport subnetworks, I think using slice endpoints makes more sense.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In other words, I agree with Luis on this point.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> My two cents,
>>>>>>>>
>>>>>>>> Young
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2021년 2월 24일 (수) 오후 7:00, Luis M. Contreras <
>>>>>>>> [e-mail]>님이 작성:
>>>>>>>>
>>>>>>>> Thanks Med and Joel for the answers.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Noting what you said, and assuming that we are covering not only
>>>>>>>> IP/MPLS technologies, probably we need to associate the same idea of CE and
>>>>>>>> PE to technologies where those roles are not commonly associated, such as
>>>>>>>> OTN, DWDM or wireless / microwave, since all of them can be potential
>>>>>>>> targets of the IETF Network Slicing realization. Then, if we follow this
>>>>>>>> same rationale and finally the WG decides to go in this direction, I guess
>>>>>>>> we need to span the CE and PE conception also to those, maybe explaining
>>>>>>>> this in the definitions draft. Am I right?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Med, when I was referring to IETF Network Slice of technology X or
>>>>>>>> Y I was thinking on the realization. So my point here is that in case you
>>>>>>>> have an IETF Network Slice let's say realized as IP/MPLS, and another one
>>>>>>>> let's say realized on OTN or DWDM, where the IP/MPLS slice is supported by
>>>>>>>> the OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is
>>>>>>>> OTN/DWDM? It sounds strange to me.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Luis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> El mié, 24 feb 2021 a las 7:16, <[e-mail]>
>>>>>>>> escribió:
>>>>>>>>
>>>>>>>> Hi Luis,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Actually, this is all about recursion, service decomposition and
>>>>>>>> manipulating customer/provider ROLES. In all cases, there are reference
>>>>>>>> points delimiting the scope of the slice from both the customer view (we
>>>>>>>> call them, customer edges) and provider view (provider edges).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Nothing prevents that at the realization stage, two PEs can’t be
>>>>>>>> connected. I’m thinking about the example where inter-AS VPN can be used to
>>>>>>>> implement an IETF network slice.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> BTW, can you please clarify what do you mean by a “IETF Network
>>>>>>>> Slice of technology X or Y” as slice is technology-agnostic? Thank
>>>>>>>> you.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Med
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *De :* Luis M. Contreras [mailto:[e-mail]]
>>>>>>>> *Envoyé :* mardi 23 février 2021 23:46
>>>>>>>> *À :* Eric Gray <[e-mail]>
>>>>>>>> *Cc :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>;
>>>>>>>> Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>; John E
>>>>>>>> Drake <jdrake=[e-mail]>; [e-mail]; Joel
>>>>>>>> M. Halpern <[e-mail]>
>>>>>>>> *Objet :* Re: [Teas] network Slice Endpoint in
>>>>>>>> draft-ietf-teas-ietf-network-slice-definition-00
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regarding the CE / PE discussion, I have doubts if this would apply
>>>>>>>> to scenarios where we could have stitching of IETF Network Slices or in
>>>>>>>> scenarios where an IETF Network Slice of technology X is supported on  IETF
>>>>>>>> Network Slice of technology Y. While end-point can work in all the cases, I
>>>>>>>> think that CE / PE don't become naturally applicable in all cases.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Respect to the discussion on IETF Network Slice Service, I think it
>>>>>>>> is redundant since we are talking of consumer/customer and provider in the
>>>>>>>> context of  IETF Network Slice, so being "Service" redundant there.
>>>>>>>> Probably adds more confusion than clarification.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Luis
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Teas mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> <http://www.verizon.com/>
>>>>>>>
>>>>>>> *Gyan Mishra*
>>>>>>>
>>>>>>> *Network Solutions A**rchitect *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *M 301 502-134713101 Columbia Pike
>>>>>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>>>>>> Spring, MD
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Teas mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>>>>
>>>>>> --
>>>>>
>>>>> <http://www.verizon.com/>
>>>>>
>>>>> *Gyan Mishra*
>>>>>
>>>>> *Network Solutions A**rchitect *
>>>>>
>>>>>
>>>>>
>>>>> *M 301 502-134713101 Columbia Pike
>>>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>>>> Spring, MD
>>>>>
>>>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>>
>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>>> Spring, MD
>>>
>>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>