Subject: Re: [Softwires] Genart last call review ofdraft-ietf-softwire-mesh-multicast-22

From: "杨术" <[email-masked]>
Date: Sun, 16 Sep 2018 02:41:01 +0800

Dear Brian,

Thank you very much for your comments, the following is the response, 

> “One of the authors (Shu Yang) stated that the Bitway company (a networking
 
> device company in China) have implemented a prototype."

> Note that the -00 draft was published in 2011. Not exactly fast progress
 
> in the market.

We have made more progress in these years, Bitway has already implemented
 
it and deployed it in about 100 universities in CERNET2.

> ”7.3.  Fragmentation

>> The encapsulation performed by an upstream AFBR will increase the
 
>> size of packets.  As a result, the outgoing I-IP link MTU may not
 
>> accommodate the larger packet size.  As it is not always possible for
 
>> core operators to increase the MTU of every link.  Fragmentation
 
>> after encapsulation and reassembling of encapsulated packets MUST be
 
>> supported by AFBRs [RFC5565]."

> This is troublesome. Firstly, a nit: the 3rd sentence is not a sentence.
 
> But more seriously, if I-IP is IPv6, how does the originator of the IPv6
 
> packet (the AFBR) know that it needs to include a fragment header?
 
> Is there some kind of hidden PMTUD process, or is this configured?
 
> (I assume we are not so interested in the case that I-IP is IPv4, but
 
> then the issue is that the AFBR MUST NOT set the DF bit.)

> The reference [RFC5565] doesn't help at all, because it just says the
 
> MTU SHOULD be big enough to avoid fragmentation.

Thanks for your helpful comments, we add draft-ietf-intarea-tunnel as a reference
 
for fragmentation.

>> “9.  Softwire Mesh Multicast Encapsulation

>> Softwire mesh multicast encapsulation does not require the use of any
 
>> one particular encapsulation mechanism.  Rather, it MUST accommodate
 
>> a variety of different encapsulation mechanisms, and allow the use of
 
>> encapsulation mechanisms mentioned in [RFC4925].  Additionally, all
 
>> of the AFBRs attached to the I-IP network MUST implement the same
 
>> encapsulation mechanism."

> It isn't clear how this is achieved. Presumably it needs to be configured
 
> in each AFBR? An operator needs to manage this somehow or other.

Again, we add a pointer to draft-ietf-intarea-tunnel, which discuss about
 
tunnel, fragmentation, ttl in more details. 

> “(S,G) state" is a term of art that is not defined here, or in the
 
> reference [RFC7899]. I think there should be a reference to [RFC7761]
 
> where "(S,G) state" is first used; or define it in the Terminology
 
> section.

We add a reference to [RFC7761] each time when (S,G), (*, G), (S,G,rpt)
 
is first used.

We have uploaded a new version: https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-23

Best Regards,

Shu Yang

------------------

杨术

欧德蒙科技有限公司

This message may contain privileged and confidential information only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately. 

------------------ Original ------------------
From:  "Brian Carpenter"<[email-masked]>;
Date:  Mon, Aug 27, 2018 07:35 AM
To:  "gen-art"<[email-masked]>; 
Cc:  "softwires"<[email-masked]>; "draft-ietf-softwire-mesh-multicast.all"<[email-masked]>; 
Subject:  [Softwires] Genart last call review ofdraft-ietf-softwire-mesh-multicast-22

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-softwire-mesh-multicast-22

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-softwire-mesh-multicast-22.txt
Reviewer: Brian Carpenter
Review Date: 2018-08-27
IETF LC End Date: 2018-09-06
IESG Telechat date: 

Summary: Ready with issues
--------

Comments: 
---------

"One of the authors (Shu Yang) stated that the Bitway company (a networking
device company in China) have implemented a prototype."

Note that the -00 draft was published in 2011. Not exactly fast progress
in the market.

Issues:
-------

"7.3.  Fragmentation

   The encapsulation performed by an upstream AFBR will increase the
   size of packets.  As a result, the outgoing I-IP link MTU may not
   accommodate the larger packet size.  As it is not always possible for
   core operators to increase the MTU of every link.  Fragmentation
   after encapsulation and reassembling of encapsulated packets MUST be
   supported by AFBRs [RFC5565]."

