RFC 6423

Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)

πŸ“… published November 2011, from ietf

Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) πŸ’–

okay bestie, this is RFC 6423 πŸŽ€ It's a Standards Track document, so it's a real Internet standard and not just vibes. It was dated November 2011, and it's an ISSN 2070-1721 thing. The authors are Han Li (China Mobile), Luca Martini (Cisco Systems), Jia He (Huawei), and Feng Huang (Alcatel-Lucent). The header only lists one doc it updates, which is [RFC5586]. It doesn't obsolete anything. The whole point of this one is to update RFC 5586 by fixing a restriction on GAL for pseudowires 🧚

Abstract πŸ¦‹

This document covers the requirements for using the Generic Associated Channel Label (GAL) in pseudowires (PWs) in MPLS Transport Profile (MPLS-TP) networks. It also updates how RFC 5586 describes GAL usage by removing the restriction on using GAL for PWs, especially in MPLS-TP environments. πŸ’œ

Status of This Memo πŸ“œ

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6423.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents πŸ—‚οΈ

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
   2.1. Terminology ................................................3
3. GAL Usage for MPLS-TP PW ........................................3
4. Security Considerations .........................................4
5. Acknowledgments .................................................4
6. References ......................................................5
   6.1. Normative References .......................................5
   6.2. Informative References .....................................5

1. Introduction ✨

[RFC5586] takes the Associated Channel mechanism from [RFC5085] and generalizes it so it can be used for Sections, Label Switched Paths (LSPs), and Pseudowires (PWs) in MPLS networks. [RFC5085] defines the Associated Channel Header (ACH), and [RFC5586] generalizes this into the Generic Associated Channel (G-ACh). 🫢

[RFC5586] also defines a generalized label-based exception mechanism that uses the Generic Associated Channel Label (GAL) alongside the ACH for use with LSPs, but it prohibits GAL usage with PWs. πŸ™ˆ

This document removes that restriction imposed by [RFC5586]. πŸ”₯

2. Conventions Used in This Document πŸ“

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the ones that carry the weight, so read them carefully πŸ‘‘

2.1. Terminology πŸ’…

ACH      Associated Channel Header

CW       Control Word

G-ACh    Generic Associated Channel

GAL      Generic Associated Channel Label

MPLS-TP  MPLS Transport Profile

OAM      Operation, Administration, and Maintenance

3. GAL Usage for MPLS-TP PW πŸ’–

Okay so, according to the MPLS-TP requirements document [RFC5654], MPLS-TP mechanisms and capabilities need to be able to interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] architectures, as appropriate. [RFC5586] splits up the usage of GAL with PWs in MPLS and MPLS-TP environments in Section 4.2, and it says this:

In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs.

So the GAL can be used for MPLS-TP LSPs and Sections, but not for PWs in an MPLS-TP network. The drama 😭

But here's the plot twist. There's no restriction on GAL usage in MPLS PWs. That's described right after in the same section (Section 4.2) of [RFC5586]:

However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs.

The inconsistency between GAL with MPLS PWs and GAL with MPLS-TP PWs can cause unnecessary implementation differences, and it goes against the MPLS-TP requirements. Not it πŸ™…β€β™€οΈ

So this document says the GAL can be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, Sections, and PWs in both MPLS and MPLS-TP environments, with no discrimination. Equal treatment, bestie 🌸

Here's how [RFC5586] gets updated, by removing the restrictions on using GAL for PWs:

  • Section 1 (Introduction) in [RFC5586]: the original text was
The GAL mechanism is defined to work together with the ACH for LSPs and MPLS Sections.

and it gets replaced by

The GAL mechanism is defined to work together with the ACH for LSPs and MPLS Sections, and for PWs.
  • Section 4.2. (GAL Applicability and Usage) in [RFC5586]: the original text was
In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs.

and it gets replaced by

In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack.

4. Security Considerations πŸ”’

There are no further security considerations than those in [RFC5586]. So the security story is the one from RFC 5586, and that's the one to read with full focus πŸ’€

5. Acknowledgments 🫢

The authors would like to thank Luyuan Fang, Adrian Farrel, Haiyan Zhang, Guanghui Sun, Italo Busi, and Matthew Bocci for their contributions to this work.

The authors would also like to thank the authors of [RFC5586] and the people who were involved in developing [RFC5586]. 🌷

6. References πŸ“š

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
          Label Switching Architecture", RFC 3031, January 2001.

[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
          Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
          "MPLS Generic Associated Channel", RFC 5586, June 2009.

6.2. Informative References

[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
          Circuit Connectivity Verification (VCCV): A Control Channel
          for Pseudowires", RFC 5085, December 2007.

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
          Sprecher, N.,and S. Ueno, "Requirements of an MPLS
          Transport Profile", RFC 5654, September 2009.

Authors' Addresses πŸ’Œ

Han Li
China Mobile Communications Corporation
EMail: lihan@chinamobile.com

Luca Martini
Cisco Systems, Inc.
EMail: lmartini@cisco.com

Jia He
Huawei Technologies Co., Ltd.
EMail: hejia@huawei.com

Feng Huang
Alcatel-Lucent shanghai Bell
EMail: feng.f.huang@alcatel-sbell.com.cn

That's the whole RFC, bestie. Go spread the GAL-for-PWs energy πŸŒˆπŸ’…βœ¨

πŸ“¦ where this page comes from