Subject: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320

From: Wojciech Dec <[email-masked]>
Date: Thu, 08 Mar 2012 10:12:55 +0100

Hello All,

The following text has been brought to my attention in: ANCP RFC 6320 under
section 3.5.2.1:
 
 ³Once an adjacency has been established, if more than one NAS has
established an adjacency to the same partition, then the AN sends an
Adjacency Update message to each such NAS to    let it know how many
established adjacencies the partition currently supports."

This text appears to indicate that ANCP supports a single Access Node
partition that is controlled/has an adjacency with more than one
NAS/controller, which would not be in line with WG conclusions on this topic
(eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html),
besides covering technical matters such as likely race conditions, etc.

Seems like a case to jot down for fixing in an RFC "errata".

Regards,
Woj.

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 09:55:33 +0100

Woj, all,
it seems to me if we have here a different interpretation rather than a need for an errata of RFC6320.

IMHO the listed result of a working group discussion belonged to physical or logical partitioning. But it was not decided to exclude functionality regarding R-37 to R-41 of RFC5158 from protocol work.

Please see RFC5158: R-41:  The Access Node should be able to establish and maintain ANCP
                           Adjacencies to redundant controllers.

A redundancy use case considers typically a single edge architecture but single edge means "one service edge" which may consist of two physical boxes which may be redundant.

So in my opinion an errata is not necessary because there is no conflict between Framework and protocol specification.
RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 driven by redundancy use case.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Wojciech Dec
Gesendet: Donnerstag, 8. März 2012 10:13
An: [email-masked]
Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320

Hello All,

Regards,
Woj.

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

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 09 Mar 2012 10:31:59 +0100

Hi Thomas,

Ok, but how would that work? Would the ANCP Partition-id be seen as the same
to both NASes, and how would one NAS know that it is "the backup" (thus not
allowed to say send commands)? There is nothing in the rest of the spec that
I can see which addresses this, so while redundancy may have been the
intent, it does not appear to be specified to the extent of making it work
across the suite of ANCP applications. Or am I missing something?

Regards,
Woj.

On 09/03/2012 09:55, "[email-masked]" <[email-masked]> wrote:

> IMHO the listed result of a working group discussion belonged to physical or
> logical partitioning. But it was not decided to exclude functionality
> regarding R-37 to R-41 of RFC5158 from protocol work.
> 
> A redundancy use case considers typically a single edge architecture but
> single edge means "one service edge" which may consist of two physical boxes
> which may be redundant.
> 
> So in my opinion an errata is not necessary because there is no conflict
> between Framework and protocol specification.

---

From: Tom Taylor <[email-masked]>
Date: Fri, 09 Mar 2012 07:20:27 -0500

I would think the distinction would be by configuration, and maybe that 
is underspecified..

When we did Megaco we had the concept of a primary controller of a 
partition and (potentially) multiple secondary controllers. We left it 
up to implementors to work out the details. Inter-controller 
communication was not in scope of our work.

On 09/03/2012 4:31 AM, Wojciech Dec wrote:
> On 09/03/2012 09:55, "[email-masked]"<[email-masked]>  wrote:
>
>> Woj, all,

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 13:28:26 +0100

Hi Woj,

Yes, I guess you're missing the context to TR-147.

In RFC6320 is mentioned in section 1:

At various points in this document, information flows between the
   control applications and ANCP are described.  The purpose of such
   descriptions is to clarify the boundary between this specification
   and, for example, [TR-147].  There is no intention to place limits on
   the degree to which the control application and the protocol
   implementation are integrated.

If you look to BBF TR-147 in section 5.7 describes redundancy from use case perspective and section 9.3 R-28 to R-30 provides relevant requirements.

Making redundancy work can be performed in concert with TR-147. Basic protocol features IDs, TLVs can be used.

How network element treat a handower and how to organize interchasis communication is out of scope of ANCP because it is implementation specific.
But ANCP covers AN-BNG (NAS) communication without making an exception or limitation.
I see your proposal in making that limitiation by creating an errata. But I don't think tat this is a good idea by the given arguments.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Wojciech Dec [mailto:[email-masked]]
Gesendet: Freitag, 9. März 2012 10:32
An: Haag, Thomas; [email-masked]
Betreff: Re: AW: Multiple adjacency issue in ANCP spec - RFC6320

Hi Thomas,

Regards,
Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 09 Mar 2012 13:58:49 +0100

Right, but given that single controllers need to be aware of whether they
can act/change state,  such a ³redundant controller² feature would need to
be exposed in the protocol (inter controller still being out of scope). The
notion of active and standby adjacency would appear to be needed, besides
spec info like ³send/don¹t send all data for the same partition to both
controllers².
In short, if you allow for redundant controllers in a standard protocol,
it¹s of little use to then say ³redundant controllers are left up for
specific implementation²  this is a standards doc. If redundant controllers
are a proprietary feature, so be it, but in that case the multiple
adjacencies per partition are proprietary too.

