Subject: [ANCP] Result field use and ANCP messaging principles

From: "Maglione Roberta" <[email-masked]>
Date: Mon, 4 Aug 2008 18:06:52 +0200

Hello,
    as part of GSMP legacy, ANCP has inherited some base protocol header fields that may deserve some additional clarifications in ANCP protocol spec; an example of such a field is the Result.
RFC 3292 in section 3.1.1 defines 6 values for Result field:
NoSuccessAck:       Result = 1
AckAll:             Result = 2
Success:            Result = 3
Failure:            Result = 4
More:               Result = 5
ReturnReceipt       Result = 6

"NoSuccessAck" and  "AckAll" used in Request message;
"Success," "More," and "Failure" used in Response message;
and ReturnReceipt used in Events

As current ANCP spec, in some cases, already deviates from original GMSP design, it could be worth to rationalize the use of Result field in case of ANCP. In particular I'd like to identify/clarify which are the most useful codes for this field.

Following the proposal presented by the design team for Multicast extension the most useful codes for Result would seem to be Nack (NoSuccessAck) 0x1 and AckAll 0x2, for request and Success 0x3 Failure 0x4 for response. Considering that WG selected to carry ANCP over a reliable transport protocol NAck appears to be the most suitable candidate for default Result code.

Now according to both current ANCP protocol spec and a couple of implementations I've seen the Result field is:
- set to 0 in the GSMP Event message with PORT UP message type in case of Topology Discovery  use case  (section 5.4.2)
- set to "AckAll"  in GSMP "Port Management" message, in case of OAM use case (section 5.4.4)
 - ???  in case of Line Configuration protocol draft does not specify the code for Result. Does anybody know the Result code for this scenario?

The use of Result field 0 looks quite strange to me as this code does not belong to the range of values defined for Result field in RFC3292 thus I have a couple of questions:
- does your ANCP implementation pay attention to the Result code for Topology   Discovery and OAM use-cases?
- What does "0" mean in Port-UP?  A Nack behavior perhaps?
- what does an "AckAll" in an OAM scenario mean?

The reason why I'm asking these questions is because the value of Result field has impacts on the messaging interaction mode in terms of request/response (Nack versus AckAll.) Regarding messaging principles RFC 3292 allowed for two modes of messaging interaction:
1. A request message type and a response message type
2. A request message type with a response sent in the same message type but a different result and code fields setting.

Based on the OAM use case, and on the proposed multicast extensions and having in mind also protocol flexibility for future extensions it would seem reasonable to use the 1st alternative as it is much more easier to understand and simpler to be generalized.
Going on this direction I'd like to hear working group opinion/feedback on the following proposals:

1 - Add a clarification in ANCP protocol draft that explains the use of Result codes for ANCP (deviations from GSMP), in particular if nobody has a use-case that requires AckAll I would propose to remove the Ackall behavior for Result field from the Request message and to use Nack for all use-cases.

2 - Adopt mode of interaction 1 (A request message type and a response message type) as the only mode for messaging interaction in ANCP and discard mode 2;

Thanks and best regards,
Roberta

---------------------------------------------
Roberta Maglione  - CCIE #18425
---------------------------------------------

--------------------------------------------------------------------

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

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Tue, 5 Aug 2008 10:59:19 +0200

Hi,

Would it not be possible to have a mix of both modes: for some messages
the response has the same message type and for others the response is a
different message type?  the meaning of ackall in oam looks quite clear
to me as it is explained in the ancp spec.  The value NoSuccessAck is
not good for OAM because a response is always expected.

Note following assignments by IANA

