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
On 7/8/14, 4:32 PM, Fabio Maino wrote:
On 7/7/14, 5:27 PM, Marc Binderberger wrote:
...
4) section "4.1. LISP-gpe Routers to (legacy) LISP Routers" you say
When the P bit is set, the N, E, and V bits MUST be set to zero. The
receiving (legacy) LISP router will ignore N, E and V bits, when the
P bit is set.
I would think a receiving legacy LISP router has no idea about the P bit,
which is why you explicitly set N/E/V to zero?
Right. Per LISP specification P bit is ignored, and given that NEV are
set to zero, the next protocol field is ignored too. We'll rephrase the
sentence to make it more clear.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
