Layer 2 VPN(L2VPN) Service Model (L2SM) Interim meetjng Wednesday 27th September 2017 2pm-3:30pm London Time Webex: htups://ietg.webex.com/ietg/j.php?MTID=m269230aaa9b65847700af143006c1a55 Adrian Farrel (adrian@olddog.co.uk ) Qin WU (bill.wu@huawei.com) htup://tools.ietg.org/wg/l2sm/charters 1 IETF L2SM Working Group Interim Meetjng
Note Well • Any submission to the IETF intended by the Contributor for publicatjon as all or part of an IETF Internet- Drafu or RFC and any statement made within the context of an IETF actjvity is considered an "IETF Contributjon". Such statements include oral statements in IETF sessions, as well as writuen and electronic communicatjons made at any tjme or place, which are addressed to: • The IETF plenary session • The IESG, or any member thereof on behalf of the IESG • Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functjoning under IETF auspices • Any IETF working group or portjon thereof • Any Birds of a Feather (BOF) session • The IAB or any member thereof on behalf of the IAB • The RFC Editor or the Internet-Drafus functjon • All IETF Contributjons are subject to the rules of RFC 5378 and RFC 8179. • Statements made outside of an IETF session, mailing list or other functjon, that are clearly not intended to be input to an IETF actjvity, group or functjon, are not IETF Contributjons in the context of this notjce. Please consult RFC 5378 and RFC 8179 for details. • A partjcipant in any IETF actjvity is deemed to accept all IETF rules of process, as documented in Best Current Practjces RFCs and IESG Statements. • A partjcipant in any IETF actjvity acknowledges that writuen, audio and video records of meetjngs may be made and may be available to the public. 2 IETF L2SM Working Group Interim Meetjng
Administratjvia • Charter: htup://datatracker.ietg.org/wg/l2sm/charter/ • Mailing List: htups://www.ietg.org/mailman/listjnfo/l2sm • Minutes: – htup://etherpad.tools.ietg.org:9000/p/l2sm-interim-2017-09-27- minutes – Chairs will record conclusions during the meetjng – Any volunteers to help? • Virtual Bluesheet: – You MUST record your atuendance on the (virtual blue sheets) – Use the space at the top of the Etherpad 3 IETF L2SM Working Group Interim Meetjng
Agenda (90 minutes) • Introductjon – Administrivia and Agenda Bash – (Chairs, 2 mins) – WG Status (Chairs, 3 mins) • Document Status (Giuseppe, 15 mins) – High-level overview of model – Changes since last revision • Work on Open Issues (Giuseppe / everyone, 45 mins) • Lessons from L3SM revision (Qin, 10 mins) • Raise new issues (All, 10 mins) • Next steps and wrap-up (Chairs, 5 mins ) 4 IETF L2SM Working Group Interim Meetjng
WG Status • Initjal version of I-D by L2SM design Team comprising 4 operators before Seoul – drafu-wen-l2sm-l2vpn-service-model-04 – Four revisions issued • Adopted L2sm drafu in Feb 21 afuer Seoul Meetjng – Two WG adoptjon calls on v-03 and v-04 of L2SM drafu drafu-wen-l2sm-l2vpn-service-model – V-04 adds usage example and change model structure to get in line with L3SM WG document (RFC8049) • 1 st L2SM meetjng (IETF97) in Seoul – Discussed relatjonship with MEF and prepare Liaison response. – Discuss L2SM Charter and the Defjnitjon of Customer Service Model – Discuss L2SM Design Team work and several open issues. • No Face to face L2SM meetjng in Chicago (IETF 98). But Design Team members in Chicago had a short meetjng with the following actjons: – Advance the content of the document through regular meetjngs focusing on specifjc issues – Edit and post revision of the document (Giuseppe : May 23, 2017) • One interim meetjng before IETF99 scheduled on May 25, 2017 – Discussion of outstanding issues – Edit and post revision of the document (Giuseppe : July 3, 2017) • No Face to Face L2SM meetjng in Prague (IETF99). But Design Team had a short meetjng to discuss remaining issues and planned for the next step. – Edit and post revision of the document (Giuseppe : September 18, 2017) 5 IETF L2SM Working Group Interim Meetjng
VPN Service Defjnitjon • Have a common base model that addresses multjple popular L2VPN service types. • The working group will derive a single data model that includes support for the following: – Point-to-point Virtual Private Wire Services (VPWS); – Multjpoint Virtual Private LAN services (VPLS) that use LDP-signaled Pseudowires ; – Multjpoint Virtual Private LAN services (VPLS) that use a Border Gateway Protocol (BGP) control plane as described in RFC4761 and RFC6624 ; – Ethernet VPNs specifjed in RFC 7432; – Other L2VPN service types may be included if there is consensus in the working group. • EVC Service? (Open issue for discussion later) 6 IETF L2SM Working Group Interim Meetjng
What is the L2SM Service Model Cloud Access VPN Topo VPN Service Multjcast 1. Support L2VPN creatjon 2. Support one site belonging to one VPN Site Extranet-VPN 3. Support one site belonging to multj-VPN Customer-Name 4. Support one Site with multjple logical accesses Service • Connectjng to multjple VPNs and these QoS Classifjcatjon logical accesses sharing the same bearer. Locatjon Standard Profjle 5. Provide L2VPN with Public Cloud Access QoS Profjle Device 6. Support extend L2VPN to Private Cloud Or Data Customized Site Diversity Center Network Profjle 7. Support Site-level QoS requirements VPN Policy Filter 8. Support Network Access level QoS VPN id VPN Management requirements Site-Role 9. Support Site level and Network Access Level Site VPN fmavor Security Requirements. Security 10.Support Site level Multjcast requirements and Access Diversity Network global level Multjcast requirements Access Bearer 11.Multj-AS support type 12.Support Network Access Creatjon based on Load balance Connectjon EVPN Service Placement constraints and other Multjcast Security constraints parameters. VPW,VPLS Service 13.Support point to point network connectjvity based VPN and multj-point network connectjvity. VPN atuach PWE3 14.Support distribute VPN route across sites Availability L2TP-PW belonging to difgerent VPNs Signaling Optjon 7 IETF L2SM Working Group Interim Meetjng
Connectjon Defjnitjon in L2SM model 802.3 802.3 Customer Port Mode CE PE PE CE Network Tagged Customer 802.3 CE PE PE CE VLAN Mode Network 802.1Q Tagged Customer 802.3 QinQ Mode CE PE PE CE Network 802.1Q 802.3 Tagged Customer QinAny Mode CE PE PE CE Network 802.1Q LACP Customer 802.3 LAG Mode CE PE PE CE Network LAG Interface • Under each Site Network Access, Ethernet connectjon in data plane supports several modes – Physical Interface Mode – Dot1q interface Mode • VLAN Mode: • QinQ Mode: Confjg both S-tag and C-tag on PE • QinAny Mode: Only Confjg S-tag on PE and PE doesn’t know C-Tag – LAG Interface Mode • Need to specify LACP parameters. – In additjon, we may support optjonal L2CP parameters between CE and PE 8 IETF L2SM Working Group Interim Meetjng
Multjcast Support • In case of multjcast support, we describe multjcast tree type, Paris Site traffjc type, and group-to-port- mapping type at a global level • We also describe MAC Multjcast Barcelona Group at site level: Site PE1 Madrid PE2 Site – VLAN ID : Displays the VLAN ID of the Multjcast group – MAC Address Group: Displays the London Site MAC address of the group – Ports/LAG: Select to display the ports/LAGs belonging to the Multjcast group 9 IETF L2SM Working Group Interim Meetjng
Single homed, Dual Home, and Multj-homing Support • The "site-type" defjnes the way the VPN multjplexing is done. – site-vpn-fmavor-single: The site belongs to only one VPN. – site-vpn-fmavor-multj: The site belongs to multjple VPNs, and all the logical accesses of the sites belong to the same set of VPNs. • In additjon, we have site-network- access/access-diversity parameters (e.g., group-id, constraint-type ), they can tell us which of network accesses belong to the same group, what constraint type is. • Intentjon is that text describes how to use all these parameters to achieve the four deployment models shown Actjon point 10 IETF L2SM Working Group Interim Meetjng
NNI Support • In case of both two sites belonging to Paris one single AS or one administratjve Site domain, we can use site-network- NNI access to describe one or more Site network–connectjvity under each site. Barcelona Site PE1 PE1 ASBR1 ASBR2 Madrid Site • In case of both two sites belonging to ASes, we can use NNI site type to London describe network connectjvity between Site ASBR1 and ASBR2. • This enables us to provide Inter- provider control connectjons to run only between the two border routers 11 IETF L2SM Working Group Interim Meetjng
Recommend
More recommend
