Re: [Dime] AD evaluation of draft-ietf-dime-load-06

[Steve Donovan <[e-mail]>]

Stephen,

I think that what you are proposing is for the following network:

A' ---- B' ----- C ----- D --|-- E'
                                               ^
                                 Administrative boundary

Where A', B' and E' support load and C and D do not.

I think you are proposing that node D strips a peer load report inserted 
by B'.  Is this correct?

The issue is that this is load-specific functionality, requiring D to 
understand at least some of the Load mechanism.  But, by definition,  D 
does not support or understand anything about the load mechanism.

I don't see a way of achieving what you propose without adding load 
specific functionality to D.

Steve

On 1/12/17 5:54 AM, Stephen Farrell wrote:
> Hiya,
>
> Just one thing below I'd like to figure out before
> IETF LC...
>
> On 09/01/17 22:28, Steve Donovan wrote:
>> Stephen,
>>
>> Thanks for the review and for the ping.  Comments below.
>>
>> Regards,
>>
>> Steve
>>
>> On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>> Just bumping this, post holidays. I believe the
>>> ball is not in my court for this one:-)
>>>
>>> Cheers,
>>> S.
>>>
>>> On 16/12/16 17:38, Stephen Farrell wrote:
>>>> Hiya,
>>>>
>>>> Thanks for getting this stuff progressed. I've done my
>>>> AD evaluation and have a few questions I'd like to ask
>>>> before starting IETF last call. Those are below along
>>>> with some more nitty comments that can be handled now or
>>>> later as the authors/WG prefer.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> Things to chat about before starting IETF LC:
>>>> ---------------------------------------------
>>>>
>>>> (1) Is "server selection" sufficiently clear? Where is
>>>> that defined? I was a bit confused as to what this means
>>>> that is not next-hop selection.
>> SRD> Server selection is touched on in RFC7638 (DOIC) and the concept
>> carries over to Load.  It refers to selection of the specific server
>> instance that will be handling the request.  This is according to the
>> Diameter Client, Server model.  I think it is well understood what is
>> meant by those who understand Diameter and would be implementing this
>> spec.  We can, if needed, add some definition. That would have been best
>> do be in the DOIC RFC but it can go here if needed.
> Ok, let's handle that as an IETF LC comment. If others
> think a definition would be good you can add it later.
> If it's just me, don't bother.
>
>>>> (2) PEER reports that are first received at a
>>>> non-supporting node will be left in place and will reach
>>>> the destination of the message. If that destination is in a
>>>> different domain then that leaks some internal structure
>>>> (the SourceID) to outsiders. Is that desirable?  Why not
>>>> have the first node that does support this AVP delete the
>>>> PEER report even if the node that added the PEER report is
>>>> not a peer of this node? (Note: I see this risk is ack'd
>>>> in section 8, I'm asking if we can avoid it almost
>>>> entirely by removing PEER reports that are useless.)
>> SRD> There is no formal mechanism in place in Diameter to do "topology
>> hiding".  There are many other places where topology information can
>> leak, so it isn't an issue specific to Load.  It is addressed today
>> through proprietary implementations.
> Sure, that's not a good reason to make it harder though.
> But see below...
>
>> SRD> Having a node that does not support would go against the Diameter
>> extensibility strategy.  Nodes that don't understand an AVP are required
>> to pass it on.  Nodes that do support the mechanism and see a Load
>> report of type peer that isn't of type peer are supposed to remove it.
> I don't understand what " a Load report of type peer that
> isn't of type peer" can mean.
>
>> Doing anything other than this would require a change to the base
>> Diameter specification.
> Either I'm mis-remembering the draft or we're talking at
> cross purposes. My reading was that nodes that do support
> the mechanism could delete a peer report that actually
> comes via a node that does not support the mechanism. Am
> I wrong? If so maybe there's a clarity issue. If not, I
> don't see why that makes sense.
>
> Cheers,
> S.
>
> PS: The rest below is fine to handle later as you suggest.
>
>>>> (3) This spec is a bit like RFC7944 (DRMP) in that it
>>>> defines some but not all of the things one needs to end up
>>>> with a workable system. That aspect of DRMP caused some
>>>> discussion during IESG evaluation. Have the authors of
>>>> this reviewed that discussion to see if we can avoid any
>>>> likely iterations being needed at that point? I'm hoping
>>>> that Steve, as an author of both, won't find this too
>>>> hard to do:-) If that's been done, great. If not, please
>>>> consider if there's any additional explanatory material
>>>> that could be added that might help us not to have to
>>>> iterate to discuss the same kinds of concern.
>> SRD> I'll go back and review that discussion and see if there is
>> something that needs to be added.  I'm hoping that the fact that we made
>> it through the discussion with DRMP will make it easier to do so with
>> Load (and maybe agent overload).  I'm doubtful that we can fully
>> inoculate the draft from some of this level of discussion as we are
>> dealing with Diameter here.
>>>> nits (fine to be considered last call comments):
>>>> -------------------------------------------------
>> SRD> I'll deal with these as part of last call.
>>>> abstract: maybe put the 1st sentence last? that might read
>>>> better
>>>>
>>>> 4.1: the "opinion of the authors" isn't really of interest
>>>> at this point - is this also the opinion of the WG? (I
>>>> assume it is)
>>>>
>>>> section 5 says "The load report includes a value
>>>> indicating the load of the sending node relative load of
>>>> the sending node, specified in a manner consistent with
>>>> that defined for DNS SRV [RFC2782]." I can't parse that.
>>>>
>>>> - 6.2: What is a Diameter "connection?" I thought that
>>>> Diameter could use UDP as well as TCP so is that really
>>>> the right term? Maybe "message sender" is a better way to
>>>> identify the peer?
>>>>
>>>> - section 8: "might require a transitive trust model" is
>>>> far too coy IMO. I think you should say that DOIC and this
>>>> entirely require transitive trust because we have no
>>>> Diameter mechanism that allows authenticated adding and
>>>> removal of AVPs as messages transit a network. (We did try
>>>> develop that ages ago but it was too complex, so I'm not
>>>> arguing to try again, just that we clearly ack the fact
>>>> that this stuff requires transitive trust.)
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>>