In example terms, we currently appear to have the door open to: controller A
sending mcast command Z, and controller B sending mcast command Y. Each
would expect the command to be acted upon, and even in the error codes that
an AN could send we do not covey info like ³sorry, you¹re not the active
controller². Both controllers are following existing standard functionality.
Please let me know how you would envisage controller and access node
implementations to deal with this case.

 -Woj.

On 09/03/2012 13:20, "Tom Taylor" <[email-masked]> wrote:

>>> >> it seems to me if we have here a different interpretation rather than a
>>> need
>>> >> for an errata of RFC6320.
>>> >>
>>> >> Please see RFC5158: R-41:  The Access Node should be able to establish
>>> and
>>> >> maintain ANCP
>>> >> RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851
>>> driven
>>> >> by redundancy use case.
>>> >>
>>> >> Regards
>>> >> Thomas
>>> >>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 09 Mar 2012 08:21:38 -0500

Megaco partitioned per-termination. Translated into ANCP terms, each 
line belongs to a specific controller. That way there is no conflict. 
The division between primary and secondary comes with respect to 
commands affecting the AN as a whole.

Agreed that the supporting language just isn't there.

On 09/03/2012 7:58 AM, Wojciech Dec wrote:
> Right, but given that single controllers need to be aware of whether
> they can act/change state, such a “redundant controller” feature would
> need to be exposed in the protocol (inter controller still being out of
> scope). The notion of active and standby adjacency would appear to be
> needed, besides spec info like “send/don’t send all data for the same
> partition to both controllers”.
> it’s of little use to then say “redundant controllers are left up for
> specific implementation” – this is a standards doc. If redundant
> controllers are a proprietary feature, so be it, but in that case the
> multiple adjacencies per partition are proprietary too.
>
> In example terms, we currently appear to have the door open to:
> controller A sending mcast command Z, and controller B sending mcast
> command Y. Each would expect the command to be acted upon, and even in
> the error codes that an AN could send we do not covey info like “sorry,
> you’re not the active controller”. Both controllers are following
> existing standard functionality. Please let me know how you would
> envisage controller and access node implementations to deal with this case.
>
> -Woj.
>
...

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 09 Mar 2012 15:01:26 +0100

Hi Thomas,

I don't think I missing the context of requirements. What is missing is how
the requirements are realized in the protocol along with the specified ANCP
applications. 
At the very least the requirements are not being met by the current protocol
specification.

Feel free to illustrate how the following situation should be handled in a
case of controllers A and B both having an adjacency to the same partition
(and port). 
Controller A sends mcast command Z, and controller B sends mcast command Y.
Both controllers are following existing standard functionality. Each
controller would expect the command to be acted upon, and obtain a response.
In the error codes that an AN could send we do not covey info like ³sorry,
you¹re backup controller², nor in the adjacency info, etc. Other similar use
cases, also for port-up and line config apply.

Regards,
-Woj.

On 09/03/2012 13:28, "[email-masked]" <[email-masked]> wrote:

> If you look to BBF TR-147 in section 5.7 describes redundancy from use case
> perspective and section 9.3 R-28 to R-30 provides relevant requirements.
> 
> How network element treat a handower and how to organize interchasis
> communication is out of scope of ANCP because it is implementation specific.
> I see your proposal in making that limitiation by creating an errata. But I
> don't think tat this is a good idea by the given arguments.
> 
> Regards
> Thomas
>

---

From: <[email-masked]>
Date: Mon, 19 Mar 2012 12:29:53 +0100

Hi Woj,

As far as I understood you a protocol may have options to signal peering states and error conditions.
O.k. except OAM we currently don't have that for ANCP.

But how to deal with it? Do we have alternatives to operate ANCP?
I see two options:

Option 1:
I see one option in updating RFC6320 in a way to extend appropriate error codes in order to meet use case requirement rather then reducing use cases.

Option 2:
Another option may be to let the network element control which control entity is active and which standby and decide on a per adjacency / link decision basis. No change in RFC 6320 necessary.

Referring to your example:

Controler A is defined being master; Controler B is configured being stand by controller.
In that case controller A is allowed sending a mcast command to AN only. That prevents the case that two messages are sent from two sources to one sink. If controller A fails controler B take over controller A.

Considering upstream messages e.g. topolocy discovery control B has to ignore them if controler A is active and vice versa.

If controller A and B in a single unit this is a matter of system design.
If they are in different units it is assumed to have a inter chasis communication or controled by platform control. But IMHO this is not a task of ANCP.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Wojciech Dec [mailto:[email-masked]]
Gesendet: Freitag, 9. März 2012 15:01
An: Haag, Thomas; [email-masked]
Betreff: Re: AW: AW: Multiple adjacency issue in ANCP spec - RFC6320

Hi Thomas,

Regards,
-Woj.