[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt
- To: Multi6 <multi6@ops.ietf.org>
- Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt
- From: Brian E Carpenter <brc@zurich.ibm.com>
- Date: Mon, 26 Jul 2004 09:15:33 +0200
- In-reply-to: <200407091529.LAA05687@ietf.org>
- Organization: IBM
- References: <200407091529.LAA05687@ietf.org>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
(Chair hat off)
I guess I have three high level concerns with NOID.
1. I am uncomfortable about the dependency on reverse DNS. It will effectively
mean that only well-run servers can benefit from mh, because client systems
with temporary addresses (especially RFC 3041 addresses) are realistically
unlikely to have reverse DNS in place. And that probably eliminates mh for
peer-to-peer applications too, which is a shame.
2. I'd have liked to see a walk-through for a 3rd-party referral case (i.e.
how would it work for p2p anyway?).
3. I am also uncomfortable about "the bit." The whole of section 6 is, well,
a bit kludgy. The only clean solution IMHO is a shim header, which knocks
8 bytes off the user's MTU. In the catgeory of possible alternatives, we could
in theory add
- encode a couple of bits in the flow label
- get back the ECN bits
(I'm not advocating either of these, but since the draft lists alternatives...)
Brian