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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sun, 02 Jun 2019 03:05:10 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-mpls-sr-over-ip-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you all for the work put into this document

== COMMENTS ==

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

-- 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' ?

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Jun 2019 11:51:46 +0100

Hi Eric,

Thanks for squeezing in the extra review: much appreciated.

> Generic question of mine: is there a way to leverage SRv6 in

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.)

> 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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 2 Jun 2019 15:04:46 +0000

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" <[email-masked]> wrote:

    Hi Eric,

    

    

    

    Thanks,
    Adrian