In LDP networks, I see 2 problems and 2 goals. 2 problems: - T-LDP (TL): finding an IP address of the PQ to set up the T-LDP session - TUnnel end point (TU): finding an IP address of the PQ useable as tunnel end point.
And 2 goals: - A short term goal is to maximize (>80% ?) the ability of the PLR/S/R-LFA to get the right IP address of the PQ, while the PQ is not compliant with R-LFA. To keep LFA deployments properties, it would be nice if the PLR would work out of the box, without requiring change (software/configuration) on other routers. This is the ingress (i) issue in current networks. One could say that this is a local issue that does not need standardization. However, this requires taking into account existing PQ implementations/capabilities. Hence RTGWG seems a useful place for discussing this, versus a full mesh of bi-lateral discussion between vendors which besides would not include SP. This does not prohibit an implementation to use a smarter solution. - A long term goal is to guaranty (100%) the ability of the PLR/S/R-LFA to get the right IP address of the PQ, when the PQ is compliant with R-LFA. This is the egress (e) issue/requirements in future networks. This point requires standardization. When combining, this gives 4 points to consider. Eventually, there will be some overlap between the solutions. ==TL== Regarding TL (T-LDP): =e=: for the egress long term, 2 solutions have been suggested - advertise the TLV 124 (TE Router ID) and accept T-LDP hello from this address. Then either advertise LDP Transport Address optional object or accept LDP session from this address. (Hannes) - accept T-LDP hello from all its /32 address advertise in the IGP. Then either advertise LDP Transport Address optional object or accept LDP session from these addresses. (Anton) =i=: for the ingress short term, 2 solutions: - TE-router ID TLV 134, alternatively the /32 IP interface address TLV 132 (both needs also be advertised in any IP Reach TLVs (128,135, 235)) (Hannes) - idem but trying all /32 IP interface in address TLV 132, or possibly all /32 advertised in any IP reach if the number of reach /32 if below a threshold (e.g. 5) or matching a configured prefix. ==TU== regarding TUnnel end point: TU may be different than TL, for example in a network using multiple loopbacks addresses, one being advertised as FEC in LDP for MPLS traffic and one not being advertised for IP traffic routed hop-by-hop. So far this point has not been discussed. =i= for the ingress short term: - one could use TL if there is an LSP toward this FEC. Alternatively, a FEC received over the T-LDP session with a null label (explicit or implicit). =e= for the egress short term: - requiring the TL to be advertised in LDP may not be possible with existing configuration (e.g. setting both the Router ID and the range of FEC advertised in LDP). Seems a priori hard to me to require the change of the configuration (changing the loopback advertised in LDP is not an option. Changing the TE-router ID to prefer the one advertised in LDP seems easier. Should we require this by default? However, that does not seem to me like a long term solution when we can change the behavior both on the PLR & the PQ. - advertising all loopbacks in TLV 132 (IP interface address). Then the ingress intersects this set with the set of FEC advertised in LDP. - finding another existing field? - defining a new field (either in IGP or T-LDP) Thanks, Regards, Bruno >From: Anton Smirnov >Sent: Friday, December 14, 2012 6:42 PM > > 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
