Summary

  • RFC 7212 lets an MPLS endpoint advertise capabilities, configuration parameters and application-specific information over the G-ACh; it does not turn the sender into the receiver’s configuration authority.
  • The receiver retains control through per-channel enablement, local application authorization, application-specific processing rules, explicit lifetimes and authenticated freshness.
  • Safe automation requires an operator-visible reason chain: what arrived, who authenticated it, how long it remains valid, which local policy consumed it and why any configuration value changed.

An advertisement is a fact, not a command

The G-ACh Advertisement Protocol, or GAP, solves a practical transport-network problem. An LSP, pseudowire or section endpoint may need to tell a peer which capabilities it supports, which parameters it is using or what an application should know about the channel. In a non-IP MPLS-TP environment, familiar IP discovery mechanisms may not exist. A link-layer-independent advertisement channel can therefore remove brittle manual steps and expose configuration mismatches earlier.

The useful leadership boundary sits inside the word “advertisement.” RFC 7212 describes a simple one-way mode: a configured sender transmits application data blocks containing typed information. The receiver may validate or adjust local configuration, but the protocol does not collapse the two administrative roles. Transmission and reception operate per data channel and are configurable by the operator. All GAP applications are disabled by default. Received data is made available only to local applications that need it and are locally authorized to view it.

Those rules divide power cleanly. The sender controls the truth it presents about itself. The receiving operator controls whether GAP runs, which local application may see the information and what that application is permitted to do. The application specification controls the meaning of its TLVs. A packet’s arrival proves none of those permissions by itself.

A concrete control fixture

Consider two adjacent MPLS-TP nodes on an Ethernet section without IP forwarding. Node A advertises its source MAC address and maximum frame size using the Ethernet Interface Parameters application defined by RFC 7213. Node B can learn the address and compare the advertised frame size with its own minimum.

That is valuable evidence, but it is not a remote instruction to shut the link. RFC 7213 leaves the consequential response to configured policy: an operator may choose to take the link down after a mismatch, or leave it up and use OAM to test the effective frame size. The same received fact can therefore support different legitimate actions under different local policies.

The beneficiary is not merely the protocol implementation. The operator gains a visible account of the peer state, a way to replace stale static assumptions and a diagnostic trail when two ends disagree. RFC 7213 recommends sending the relevant advertisement promptly after reconfiguration, restart or a detected disconnection so that link state can be initialized again. Applications benefit from a common carrier that does not depend on a particular link-layer discovery protocol. None of those benefits requires surrendering local change authority.

Freshness, identity and meaning are separate checks

RFC 7212 gives every application data block a lifetime. Static data may be retained only for the stated period. A zero lifetime marks it immediately expired, while an empty block can expire the prior data for that application. On restart, retained peer and application state must be discarded. These are not housekeeping details; they prevent an earlier observation from masquerading as current authority.

Authentication answers another question. The RFC defines a keyed message-authentication procedure and uses timestamps to help reject replayed messages. Key identifiers are associated with authentication parameters through explicit operator configuration or a separate key exchange. Thus, authenticity, freshness and semantic authorization remain distinct. A valid MAC can show that an approved key protected the message. It cannot decide whether the receiving application should rewrite a parameter, and it cannot extend data beyond its lifetime.

Unknown application data makes the same point from the opposite direction. A receiver that cannot interpret an application may retain the bytes for the advertised lifetime because they may help an operator. Retention is not execution. The system can preserve evidence without pretending to understand it.

The operating cost belongs with the authority

GAP deliberately leaves several costs with applications and operators. The sender chooses the transmission rate. The application must fragment data that does not fit, because GAP supplies no fragmentation or reassembly. The application and operator must prevent advertisements from congesting the peer link. Keys, clock behavior, replay tolerance, expiration, restart cleanup and audit visibility all need operating ownership.

RFC 7212 also requires received data to be inspectable. If inbound information changes local configuration, the reason for the change must be clear. This is the decisive governance control. Automation is acceptable when it produces a receipt that lets an operator reconstruct the transition from authenticated observation to local decision. Without that record, convenience quietly turns a peer’s statement into unexplained authority.

The counterfactual is easy to picture. A previously legitimate advertisement is replayed after a hardware replacement. A lifetime is ignored across a restart. A consuming application treats an unknown or unauthorised TLV as a command. The bytes may look technically well formed while the resulting configuration is wrong. GAP’s design gives operators the pieces to avoid this outcome, but only if deployments keep the pieces separate.

Sources