1 / 7

RFC 3036 FECs

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.

kaiyo
Download Presentation

RFC 3036 FECs

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. 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 11/9/04

  2. 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. 11/9/04

  3. 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 11/9/04

  4. 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? 11/9/04

  5. 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 11/9/04

  6. 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 11/9/04

  7. 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 11/9/04

More Related