Subject: [Teas] Enhanced VPN discussions in various WGs

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 13 Nov 2019 07:27:02 -0000

Hi,

TEAS is the home of draft-ietf-teas-enhanced-vpn, and that provides an
anchor for a lot of VPN+ work going on across the IETF in Singapore.

It is worth a heads-up on this to help you track what is going on and pull
together the pieces in case you are interested in this approach to network
slicing. Apologies if I have missed anything.

TEAS
- A Framework for Enhanced Virtual Private Networks (VPN+) Service 
   draft-ietf-teas-enhanced-vpn-01
- Control plane considerations of enhanced VPN
   draft-dong-teas-enhanced-vpn-control-plane-00

LSR
- IGP Extensions for Segment Routing Based Enhanced VPN 
  draft-dong-lsr-sr-enhanced-vpn

BESS
- BGP-LS Filters: A Framework for Network Slicing and Enhanced VPNs
  draft-drake-bess-enhanced-vpn

SPRING
- Segment Routing for Enhanced VPN Service
  draft-dong-spring-sr-for-enhanced-vpn

I also note draft-dong-idr-bgpls-sr-enhanced-vpn, but don't see it on any
agendas this time around.

Cheers,
Adrian
--
Bored with reading Interent-Drafts?
Read some fairy stories for adults of all ages instead.
. Tales from the Wood
. More Tales from the Wood
. Tales from Beyond the Wood
. Tales from the Castle
Get them on line https://www.feedaread.com/profiles/8604/
Or buy a signed copy from me by post
*** Stop me in the corridor at IETF-106 to get a copy ***

---

From: David Sinicrope <[email-masked]>
Date: Wed, 13 Nov 2019 13:59:45 +0000

Hi Adrian,
Thanks for providing the cross reference, this is very useful.

How is the VPN+ work below related to GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE) draft-izh-ccamp-flexe-fwk-07?
There are some serious concerns with the draft above and exposure of FlexE constructs that OIF FlexE notes should not be exposed. 
e.g., FlexE Group, FlexE Channel
OIF FlexE indicates that it should present to the upper layer as Ethernet with no indication of FlexE in the dataplane i.e., it looks like any other Ethernet interface (with perhaps enhanced QoS capabilities.)

I see what looks to be exposure of similar FlexE constructs in the TEAS draft and other drafts. (e.g., FlexE Channels)

It would be good for these drafts to align with OIF specification of FlexE such that these constructs remain transparent and thereby ensuring they are leveraging what OIF specified and not variants.  i.e., present an Ethernet interface to the upper layer vs exposing FlexE constructs OIF says remain transparent. One exception to this would of course be the management and FlexE models which would be required to configure the FlexE links.  These of course should be liaised to OIF with an invite for that community to review and comment the work ongoing in IETF (CCAMP).

Thanks,
Dave

-----Original Message-----
From: Teas <[email-masked]> on behalf of "Adrian uk>" <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "Adrian uk>" <[email-masked]>
Date: Wednesday, November 13, 2019 at 8:28 AM
To: TEAS WG <[email-masked]>
Subject: [Teas] Enhanced VPN discussions in various WGs

    Hi,

    
    TEAS
    
    LSR
    
    BESS
    
    SPRING

    Cheers,
    Adrian
    --
    Bored with reading Interent-Drafts?
    Read some fairy stories for adults of all ages instead.
    .. Tales from the Wood
    .. More Tales from the Wood
    .. Tales from Beyond the Wood
    .. Tales from the Castle
    Get them on line https://protect2.fireeye.com/v1/url?k=2f623436-73e8fef5-2f6274ad-86e1ed4002b1-2fe12d2ac4a7279e&q=1&e=5710c793-d87c-49fb-8382-20dfcc8c29b5&u=https%3A%2F%2Fwww.feedaread.com%2Fprofiles%2F8604%2F
    Or buy a signed copy from me by post
    *** Stop me in the corridor at IETF-106 to get a copy ***

    _______________________________________________
    Teas mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/teas

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 14 Nov 2019 02:06:56 +0000

Hi Dave,

Thanks for your comments. 

The VPN+ framework document describes the framework and candidate technologies in different network layers which can be used together to provide VPN+ service. FlexE is listed as one of the candidate technologies in underlay data plane. In VPN+ related drafts, there is no description about exposing detailed information of FlexE. On contrary, abstraction is used to represent different underlay technologies with a unified manner to the network. 

Hope this helps to solve your concerns.

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of David Sinicrope
> Sent: Wednesday, November 13, 2019 10:00 PM
> To: [email-masked]; [email-masked]
> Cc: 'ccamp@ietf. org' <[email-masked]>
> Subject: Re: [Teas] Enhanced VPN discussions in various WGs
> 
> Hi Adrian,
> How is the VPN+ work below related to GMPLS Routing and Signaling
> Framework for Flexible Ethernet (FlexE) draft-izh-ccamp-flexe-fwk-07?
> There are some serious concerns with the draft above and exposure of FlexE
> constructs that OIF FlexE notes should not be exposed.
> OIF FlexE indicates that it should present to the upper layer as Ethernet with no
> indication of FlexE in the dataplane i.e., it looks like any other Ethernet interface
> (with perhaps enhanced QoS capabilities.)
> 
> It would be good for these drafts to align with OIF specification of FlexE such
> that these constructs remain transparent and thereby ensuring they are
> leveraging what OIF specified and not variants.  i.e., present an Ethernet
> interface to the upper layer vs exposing FlexE constructs OIF says remain
> transparent. One exception to this would of course be the management and
> FlexE models which would be required to configure the FlexE links.  These of
> course should be liaised to OIF with an invite for that community to review and
> comment the work ongoing in IETF (CCAMP).
> 
> Thanks,
> Dave
> 
> 
>     Get them on line
> https://protect2.fireeye.com/v1/url?k=2f623436-73e8fef5-2f6274ad-86e1ed
> 4002b1-2fe12d2ac4a7279e&q=1&e=5710c793-d87c-49fb-8382-20dfcc8c29b
> 5&u=https%3A%2F%2Fwww.feedaread.com%2Fprofiles%2F8604%2F