Subject: [ANCP] Multiple NAS controlling one AN partition?

From: Tom Taylor <[email-masked]>
Date: Tue, 5 Apr 2011 12:41:49 -0400

I am in the process of copying over the RFC 3292 adjacency procedures so 
as to make the ANCP base protocol document independent of RFC 3292. 
Section 11.5 of RFC 3292 (translated to ANCP context) gives procedures 
for allowing multiple NAS to control one AN partition. Does ANCP need 
this capability?

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Wed, 6 Apr 2011 09:10:02 -0400

Just to make the implications of this capability clear: it could be used 
for load balancing or hot standby. How the NASs coordinate is out of 
scope of RFC 3292. But if we include it, we also have to include the 
Adjacency Update message in our specification. That message is an Event 
message rather than an adjacency message, so it has the usual header 
including Result and Code. If no one speaks up, I will use our new bit 
allocation for those two fields (4 bits for Result, 12 Code instead of 
the 8 bits each in RFC 3292).

On 05/04/2011 12:41 PM, Tom Taylor wrote:
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp
>
>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 6 Apr 2011 11:53:02 -0400

I hate to be a pest on this, but if no one has implemented the Adjacency 
Update message in ANCP yet, it would be nice to be able to truncate it, 
dropping the last 4+ words since they are unused. Here is the message 
format shown in RFC 3292:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Version    | Message Type  |    Result     |     Code      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  |            Transaction Identifier             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|      SubMessage Number      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Port                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Port Session Number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Event Sequence Number                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |x|S|x|x|                                                       |
    +-+-+-+-+                     Label                             |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Nothing of this after Length is actually used by the Adjacency Update 
message. Of course, if implementations are written to expect the full 
Event message format for Event messages, we are stuck with the excess 
baggage, but until I hear otherwise, I am going to assume that the ANCP 
Adjacency Update message has the format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Version    | Message Type  |Result |          Code         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  |            Transaction Identifier             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|      SubMessage Number      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That is, it consists of the ANCP general message header alone.

Tom Taylor

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 12 Apr 2011 21:20:56 +0200

FYI This was the topic of some previous WG discussions:
http://www.ietf.org/mail-archive/web/ancp/current/msg00779.html

-Woj.