Subject: Re: [ANCP] Result field

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 7 Nov 2008 17:02:18 +0100

Roberta et al,

ancp-protocol-04 incorporates the Result value "0x00 - Ignore" in  
accordance with the thread below:
"Res = 0x00 - Ignore this field on receipt and follow the
             procedures specified for the received message type.
"

However, section 5.4.5.2 still assumes use of Result=AckAll or Nack  
for the Multicast Replication Control.
Would you agree to using Result=Ignore for Multicast Replication  
Control messages (as is already proposed in ancp-mc-extensions)?

Thanks

Francois

On 24 Oct 2008, at 15:40, Wojciech Dec (wdec) wrote:

>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: 24 October 2008 14:37
>> To: Maglione Roberta
>> Cc: [email-masked]
>> Subject: Re: [ANCP] Result field
>>
>> Roberta and all,
>>
>> On 24 Oct 2008, at 08:12, Maglione Roberta wrote:
>>
>>> Hello,
>>>       I am currently updating the ancp-protocol draft and I would
>>> like to incorporate the topics recently discussed in this alias. In
>>> particular a couple of weeks ago we talked about the use of Result
>>> Field in ANCP messages in order to try to rationalize the codes for
>>> this field, coming from GSMP, and actually useful for ANCP protocol.
>>> http://www.ietf.org/mail-archive/web/ancp/current/msg00661.html
>>>
>>> According to this thread the useful codes for Result field
>> in ANCP use
>>> cases seem to be:
>>> "AckAll": (always send a response) used in OAM use case;
>>> "NAck": (generate a response only in case of an error
>> condition) for
>>> Multicast use case; 0 used in Topology Discover use case.
>>>
>>> The value 0 for Result field is not defined in GSMP RFC, but it is
>>> actually used in one of the ANCP use case. In order to guarantee
>>> backward compatibility with current implementations it's
>> reasonable to
>>> keep the code 0 for Result field, the proposal on previous email
>>> thread was to define in ANCP protocol draft  a semantic for
>> Result =
>>> 0x00.
>>>
>>> The proposed semantic was Result = 0x00 meaning "No Response
>>> required".
>>
>> Can we generalize the semantics of Result = 0x00 to "Ignore
>> this field on receipt and follow the procedures specified for
>> the received message type"?
>
> This is a fine proposal indeed.
>
>>
>> In the case of the Topology Discovery use case, you could
>> specify that the receiver of a Port_UP message is never to
>> respond to that message (assuming this is what you want). In
>> that case, Result = 0x00 would effectively mean "no
>> response", which would match the current implementation
>> behaviors you're targeting.
>
> While there is no "Port-up reply" message defined, an overall gap in
> the protocol and initial implementations is the inability to  
> communicate
> protocol errors. Hence it would not be wise to preculde such an "error
> message" response to a flawed Port-up in the future, and I'd argue  
> that
> the same "Ignore this field on receipt" semantics should apply for the
> PortUP messages too.
>
> Regards,
> Woj.
>
>>
>> In other use cases, Result=0x00 could also be used and the
>> behavior on receipt of another message type would also be
>> defined in the procedures for that message. In some cases,
>> the responder behavior could be a little more subtle (e.g.
>> respond with message X in such situation, respond with
>> message Y in that situation, and don't respond at all in such
>> situations ).
>>
>> Francois
>>
>> PS: one question: I assume the Result = "Failure" value is
>> not affected by this discussion (ie it remains valid e.g. in
>> Multicast Status message). right?
>>
>>
>>>
>>>
>>> Please let me know if this semantic for Result field is ok
>> for you or
>>> you have any additional comment on this proposal.
>>> Thanks
>>> Best Regards,
>>> Roberta
>>>
>>>
>>> CONFIDENTIALITY NOTICE
>>>
>>> This message and its attachments are addressed solely to
>> the persons
>>> above and may contain confidential information. If you have
>> received
>>> the message in error, be informed that any use of the
>> content hereof
>>> is prohibited. Please return it immediately to the sender
>> and delete
>>> the message. Should you have any questions, please contact us by
>>> replying to [email-masked].
>>>
>>>       Thank you
>>>
>>>                                       www.telecomitalia.it
>>> _______________________________________________
>>> ANCP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ancp
>>
>> _______________________________________________
>> ANCP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ancp
>>

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 7 Nov 2008 17:59:28 +0100

Hi Francois,
        Section 5.4.5 incorporates draft-ancp-mc-extensions-00.txt as it was presented in Dublin: in particular section 5.4.2.1 of the protocol draft reflects result field equal to ACKall as per section 4.1 of the draft-ancp-mc-extensions-00.txt draft.
The possibility to set result field to 0 for multicast replication control message is an option that came up later, and that we mentioned in draft draft-lefaucheur-ancp-mc-extensions-00.
This alternative makes sense to me, but in my opinion it should be discussed with the WG before appearing in the protocol draft .

Best Regards,
Roberta

________________________________________
From: Francois Le Faucheur IMAP [[email-masked]]
Sent: Friday, November 07, 2008 5:02 PM
To: Maglione Roberta
Cc: Francois Le Faucheur IMAP; [email-masked]; Wojciech Dec (wdec)
Subject: Re: [ANCP] Result field

Roberta et al,

Thanks

Francois

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it