This is troublesome. Firstly, a nit: the 3rd sentence is not a sentence.
But more seriously, if I-IP is IPv6, how does the originator of the IPv6
packet (the AFBR) know that it needs to include a fragment header?
Is there some kind of hidden PMTUD process, or is this configured?
(I assume we are not so interested in the case that I-IP is IPv4, but
then the issue is that the AFBR MUST NOT set the DF bit.)

The reference [RFC5565] doesn't help at all, because it just says the
MTU SHOULD be big enough to avoid fragmentation.

"9.  Softwire Mesh Multicast Encapsulation

   Softwire mesh multicast encapsulation does not require the use of any
   one particular encapsulation mechanism.  Rather, it MUST accommodate
   a variety of different encapsulation mechanisms, and allow the use of
   encapsulation mechanisms mentioned in [RFC4925].  Additionally, all
   of the AFBRs attached to the I-IP network MUST implement the same
   encapsulation mechanism."

It isn't clear how this is achieved. Presumably it needs to be configured
in each AFBR? An operator needs to manage this somehow or other.

Nits:
-----

"(S,G) state" is a term of art that is not defined here, or in the
reference [RFC7899]. I think there should be a reference to [RFC7761]
where "(S,G) state" is first used; or define it in the Terminology
section.

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Sep 2018 10:32:15 +1200

Dear 杨术,

I have added Joe Touch in Cc because one point below overlaps
with his TSVART review.
> it and deployed it in about 100 universities in CERNET2.

That's good to know. (I like the concept of an Implementation Status
section as described in RFC7942, and I wish that all WGs would use this.)

Now back to the fragmentation issue. Thank you for the new text:

7.3.  Fragmentation

   The encapsulation performed by an upstream AFBR will increase the
   size of packets.  As a result, the outgoing I-IP link MTU may not
   accommodate the larger packet size.  It is not always possible for
   core operators to increase the MTU of every link, thus fragmentation
   after encapsulation and reassembling of encapsulated packets MUST be
   supported by AFBRs [RFC5565].  The specific requirements for
   fragmentation and tunnel configuration COULD be referred to in
   [I-D.ietf-intarea-tunnels], which is under revision currently.

>> then the issue is that the AFBR MUST NOT set the DF bit.)

draft-ietf-intarea-tunnels does cover the setting of DF, but it still
doesn't state how the tunnel end point knows when to include an IPv6
fragment header, unless I missed something. I'm not sure whether this
needs discussion in the present draft or in Joe's draft, which is why
I added the Cc.

Also I feel that the reference to draft-ietf-intarea-tunnels
should be normative, because I think an implementor needs to get
this right.

...
 
> tunnel, fragmentation, ttl in more details.

True, but it does not answer my question. In the specific case
of softwire-mesh-multicast, how is that "MUST" achieved?
Perhaps all you need to say is:

  Additionally, all
  of the AFBRs attached to the I-IP network MUST be configured
  to use the same encapsulation mechanism.  
> We add a reference to [RFC7761] each time when (S,G), (*, G), (S,G,rpt) 

Thanks!

    Brian

---

From: Joe Touch <[email-masked]>
Date: Sun, 16 Sep 2018 10:15:34 -0700

Hi, Brian,

See comments below…

Joe

> On Sep 15, 2018, at 3:32 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Dear 杨术,
> 
> fragment header, unless I missed something.

If IPv6 fragmentation is needed, then the frag header is included. Otherwise, it is not. As per the standard. There’s no “DF” in IPv6 because on-path fragmentation isn’t possible.

> I'm not sure whether this

Draft-ietf-intarea-tunnels is currently slated for BCP, not standards-track. I don’t recall if that matters for standards-track docs or whether it’s considered a down-ref.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Sep 2018 08:44:02 +1200

Hi Joe,
On 2018-09-17 05:15, Joe Touch wrote:
> If IPv6 fragmentation is needed, then the frag header is included. Otherwise, it is not. As per the standard. 

Yes, but my question is: How does the AFBR (the IPv6 source node) *know*
that fragmentation is needed? This question doesn't arise for IPv4;
if you don't set DF, you don't need to worry about PMTU size.

> There’s no “DF” in IPv6 because on-path fragmentation isn’t possible.

Exactly, so the absence of a fragment header forbids it. So should
the AFBR include a frag header just in case? Should this be
configurable? Should it use some form of PMTUD? Or do we require
the actual PMTU to be big enough?

