On 7/8/14, 5:04 PM, 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.
No. the draft is just suggesting that a GPE implementation can take
advantage of how LISP is specified and send a GPE encapsulated packet
(with an IPvX payload) to a LISP receiver. There are no assumption made
on the receiver behavior, excpet than it should be a LISP device.
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?
that information could come from the mapping system.
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.
Fair comment, we'll add text trying to capture this.
I personally think that it would be a reasonable trade off to give those
features up in exchange of adding support for multiprotocol, OAM and
explicit service tagging. If the group wishes to do so, I think that
the flexibility added by GPE would allow to reintroduce some or all of
those features.
Fabio
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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
