Re: [mpls] Éric Vyncke's No Objection on draft-ietf-mpls-sr-over-ip-06: (with COMMENT)

["Adrian Farrel" <[e-mail]>]

Hi Eric,

Thanks for squeezing in the extra review: much appreciated.

> == COMMENTS ==
>
> Generic question of mine: is there a way to leverage SRv6 in
> the underlay ?

Depends what you mean by "leverage" :-)

The full-blown leveraging is to use SRv6 and move on. There are many who would say that that should be the principal focus.

Here we are looking at how to move ahead with limited SR capabilities and run over an existing network. That underlay network could certainly be IPv6 (or IPv4 or MPLS), and one of the reasons we use UDP as an encapsulation is because it is agnostic about the underlay technology. (There are, of course, other reasons for choosing UDP.)

> -- Section 3.2.3 --
>
> About the IP encapsulation, is the hop limit / TTL simply copied from the
> 'payload packet header'? What is the procedure at the exit of the tunnel wrt
> hop limit / TTL of the 'payload packet header' ?

There is a bit of chain of dependencies to follow here. We have tried to not change the core MPLS-in-UDP rules set in RFC 7510, so I could just point you there. But you would find that 7510 hands the baton to 4023 (MPLS-in-IP and MPLS-in-GRE), and section 5.2 is the place to look to see how to set the TTL in the encapsulating packet.

At transit points on the tunnel, the TTL is (of course?) handled as normal for the encapsulating layer. 

At the end point of the tunnel there are two tasks:
1. Process the packet according to the encapsulating layer, just as we would for any other packet destined to a local address. No change there.
2. Process the payload packet. Once the encapsulation has been stripped, the TTL of the payload must be processed. Per 4023, the remaining encapsulation TTL may be copied into the payload if (and only if) doing so does not increase the payload TTL value. 

In all these three places on the path, we are not altering 7510 and 4023 behavior.

Thanks,
Adrian