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

Gyan Mishra <hayabusagsm@gmail.com> Fri, 05 March 2021 23:11 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 17A1B3A11B4 for <teas@ietfa.amsl.com>; Fri, 5 Mar 2021 15:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.097
X-Spam-Level:
X-Spam-Status: No, score=-6.097 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 vM4vnyQAbgU3 for <teas@ietfa.amsl.com>; Fri, 5 Mar 2021 15:11:13 -0800 (PST)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 A1FA53A11AB for <teas@ietf.org>; Fri, 5 Mar 2021 15:11:13 -0800 (PST)
Received: by mail-pl1-x62f.google.com with SMTP id u18so2162766plc.12 for <teas@ietf.org>; Fri, 05 Mar 2021 15:11:13 -0800 (PST)
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=qc6W7Qod0riaDSXDMVrLzanFeLutMF8Y4tQVdiSs4fw=; b=pnUhSxTnq0nWsYdClc36I4uOaIMK8753bYt5/cFZedx0PnVoFExkSUyyIKqybIS2Qr yR88eKSBQDZN/Sq3jU6h7CQfXfFGlUJQV3GTiQtDopm7kAgGWgk/9l/PivIb2UGzZZwL JG54YVTBdcUJFES5nw7cz4dc+sgQgfnjNpgfCX47Bl21uyU7OGmIoLxkQ0dkaqQ/cyUs bnhk96DtyfXwZLNV6d11pLibAHtFj3UUDieOjDi7MoRQe638ixEqGdFib2FehEzgPWjk LxwsCRT5x1HkyXVnMZlyb+EgILXe2IZ6Xsl1pWiXBBjMHeL76Jxv0f7sHsveUFgx1xBw 8ziA==
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=qc6W7Qod0riaDSXDMVrLzanFeLutMF8Y4tQVdiSs4fw=; b=Q7pM+HGueZ30AxZE+8BDQO606upSKMUgehrbNV32IS41BXMLef5G+bXJadRQNH70Vj QMWIVz8W4GKTHPOeNbvC9PUYr5cUD6dY816wjeDyfnwT9cMst+JfRcT6gqiYDHg/74YV jS+VA9XMVJ4U9SbDRthM/4VFH+dCih88BooRB9mvCuEyPAmznJtZNfgL9pTiYbPXrKHy EyulkvYO5fPWtb8dcg2QzifCzmWm1TwVRBRTucgtgS4E0VBFeeVdYnnN+X64B52uTNTh Ij7xgVWbptwafPuP7y9x2xIkCVe7poYqR1RK1W/nntPU24YFFuZTqXSYEHTZlkovk3Ph JVYw==
X-Gm-Message-State: AOAM5314J3NJOLtFYl9it3oP896TDNEX52gQEXweKG+w//rsxp5CuIUI aoQnGx8Q4ZeM3QJFM+gDX8o7lzNLVPeYWtHMRqw=
X-Google-Smtp-Source: ABdhPJyRqIRKc79h9t3q8MDIVGDzI0Mo7nFl9hylklvfbMhotSfIInVSzZRBhr2L1r77wsZKrruVbnLqbf9B6T1VFSA=
X-Received: by 2002:a17:902:fe09:b029:e4:951e:2d2e with SMTP id g9-20020a170902fe09b02900e4951e2d2emr10861680plj.22.1614985872134; Fri, 05 Mar 2021 15:11:12 -0800 (PST)
MIME-Version: 1.0
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1bf03e82-3734-885a-7047-cacf5c63d9cc@joelhalpern.com> <8211_1613493543_602BF527_8211_334_1_787AE7BB302AE849A7480A190F8B9330315CF95E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <cde51de3-4533-9acd-a654-59a1dc9f195b@joelhalpern.com> <11878_1613494720_602BF9C0_11878_194_1_787AE7BB302AE849A7480A190F8B9330315CF9FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MN2PR05MB6623B0D3F5EEECFB3CE3FA8BC7809@MN2PR05MB6623.namprd05.prod.outlook.com> <71F75531-DE7E-419E-890D-A5AB6D5F4D8F@nokia.com> <27179_1614103167_6035427F_27179_485_2_787AE7BB302AE849A7480A190F8B9330315D83ED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <54DAE6D4-7435-4E1A-9538-51F2ED35B132@gmail.com> <CAE4dcxnhjszy7OMD-JusSnDBg2oR7Buo4XKO6gXk1-DrQc2FsA@mail.gmail.com> <CAE4dcxmeSLLaqa2Q7VTF=EJZXiyMV6hft2pCMSASAWb+N6PmVg@mail.gmail.com> <CAGHSPWNmr3RQrSGsbsEvyGoLqtY1eqPQ=uOv=oDdQFNz3_VLiA@mail.gmail.com> <069101d70b64$3d32bf10$b7983d30$@olddog.co.uk> <81cdb36e29e64fd79bafeb578926e6a8@huawei.com> <CABNhwV2ZVT47m17KARJDjXzr232bs5srp2KdD7njmgTPw0=8BQ@mail.gmail.com> <CAKr2Fb9cd6F7GGq7Pw-jPpxzwQtTE7M_DY0oQ83mmENoEHkTFw@mail.gmail.com> <CABNhwV3Dz86VkePniMGmF6vOvu63VEN9J-izHZ__=qn97cqzdg@mail.gmail.com> <CAKr2Fb9f9B-BUobJGV2X90tCUdAtHzoZHWth4nbqKG9cN3r1Gg@mail.gmail.com> <CABNhwV0q82AobMnSBYfSaCRUNKe9=yb=ZrTFaS1YGF-UOFBeWQ@mail.gmail.com> <CAKr2Fb9dXMHSJ1psYGbUvm=6J3XFfAaZ9BwNe+F4Q_moR=Ro0Q@mail.gmail.com> <CABNhwV3mZVbhbNc-W_LtfUkVnT5KhqZUNFXc+we_vwBEQKj8Gw@mail.gmail.com> <CAKr2Fb81Un6YeyE=4LPFhEpLFOn9wgzVphn8DcUMZc9vDcB9Fw@mail.gmail.com> <CABNhwV24d7QHaKceLtiJi=v=7jMiO0=n5RQEc=apeVeu8=bRqg@mail.gmail.com> <CABNhwV1bV48f1=Cq4aM8pT9qFr-acxbkTPkrkXfZURx8JeO42A@mail.gmail.com> <CAKr2Fb98qvWWHEk8ibSTujKwGC1XyyK0MQ1uAS98RDnEW3zHbA@mail.gmail.com> <CABNhwV100r8qwvt6EQD72Wq2BAMBz3EWG09xSQHWMPxFeHAxyA@mail.gmail.com> <CAGU6MPfC-d7skGaR7__b-X49R8Q26zceiEvj20PR7QRytM4p1A@mail.gmail.com>
In-Reply-To: <CAGU6MPfC-d7skGaR7__b-X49R8Q26zceiEvj20PR7QRytM4p1A@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 5 Mar 2021 16:15:56 -0500
Message-ID: <CABNhwV11u0bLCJDjABW45aeKRSTT0h3ut=euQ2_BEv7GrSK+5w@mail.gmail.com>
To: Shunsuke Homma <s.homma0718@gmail.com>
Cc: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "Luis M. Contreras" <contreras.ietf@gmail.com>, "teas@ietf.org" <teas@ietf.org>, Eric Gray <ewgray2k@gmail.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Young Lee <younglee.tx@gmail.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary="00000000000039d61605bcd23345"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/d_MDe8Pt7CFNc0hArnugjIZ1lLQ>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
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: Fri, 05 Mar 2021 23:11:19 -0000

