On Wed, Jun 20, 2018 at 03:24:16PM -0400, Michael Richardson wrote:
> > Ok. *sigh*. I guess i didn't quite get that. So, if we want to make
> > GRASP in BRSKI work correctly for IPinIP instead of just making it
> > sugestive, there are a bunch of fixes necessary.
>
> I just don't see them.
> I can't see any protocol changes necessary, and I can't understand how
> the GRASP definition can change unless you want to re-open GRASP and create
> an IANA registry on transport-proto.
I did send a detailled suggestion for changes in my original mail about this
issues. It would be easier if yo could reply inline to that email and comment
on the suggstion. I spent a good amount of effort there to explain how the
GRASp announcement needs to carry all the information so that we get the
right auto-discovery needed for IPinIP and proposed how it can easily be
encoded into the GRASP objective value.
None of this requires changing the GRASP RFC. This was all just the
objective-value. Thats the field that GRASP defines to cary the objective
specific information in. Aka: the mayority of any GRASP application
signaling wold be in the GRASP objective. In the GRSP RFC it's
defined to be "any", therefore obviously no update needed.
> > You didn't like the idea of using
> > objective-value strings
> > to identify the proxy method. But the fix i suggested also fixed other
> GRASP
> > details.
>
> As far as I understood, you seem to be asking us to invent a new protocol
> that is not GRASP M_FLOOD, but looks almost, but not quite like it because
> the CDDL syntax differs slightly.
No, in my reply email i brought up multiple issue. The discussion about
expanding GRASP RFC only came up because the GRASP RFC didn't define
the transport field value in the header to be "ANY" or at least a large
enough numerical value, but only allowed an explicit set of numerical
values via their macros, and for IPinIP another value was needed. We
did lay that argument to rest so far by both Brian and you arguing that
the fact that anynumeric value is allowed in that wild should be deduced
fromt the comment.
So forget about GRAp RFC/header changes. This discus is only about the
IMHO necessary information in the objective-vale so GRASP for IPinIP
signals all the necessary information so the proxy can auto-configure itself
for IPinIP and also signl out the right GRASP info to the Pledge.
> > a) Insert after:
> > | A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself.
> > | This announcement can be within the same message as the ACP
> > | announcement detailed in [I-D.ietf-anima-autonomic-control-plane].
>
> > The optional IPinIP proxy as described in Appendix C requires
> > the following extension to the syntax of [GRASP]:
>
> We are removing Appendix C.
> The document will go forward with NAT66 being the only described protocol for
> the Join Proxy.
I think we should then be fine with BRSKI, but the discuss for how to
signal in GRASP for IPinIP would would come up when you do post a new
draft for IPinIP, which i hope does happen, because as i told you ,
i think those IPinIP proxies could actually be quite useful even beyond
bootstrap given how they are not state-limited as the NAT66 proxies.
Let me check if there was anything left with this decision to remove,
else i'll declare my comments done, and then i could put into IESG
shepherd writeup that we just need to get another rev with IPinIP and
related GRASP stuff removed (for followup work).o
Ok ?
Cheers
Toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