Result Value  Result Type Name                        Reference
------------  --------------------------------------  ---------
0             Reserved
1             NoSuccessAck                            [RFC3292]
2             AckAll                                  [RFC3292]
3             Success                                 [RFC3292]
4             Failure                                 [RFC3292]
5             More                                    [RFC3292]
6             ReturnReceipt                           [RFC3292]
7-255         Unassigned
value 0 is reserved but is nowhere explained.  I was looking to RFC3292
and see that value 6 is used in case an event message expects a response
but the rfc does not mention what value has to be used in case the event
message does not expect a response.  The value 0 looks a reasonable
choice to me. it means that the field is not used.  Actually, RFC3292
seems to suggest that for port up messages no response is sent unless
the result field is set to 6 in the port up.  This means that when no
response is expected like in ancp, any value is allowed besides from 6
so value 0 is good as well.  ANCP spec is further restricting that it
has to be zero.

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maglione Roberta
Sent: maandag 4 augustus 2008 18:07
To: [email-masked]
Subject: [ANCP] Result field use and ANCP messaging principles

Hello,
    as part of GSMP legacy, ANCP has inherited some base protocol header
fields that may deserve some additional clarifications in ANCP protocol
spec; an example of such a field is the Result.
RFC 3292 in section 3.1.1 defines 6 values for Result field:
NoSuccessAck:       Result = 1
AckAll:             Result = 2
Success:            Result = 3
Failure:            Result = 4
More:               Result = 5
ReturnReceipt       Result = 6

"NoSuccessAck" and  "AckAll" used in Request message; "Success," "More,"
and "Failure" used in Response message; and ReturnReceipt used in Events

As current ANCP spec, in some cases, already deviates from original GMSP
design, it could be worth to rationalize the use of Result field in case
of ANCP. In particular I'd like to identify/clarify which are the most
useful codes for this field.

Following the proposal presented by the design team for Multicast
extension the most useful codes for Result would seem to be Nack
(NoSuccessAck) 0x1 and AckAll 0x2, for request and Success 0x3 Failure
0x4 for response. Considering that WG selected to carry ANCP over a
reliable transport protocol NAck appears to be the most suitable
candidate for default Result code.

Now according to both current ANCP protocol spec and a couple of
implementations I've seen the Result field is:
- set to 0 in the GSMP Event message with PORT UP message type in case
of Topology Discovery  use case  (section 5.4.2)
- set to "AckAll"  in GSMP "Port Management" message, in case of OAM use
case (section 5.4.4)
 - ???  in case of Line Configuration protocol draft does not specify
the code for Result. Does anybody know the Result code for this
scenario?

The use of Result field 0 looks quite strange to me as this code does
not belong to the range of values defined for Result field in RFC3292
thus I have a couple of questions:
- does your ANCP implementation pay attention to the Result code for
Topology   Discovery and OAM use-cases?
- What does "0" mean in Port-UP?  A Nack behavior perhaps?
- what does an "AckAll" in an OAM scenario mean?

The reason why I'm asking these questions is because the value of Result
field has impacts on the messaging interaction mode in terms of
request/response (Nack versus AckAll.) Regarding messaging principles
RFC 3292 allowed for two modes of messaging interaction:
1. A request message type and a response message type 2. A request
message type with a response sent in the same message type but a
different result and code fields setting.

Based on the OAM use case, and on the proposed multicast extensions and
having in mind also protocol flexibility for future extensions it would
seem reasonable to use the 1st alternative as it is much more easier to
understand and simpler to be generalized.
Going on this direction I'd like to hear working group opinion/feedback
on the following proposals:

1 - Add a clarification in ANCP protocol draft that explains the use of
Result codes for ANCP (deviations from GSMP), in particular if nobody
has a use-case that requires AckAll I would propose to remove the Ackall
behavior for Result field from the Request message and to use Nack for
all use-cases.

2 - Adopt mode of interaction 1 (A request message type and a response
message type) as the only mode for messaging interaction in ANCP and
discard mode 2;

Thanks and 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

---

From: "Maglione Roberta" <[email-masked]>
Date: Tue, 5 Aug 2008 13:44:25 +0200

Hello,

> different message type?

I don't say it is not possible to have a mix of both modes for different use-cases, but also thinking about future message designer it would seem cleaner to have one single approach for message principles for all use cases rather having to deal with different methods for different scenarios. In addition there could be cases where the same response message could be re-used across different scenarios.

