Hi Hannes,
I saw this [lively] thread only today. I am not sure concerns which
you brought up are really that big. You mentioned concerns of:
- interoperability
- efficiency (multiple LDP sessions)
- security
What happens with MPLS if Remote LFA chose 'wrong' IP address to
terminate the tunnel:
- IGP asks LDP to open targeted session to computed IP address
- LDP sends targeted Hello (UDP)
- Remote router responds with its ID and its transport address (which
generally speaking is different than IP address where targeted Hello was
received)
- TCP session is established between transport addresses.
So, after Hello exchange LDP has enough information to uniquely identify
peer router and avoid duplicated TCP sessions.
Transport address is always selected by receiving router and rLFA does
not have control over it.
I do not see room for interoperability issues even if rLFA routers
follow different selection algorithms. The only requirement is that rLFA
selects /32 address belonging to the remote end router.
There are no efficiency compromises - label exchange will happen
over single TCP session.
Security considerations - selection of address to terminate TCP
session is controlled by LDP configuration of a router, not by rLFA.
The only thing left is that tunnel tailend router must not block LDP
targeted Hellos on IP address selected by rLFA of computing router. This
is achievable even if rLFA algorithm of selecting termination IP address
is unknown (because there is finite number of /32 addresses advertised
by the router via IGP). With little help of vendor's documentation it
should be easy.
So it's good if authors add to the draft a possible algorithm but I
do not see a need for it to be too complex or truly standardized.
Anton
On 12/12/2012 03:49 PM, Hannes Gredler wrote:
clarence, stewart,
In favor of interoperable implementations i feel one should document how to
identify the transport IP address (in lieu of protocols extensions who would
explicitly advertise the transport IP addresses) to the PQ node for the
targeted LDP session.
I am proposing to append the following text to 3.2. "Tunnel requirements":
3.2. Tunnel Requirements
[ … ]
When a failure is detected, it is necessary to immediately redirect
traffic to the repair path. Consequently, the repair tunnel used
must be provisioned beforehand in anticipation of the failure. Since
the location of the repair tunnels is dynamically determined it is
necessary to establish the repair tunnels without management action.
Multiple repairs may share a tunnel end point.
<added-text>
Targeted LDP sessions are brought up using a pair of source (PLR) and
destination
(PQ node) loopback addresses. The following heuristics should be applied for
deriving the
loopback IP address from a PQ nodes link-state advertisement.
for the IS-IS routing protocol:
A PLR router should connect to the address
traffic-engineering deployments:
- reported both in the TE-router ID TLV 134
- and IP Reach TLVs (128,135) given that
- the prefix length is /32
or
no traffic-engineering deployments:
- reported both in the IP interface address TLV 132
- and IP Reach TLVs (128,135), given that
- there is only a single interface address advertised per the router
- the prefix length is /32
for the OSPF routing protocol:
A PLR router should connect to the address
traffic-engineering deployments:
- reported in the Router Address TLV (Type 10 LSA) and
- router (Type 1 LSA) ) stub network advertisement and
- the address mask is 255.255.255.255
or
non-traffic-engineering deployments:
- reported in the router-id field of the Type-1 LSA)
- the router (Type 1 LSA) stub network advertisement and
- the address mask is 255.255.255.255
</added-text>
tx,
/hannes
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
