Thomas, there is plenty of discussion on TTL handling for LISP in RFC 6830. And at the same time, you have to decide what traceroute behavior you want. You need to decide if tunnels are 1-hop or n hops. MPLS chose 1-hop tunnels but product configuration knobs could change the behavior. LISP choose n-hops because operators gave us requirements to see the entire path.
You will have to ask this question for QOS/TOS handling as well. David Black contributed text to the LISP working group, so you can see the resulting decisions in RFC 6830. Dino On Nov 26, 2013, at 8:57 AM, Thomas Narten <[email protected]> wrote: > Hi. > > In precisely defining L3 service, one question that comes up is how is > the TTL treated. That is, say NVO3 provides L3 VN service to a > TS. When TSes on the VN communicate with each other, they are always > using IP. What happens to the TTL in such packets? > > I see several choices: > > a) do not decrement the TTL at all. Treat the TSes as if they were directly > attached to each other (i.e., on the same link) > > b) Decrement by 1... > > c) Decrement by some random amount.. :-) > > Some protocols may care about TTL handling. IPv6 Neighbor Discovery, > for example, requires that ND packets be dropped if they are received > with a TTL other than 255 (i.e., they'd require choice a). I think > some other routing protocols do the same (as a way to ignore packets > from offlink "attackers"). > > What do tenants of an L3 service expect? Do they care (other than in > cases like ND)? > > Can we just define L3 service as saying the TTL of tenant packets are > not modified by NVO3? > > Any advice from L3 service providers that already provide such > services today? > > Thomas > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
