headers
Wojciech Dec | 8 Mar 2012 10:12
Picon
Favicon

Multiple adjacency issue in ANCP spec - RFC6320

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.
Permalink | Reply |
headers
HaagT | 9 Mar 2012 09:55
Picon

Re: Multiple adjacency issue in ANCP spec - RFC6320

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: 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 3.5.2.1:

 ³Once an adjacency has been established, if more than one NAS has
(Continue reading)

Permalink | Reply |
headers
Wojciech Dec | 9 Mar 2012 10:31
Picon
Favicon

Re: 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?

Regards,
Woj.

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.
>
(Continue reading)

Permalink | Reply |
headers
Tom Taylor | 9 Mar 2012 13:20
Picon

Re: Multiple adjacency issue in ANCP spec - RFC6320

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:
> 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, "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
(Continue reading)

Permalink | Reply |
headers
Wojciech Dec | 9 Mar 2012 13:58
Picon
Favicon

Re: Multiple adjacency issue in ANCP spec - RFC6320

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" <tom.taylor.stds <at> gmail.com> wrote:

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:
> 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, "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 3.5.2.1 is fully in line with requirements in RFC5851 driven
>> by redundancy use case.
>>
>> Regards
>> Thomas
>>
>> -----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 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.
>>
>> _______________________________________________
>> ANCP mailing list
>> ANCP <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ancp
>
> _______________________________________________
> ANCP mailing list
> ANCP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ancp
>
_______________________________________________
ANCP mailing list
ANCP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ancp

<div>
<span>Right, but given that single controllers need to be aware of whether they can act/change state, &nbsp;such a &ldquo;redundant controller&rdquo; 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 &ldquo;send/don&rsquo;t send all data for the same partition to both controllers&rdquo;.<br>
In short, if you allow for redundant controllers in a standard protocol, it&rsquo;s of little use to then say &ldquo;redundant controllers are left up for specific implementation&rdquo; &ndash; 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.<br><br>
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 &ldquo;sorry, you&rsquo;re not the active controller&rdquo;. 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. &nbsp;<br><br>
&nbsp;-Woj.<br><br>
On 09/03/2012 13:20, "Tom Taylor" &lt;<a href="tom.taylor.stds <at> gmail.com">tom.taylor.stds <at> gmail.com</a>&gt; wrote:<br><br></span><blockquote><span>I would think the distinction would be by configuration, and maybe that<br>
is underspecified..<br><br>
When we did Megaco we had the concept of a primary controller of a<br>
partition and (potentially) multiple secondary controllers. We left it<br>
up to implementors to work out the details. Inter-controller<br>
communication was not in scope of our work.<br><br>
On 09/03/2012 4:31 AM, Wojciech Dec wrote:<br>
&gt; Hi Thomas,<br>
&gt;<br>
&gt; Ok, but how would that work? Would the ANCP Partition-id be seen as the same<br>
&gt; to both NASes, and how would one NAS know that it is "the backup" (thus not<br>
&gt; allowed to say send commands)? There is nothing in the rest of the spec that<br>
&gt; I can see which addresses this, so while redundancy may have been the<br>
&gt; intent, it does not appear to be specified to the extent of making it work<br>
&gt; across the suite of ANCP applications. Or am I missing something?<br>
&gt;<br>
&gt; Regards,<br>
&gt; Woj.<br>
&gt;<br>
&gt;<br>
&gt; On 09/03/2012 09:55, "<a href="HaagT <at> telekom.de%22&lt;HaagT">HaagT <at> telekom.de"&lt;HaagT</a> <at> telekom.de&gt; &nbsp;wrote:<br>
&gt;<br>
&gt;&gt; Woj, all,<br>
&gt;&gt; it seems to me if we have here a different interpretation rather than a need<br>
&gt;&gt; for an errata of RFC6320.<br>
&gt;&gt;<br>
&gt;&gt; IMHO the listed result of a working group discussion belonged to physical or<br>
&gt;&gt; logical partitioning. But it was not decided to exclude functionality<br>
&gt;&gt; regarding R-37 to R-41 of RFC5158 from protocol work.<br>
&gt;&gt;<br>
&gt;&gt; Please see RFC5158: R-41: &nbsp;The Access Node should be able to establish and<br>
&gt;&gt; maintain ANCP<br>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Adjacencies to redundant controllers.<br>
&gt;&gt;<br>
&gt;&gt; A redundancy use case considers typically a single edge architecture but<br>
&gt;&gt; single edge means "one service edge" which may consist of two physical boxes<br>
&gt;&gt; which may be redundant.<br>
&gt;&gt;<br>
&gt;&gt; So in my opinion an errata is not necessary because there is no conflict<br>
&gt;&gt; between Framework and protocol specification.<br>
&gt;&gt; RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 driven<br>
&gt;&gt; by redundancy use case.<br>
&gt;&gt;<br>
&gt;&gt; Regards<br>
&gt;&gt; Thomas<br>
&gt;&gt;<br>
&gt;&gt; -----Urspr&uuml;ngliche Nachricht-----<br>
&gt;&gt; Von: <a href="ancp-bounces <at> ietf.org">ancp-bounces <at> ietf.org</a> [<a href="mailto:ancp-bounces <at> ietf.org">mailto:ancp-bounces <at> ietf.org</a>] Im Auftrag von<br>
&gt;&gt; Wojciech Dec<br>
&gt;&gt; Gesendet: Donnerstag, 8. M&auml;rz 2012 10:13<br>
&gt;&gt; An: <a href="ancp <at> ietf.org">ancp <at> ietf.org</a><br>
&gt;&gt; Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320<br>
&gt;&gt;<br>
&gt;&gt; Hello All,<br>
&gt;&gt;<br>
&gt;&gt; The following text has been brought to my attention in: ANCP RFC 6320 under<br>
&gt;&gt; section 3.5.2.1:<br>
&gt;&gt;<br>
&gt;&gt; &nbsp;&nbsp;&ldquo;Once an adjacency has been established, if more than one NAS has<br>
&gt;&gt; established an adjacency to the same partition, then the AN sends an<br>
&gt;&gt; Adjacency Update message to each such NAS to &nbsp;&nbsp;&nbsp;let it know how many<br>
&gt;&gt; established adjacencies the partition currently supports."<br>
&gt;&gt;<br>
&gt;&gt; This text appears to indicate that ANCP supports a single Access Node<br>
&gt;&gt; partition that is controlled/has an adjacency with more than one<br>
&gt;&gt; NAS/controller, which would not be in line with WG conclusions on this topic<br>
&gt;&gt; (eg <a href="http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html">http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html</a>),<br>
&gt;&gt; besides covering technical matters such as likely race conditions, etc.<br>
&gt;&gt;<br>
&gt;&gt; Seems like a case to jot down for fixing in an RFC "errata".<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt; Woj.<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; ANCP mailing list<br>
&gt;&gt; <a href="ANCP <at> ietf.org">ANCP <at> ietf.org</a><br>
&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/ancp">https://www.ietf.org/mailman/listinfo/ancp</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; ANCP mailing list<br>
&gt; <a href="ANCP <at> ietf.org">ANCP <at> ietf.org</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/ancp">https://www.ietf.org/mailman/listinfo/ancp</a><br>
&gt;<br>
_______________________________________________<br>
ANCP mailing list<br><a href="ANCP <at> ietf.org">ANCP <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ancp">https://www.ietf.org/mailman/listinfo/ancp</a><br><br></span></blockquote>
</div>
Permalink | Reply |
headers
Tom Taylor | 9 Mar 2012 14:21
Picon

