Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Apr 2017 01:15:00 +0200

On 03/31/2017 04:11 PM, Robert Raszuk wrote:
> I do not understand how 2460bis makes it "easier" if proposed change to
> the text directly tries to prohibit what is described in a document
> already long time back accepted as a 6man working group draft.

This is incorrect. For instance, the condition to accepting such I-D as
a wg items was indeed that EH insertion was removed, and that
encapsulation be used instead.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Apr 2017 08:12:02 +0200

Hi Fernando,

The WG document talks about two cases ...

* EH insertion at the host (src of packet)

* IPv6 new encapsulation + EH insertion on the ingress to SR domain
followed by decapsulation at the egress of SR domain.

I hope we can agree on that.

However is it wise to expect any time within SR domain for a packet (v6
encapsulated on ingress) to get steered differently (say coming out of
service chain) to decapsulate and encapsulate again ? Seems to me like
quite local box decision anyway.

Hence my comment about implicit insertion.

In any case if we see this entire thread the only technical concern with EH
insertion was MTU. And how that issue is solved when you do additional IPv6
header encap ?

Or maybe encap is allowed simply as it can not be forbidden :))

Cheers,
Robert.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Apr 2017 00:57:19 +1200

> I hope we can agree on that.

We can't, because neither of them is "insertion". They are simply packets
created at their source (the encapsulator) that happen to contain SR headers,
or any other kind of IPv6 extension header for that matter.

> quite local box decision anyway.

Yes, they can decapsulate and re-encapsulate as often as they like and 
remain consistent with 2460bis.

> insertion was MTU. And how that issue is solved when you do additional IPv6

PMTUD applies to the path between source A (encapsulator) and destination B
(decapsulator). If you decapsulate at B and the encapsulate again, PMTUD
applies to the path between B (encapsulator) and C (decapsulator). They are
completely independent; it's a new packet. PMTUD doesn't occur between A 
and C at all.

    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Apr 2017 15:22:32 +0200

Hi Brian,

> completely independent; it's a new packet. PMTUD doesn't occur between A

​Are you saying that it is "legal" to fragment IPv6 packet by a router at
the encapsulation point in the network ?

That would be news to me.

Many thx,
Robert.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Apr 2017 01:36:54 +1200

> the encapsulation point in the network ?

I can't see any reason why the encapsulating packet couldn't be fragmented;
it's just a packet (whose payload happens to be another packet). But I would
hope that jumbo frames would make this unnecessary in the scenarios where
SR will be used.

Also, assuming 2460bis is on its way through the IESG and RFC Editor soon,
I can't see any reason why draft-ietf-6man-segment-routing-header-06
couldn't proceed to WG Last Call. I'm not quite sure why we're having this
conversation.

   Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 4 Apr 2017 13:56:37 +0000

Hi Robert,

> On Apr 4, 2017, at 9:22 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Brian,
> 
> ​Are you saying that it is "legal" to fragment IPv6 packet by a router at the encapsulation point in the network ? 

> That would be news to me. 

Yes. It is legal. Please take a look at section 7 of RFC2473.

Regards
Suresh