> the meaning of ackall in oam looks quite clear

Agree with you that in case of OAM a response is always expected but is there a different way to convey that in case of OAM response is required? For example can OAM request message request/application be made to mean "always reply"?

> the result field is set to 6 in the port up.

Agree with you that we can guess from RFC3292 that in case of Port-UP no response is sent unless result is set to 6, but as you mentioned RFC 3292 says that ReturnReceipt can be used in Events to indicate that an acknowledgement is required for the message.   It is not clear to me if RetunrnReceipt means a behavior like AckAll or Nack

The reason why I'm asking is because today we have Port-Up with Result set to zero and implementations interpret this "0" as  "no response" this behavior does not allow to identify error conditions. Let's consider for example a scenario where NAS receives from the AN a Port-UP message where a mandatory TLV is somehow missing or wrong; the ANCP protocol spec says that the NAS is supposed to discard this message ("if a TLV is not understood by the NAS, it is silently ignored".)
In this case the NAS just discards the message but the AN does not have any way to know the something wrong happened.
Now back to the original question today we have 0 meaning no response, if we use result equal to 6 what do we get ackall or Nack? Don't you think it could be useful to have a sort of "Nack" behavior both for Port-UP and Port-Management (for line configuration) in order to be able to catch error conditions?
In addition in case of the error condition the same response message could be re-used for different scenarios if we choose the philosophy "A request message type and a response message type".

Thanks,
Regards,
Roberta

> This means that when no

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Tue, 5 Aug 2008 15:11:29 +0200

Hi Roberta,

It makes no sense to define a response for port-up because it is not
clear to me what the AN should do with that information.  And if their
would be a good case where it is useful, I would prefer to use the same
message type for the response.    The meaning of returnreceipt looks
like an ackall, but if you want a behavior that is like Nack then it is
still possible to define new values for the Result field.

What is the impact of this proposal exactly on the existing port-up and
OAM messages?  Is the proposal to use other message types for OAM
messages?

regards,
Stefaan

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: dinsdag 5 augustus 2008 13:44
To: DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hello,

> Would it not be possible to have a mix of both modes: for some 
> messages the response has the same message type and for others the 
> response is a different message type?

I don't say it is not possible to have a mix of both modes for different
use-cases, but also thinking about future message designer it would seem
cleaner to have one single approach for message principles for all use
cases rather having to deal with different methods for different
scenarios. In addition there could be cases where the same response
message could be re-used across different scenarios.

> the meaning of ackall in oam looks quite clear to me as it is 
> explained in the ancp spec.  The value NoSuccessAck is not good for 
> OAM because a response is always expected.

Agree with you that in case of OAM a response is always expected but is
there a different way to convey that in case of OAM response is
required? For example can OAM request message request/application be
made to mean "always reply"?

> value 0 is reserved but is nowhere explained.  I was looking to 
> RFC3292 and see that value 6 is used in case an event message expects 
> a response but the rfc does not mention what value has to be used in 
> case the event message does not expect a response.  The value 0 looks 
> a reasonable choice to me. it means that the field is not used.
> Actually, RFC3292

Agree with you that we can guess from RFC3292 that in case of Port-UP no
response is sent unless result is set to 6, but as you mentioned RFC
3292 says that ReturnReceipt can be used in Events to indicate that an
acknowledgement is required for the message.   It is not clear to me if
RetunrnReceipt means a behavior like AckAll or Nack

