RFC 3036 FECs RFC 3036 defines FECs used to bind labels to address prefixes in routing table Two FECs defined: Address Prefix FEC Host Address FEC Not all possible FECs When labels are bound to other things, need other FECs E.g., PWE3 defines FECs for binding labels to PWs E.C.Rosen, MPLS WG 11/9/04

HA FEC vs. AP FEC What’s the difference between: HA FEC and AP FEC with /32 address? Some claimed: egress LSR must distinguish, from top label: whether packet is addressed to it, or whether packet needs to be forwarded further (i.e., packet tunneled to egress LSR). So need label which can be used only for 1, never for 2. E.C.Rosen, MPLS WG 11/9/04

Functionality not Needed LSR Egress specifies HA FEC for its own address Corresponding label used for management packets address to that LSR Is this needed? Was always doubtful Never been used The DS needs to remove this functionality E.C.Rosen, MPLS WG 11/9/04

Another Party Heard From MPLS/FR Forum has proposal using HA FEC Issues: Are they really using HA FEC as defined in RFC 3036, or Are they using only a subset of that functionality, so that the rest can be discarded, or Are they extending LDP in a way which requires a new FEC? E.C.Rosen, MPLS WG 11/9/04

MPLS Forum’s Proposal CE sends to Ingress PE: Label Request with HA FEC and Traffic Parms TLV Makes a resource reservation Ingress PE responds with label Same label may be assigned to multiple HA FECs, if they all have the same egress PE Ingress PE uses label to find corresponding reservation Ingress PE may base forwarding decision for labeled packet on IP address of packet E.C.Rosen, MPLS WG 11/9/04

Observations on Forum Proposal Violates RFC 3036/3.5.7.1: this use of HA FEC does not require a routing table entry for the address Strange data plane semantics: “PE may or may not look at IP address” Suggests that the LSP can only be one hop long Downstream on Demand only whereas RFC 3036 defines for DU ordered mode Forwarding Equivalence Class is set of packets to which a particular resource reservation should be applied E.C.Rosen, MPLS WG 11/9/04

Conclusions New FEC has been implicitly defined New FEC type must be defined Resource reservation is part of the FEC Advantages of using new FEC type: No issues of how HA FEC is handled or what it means in non-Forum situations (e.g., DU, no reservations) Use of HA FEC in non-Forum situations would be error Unused functionality discussed earlier can be eliminated from LDP Forum can freely define label and FEC semantics without worry of conflict No impact on non-Forum implementations E.C.Rosen, MPLS WG 11/9/04