I think we made significant progress and consensus on this topic.

I see Reza has already sent a readout on the PE / CE discussion.

Kind Regards

Gyan

On Wed, Mar 3, 2021 at 1:05 PM Shunsuke Homma <s.homma0718@gmail.com> wrote:

> Hi Gyan,
>
> 2021年3月3日(水) 11:06 Gyan Mishra <hayabusagsm@gmail.com>om>:
>
>>
>> Shunsuke,
>>
>> On Mon, Mar 1, 2021 at 10:33 AM Shunsuke Homma <
>> shunsuke.homma.ietf@gmail.com> wrote:
>>
>>> Hi Gyan,
>>>
>>> On Sun, Feb 28, 2021 at 11:53 PM Gyan Mishra <hayabusagsm@gmail.com>
>>> wrote:
>>>
>>>> Hi Shunsuke
>>>>
>>>> On Sun, Feb 28, 2021 at 9:30 AM Gyan Mishra <hayabusagsm@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Shunsuke
>>>>>
>>>>> On Sat, Feb 27, 2021 at 11:21 PM Shunsuke Homma <
>>>>> shunsuke.homma.ietf@gmail.com> wrote:
>>>>>
>>>>>> Hi Gyan,
>>>>>>
>>>>>> Please see inline.
>>>>>>
>>>>>> On Sun, Feb 28, 2021 at 3:37 AM Gyan Mishra <hayabusagsm@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Shunsuke
>>>>>>>
>>>>>>> On Sat, Feb 27, 2021 at 9:06 AM Shunsuke Homma <
>>>>>>> shunsuke.homma.ietf@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Gyan,
>>>>>>>>
>>>>>>>> Please see inline.
>>>>>>>>
>>>>>>>> On Sat, Feb 27, 2021 at 5:35 PM Gyan Mishra <hayabusagsm@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Shunsuke
>>>>>>>>>
>>>>>>>>> On Sat, Feb 27, 2021 at 2:01 AM Shunsuke Homma <
>>>>>>>>> shunsuke.homma.ietf@gmail.com> 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.
>>>>>>
>>>>>
>>>>>     Gyan> Great.  I think we are making progress.😀
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>>     Gyan> The concept of underlay/overlay actually historically
>>>>> started with any framework where you have a concept of multi tenancy or
>>>>> multiple customer framework that broadened the single tenant IP based
>>>>> framework to a logical construct by creating a “hypervisor like”
>>>>> overlay/underlay model now called “MPLS”.  MPLS can be utilized as a single
>>>>> tenant model similar to IP based model in an enterprise MPLS framework
>>>>> where the PE-CE edge is native IP “no VRF” or virtualization of the edge
>>>>> layer using “global table” single layer no overlay routing PE-RR SAFI 1 for
>>>>> IPv4 and SAFI 4 for IPv6 BGP LU (6PE) to connect IPv6 islands over an MPLS
>>>>> core. “MPLS” can also be user in a Service Provider mode of “multi tenancy”
>>>>> multi customer model identical to NVO3 with a virtualization “hypervisor
>>>>> like” layer added with now populating the label stack two layers deep with
>>>>> now a virtualization of the PE-CE edge layer with VRF concept similar to a
>>>>> VM VNF on a NFV framework, so now the topmost transport label is the
>>>>>  underlay global table routing and your bottom of stack a label BOS bit set
>>>>> is your virtualization layer VPN “overlay” layer identical to NVO3
>>>>> “overlay/underlay” concept.  So the idea of tunneling is tunnel endpoint
>>>>> and tunnel termination point is not new and applies to any framework where
>>>>> you have encapsulation and decapsualation occurring in MPLS it’s imposition
>>>>> and disposition of the Label stack to forward native IP to the CE edge end
>>>>> in NVO3 it’s the same removal of the outer envelope to forward native IP to
>>>>> the edge.  The virtualization layer in both cases stops at the PE edge when
>>>>> the handoff occurs from PE to CE as now the CE edge sits in the global
>>>>> table routing.  This is true any overlay/underlay architecture with MPLS
>>>>> and NVO3 as direct parity examples.  We can actually think of the concept
>>>>> of network slice framework as a pre existing condition of any overlay /
>>>>> underlay model as logically the overlay “VPN overlay” or “NVO3 overlay”  is
>>>>> a slice of the physical with the virtualization layer terminating on what
>>>>> we call today a “PE” and tomorrow with network slice paradigm shift with my
>>>>> parity added in the paradigm shift we end up still calling it a “PE”.
>>>>>
>>>>>>
>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>>     Gyan> Agreed.
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>>     Gyan> The major take away here is in my mind is added industry
>>>>> confusion or layer of abstraction as it may be with new nomenclature where
>>>>> we are really still talking about the same endpoint type.  Nothing has
>>>>> really changed, but it’s just wrapping our heads around the network slice
>>>>> concept where in reality it has existed for decades.
>>>>>
>>>>
>>>> Shunsuke > In the recent network slicing concept, I think that two
>>> factors are added to the existing traditional network model: E2E coverage
>>> and on-demand provisioning by automation. In many cases, IETF network is a
>>> part of the entire network connecting end hosts, and an E2E network slice
>>> would be realized with combining network slices deployed over different
>>> type of networks. Also, in the future, deployment of each network slice and
>>> combining them will be fully automated with orchestrators (for E2E and each
>>> domain). Then, what should be prior in IETF Network Slice NBI may not be
>>> providers' aspect but one consumer, including customers and orchestrators.
>>> In short, terms which are general and unified independently of underlay
>>> types may be needed.
>>> # This is just one option, and I don't say that the PE-CE model is
>>> inappropriate from such a perspective.
>>>
>>>
>>>>     Gyan> So the concept of “network slice” is half way there with the
>>>> slide concept being a pre existing condition with the overlay VPN or NVO3
>>>> overlay concept.  The second half of the slicing that was missing that is
>>>> now being added is the underpinnings of VPN overlay which is already sliced
>>>> to the underlay now extending the overlay slicing to the underlay slice of
>>>> resources.  From a cross sectional standpoint if you think of a pie the
>>>> knife went half way through the slice but landed in the middle bottom half
>>>> being the underlay but now when the knife goes all the way through the
>>>> cross section now you have slice of pie which is the “network slice”.
>>>>
>>>>>
>>>>>> Shunsuke > That's a very important point. What we need is a framework
>>> for linking overlay and underlay resources.
>>>
>>
>>     Gyan> Understood.  We have the framework draft.
>>
>> https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-07
>>
>> Are you good then with using the historical PE / CE nomenclature?
>>
>> Shunsuke> I'm still deciding which terms would be better, but I
> personally think that there are no problems to use  PE / CE  for this case.
> # The definition draft's authors will provide a result of analysis about
> endpoint soon.
>
>
>
>>
>>>
>>>>
>>>>>>
>>>>>>>
>>>>>>>> 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 <
>>>>>>>>>> hayabusagsm@gmail.com> 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 <
>>>>>>>>>>> shunsuke.homma.ietf@gmail.com> 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 <
>>>>>>>>>>>> hayabusagsm@gmail.com> 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) <
>>>>>>>>>>>>> jie.dong@huawei.com> 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:teas-bounces@ietf.org] *On Behalf Of *Adrian
>>>>>>>>>>>>>> Farrel
>>>>>>>>>>>>>> *Sent:* Thursday, February 25, 2021 6:52 PM
>>>>>>>>>>>>>> *To:* 'Young Lee' <younglee.tx@gmail.com>om>; 'Luis M.
>>>>>>>>>>>>>> Contreras' <contreras.ietf@gmail.com>
>>>>>>>>>>>>>> *Cc:* 'Joel M. Halpern' <jmh@joelhalpern.com>om>; teas@ietf.org;
>>>>>>>>>>>>>> 'Eric Gray' <ewgray2k@gmail.com>om>; 'John E Drake' <jdrake=
>>>>>>>>>>>>>> 40juniper.net@dmarc.ietf.org>gt;; 'Rokui, Reza (Nokia -
>>>>>>>>>>>>>> CA/Ottawa)' <reza.rokui@nokia.com>om>;
>>>>>>>>>>>>>> mohamed.boucadair@orange.com
>>>>>>>>>>>>>> *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 <teas-bounces@ietf.org> *On Behalf Of *Young Lee
>>>>>>>>>>>>>> *Sent:* 24 February 2021 10:22
>>>>>>>>>>>>>> *To:* Luis M. Contreras <contreras.ietf@gmail.com>
>>>>>>>>>>>>>> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>om>;
>>>>>>>>>>>>>> teas@ietf.org; Eric Gray <ewgray2k@gmail.com>om>; John E Drake <
>>>>>>>>>>>>>> jdrake=40juniper.net@dmarc.ietf.org>gt;; Joel M. Halpern <
>>>>>>>>>>>>>> jmh@joelhalpern.com>gt;; mohamed.boucadair@orange.com
>>>>>>>>>>>>>> *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 <
>>>>>>>>>>>>>> contreras.ietf@gmail.com>님이 작성:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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, <mohamed.boucadair@orange.com>
>>>>>>>>>>>>>> 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:contreras.ietf@gmail.com]
>>>>>>>>>>>>>> *Envoyé :* mardi 23 février 2021 23:46
>>>>>>>>>>>>>> *À :* Eric Gray <ewgray2k@gmail.com>
>>>>>>>>>>>>>> *Cc :* BOUCADAIR Mohamed TGI/OLN <
>>>>>>>>>>>>>> mohamed.boucadair@orange.com>gt;; Rokui, Reza (Nokia -
>>>>>>>>>>>>>> CA/Ottawa) <reza.rokui@nokia.com>om>; John E Drake <jdrake=
>>>>>>>>>>>>>> 40juniper.net@dmarc.ietf.org>gt;; teas@ietf.org; Joel M.
>>>>>>>>>>>>>> Halpern <jmh@joelhalpern.com>
>>>>>>>>>>>>>> *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
>>>>>>>>>>>>>> Teas@ietf.org
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> Teas@ietf.org
>>>>>>>>>>>>> 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
>>>>>>> <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
>>>> <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
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD