> 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 made this comment to the co-authors of the draft. I suggested the best way to handle this is for an ETR to indicate in its RLOC record it registers to the mapping system, what format it can parse. Again, you know where I'm going with this but don't want to say so. LOL. > 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. Agree. Dino > > 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
