1 / 8

draft-jounay-pwe3-p2mp-pw-requirements-02.txt

draft-jounay-pwe3-p2mp-pw-requirements-02.txt. IETF 72 PWE3 Working Group Dublin, July 2008 F. Jounay , P. Niger, France Telecom Y. Kamite, NTT Communications S. Delord, Uecomm L. Wang,Telenor G. Heron, BT R. Aggarwal, Juniper L. Martini, Cisco

alexandra-brennan
Download Presentation

draft-jounay-pwe3-p2mp-pw-requirements-02.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-jounay-pwe3-p2mp-pw-requirements-02.txt IETF 72 PWE3 Working Group Dublin, July 2008 F. Jounay, P. Niger, France Telecom Y. Kamite, NTT Communications S. Delord, Uecomm L. Wang,Telenor G. Heron, BT R. Aggarwal, Juniper L. Martini, Cisco M. Bocci, M. Vigoureux, Alcatel-Lucent (new co-authors) L. Jin, Nokia-Siemens (new co-author)

  2. General context • PWE3 rechartering, today the PWE3 WG charter includes • "A pseudowire emulates a point-to-point or point-to-multipoint link" • "PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts, in particular in defining point-multipoint (P2MP) PWs." • WG objectives • "Specify requirements and mechanisms for P2MP functionality for PWs. This work will be coordinated with the L2VPN and MPLS working groups." • Goals and Milestones • Jul 2009 P2MP Requirements LC • L2VPN rechartering in progress • Virtual Private Multicast Service (VPMS) -- A Layer 2 service that Provides point-to-multipoint connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, etc., across an IP or MPLS-enabled IP PSN. • Goals and Milestones • Mar 2009 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG • Nov 2009 Submit Auto-Discovery solution for VPMS to IESG

  3. P2MP draft history draft-ietf-jounay-pwe3-p2mp-pw-requirements • March 2007 (version v00, IETF68) • Use Cases • P2MP SS-PW reference model, signaling requirements (setup, maintenance, OAM) • P2MP MS-PW reference model, signaling requirements • December 2007 (version v01, IETF70) • P2MP PW definition rewording • introduction of VPMS "VPMS Virtual Private Multicast Service as the associated service relying on the use of unidirectional P2MP PWs and on a cross-connect function at PEs" • Refocused the proposed draft on requirements, removed some text related to implementation solution : VPLS, source/leaf initiated setup, PW label assignment… • July 2008 (version v02, IETF72) • Proposal to progress the work based on existing drafts • L2VPN WG • Framework and Requirements for Virtual Private Multicast Service (VPMS), draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt • PWE3 WG • Requirements for Point-to-Multipoint Pseudowire, draft-jounay-pwe3-p2mp-pw-requirements-02.txt

  4. Changes since last version • Text removal • All parts related to VPMS (e.g. use cases) • now described in the associated L2VPN draft • Some rewording for the sake of clarity • Abstract • Problem statement • MAY, SHOULD, MUST • Some technical modifications, mainly • Clarification text to explain that a P2MP PW is unidirectionnal • Additional text to guarantee a P2MP PW consistent set up (same type of ACs, compatible interface parameters, etc)

  5. Technical modifications (1/3) P2MP SS-PW Reference Model • Section 3.3.1. • An AC attached to P2MP PW MUST be configured as "sender" or "receiver" not both. Any AC is associated with the role of either sending side (Tx) or receiving side (Rx) from the view of CE. Thus every AC deals with unidirectional traffic. P2MP SS-PW Underlying Layer • Section 3.3.1. • The P2MP PW MUST be supported over only one P2MP PSN tunnel. This P2MP PSN tunnel MUST be able to serve more than one P2MP PW. PW Type Mismatch • Section 3.3.1. • the ACs configured at Ingress PE and Egress PEs of a P2MP PW MUST be of the same PW type [RFC4446]. In case of a different type, the passive PE (Ingress or Egress PE, depending on the signaling process) MUST support mechanisms to reject attempts to establish the P2MP PW. • Section 4.3.3. • the P2MP MS-PW requires ACs of the same PW type. Therefore the segments composing the P2MP MS-PW MUST be also of the same PW type [RFC4446]. The S-PE MAY only support switching PWs of the same PW type. In case of a different type, the passive PE (S-PE or T-PE) MUST support mechanisms to reject attempts to establish the P2MP MS-PW

  6. Technical modifications (2/3) Interface Parameters sub-TLV • Section 3.3.2. • When the interface parameters are signaled, the Ingress PE SHOULD take the decision to accept or not an Egress PE in the PW tree based on the interface parameters advertised by the Egress PE. For that purpose the Ingress PE MUST be configured with a threshold value of the advertised interface parameters. E.g. for some interface parameters (e.g. MTU size (Ethernet), number max of concatenated ATM cells, etc), the parameters advertised by the Egress PE MUST be at least superior or equal to those configured at the Ingress PE. For other like CEP/TDM Payload bytes (TDM), the value MUST match exactly at the Ingress and Egress PEs. • Note that when using an Ethernet P2MP PW with the Tag mode, the interface parameter VLAN requested MUST be disabled, since a given Egress PE requesting a VLAN marking at the Ingress PE will impose this value to all Egress PEs belonging to the PW tree • Note that a translation (VPI/VCI or VLAN service delimiter) SHOULD be enabled only at the Egress PE. Section 4.3.4. • The section 3.3.2 is also relevant to P2MP MS-PW. The Egress T-PE MAY signal its AC' interface parameters to the Ingress T-PE so as to make sure that AC at the Egress T-PE is capable to support traffic coming from AC at the Ingress T-PE. In the P2MP MS-PW case, S-PEs MUST propagate correctly this information up to the Ingress T-PE.

  7. Technical modifications (3/3) Leaf Grafting/Pruning • Section 3.3.3. • The addition or removal of a leaf SHOULD also lead to the P2MP PSN tunnel update accordingly. This MAY cause P2MP PSN tunnel to add or remove the corresponding leaf. Failure Reporting and Processing • Section 3.4. • A solution MUST support in-band OAM mechanism to detect failures: unidirectional point-to-multipoint traffic failure. This SHOULD be realized by enhancing existing unicast PW methods, such as VCCV for seamless and familiar operation. • In case of failure, it SHOULD correctly report which leaf PEs are affected. This SHOULD be realized by enhancing existing PW methods, such as LDP Notification for seamless and familiar operation. The notification message SHOULD include the type of fault (P2MP PW, AC or PSN tunnel). • A solution MAY support OAM message mapping at PE if failure happens (i.e., mapping between AC service OAM and P2MP PW OAM) • Section 4.4. (P2MP MS-PW)

  8. Next Steps • Current draft incorporates all the feedback/comments received today from interested parties • Additional comments, proposal are welcomed • The draft is largely considered as a good basis to progress the work on P2MP PW definition within the PWE3 WG • Already presented two times in PWE3 WG meetings • No significant concerns/objections expressed • The authors would like the WG to consider adoption of this document as WG draft • Would provide the necessary coordination with the associated work in the L2-VPN WG • Would be used as requirements document to provide guidelines for the definition of solution drafts

More Related