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

["Eric Vyncke (evyncke)" <[e-mail]>]

Adrian

Thank you for such a quick reply on a Sunday.

About SRv6, while I understand and agree with your reply, I wonder whether this point should be added in the document. Just to avoid other people (not aware of all MPLS WG history) wondering like I did ;-)

About hop-limit, basically the same comment: I am with you but why not referencing the behavior you described? (alas I am in a plane and I do not have a copy of your I-D when replying... so it may already be the case)

Regards

-éric

On 02/06/2019, 12:55, "Adrian Farrel" <[e-mail]> wrote:

    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