The reason why I'm asking is because today we have Port-Up with Result
set to zero and implementations interpret this "0" as  "no response"
this behavior does not allow to identify error conditions. Let's
consider for example a scenario where NAS receives from the AN a Port-UP
message where a mandatory TLV is somehow missing or wrong; the ANCP
protocol spec says that the NAS is supposed to discard this message ("if
a TLV is not understood by the NAS, it is silently ignored".) In this
case the NAS just discards the message but the AN does not have any way
to know the something wrong happened.
Now back to the original question today we have 0 meaning no response,
if we use result equal to 6 what do we get ackall or Nack? Don't you
think it could be useful to have a sort of "Nack" behavior both for
Port-UP and Port-Management (for line configuration) in order to be able
to catch error conditions?
In addition in case of the error condition the same response message
could be re-used for different scenarios if we choose the philosophy "A
request message type and a response message type".

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Haag, T" <[email-masked]>
Date: Tue, 5 Aug 2008 15:56:10 +0200

Roberta, Stefaan,

please consider that in case of designing response messages a BRAS will get a heavy burden of performance because in case of loosing adjacency to all AN of one domain (eg. due to aggregation failure/interupt)the BRAS has to respond all port status messages of all AN and all ports which can be easily 100000 and more. So the benefit is not clear to me for use case topology discovery.

Mechanisms for connectivity control:  
If we run adjacency we have keep alive between AN and BRAS. If we run TCP/IP we have flow control. I don't see an added value for using response messages because in case of failure the mechanism inside AN and / or BRAS failed.

Considering the OAM use case error conditions for OAM use case are defined too.

I would highly recommend also considering and keep existing implementations also with respect to backward compatibility of existing solutions.

Regards
 
Thomas
 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Maglione Roberta" <[email-masked]>
Date: Tue, 5 Aug 2008 16:27:14 +0200

Hi Stefaan,
 thanks for your comments please see inline.

Regards,
Roberta
________________________________________
From: DE CNODDER Stefaan [[email-masked]]
Sent: Tuesday, August 05, 2008 3:11 PM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi Roberta,

It makes no sense to define a response for port-up because it is not
clear to me what the AN should do with that information.  And if their
would be a good case where it is useful,

[RM] Don't you think it would be useful for troubleshooting purposes to be able to detect an error condition like for example malformed TLV in Port-UP?

 I would prefer to use the same message type for the response.
[RM] if we would like to detect an error condition for topology discovery you are suggesting the same message type for the response thus a port up with code error
For line configuration: NAS uses Port management to configure some parameters on the AN and something goes wrong also in this case do you think is better to  use the same message type for the response?

The meaning of returnreceipt looks like an ackall,

[RM] Ackall does not seem useful with TCP and it does not scale

but if you want a behavior that is like Nack then it is
still possible to define new values for the Result field.

[RM] Why do we need to re-define the Nack behavior if there is already a Result code for Nack?
ReturnReceipt is already a duplicate of Ackall, do you find useful having two different codes with same meaning but to be used for different message types?

[RM] I am just trying to understand if it is possible to use a single mode of interaction ("A
request message type and a response message type") adding additional functionalities (like detecting error conditions) but without or minimizing impacts on current implementations in order to maintain backward compatibility with current implementations.

Regards,
Roberta

regards,
Stefaan

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: dinsdag 5 augustus 2008 13:44
To: DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Maglione Roberta" <[email-masked]>
Date: Tue, 5 Aug 2008 17:03:17 +0200

Hi Thomas,
   please see inline.
Thanks,
Regards,
Roberta
________________________________________
From: Haag, T [[email-masked]]
Sent: Tuesday, August 05, 2008 3:56 PM
To: Maglione Roberta; [email-masked]; [email-masked]
Subject: AW: [ANCP] Result field use and ANCP messaging principles

Roberta, Stefaan,

please consider that in case of designing response messages a BRAS will get a heavy burden of performance because in case of loosing adjacency to all AN of one domain (eg. due to aggregation failure/interupt)the BRAS has to respond all port status messages of all AN and all ports which can be easily 100000 and more.

[RM] Agree with you on this point that's why I'm saying that AckAll for Result does not scale, we should have a Nack behavior.

So the benefit is not clear to me for use case topology discovery.

[RM] I have seen the following scenarios:
1. AN and NAS implementing two different flavors of ANCP: AN was sending Port-UP with one label format, while NAS was expecting a label with another format.
2. Other case: problems caused by deprecated TLVs same behavior
AN was sending PORT-UP with TLV 0x04 sub-TLV 0x91 while NAS was expecting PORT-UP TLV 0x04 sub-TLV 0x90
in both cases NAS just silently discarded the packet.
I'm just asking if there is interest in trying to improve the protocol to address these kind of corner cases or if you think it is not useful or it's too complex

[RM] Agree.

Regards,
Roberta

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Tue, 5 Aug 2008 17:16:28 +0200

Roberta,

What if the response is malformed?  Introducing a new message to detect whether something wrong is another message is not going to help if it is just for troubleshooting.  We should not introduce new messages just to detect bugs because they might only introduce bugs.  Secondly, it is still not clear to me what the AN should do with the response.  You can see on the NAS that it received a malformed packet.  Actually, in the NAS MIB there is an object showing the number of malformed packets that a NAS has received from a particular access node (ancpNasCurrentSessionStatDiscardedMessages).  If you see this value incrementing, you know that the AN is misbehaving and you can enable whatever tracing tools that are available on the NAS to further pin down what is exactly going wrong.

If there is an existing value defined for the Result field that suites your needs, then use that value.  If there is no such value, then define a new value.

regards,
Stefaan

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: dinsdag 5 augustus 2008 17:03
To: Haag, T; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi Thomas,
   please see inline.
Thanks,
Regards,
Roberta

Roberta, Stefaan,

[RM] I have seen the following scenarios:
1. AN and NAS implementing two different flavors of ANCP: AN was sending Port-UP with one label format, while NAS was expecting a label with another format.
2. Other case: problems caused by deprecated TLVs same behavior AN was sending PORT-UP with TLV 0x04 sub-TLV 0x91 while NAS was expecting PORT-UP TLV 0x04 sub-TLV 0x90 in both cases NAS just silently discarded the packet.
I'm just asking if there is interest in trying to improve the protocol to address these kind of corner cases or if you think it is not useful or it's too complex

[RM] Agree.

Regards,
Roberta

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

The reason why I'm asking is because today we have Port-Up with Result set to zero and implementations interpret this "0" as  "no response" this behavior does not allow to identify error conditions. Let's consider for example a scenario where NAS receives from the AN a Port-UP message where a mandatory TLV is somehow missing or wrong; the ANCP protocol spec says that the NAS is supposed to discard this message ("if a TLV is not understood by the NAS, it is silently ignored".) In this case the NAS just discards the message but the AN does not have any way to know the something wrong happened.
Now back to the original question today we have 0 meaning no response, if we use result equal to 6 what do we get ackall or Nack? Don't you think it could be useful to have a sort of "Nack" behavior both for Port-UP and Port-Management (for line configuration) in order to be able to catch error conditions?
In addition in case of the error condition the same response message could be re-used for different scenarios if we choose the philosophy "A request message type and a response message type".

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

Would it not be possible to have a mix of both modes: for some messages the response has the same message type and for others the response is a different message type?  the meaning of ackall in oam looks quite clear to me as it is explained in the ancp spec.  The value NoSuccessAck is not good for OAM because a response is always expected.

Result Value  Result Type Name                        Reference
------------  --------------------------------------  ---------
0             Reserved
1             NoSuccessAck                            [RFC3292]
2             AckAll                                  [RFC3292]
3             Success                                 [RFC3292]
4             Failure                                 [RFC3292]
5             More                                    [RFC3292]
6             ReturnReceipt                           [RFC3292]
7-255         Unassigned
value 0 is reserved but is nowhere explained.  I was looking to RFC3292 and see that value 6 is used in case an event message expects a response but the rfc does not mention what value has to be used in case the event message does not expect a response.  The value 0 looks a reasonable choice to me. it means that the field is not used.  Actually, RFC3292 seems to suggest that for port up messages no response is sent unless the result field is set to 6 in the port up.  This means that when no response is expected like in ancp, any value is allowed besides from 6 so value 0 is good as well.  ANCP spec is further restricting that it has to be zero.

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maglione Roberta
Sent: maandag 4 augustus 2008 18:07
To: [email-masked]
Subject: [ANCP] Result field use and ANCP messaging principles

Hello,

Following the proposal presented by the design team for Multicast extension the most useful codes for Result would seem to be Nack
(NoSuccessAck) 0x1 and AckAll 0x2, for request and Success 0x3 Failure
0x4 for response. Considering that WG selected to carry ANCP over a reliable transport protocol NAck appears to be the most suitable candidate for default Result code.

The reason why I'm asking these questions is because the value of Result field has impacts on the messaging interaction mode in terms of request/response (Nack versus AckAll.) Regarding messaging principles RFC 3292 allowed for two modes of messaging interaction:
1. A request message type and a response message type 2. A request message type with a response sent in the same message type but a different result and code fields setting.

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 5 Aug 2008 11:30:15 -0400

Stefaan
  For certain error conditions it is useful for the side that detects it to let the other end know of the exact error and automatically bring down the adjacency. It is not necessary that the same operator/organization is managing both NAS and AN. Adding hooks to the protocol for suitable error notifications and a well defined behavior when encountering errors seems useful.

-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DE CNODDER Stefaan
Sent: Tuesday, August 05, 2008 11:16 AM
To: Maglione Roberta; [email-masked]
Subject: Re: [ANCP] Result field use and ANCP messaging principles

Roberta,

regards,
Stefaan

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: dinsdag 5 augustus 2008 17:03
To: Haag, T; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi Thomas,
   please see inline.
Thanks,
Regards,
Roberta

Roberta, Stefaan,

[RM] Agree.

Regards,
Roberta

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maglione Roberta
Sent: maandag 4 augustus 2008 18:07
To: [email-masked]
Subject: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 5 Aug 2008 11:24:29 -0400

Thomas
  Any change to existing spec will be with the constraint that we remain backwards compatible. I don't believe the proposal is an "AckAll" for PORT-UP messages that convey DSL line attributes, which as you rightly said will impose additional messaging and processing load on both BRAS and AN, and is not needed. Also, transaction-id is always set to 0 in PORT-UP message, which means the sender doesn't have an easy way to relate the response to the request. 

However, it is useful to handle general "fatal" errors such as missing mandatory TLVs and sub-TLVs. We can handle these via a "generic" TBD ERROR message which results in tearing the adjacency down. 

In general, defining "AckAll" (always send a response), "NAck" (generate a response only in case of an error condition), and "No Response required" (which could be 0) as valid response types for ANCP messages is useful. These values seem sufficient for current known use-cases.
OAM requests and "admission control" requests must always expect a response back (could be implicit, but explicitly requiring AckAll to be set in the request doesn't cause any issue). For messages such as "replication control", "access control" or line configuration in general, having result field optionally set as "AckAll" or "NAck" allows for some flexibility. We can specify the default value for these use-cases.

Thanks
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haag, T
Sent: Tuesday, August 05, 2008 9:56 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] Result field use and ANCP messaging principles

Roberta, Stefaan,

Regards
 
Thomas
 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Tue, 5 Aug 2008 18:39:57 +0200

Such an error message looks more useful to me than defining responses to port up messages.  It can be sent before closing the session as a purely informative message indicating the reason of the session shutdown.  However, it has nothing to do with AckAll or Nack in the Result field.  It can be sent when it is zero as well, and can even be sent without receiving a message before (e.g., when the session goes down because the operator has set it to admin down).  I guess the content of the error message is a purely informative human readable string.

Defining responses to port up messages will only create problems: the NAS tells the access node that a mandatory TLV was missing but the AN will say that this is not true, so where is the problem?  Is there a bug in the AN, or is there a bug in the NAS?  You still dont know.  In addition, this is a very specific case.  So many things can go wrong, and I hope that no error types are defined for each individual case that might go wrong.  A missing mandatory TLV is one out of many problems that might happen.

regards,
Stefaan

-----Original Message-----
From: Sanjay Wadhwa [mailto:[email-masked]] 
Sent: dinsdag 5 augustus 2008 17:24
To: Haag, T; [email-masked]; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Thomas

Thanks
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haag, T
Sent: Tuesday, August 05, 2008 9:56 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] Result field use and ANCP messaging principles

Roberta, Stefaan,

Regards
 
Thomas
 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maglione Roberta
Sent: maandag 4 augustus 2008 18:07
To: [email-masked]
Subject: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Maglione Roberta" <[email-masked]>
Date: Wed, 6 Aug 2008 10:34:19 +0200

Hello,
        I briefly summarize the initial outcomes of the discussion we had on Result field and error conditions:

1. Result field:
NoResp :    No Response required:  Res= 0x0
NAck    :    response  required only in case of an error condition code Res=  0x1
AckAll   :    always send a response      Res=  0x2

Success:    Res=0x3
Failure  :    Res=0x4

These values seem sufficient for current known use-cases, thus I propose to add a clarification in ANCP protocol I-D to explicitly say that  in case of ANCP, Result field can only take one of these codes.

In particular in order to maintain backward compatibility:
- for topology discovery Result field is set 0  No Response required;
- OAM requests and "admission control" requests must always expect a response back:
        * this could be implicit,
        * explicitly requiring AckAll to be set in the request
Any preference on this point?

- for "multicast replication control", "access control" or line configuration in general, result field can be optionally set as "AckAll" or "NAck". We can specify the default value for these use-cases.

2. Generic Error Message

It seems to be interest in defining a new message type to be able to handle error conditions.
Action Item for ANCP design team: specify this new Generic Error Message

According to the feedback currently received this message could be sent independently of the result field value. Other opinions on this point?

3. As far as modes of messaging interaction:
- A request message type and a response message type
- A request message type with a response sent in the same message type but a different result and code fields setting.

We received one preference for a mixed mode: additional feedback/opinion on this point?

Thanks
Best Regards,
Roberta

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of DE CNODDER Stefaan [[email-masked]]
Sent: Tuesday, August 05, 2008 6:39 PM
To: Sanjay Wadhwa; [email-masked]
Subject: Re: [ANCP] Result field use and ANCP messaging principles

regards,
Stefaan

-----Original Message-----
From: Sanjay Wadhwa [mailto:[email-masked]]
Sent: dinsdag 5 augustus 2008 17:24
To: Haag, T; [email-masked]; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Thomas

Thanks
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haag, T
Sent: Tuesday, August 05, 2008 9:56 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] Result field use and ANCP messaging principles

