Bruce, I followed this thread and generally I like this option. It would be explicitly useful to identify client and peer operations. I'm a little confused why we should depend on the Update message to determine whether an attached node is a client or a peer.
Thanks! Haibin >-----Original Message----- >From: [email protected] [mailto:[email protected]] >On Behalf Of Bruce Lowekamp >Sent: Monday, July 13, 2009 5:16 AM >To: Eric Rescorla >Cc: [email protected]; [email protected] >Subject: Re: [P2PSIP] Client operation in RELOAD > >On Sun, Jul 12, 2009 at 5:08 PM, Eric >Rescorla<[email protected]> wrote: >> At Sun, 12 Jul 2009 20:54:14 +0000, >> David A. Bryan wrote: >>> >>> Actually this is more of a general comment that it is big >enough that >>> using it as an excuse to not include something isn't really a valid >>> reason. >> >> So you'll totally support it when I suggest we incorporate a feature >> to carry around BGP route tables? After all, we might need that >> someday and if the protocol is bloated already, no harm no foul, >> right? >> >> >>> My point is more that you saying "you don't like cruft" is >not a very >>> well articulated reason to not include a 16 bit field in an already >>> 141 page document. I think we have included enough that, this looks >>> to me as useful as many other things in the draft, and I personally >>> support it. >> >> Of course, you're just totally mischaracterizing what I said, which >> was: >> >> ? I don't see that this change adds any value. It's just >additional ? >> cruft. >> >> To be clear, my objection isn't just that I don't like cruft, but >> rather that this feature is useless. Actually, now that I >look at it, >> it's worse than useless, it's actively harmful; RELOAD >doesn't include >> clients as a first-class concept for a good reason, it's not >necessary >> and it interferes with the orthogonality of the protocol, which is >> almost never a good architectural decision. >> >> It's particularly bad in this case because we're adding an ad hoc >> indicator that receivers don't process but that categorizes nodes in >> an ill-defined way. In fact, of the five possible settings Bruce >> listed, I don't know what two of them ("peer optimization" >and "client >> optimization") mean, and one distinction (neighbor versus routing >> table) only makes sense with specific overlays, and so properly >> belongs at the Topology Plugin Layer. > >The terms were explained in the email I sent out prior to that one. >Were we to add such a field, I think the exact values that it >should have would be a matter that required some thought. (I >at first considered adding an overlay-specific bit, but since >clients don't need to implement the full overlay algorithm >decided it would be better to focus on more general concepts.) > >Regardless, after further thought I believe that something >more like ForwardingOption with comprehension >required/optional would be far more useful. > >Bruce >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
