Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06

[Mirja Kühlewind <[e-mail]>]

Hi Bob,

thanks for your review. Please see comments inline.

(Please also note my new email address...)



> ----------  Forwarded Message  ----------
>
> Subject: Review: draft-ietf-conex-destopt-06
> Date: Tuesday 12 August 2014, 01:26:01
> From: Bob Briscoe <[e-mail]>
> To: Suresh KRISHNAN <[e-mail]>, Mirja KUEHLEWIND
> <[e-mail]>, Carlos Ucendo <[e-mail]>
> CC: ConEx IETF list <[e-mail]>
>
> Suresh, Mirja, Carlos,
>
> As promised at the authors mtg in Toronto, I have reviewed
> draft-ietf-conex-destopt-06.
>
> At this late stage, I prefer to suggest text, not just criticise. But
> pls don't take this to mean I expect you to use my suggested text.
>
> I had a lot of nits, so I thought it easiest to deal with these by
> annotating the draft (using MS Word, but also supplied as PDF output):
> <http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.doc>
> <http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.pdf>
>
> I have also included all my more substantial concerns in the above
> annotations - highlighted in yellow.
>
> I've listed the major items here, as hooks if mailing list discussion
> is needed on any of them (but see the annotations for detail before
> discussing).
>
> My most controversial disagreement is around IPsec compatibility,
> which we ought to spin into a separate thread if you want to discuss/argue.
>
> Most of the other additions are because conex-abstract-mech says a
> concrete protocol spec has to address specific aspects, which weren't
> addressed.
>
> ==Intro==
> * Added scoping in Intro (solely wire protocol; specific transport
> protocol specs will determine when specifically to set each marking,
> e.g. conex-tcp-modifications)

k. I added something to the previous paragraph because this was already 
intended to say that this document is mainly for people that implement a 
network node and want to do something with ConEx.

>
> * Standards Track -> Experimental
Yes, thanks.

> * Added subsection of intro on experiment goals: criteria for success
> and duration

I believe most of the text actually should go in the tcp mods draft. I 
not sure if there is a common sense in the mean time to have such a 
section in very exp document. But if not I would rather not have it in 
this document because I'm not sure how to define if an experiment was 
successful. If fact the CDO is the only approach at could fulfill our 
requirements, so there is no other  option. And if the coding itself 
with the four bits is useful or not, is not really a question of this 
document, but amybe more of the whole mechanism (incl. auditing and 
policing) or maybe the tcp mods document...?

>
> ==Requirements==
>
> * Referred to abstract-mech for requirements, explained that it would
> be hard to satisfy them all, and explained which one wasn't satisfied
> (visibility in outer), referring to section on fast-path performance.

Took over some of your text at the beginning of this section (and also 
reused some text we already used to have there).

Do you really think that the two requirements you've added are needed? 
Because both basically say that the ConEx coding should encode the Conex 
signal, which is, from my point of view, the whole purpose of this 
document. I do have the feeling that the other requirements listed here 
are on a slightly different level because they are more related to 
deployment issues.

And regarding tunneling: you are right that we need to give more advise 
on tunneling. Shouldn't we just say that one MUST copy the inner ConEx 
Option to the outer header (to solve the visibility problem)?


>
> ==CDO==

The current version says 'immediate nodes SHOULD only read the CDO 
field' which you changed to 'MUST forward unaltered'. This 'SHOULD' was 
actually a SHOULD because you (!) came up with the idea that a policer 
should be able to remove ConEx markings instead of dropping immediately.
I don't think and never thought that this is a good idea because it 
changes the ConEx information for other nodes later on the path. If you 
think that is definitely not needed anymore, I'm happy to have a MUST there.

>
> * For any text about ignoring invalid fields, explicitly said that
> intermediate nodes MUST NOT normalise. Also, specified to treat
> packets with invalid fields like a non-ConEx-capable packet.

ACK, will add your text here.

>
> * Specified precisely which IP header is included in the byte count.
So you suggest to not include any options? Why? I'd say you either 
include all bits because all of them contribute to congestion, or none 
of the IP header bits because that's just the overhead you can't avoid 
if you what to send anything. Also of course you can generate a larger 
percentage of overhead if you send smaller packets.

>
> * Suggested deleting example of Not-ConEx-capable packets (see
> separate thread to conex-tcp-modifications authors about TCP pure ACKs).
I can remove the example but not sure why you are suggesting this. If 
you actually imply that the X bit should never be zero that we have to 
discuss if the X bit is needed at all.


>
> ==Fast-path==
>
> * CDO as first destination option: changed from MUST to SHOULD (with
> an example of when not to).
I believe this really needs to be a MUST. I know that might restrict the 
use of ConEx with potential other options that might have the same 
requirement (for different reasons). But if you don't put a MUST here, 
you cannot implemented the suggested way in the fast path.


>
> ==Config & Management==
>
> * Added section, mainly to say there is no config & mgmt (required by
> abstract-mech).
I don't thing that the statement about being able to switch ConEx on and 
off belongs in this document (but in tcp mods).
I can add one sentence on warnings or error messages if really needed, 
but I don't think that needs an own section.

>
> ==IPsec compatibility==
>
> * Suggested ConEx counts the AH header, and the outer tunnel mode
> header, with reasoning.
Yes, need to be more precise. Will add.

>
> * Suggested the section is restructured because I believe the
> visibility problem is not related to tunnel mode, but only to ESP in
> tunnel mode.
I agree that tunneling was not addressed well.

>
> * Added a para about the possibility of implementing a ConEx proxy
> (without breaking e2e authentication).
ACK will add.

>
> ==Tunnelling==
>
> * Section added, to generalise from just IPsec to any IP-in-IP
> tunnelling (particularly relevant to mobile scenarios).
If we have a separate section on tunneling. Shouldn't we have tunning 
first and then IPSec...?

>
> * Suggested optional copying of CDO to outer, but also a simpler 'Do
> not copy CDO' alternative.
I don't really get you SHOULD NOT but MAY here...?

>
> ==Security Considerations==
>
> * Added lots, all pointers to where security issues are discussed in
> other places (which is what security directorate reviewers need).
Okay I can add that if you think it's necessary (I would say it's just 
redundant, but you be might right that it just helps the sec dir).


>
> ==IANA==
>
> * I think the act bits need to be 00 not 10 to avoid ConEx packets
> being dropped by non-ConEx nodes (including by non-ConEx receivers)?
> But I'm willing to be corrected.
I agree; Will ask Suresh why he has put a 10 though.

Thanks,
Mirja

>
>
> Regards
>
>
>
>
> Bob
>
>
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>
>
> -------------------------------------------------------
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: [phone]
email: [e-mail]
------------------------------------------