Hi, Bruce: Thanks for your comments. Comments in line.
Regards Jiang XingFeng > > I think it's great to see this written up. While I've argued against > incorporating DRR and RPR into the base spec, I think developing it as > an extension is an excellent idea. A few high-level comments. > > I think the right thing to do is to separate out an p2p-based > implementation of nat-behavior-discovery as a separate usage and put > it in its own draft. I'm more than happy to contribute to such an > effort. The reason Roni and I put the NAT-behavior-discovery in the draft is that I tried to figure out that this kind of discovery is feasible and the results can be helpful to DRR and RPR. We are also planning to ask for the WG whether the topic can be moved out to a separate draft. If WG says yes, we will try to start this work. If possible, you are welcome to work with us together in the future. > > I agree with the decision to use a ForwardingOption for signalling the > desired response address. But a couple details concern me. > - I'm not sure I agree DESTINATION_CRITICAL needs to be set here. It > seems like if the responder doesn't support this routing mode, it will > just return via SRR like normal. > - The only complication I see is that reload's SRR allows intermediate > peers to keep state about transactions rather than store the state in > the Via list (5.1.2.2). Not using SRR would cause such a peer to have > a possible state explosion waiting for transactions to time out. > Options I can think of offhand for solving that are: 1) ignore the > problem, 2) make the ForwardingOption FORWARD_CRITICAL, 3) add a new > flag to the forwarding header that suggests intermediate peers not > keep state. > I think option 3) is a better one. > > > On Sun, Oct 26, 2008 at 8:20 PM, jiangxingfeng 36340 > <[EMAIL PROTECTED]> wrote: > > Hi, folks: > > > > We've just submitted a draft which proposes an extension to RELOAD to > > support > direct response and relay peer routing mode. This topic has been discussed > during Dublin meeting and is based on the draft-jiang-p2psip-sep-01. > > > > Any comments are appreciated. > > > > Regards > > > > Jiang XingFeng > > > > > > ---------- Forwarded message ---------- > > From: IETF I-D Submission Tool <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Date: Sat, 25 Oct 2008 06:52:12 -0700 (PDT) > > Subject: New Version Notification for draft-jiang-p2psip-relay-00 > > > > A new version of I-D, draft-jiang-p2psip-relay-00.txt has been successfuly > submitted by XingFeng Jiang and posted to the IETF repository. > > > > Filename: draft-jiang-p2psip-relay > > Revision: 00 > > Title: An extension to RELOAD to support Direct Response and Relay > Peer routing > > Creation_date: 2008-10-25 > > WG ID: Independent Submission > > Number_of_pages: 19 > > > > Abstract: > > This document proposes an extension to RELOAD to support direct > > response and relay peer routing modes. The document starts with the > > problem statement and address concerns about these two routing modes > > mentioned in RELOAD. Then methods about how to discover NAT behavior > > of the client in P2PSIP situations are discussed. The last part > > proposes extensions to RELOAD for supporting these additional routing > > modes. > > > > > > > > The IETF Secretariat. > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > [EMAIL PROTECTED] > > https://www.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
