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
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.)”
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
Intra-Area
• We are agreed
– The TED includes TE links from within the IGP Area
– IGP TE extensions are used
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
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)
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)
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
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
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
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?
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”
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?
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
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