Re: Multiple adjacency issue in ANCP spec - RFC6320
<HaagT <at> telekom.de>
2012-03-19 11:29:53 GMT
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:
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.
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.
Von: Wojciech Dec [mailto:wdec <at> cisco.com]
Gesendet: Freitag, 9. März 2012 15:01
An: Haag, Thomas; ancp <at> ietf.org
Betreff: Re: AW: AW: Multiple adjacency issue in ANCP spec - RFC6320
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
At the very least the requirements are not being met by the current protocol
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
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.
On 09/03/2012 13:28, "HaagT <at> telekom.de" <HaagT <at> telekom.de> wrote:
> 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
> 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.
> -----Ursprüngliche Nachricht-----
> Von: Wojciech Dec [mailto:wdec <at> cisco.com]
> Gesendet: Freitag, 9. März 2012 10:32
> An: Haag, Thomas; ancp <at> ietf.org
> Betreff: Re: AW: Multiple adjacency issue in ANCP spec - RFC6320
> 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?
> On 09/03/2012 09:55, "HaagT <at> telekom.de" <HaagT <at> telekom.de> wrote:
>> 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 18.104.22.168 is fully in line with requirements in RFC5851 driven
>> by redundancy use case.
>> -----Ursprüngliche Nachricht-----
>> Von: ancp-bounces <at> ietf.org [mailto:ancp-bounces <at> ietf.org] Im Auftrag von
>> Wojciech Dec
>> Gesendet: Donnerstag, 8. März 2012 10:13
>> An: ancp <at> ietf.org
>> Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320
>> Hello All,
>> The following text has been brought to my attention in: ANCP RFC 6320 under
>> section 22.214.171.124:
>> ³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".
>> ANCP mailing list
>> ANCP <at> ietf.org