I am refering to the issue that N/E/V must be zero.
This is different from N/E must be zero when V is one for two reasons.
The important reason, and the only reason that the WG needs to address,
is that the existing document explains what features are lost when you
do that.
The other reason is that the N/E/V bits are essentially alternative
mechanisms for addressing related problems. The P bit is for a very
different problem.
I have seen confirmation on the list from the authros taht they are
happy to put in the explicit text. After that, I leave it to the rest
of the WG whether the tradeoff is one they want to make.
Yours,
Joel
On 7/9/14, 2:24 PM, Marc Binderberger wrote:
Hello Joel,
I am also concerned that this is removing several features that the working
group has, up till now, deemed important.
I'm not sure I understand this comment. You mean the collision with
draft-farinacci-lisp-crypto-00 ? (and other drafts which I may have missed)
Or do you mean that N/E/V must be zero when P=1 ? How is this different from
e.g. N/E must be zero when V=1 ?
Regards, Marc
On Tue, 08 Jul 2014 20:04:15 -0400, Joel M. Halpern wrote:
I am very concerned about the compatibility behavior of this.
If the sender is setting the P bit, and the next header, then he presumably
thinks that is useful to the receiver. If the receiver is ignoring the P
bit, and ignoring the field occupied by the next-header, how will the
receiver know what the content is? Are we assuming that the sender will
magically know what packet type the receiver expects, even though the
sender is capable of sending several different packet types?
I am also concerned that this is removing several features that the working
group has, up till now, deemed important. If this gpe is important, then
we will have to ensure that we do not count on any of those features for
reliable operation. If that is our intent, then the document really needs
to say so explicitly so that WG adoption actually represents agreement to
those constraints.
Yours,
Joel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
