1 / 12

Presented by: Malcolm Betts malcolm.betts@zte

LS293 - Request for G-ACh channel codepoint to support traditional transport environment and: draft-tsb-mpls-tp-ach-ptn. Presented by: Malcolm Betts malcolm.betts@zte.com.cn. What is being requested?.

ovid
Télécharger la présentation

Presented by: Malcolm Betts malcolm.betts@zte

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. LS293 - Request for G-ACh channel codepoint to support traditional transport environmentand:draft-tsb-mpls-tp-ach-ptn Presented by: Malcolm Betts malcolm.betts@zte.com.cn

  2. What is being requested? • ITU-T SG15 requests the IETF to allocate a G-ACh code point as described in:draft-tsb-mpls-tp-ach-ptn • Allocation of this code point will: • Allow ITU-T to document the tools required to address the unique needs of the transport network • Make more efficient use of the resources of both organizations • The use of this G-ACh code point will fully comply with the framework and architecture for MPLS-TP Routing Area Open Meeting

  3. February meeting of SG15 • Concluded that a significant number of network operators view that their needs are not satisfied by the solutions currently under development in the IETF • Therefore, decided to document a targeted “PTN OAM” solution in ITU-T Recommendations • 8 Network operators from Europe and Asia submitted contributions supporting this approach • Plan to produce Recommendations for both the ITU PTN OAM and IETF OAM solutions e.g. • G.8113.1 – ITU PTN OAM solution • References RFC5718 for the MCC and SCC • G.8113.2 – IETF defined OAM solution Routing Area Open Meeting

  4. February meeting of SG15 (cont’d) • Developed material to describe the network environment that caused some network operators to request the PTN OAM solution • Differences are close to invisible at the level of the requirements in RFC5860 • Many of the issues only become apparent when the protocol and equipment behaviour is explored • For a description of the network environment for this application - see: • https://datatracker.ietf.org/documents/LIAISON/file1209.pdf • draft-tsb-mpls-tp-ach-ptn will be updated to include an applicability statement • Interconnection scenarios are either client/server (no interaction) or will use the IETF defined solution - see: • https://datatracker.ietf.org/documents/LIAISON/file1210.pdf Routing Area Open Meeting

  5. Background • ITU-T OAM solution for PTN applications is documented in draft Recommendation G.8113.1 • Uses same OAM tools as draft-bhh-mpls-tp-oam-y1731-06 • draft-bhh-mpls-tp-oam-y1731-00 posted 2009-03-04 • Supporting network operators have repeatedly indicated: • The need for rapid standardization of an OAM solution to meet their urgent network deployment needs • This solution meets the needs of their transport networks Routing Area Open Meeting

  6. Background (cont’d) • At the SG15 meeting some ITU-T Members made the assertion that the IANA ACh code point registry is concerned with “Naming and Numbering” and therefore has “regulatory” implications • The IETF should clarify that it is a registry of Protocol Identifiers Routing Area Open Meeting

  7. Where are we now? • Having a single solution is a desirable objective • However, it is also necessary to be pragmatic in standards • We have been working for more than 2 years without any indication of convergence • Due to delays in the standardization of a solution major network deployments have already occurred • Over 200,000 nodes running the solution in G.8113.1 have been deployed • Standardizing 2 solutions will prevent the proliferation of multiple regional/operator specific solutions • Allocation of an ACh code point for the ITU solution will • Ensure that this solution is unambiguously identified • In the event of an accidental interconnection between the ITU and IETF solutions the ITU OAM messages can be safely discarded • Protect the Internet • Reduces the amount of time we spend on this topic in future Routing Area Open Meeting

  8. Next Steps • Clarify that the ACh code point being requested in draft-tsb-mpls-tp-gach-ptn is a protocol identifier • Add an applicability/scope statement to draft-tsb-mpls-tp-gach-ptn • Make it a WG draft • Request an early allocation from IANA Routing Area Open Meeting

  9. Backup material • Interconnection scenarios • Note: • PSN: application environment for the IETF developed solution • PTN: application environment for the ITU developed solution Routing Area Open Meeting

  10. Interconnect 1PTN client over a PSN server Routing Area Open Meeting

  11. Interconnect 2PSN client over a PTN server Routing Area Open Meeting

  12. Interconnect 3 LSP or PW originating in a PTN network and terminating in a PSN network Routing Area Open Meeting

More Related