Roberta, Stefaan,

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maglione Roberta
Sent: maandag 4 augustus 2008 18:07
To: [email-masked]
Subject: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Moti Morgenstern <[email-masked]>
Date: Wed, 6 Aug 2008 18:12:48 +0300

Hi Roberta,

We also prefer mode #2, i.e., use the same message type for both the request and the response, with different setting in various fields.

Regards,
Moti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maglione Roberta
Sent: Wednesday, August 06, 2008 11:34 AM
To: DE CNODDER Stefaan; Sanjay Wadhwa; [email-masked]
Subject: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

1. Result field:

Success:    Res=0x3
Failure  :    Res=0x4

2. Generic Error Message

Thanks
Best Regards,
Roberta

regards,
Stefaan

-----Original Message-----
From: Sanjay Wadhwa [mailto:[email-masked]]
Sent: dinsdag 5 augustus 2008 17:24
To: Haag, T; [email-masked]; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Thomas

Thanks
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haag, T
Sent: Tuesday, August 05, 2008 9:56 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] Result field use and ANCP messaging principles

Roberta, Stefaan,

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Dienstag, 5. August 2008 13:44
An: 'DE CNODDER Stefaan'; [email-masked]
Betreff: Re: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks,
Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Tuesday, August 05, 2008 10:59 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Result field use and ANCP messaging principles

Hi,

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maglione Roberta
Sent: maandag 4 augustus 2008 18:07
To: [email-masked]
Subject: [ANCP] Result field use and ANCP messaging principles

Hello,

Thanks and best regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it