Re: Multiple adjacency issue in ANCP spec - RFC6320

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”.
> 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.
>
...
Permalink | Reply |
headers
HaagT | 9 Mar 2012 13:28
Picon

Re: Multiple adjacency issue in ANCP spec - RFC6320

 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: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?

Regards,
Woj.

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 3.5.2.1 is fully in line with requirements in RFC5851 driven
> by redundancy use case.
>
> Regards
> Thomas
>
> -----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 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.
>
> _______________________________________________
> ANCP mailing list
> ANCP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ancp
Permalink | Reply |
headers
Wojciech Dec | 9 Mar 2012 15:01
Picon
Favicon

Re: Multiple adjacency issue in ANCP spec - RFC6320

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, "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
> 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: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?
> 
> Regards,
> Woj.
> 
> 
> 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 3.5.2.1 is fully in line with requirements in RFC5851 driven
>> by redundancy use case.
>> 
>> Regards
>> Thomas
>> 
>> -----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 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.
>> 
>> _______________________________________________
>> ANCP mailing list
>> ANCP <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ancp
>
Permalink | Reply |
headers
HaagT | 19 Mar 2012 12:29
Picon

Re: Multiple adjacency issue in ANCP spec - RFC6320

 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: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

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, "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
> 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: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?
>
> Regards,
> Woj.
>
>
> 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 3.5.2.1 is fully in line with requirements in RFC5851 driven
>> by redundancy use case.
>>
>> Regards
>> Thomas
>>
>> -----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 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.
>>
>> _______________________________________________
>> ANCP mailing list
>> ANCP <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ancp
>
Permalink | Reply |

Gmane