I see this as a gap in the specification.

Question to the authors: what does the Bitway implementation do?
Does it include a fragment header, or is the MTU simply configured
to be big enough?

   Brian

---

From: Joe Touch <[email-masked]>
Date: Sun, 16 Sep 2018 15:28:52 -0700

Hi, Brian,

> On Sep 16, 2018, at 1:44 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Joe,
> that fragmentation is needed?

Path MTU discovery for the tunnel - at worst, based on the tunnel interface MTU. This is discussed in Section 4.2.3 of the draft-ietf-intarea-tunnels.

> This question doesn't arise for IPv4;

For IPv4 as an outer header, yes - but see RFC 6864. Clearing DF means the tunnel ingress MUST generate new packets at a rate where it can ensure the IP IDs don’t cycle where fragments overlap (which is also already discussed in the section indicated above.

> Exactly, so the absence of a fragment header forbids it.

No, IPv6 forbids on-path fragmentation of an existing header only. The IPv6 tunnel encapsulation header isn’t on-path per se; it’s completely valid to encapsulate a received IPv6 packet inside an IPv6 tunnel that fragments *at the outer layer* (i.e., reassembling at the tunnel egress). 

> So should
> the AFBR include a frag header just in case?

That won’t help. The frag header would be generated at the tunnel ingress and has to be unique there (which has no relation to a frag header of the inner packet, if one is present).

> Should this be

See the section above; you either need to discover it dynamically or deploy the system so it’s not an issue.

> I see this as a gap in the specification.

I don’t think it’s unique to this particular tunnel approach, though.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Sep 2018 10:59:31 +1200

> That won’t help. The frag header would be generated at the tunnel ingress and has to be unique there (which has no relation to a frag header of the inner packet, if one is present).

Yes to the above, but as I understand the draft, the AFBR *is* the tunnel ingress, otherwise I wouldn't have an issue.
 
> I don’t think it’s unique to this particular tunnel approach, though.

No, it isn't, but as far as I can see, any tunnel spec needs to state how this applies. If the tunnel keeps no packet state, how is it going to perform PMTUD? If the answer is that the tunnel end points need to be configured in some way, that needs to be stated too.

Sorry to go on, but when I review a draft, I like to feel that if I had to, I could code it, and in this case I just don't know how I would code the AFBR with respect to PMTUD and/or including a fragment header.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Sun, 16 Sep 2018 17:19:24 -0700

Hi, Brian,

> Yes to the above, but as I understand the draft, the AFBR *is* the tunnel ingress, otherwise I wouldn't have an issue.

There's no "just in case" for the IPv6 header. This tunnel ingress needs
to do what all tunnel ingresses need to do - send the packet, which
means source fragmentation if needed, which means including the frag
header in IPv6 if source fragmented only.

> No, it isn't, but as far as I can see, any tunnel spec needs to state how this applies. If the tunnel keeps no packet state, how is it going to perform PMTUD? If the answer is that the tunnel end p…
Perhaps... (see below).

> Sorry to go on, but when I review a draft, I like to feel that if I had to, I could code it, and in this case I just don't know how I would code the AFBR with respect to PMTUD and/or including a fr…

The tunnel ingress in this case is emitting packets toward a destination
- that's a typical host function. There is no more - or less -
requirement here for the source to figure out the correct MTU and use
source fragmentation appropriately than for any other source.

Joe

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Sep 2018 09:01:09 +0200

> Sorry to go on, but when I review a draft, I like to feel that if I had to, I could code it, and in this case I just don't know how I would code the AFBR with respect to PMTUD and/or including a fr…

Typically tunnels are either configured with a fixed MTU, or do path MTU discovery like any other host on the Internet.
E.g. for a point to point tunnel it can dynamically set the MTU on a tunnel interface based on received PMTUD messages (or PLMTUD probing).
For point to multi-point tunnels it maintains a PMTUD cache.
There’s no magic for tunnels here, just like Joe says.

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Sep 2018 08:25:44 +1200

> There’s no magic for tunnels here, just like Joe says.

No, of course not. But the implementor has to do something, and I don't see
how this can be an interoperable specification without some guidance
for the AFBR implementor.

Since there is implementation experience, it shouldn't be hard to provide
such guidance.

    Brian