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

[Steve Donovan <[e-mail]>]

Stephen correctly pointed out that there is missing language in the 
normative portion of the draft.  It is explained in section 5 that and 
agent removes all load reports that it receives in an answer message.  
The normative text for this requirement did not make it into section 
6.2.  As such, I will be submitting a new version of the draft with the 
following added to section 6.2:

"In all cases, a Diameter Agent MUST strip all load reports of type peer
received in answer messages.

     Note: This ensures that there will be precisely one load report of
type peer, that of the Diameter node sending the message, in any answer
messages sent by the Diameter agent. "

Let me know if there are any issues with this wording.

Regards,

Steve

On 1/12/17 9:34 AM, Steve Donovan wrote:
> 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
>>>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime