On Wed, Jul 22, 2009 at 3:33 AM, Roni Even<[email protected]> wrote: >> -----Original Message----- >> From: Bruce Lowekamp [mailto:[email protected]] >> >> In Section 5.2, why not implement IGNORE-STATE-KEEPING as a >> ForwardingOption with FORWARD_CRITICAL? The WG can then discuss >> whether to incorporate that into the base draft or leave it as an >> extension. Parenthetically, the state to be concerned about is not so >> much the hop-by-hop retransmission, but state that may be kept if the >> peer is keeping per-transaction forwarding state rather than encoding >> it in the via-list. > > I think that is what 5.2.1 says we will put the right language. The current > text meant to have it in the forwarding option flags but the note asks if it > should be specified in the forwarding option in the base draft. > Maybe this should be discussed in a separate thread with reload base as the > topic. I think that there are two questions here > 1. Should this flag be part of forwarding option flags in base draft. There > is no registry for the flags > 2. Should this flag be part of forwarding header since it may have other uses.
I agree we need to have the discussion of where this is defined. I personally believe it should be an option rather than part of the header, but that's another issue for the WG to decide. We removed the flags from the header in -03 since we had no use for them. Obviously that's another issue where the WG can decide to add them back, but all of this can be implemented with Forwarding Options rather than flags. > >> >> Also in 5.2, with the changes in the via list structure, I think we >> need to revisit adding an IP address as a DestinationType in an >> extension. I think the ForwardingOption works, but it smells a bit >> too much like a hack to me. > > This may be a good solution for DRR but I am not sure if it will work for the > relay peer case since the relay may be used only in the response. Also the > peer that sends the response will not know who is the relay from the > via/destination list and the relay need to know who is the final receiver. So > there is a need to give the response path which is not defined in base draft. > The use of the ForwardingOption is the way to extend the forwarding header. A requesting peer can preload the via-list with the relay peer and itself to ensure that the desired response path is followed. There does need to be a specification for a Forwarding Option that prevents on-path peers from adding their own entries to the via list. Whether that should be the state keeping or a separate option is an interesting question. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
