On Dec 13, 2012, at 12:38 PM, Stewart Bryant wrote: > The draft as it stands is not MPLS specific and thus I am not convinced > we should add the information you propose to this draft, although > perhaps some text could go in a new section. However if we include > this text, we need to consider what we should say about IP tunnels.
rfc5286 is not MPLS specific either, yet the majority (>90%) of my customers see it as lightweight alternative to get local-repair protection for their LDP networks. draft-ietf-rtgwg-remote-lfa-00 is not LDP specific either, however the it will be deployed by a majority of customers who have an LDP/MPLS background as well. > However it might be better if this information were in IGP specific > drafts put through the IGP WGs. Certainly I think that we need to > specify more than this text since there are for example security > and capability considerations. if we go down the road of explicitly advertising the transport loopback then i agree this work should be done in ospf-wg and isis-wg. the question is wether we can go without protocol extension and identify the loopback IP based on existing protocols. > I have some explicit questions inline. > > > On 12/12/2012 14:49, 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 > What does PLR stand for? This is the point of local repair (PLR) - >> (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 >> > The text above does not scan (nor does the text below) > >> 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> > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
