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"<brian.e.carpen...@gmail.com>;
Date: Mon, Aug 27, 2018 07:35 AM
To: "gen-art"<gen-art@ietf.org>;
Cc: "softwires"<softwi...@ietf.org>;
"draft-ietf-softwire-mesh-multicast.all"<draft-ietf-softwire-mesh-multicast....@ietf.org>;
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
softwi...@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art