Re: 6MAN chair's comments on draft-ietf-conext-destopt

[Suresh Krishnan <[e-mail]>]

Hi Ole,

On 10/14/2015 02:57 PM, [e-mail] wrote:
> Suresh,
>
>>    Thanks a lot for your comments. First of all, I would like to
>> apologize for this oversight. I was certain that I discussed this in
>> 6man in the draft's early days but going back through my mails, I
>> realized it was another associated draft
>> (draft-krishnan-6man-header-reserved-bits-00.txt) that was the other
>> option for conex markings that was discussed.
>>
>> https://www.ietf.org/mail-archive/web/ipv6/current/msg12944.html
>
> Don't apologise, I would expect AD's/IESG to have dealt with this. Certainly not individual authors in this case in a different area.
>
>>>> The Hop by hop option header is required to be the first
>>>> extension header and is an easy check in the forwarding path of
>>>> routers.  This proposal appears to be attempting to create a new
>>>> hop by hop option type, instead of using the existing one based on
>>>> the requirement that this ConEx destination option be the first
>>>> destination option in the Destination header. If the authors want
>>>> hop by hop behavior, they should have defined an hop by hop
>>>> option, not try to create a new type of hop by hop capability.
>>
>> The idea was not to create a hop by hop capability. The mere presence of
>> the hop-by-hop option header hurts packet processing on routers that are
>> not conex-aware. Using a hop-by-hop option was not a viable idea. The
>> idea was to run the experiment on consenting intermediate nodes while
>> not causing issues on unmodified nodes.
>
> I understand that.
> Wouldn't you say that if the experiment turned out to be stunningly successful that you ended up creating what's essentially a new HBH header? And one that was more costly for intermediate nodes than HBH.
> The HBH header does deal with the case of unmodified nodes on the path.
> I do understand your concerns with HBH though, that's an active item under discussion in 6man.

Great.

>
> draft-baker-6man-hbh-header-handling suggests a "rescue" for HBH by making all options in the HBH optional (i.e. intermediate nodes without enabled HBH features don't have to parse them).
> (In practice, that's what I would expect most implementations to do anyway.)

That draft would really help things out. If the experiment is a success, 
then it makes a lot of sense to rewrite with a new hop by hop option if 
the intermediate nodes start to get updated with this new behavior. Even 
then, unupdated intermediate nodes (that either drop packets with the 
HBH header or punt them to the slow path) would still cause issues for 
conex marked packets.

>
> I'm personally quite concerned about opening the door and creating the requirement in an IETF document that routers are required to parse deeper into the packet than the header with the one exception.
> And if the argument is that the HBH is dropped or ignored because of performance reasons, why wouldn't the exact same argument apply to this new usage of the DestOpt header?

The concern is mainly about current intermediate nodes that 
indiscriminately penalize/drop packets just based on the presence of the 
HBH option header. If the nodes stay unupdated, they will not process 
the destopt header and will leave the packets alone. If they do get 
updated with awareness of the new option, it is most likely because they 
would like to support it, right?

>
>>>> While it doesn’t say anything specifically, it appears the intent
>>>> that this header is intended for a specific realm, perhaps a
>>>> ConEx domain.  At a minimum the draft needs to define where it is
>>>> intended to be used, that is in a isolated ConEx domain, the
>>>> whole Internet, or something else.
>>
>> Unfortunately, the goal is for this to be used across the Internet. The
>> usage of the destination option was specifically to avoid processing
>> issues on nodes that are not conex-aware. Since RFC6564 closed off other
>> avenues of extensibility (extension headers and hop-by-hop options) I am
>> not sure if there are any other possibilities.
>
> Do you know the conex-aware nodes a priori? You could of course encapsulate or source route.

No. They aren't. Like you say, encapsulation would have made a lot of 
sense if the list of conex-aware nodes on the path were known up front.

Thanks
Suresh