Certainly, LISP just tries to comply with what exists. I can understand this, and yes, I would even have blamed LISP if it requested to look into the inner (IP-) header and to decrement there the TTL-counter.
The TTL-poorness is an rtgwg-issue and hereby an intra-domain issue. Correct me, if I am wrong saying that the TTL-counter is re-initialized when SP-borders are traversed :-( Its poorness stems from the belief that endless loops can occur. With TARA however you can validate/use ALL adjacent links (for forwarding) i.e. incl.the incoming link ( crank back link). Detouring routes are either imposed with restricting rules, or, some links may be recognized as entrance to some dead-end area. In this case, as well as if the imposed restriction cannot be complied with, the packet is discarded. Heiner -----Ursprüngliche Mitteilung----- Von: Dino Farinacci <[email protected]> An: heinerhummel <[email protected]> Cc: marc <[email protected]>; lisp <[email protected]> Verschickt: Fr, 12 Jul 2013 6:29 pm Betreff: Re: [lisp] No LISP meeting for Berlin > It was in vain, instead the TTL-mechanism, which is embarrassingly poor, is still in place (and is adopted by LISP - of course), Let me make a technical point. Let's say we have MAC addresses as EIDs. Let's say we have MAC addresses that are also RLOCs. If an ITR receives a MAC frame from a host and encapsulates to an RLOC, do you realize in this scenario LISP is in use but there is no TTL decrement anywhere? Why is that? Because 802 frame does not have a TTL. If the EID space is using a protocol that has rules to be obeyed, LISP will obey those rules. Hence, an IPv4 packet with a TTL is being decremented because that is what IP routers do. After they do that and LISP kicks in, LISP defines how encapsulation should be performed. So it is not true in either case above that LISP has adopted a TTL-mechanism. Dino
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
