ietf
[Top] [All Lists]

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

2017-04-04 07:58:04
On 04/04/2017 18:12, Robert Raszuk wrote:
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.

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.

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.

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

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 ?

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


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

Cheers,
Robert.


On Tue, Apr 4, 2017 at 1:15 AM, Fernando Gont 
<fgont(_at_)si6networks(_dot_)com> wrote:

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: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492