> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bruce Lowekamp > Sent: Tuesday, March 24, 2009 6:59 PM > To: Das, Saumitra > Cc: [email protected] > Subject: Re: [P2PSIP] direct routing support > > There was no consensus to include direct response in the base draft. > Here's the text of the hum from the notes you point to: > > -------- > First hum: whether or not we include direct routing as an option in > the protocol (not worrying about what draft): result was consensus > for including it in the protocol. > -------- >
Right, there was consensus to include it in the base protocol. To me, it would make sense to add it to the base draft, since it doesn't seem to make sense to say in the base draft that it is not permitted and yet have the notion of allowing it in the base protocol. > Direct response routing can be implemented as a forwarding option as > described in the base. > > http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4 > I'm assuming that you are talking about a yet-to-be-defined forwarding option? Or, did I miss something that is already specified that can be used for this purpose? I think defining a forwarding option for this does make sense and corresponding to that option, we need to say what the forwarding behavior should be. The node sending the request also needs to provide its direct reachability parameters in the message. While we are on the topic of forwarding options, could anyone describe the purpose of the ones that are already defined in section 5.3.2.4? I don’t quite see an explanation and I am quite perplexed by them :) Thanks, Vidya > So while it's possible to do it in other ways, and to include those > techniques in the base draft, it's not required. > > (obviously it's a question of group consensus on whether it should be > added to the base draft) > > Bruce > > > 2009/3/24 Das, Saumitra <[email protected]>: > > At the previous IETF there was consensus to add direct response > routing as > > an option in the protocol. > > > > > > > > See: http://tools.ietf.org/wg/p2psip/minutes?item=minutes73.html > > > > > > > > This is not yet reflected in the base draft. > > > > > > > > My previous post to this effect with some changes is below > > > > > > > > "I would like to propose we add a flag bit in the forwarding/common > header > > that indicates that a direct routing response to a message be used by > the > > responding node. As a policy, implementations in certain scenarios > would > > enable the flag as necessary. If the flag is set, the requesting node > also > > needs to include its reachable address in the forwarding header. > > > > > > > > We can indicate that the responding node need not keep state to > minimize > > complications. The sending node can simply resend a request (e.g > STORE) with > > the flag turned off if does not receive a response to the initial > STORE > > request with the flag turned on. > > > > > > > > This allows direct routing support in scenarios where the deployer or > the > > implementation knows it is dealing with reachable IP addresses and > can > > configure the implementation to behave accordingly." > > > > > > > > Thanks > > > > Saumitra > > > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
