1. What do we put in the TED? Which TE links from the network should appear in the Traffic Engineering Database at a Label Switching Router? An attempt to list all the possibilities for working group discussion Adrian Farrel, with helpful input from Lou Berger, John Drake, Jean-Louis Le Roux, and Dimitri Papadimitriou

2. Background Material RFC 4105 : Requirements for Inter-Area MPLS Traffic Engineering “…a solution … MUST not require the IGP to carry some unreasonable amount of extra information and MUST not unreasonably increase the IGP flooding frequency.” “Containment of routing information MUST not be compromised to allow inter-area traffic engineering. Information propagation for path-selection MUST continue to be localized. In other words, the solution MUST entirely preserve the concept of IGP hierarchy.” RFC 4216 : MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements “The proposed solution(s) MUST have a minimum impact on network scalability from both intra- and inter-AS perspectives.” “This requirement applies to all of the following: –IGP (impact in terms of IGP flooding, path computation, etc.) –BGP (impact in terms of additional information carried within BGP, number of routes, flaps, overload events, etc.)”

3. Questions to Keep in Mind What TE information do we need? Where do we need the information? What are the scaling concerns –Volume of information –Stability of information Note: –“All bets are off” RFCs represent discussion and consensus and should not be disregarded lightly Current working group I-Ds can be abandoned if the WG changes direction

4. Intra-Area We are agreed –The TED includes TE links from within the IGP Area –IGP TE extensions are used

5. AS-Internal, Extra-Area We could do this –IGP TE extensions can be flooded with AS scope –But do we generally do this? I don’t see it being done anywhere Why not? –Scaling concerns per RFC 4105

6. Local Inter-AS TE links We are working on this –draft-chen-ccamp-isis-interas-te-extension –draft-ietf-ccamp-ospf-interas-te-extension Useful to help to pick a TE path out of the AS –AS may be multi-homed (to a single AS or to multiple ASes) How do we discover the TE details for the reverse direction? –Configuration? –BGP? Flooding scope? –Area scope: definitely –AS scope: maybe –(See also non-local inter-AS TE links later)

7. AS-Internal CE-PE TE Links We can’t do this yet, but there are proposals –draft-ietf-l1vpn-ospf-auto-discovery –draft-fedyk-bgp-te-attribute –draft-vasseur-ccamp-ce-ce-te Useful to help to pick a TE path to a multi-homed CE Intuitively useful for CE-CE services such as L3VPN and L1VPN Flooding scope? –Area scope: definitely –AS scope: maybe –(See also AS-external CE-PE TE links later)

8. AS-External TE Links Why don’t we do this? –Scaling –Confidentiality Why s the network partitioned into distinct ASes? Different question from TE aggregation –Considered later

9. Non-local Inter-AS TE Links What possible value? –No use in end-to-end path computation without intervening TE links –Could be used in selection of ASBR or AS sequence Particularly for multi-homed ASes How useful is this if there is no TE connectivity inside the ASes? Selection of AS sequence is a policy/commercial issue What are the issues? –Scaling –Confidentiality

10. AS-External CE-PE TE Links What is the possible value? –Could be used in selection of exit PE (and hence AS sequence) CEs can be multi-homed to multiple PEs and multiple ASes How useful is this if there is no TE connectivity knowledge inside the ASes? Selection of AS sequence is a policy/commercial issue –Intuitively useful for CE-CE services such as L3VPN and L1VPN What are the issues? –Scaling –Confidentiality

11. Virtual TE Links Virtual TE links are LSP tunnels or segments connecting border routers in a domain (here we see them for ASes) Are they any use in a TED outside the domain? –Allows ingress to plot a path across multiple domains –Allows confidentiality to be preserved while still advertising connectivity –Not much use unless inter-AS and CE-PE TE links are also advertised Scaling –Potentially many ASes with many virtual TE links –Inclusion of CE-PE TE links may be a problem Manageability –How do we plan and provision the virtual TE links?

12. Potential TE Links Potential TE links are LSP tunnels or segments connecting border routers in a domain that could be set up, but are not necessarily set up yet –Use outside the domain as for virtual TE links –Not much use unless inter-AS and CE-PE TE links are also advertised Addresses the manageability issues of virtual TE links Scaling issue is magnified Introduces the concepts of “TE reachability” and “virtual link aggregation” –Either required to be dynamic (very heavy processing and flooding consequences –Or information is potentially inaccurate (not so useful in the TED) –Note that the case of static virtual link aggregation collapses to the “virtual node aggregation model”

13. Virtual Node Aggregation Model What do we advertise? Is the aggregation valid or useful? –Consider a failure of the green link. The virtual node is partitioned. How often do we have to update the aggregation/advertisement? How do we advertise limited cross-connect capabilities?

14. Proposal A TED should not include TE links that do not have at least one link end within the AS that houses the TED –Scaling Amount of flooded information Frequency of flooding updates Intensive aggregation processing >> Rephrase this to say “Area” instead of “AS”? –Manageability –Confidentiality Dangers to be avoided –Swamped BGP or IGP –TED bloated with potentially useless information –Aggregation processing problems are issues for implementation and deployment. They do not impact other ASes. –Application of policy and filtering are *potentially* issues for implementation, but failure to filter correctly could cause problems to the rest of the network –Development of solutions ahead of implementation/deployment

15. What Should the Working Group Do? Decide what function we want to achieve Decide what function would be dangerous Decide how to achieve desired behavior –Decide what routing architecture to use –Decide what protocol extensions we need to define –Decide what behavior we should proscribe and how