Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt

[Rémi Després <[e-mail]>]

Le 2012-04-12 à 18:15, Maoke a écrit :

> 
> hi Remi,
>  
> this acknowledges the part not belonging to technical issues. 
> 2012/4/11 Rémi Després <[e-mail]>
> Maoke,
> 
> Good to see that at least one who has read the 4rd-u draft still considers that technical considerations are worth working on.
>  
>  
> sorry if you mean the "at least one" is me,

> i don't consider the technical considerations are worth working on

Sorry to learn that.

> but i only share understanding for others' judgement on the worthness.
>  
>  
> Thanks.
> 
> IMHO, you did a great job to structure this (useful) discussion.
> Here are quick comments/suggestions/corrections I propose: 
>  
>  
> thanks for comments. basically the commentary is straightforward and any statement with metaphysics should be avoided.

Agreed.

> from Mx to Tx, the author appreciate any comments but the wording will based on what the author understands.

Of course.


> on the other hand, repeating what 4rd-u draft has stated in another draft is trivial.
>  
> in details, the following comments (regarding section 4) will be reviewed but the author won't adopt some of them, especially when it contains metaphysics beyond the context.

Why you consider points below to be metaphysics is obscure to me.
They are believed to be operational and/or technical.

Your listing your own view of 4rd-u motivations, while refusing mine, remains your responsibility.


RD


>  
> thanks and regards,
> maoke
>  
>  
> 
> 
> 4.1. (M2) Rather than "simplification of L4 protocol treatment" the motivation is "Full IPv4 transparency, with never modified payloads and IPv4 fragmentation semantics"
> 
> 4.1. (M4) a motivation to be added:  "No constraint on subnet-ID assignments in customer sites"
> 
> 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as ensured as in MAP-E" instead of "4rd-U argues it should be supported no matter how minor it is observed in practice".
> 
> 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they prefer, concerning DiffServ architecture, provided users cannot make the difference" instead of "4rd-U argues ToS should be kept unchanged when the packet traverses the IPv6 domain, except the ECN bits".
> 
> 4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet validity of IPv4 tunneled packets, for all present and future protocols that have ports as the same place as TCP and the same checksum algorithm, without being concerned with where these protocols have their checksum fields"  instead of "it also argues checksum validity should be ensured through address in order to simplify L4 processing"
> 
> 4.2. (O6)- to be added 
> "UDP null checksums: [RFC6145] can be configured either to drop all IPv4 packets having null checksums, or drop only those that are fragmented. 4rd-u argues that this lack of IPv4 transparency should be avoided."
> 
> 4.2. (O7)- to be added 
> "Free assignment of subnet IDs:  subnet IDs that follow customer-site prefixes in native IPv6 addresses are so far freely chosen for each customer site. 4rd-u argues that this freedom should not be lost, despite the need to distinguish IPv4-originated packets from native IPv6 packets at customer-site entrances. 
> 
> 4.2. after (T6) CNP and V octet, because they are related to (M4), (O6), and (07), should IMHO be considered in scope (if a new version is issued).
>