Subject: [ANCP] ANCP Multicast Control Message

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 14 Apr 2008 17:00:26 +0200

Hi All,

As discussed during our recent IETF 71 meeting, our protocol design team
has forged ahead with prioritized list of problems to address, the first
of which was defining the ANCP message extensions for multicast control,
aka unsolicited multicast control. The DT is working on the response
message and also the solicited multicast control mode.
Below, we present the outcome of the work, which represents both a
design team consensus as well as a proposal for adoption into the ANCP
protocol spec, draft-ietf-ancp-protocol (some editorial work will be
still required). Please review the proposal and share your comments. We
will assume acceptance of the proposal in principle otherwise.

Regards,
Woj & Matthew.

2	Replication Control Message

This message is sent by the ANCP Server (NAS) to the ANCP Client (AN)
with a directive to either add (join) or delete (leave) a port to or
from a multicast flow. Its format is as follow:
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |Type=Replication-Control (0x01)|             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |        Client-ID Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               |
     ~                      Port Client-ID                           ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Following the Port Client-ID information, one or more Command TLV
components can be included and the Access Node should process them in
the order in which they are listed. The Access Node (ANCP Client) should
threat all the commands as a single command block to be viewed as a
whole and bail out immediately when one of them fails.
The format of command TLV is as follow:

      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  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = CommandCode           |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Addr Family   | Encoding Type |  Multicast Group Address      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Addr Family   | Encoding Type |  Multicast Source Address     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where CommandCode specifies the command and can be one of the following:

0x01  Add	Adds the specified multicast flow to the specified port
(join)
0x02  Delete	Deletes the specified multicast flow (leave) on the
specified port.
0x04  DeleteAll	Deletes All multicast flow on the specified port (leave
all). No addresses are supplied.

When we have more than one command, Deletes should always be listed
first. The unicast source address/mask follows the format defined in RFC
2362 Section 4.1 case 1 which is duplicated here for quick review:

Encoded-Unicast-address: Takes the following 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  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type |     Unicast Address           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Addr Family
           The address family of the `Unicast Address' field  of
           this address.

          Here is the address family numbers assigned by IANA:

 Number    Description
 --------  ---------------------------------------------------------
      0    Reserved
      1    IP (IP version 4)
      2    IP6 (IP version 6)
      3    NSAP
      4    HDLC (8-bit multidrop)
      5    BBN 1822
      6    802 (includes all 802 media plus Ethernet "canonical format")
      7    E.163
      8    E.164 (SMDS, Frame Relay, ATM)
      9    F.69 (Telex)
     10    X.121 (X.25, Frame Relay)
     11    IPX
     12    Appletalk
     13    Decnet IV
     14    Banyan Vines
     15    E.164 with NSAP format subaddress

     Encoding Type
          The type of encoding used within a specific Address
          Family.  The value `0' is reserved for this field,
          and represents the native encoding of the Address
          Family.

     Unicast Address
          The unicast address as represented by the given
          Address Family and Encoding Type.

Finally, although the length could be derived from the Addr Family and
the Encoding type, it is kept for future possible extension to this
command where other entry would be added to this command segment.
The equivalent of a swap command where the NAS would want to switch from
multicast group 239.23.2.2 to 239.55.3.2 will have the following format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Type (0x88-0C)         |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | Vers  |  Sub  |MessageType=90 | Result|        Code           | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | Partition ID  |            Transaction Identifier = 0001      | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |I|      SubMessage Number      |           Length              | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | 0x01 (Replication-Control)    |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | 0x01 (Access-Loop-Circuit-ID) |        Client-ID Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               |
     ~                      Port Client-ID                           ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=CommandCode: Delete(0x02)|           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   |  Mcast group: 239.23.2.2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   |  Mcast Source: 10.1.1.1       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     | Type=CommandCode: Add (0x01)  |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0   |  Mcast group: 239.55.3.2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0   |  Mcast Source: 10.1.1.1       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Each command in the list is attributed an identification number based on
its occurrence in the message. In this case, the Delete command will be
attributed command number 1 while the Add will be attributed command
number 2. During the processing of these  commands, upon the first
failure of a command, the sequence is interrupted and an error message
(via Multicast Status Message) will be returned with the command number
identifying the command that failed. 

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

---

From: <[email-masked]>
Date: Wed, 16 Apr 2008 20:11:24 +0530

Hi Woj,

Currently, the command codes for replication control message are

1. add (0x01)

2. delete (0x02)

3. delete all (0x04).

Looking at the multicast Swap message format, which is used when the NAS wants to switch from one group to another,can we not handle this situation by having a message type Modify (0x08).

By using this message type we can mention the multicast group address which needs to be swapped by new multicast group address.

Since the Command Code is 2 bytes, the second byte can be used to mention the number of multicast groups that needs to be swapped.

This will allow, for multiple multicast group swaps. This will also reduce the size of the packet. Since these messages intended only between the NAS and AN, the introduction of modify command type gives further ease to the Access boxes in implementing the swaps, which attributes to zap latency.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Type (0x88-0C)         |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Vers  |  Sub  |MessageType=90 | Result|        Code           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Partition ID  |            Transaction Identifier = 0001      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |I|      SubMessage Number      |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x01 (Replication-Control)    |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x01 (Access-Loop-Circuit-ID) |        Client-ID Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                      Port Client-ID                           ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type=CommandCode: Modify(0x08)|           Length                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AddrFamily 01 | EncType 0x0    |  Mcast group: 239.23.2.2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0    |  Mcast Source: 10.1.1.1               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
      | AddrFamily 01 | EncType 0x0   |  New Mcast group: 239.55.3.2   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     | AddrFamily 01 | EncType 0x0    |  New Mcast Source: 10.1.1.1      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Looking into the DSL TR 101, it also discusses about the multicast flow being associated with a VLAN (Multicast-Vlan). In this case, the Access Node, needs to be informed about the VLAN ID on which a particular Multicast group is being associated by the NAS. Can this information also be added as part of the TLV in message.

Thanks

Vish

________________________________

From: [email-masked] on behalf of Wojciech Dec (wdec)
Sent: Mon 4/14/2008 11:00 AM
To: [email-masked]
Subject: [ANCP] ANCP Multicast Control Message

Hi All,

Regards,
Woj & Matthew.

      0                   1                   2                   3

  0                   1                   2                   3

     Addr Family

 Number    Description

     Encoding Type

     Unicast Address

---

From: einarnn <[email-masked]>
Date: Sun, 20 Apr 2008 16:12:04 +0100

Vish,

Overloading the second byte of the command code to contain the number of
³modifications² doesn¹t seem a good approach and the space saving per
packet, which will probably be only 4 bytes most of the time, seems almost
irrelevant. I think it would be better to keep the fields in the message for
a single task.

Treating a sequence of commands as an atomic operation, as detailed in the
text, and implementing a swap via a delete follow by an add, should give ANs
the freedom to implement what are, in effect, swap operations quite
efficiently. In this context, I¹m not sure what a ³modify² command code will
really add?

Cheers,

Einar

On 16/04/2008 15:41, "[email-masked]"
<[email-masked]> wrote:

> Looking at the multicast Swap message format, which is used when the NAS wants
> to switch from one group to another,can we not handle this situation by having
> a message type Modify (0x08).
> By using this message type we can mention the multicast group address which
> needs to be swapped by new multicast group address.
> Since the Command Code is 2 bytes, the second byte can be used to mention the
> number of multicast groups that needs to be swapped.
> This will allow, for multiple multicast group swaps. This will also reduce the
> size of the packet. Since these messages intended only between the NAS and AN,
> the introduction of modify command type gives further ease to the Access boxes
> in implementing the swaps, which attributes to zap latency.
>  
> Looking into the DSL TR 101, it also discusses about the multicast flow being
> associated with a VLAN (Multicast-Vlan). In this case, the Access Node, needs
> to be informed about the VLAN ID on which a particular Multicast group is
> being associated by the NAS. Can this information also be added as part of the
> TLV in message.
>  
> Thanks
> Vish
> 
>

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 00:42:05 +0530

Einar,
Modify command would be usefull from Access box perspective, as the underlying implementation in AN's would have the freedom to design their swap operation, instead of always first deleting the existing group entry and adding another entry.
 
Thanks
Vish

From: einarnn [mailto:[email-masked]]
Sent: Sun 4/20/2008 11:12 AM
To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Multicast Control Message

Vish,

Overloading the second byte of the command code to contain the number of "modifications" doesn't seem a good approach and the space saving per packet, which will probably be only 4 bytes most of the time, seems almost irrelevant. I think it would be better to keep the fields in the message for a single task.

Treating a sequence of commands as an atomic operation, as detailed in the text, and implementing a swap via a delete follow by an add, should give ANs the freedom to implement what are, in effect, swap operations quite efficiently. In this context, I'm not sure what a "modify" command code will really add?

Cheers,

Einar

On 16/04/2008 15:41, "[email-masked]" <[email-masked]> wrote:

	Hi Woj,

	
	
	Thanks
	Vish

	
	Hi All,

	Regards,
	Woj & Matthew.

	
	
	      0                   1                   2                   3

	

	  0                   1                   2                   3
	
	     Addr Family

	 Number    Description
	
	     Encoding Type
	
	     Unicast Address

---

From: Einar Nilsen-Nygaard <[email-masked]>
Date: Mon, 21 Apr 2008 21:47:06 +0100

Vish,

I actually think that freedom in how a ³swap² operation would be implemented
in terms of the ordering of stopping the first multicast flow and starting
the second is not desirable. By specifying that the delete must come before
the add and that the operation should be terminated upon the first error,
the current specification gives us what should be deterministic behavior
between any and all conforming implementations.

In contrast, the freedom to implement a swap operation via some form of
modify leaves the door open to multiple ways in which a modify request could
fail, making error recovery more troublesome and vendor-specific which I do
not see as at all desirable.

Cheers,

Einar

On 21/04/2008 20:12, "[email-masked]"
<[email-masked]> scribbled:

> Einar,
> Modify command would be usefull from Access box perspective, as the underlying
> implementation in AN's would have the freedom to design their swap operation,
> instead of always first deleting the existing group entry and adding another
> entry.
>  
> Thanks
> Vish
>  
> 
> 
> ³modifications² doesn¹t seem a good approach and the space saving per packet,
> which will probably be only 4 bytes most of the time, seems almost irrelevant.
> I think it would be better to keep the fields in the message for a single
> task.
> 
>> Looking at the multicast Swap message format, which is used when the NAS
>> wants to switch from one group to another,can we not handle this situation by
>> having a message type Modify (0x08).
>> This will allow, for multiple multicast group swaps. This will also reduce
>> the size of the packet. Since these messages intended only between the NAS
>> and AN, the introduction of modify command type gives further ease to the
>> Access boxes in implementing the swaps, which attributes to zap latency.
>> 
>> being associated by the NAS. Can this information also be added as part of
>> the TLV in message.
>> 
>> Thanks
>> Vish
>> 
>> 
>  Please do not print this email unless it is absolutely necessary.
> 
>  The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The company
> accepts no liability for any damage caused by any virus transmitted by this
> email. 
> 
> www.wipro.com 
> 
> 
> -- 
> Einar Nilsen-Nygaard
> Technical Leader, Cisco
> 
> Clothes make the man. Naked people have little or no influence on
> society. --Mark Twain
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 21 Apr 2008 15:00:43 -0700

Some comments:

a) Please change the name of the two 'Length' fields in the 
   control mesages sucht hat they can be differentiated easier from
   another and specify what is counted in them, eg:

    Type=Replication-Control (0x01)|             Length            |
                                                 ^^^^^^
    
   suggest to change to RC-Length, explanation "total number of bytes
   of the following TLVs plus the replication control header".

    Type = CommandCode           |              Length               |
                                                ^^^^^^

   suggest to change to CC-Length, explanation "total number of 
   this CommandCode TLV, counting this header and the following
   multicast flow bytes".

b) Please try to avoid using the term "group" when referring to
   an address which is either an ASM (Any Source Multicast) group
   address (aka: a single multicast group address, IPv4 or IPv6)
   or an SSM channel (aka: source and group address).

   I would stroingly suggest to only use the term "multicast flow"
   or multicast flow address, or just "flow", and define that term
   in the beginning of the document to be either an ASN group or
   SSM channel.

   Otherwise there will be lots of confusions about whether or not
   SSM is well supported by ANCP.

c) Do not refer to rfc2362. That RFC is obsolete and replaced by rfc4601.
   I do not see a good reason to refer to any PIM spec anyhow, just
   resolve the references used within the PIM-SM spec, eg:

   http://www.iana.org/assignments/address-family-numbers

   or the like.

d) To identify an actual SSM channel, it would be preferrable IMHO
   to have an address family identifier for an SSM channel, aka:
   an IP(v6/v6) source IP address followed by a group address. As
   above IANA URL has nothing like this defined, i think there are
   two choices:

   -> I) I'll check what effort it is to get that defined through IANA.

   -> II) we stick with the existing specification, which is to
      have a separate field addrfamily/encoding/group and one
      addrfamily/encoding/source, but then i would very much
      like to see very explicit description in the protocol spec
      what sequeneces of addfamily/encoding/addr (AEA) elements are valid,
      and how they have to be interpreted:

      for add/delete commands:
        -> MUST support a single AEA argument where the address
           is an IPv4/IPv6 address that is a multicast group.
           (ASM case).

        -> MUST support TWO AEA argument where the address of the
           first AEA is an IPv4/IPv6 address which is a unicast
           address, and the second AEA is an IPv4/IPv6 address which
           is a multicast address. Aka: SSM case.
      
      In the example text i see two things i am questioning:

        I) The (S,G) channels are encoded first group and then source.
           That IMHO is not preferrable. I would rather suggest like
           written above to encode first source and then group.
         
        II) The text is suggesting to have eg: multiple group AEA
            following an add/delete TLV. I have no strong opinion
            whether or not that should be supported, but if we conclude
            it should be supported, then that should explicitly be mentioned
            in the text (see also below). And that description would
            then of course have to detail a bit how a list of AEAs
            with ASM groups and SSM channels is to be encoded.
            Particularily this case makes it of course important
            to either be very clear how an SSM channel is encoded
            (source first or group first), or even better use a separate
            Address-Familty identifier as suggested above.

e) I do not see any suggestion on the command reply. Is there
   supposed to be some failure and/or success return codes ?

f) As far as return codes are concerned: I would like to see some
   clearer statement about the suggested atomicity (if that's a
   valid english word ;-) of the execution of multiple flows
   within a single add/delete/modify TLV as well as the flows across
   multiple TLVs within the same replication control message.

   -> What happens if any individual flow add/delete fails ? The
      document right now only seems to imply that the execution of
      the following add/deletes is simply not executed.  That by
      itself would require the NAS to either query all state to figure
      out what actually was executed or to simply try everything again.

      If we would add a return code like the following, that would
      not be necessary:
      
        "Sorry, error: all flows up to byte XX into the packet where
         performed well, and the following flow failed to be
         addeded/deleted, and the rest was not even tried"
      
      I am not sure if this type of error return is the preferred
      solution, but if we do not mandate something better, then
      it probably should be done.
   
   -> A better solution would be to imply some form of atomicity,
      eg: either at TLV or at replication control level. Meaning:
      the AN tries to execute add/delete/modifies, but if anything fails,
      then everything is undone. Or better: Nothing is applied by
      the AN unless it can make sure everything will succeed.

g) Atomicity is a hard bargain for the control/forwarding plane
   of a router/switch/DSLAM i think. If there is a bunch of add/delete/modify
   and all of those should only be applied if all of them will succeed...
   good luck getting that actually implemented correctly in the
   forwarding plane of any AN.

   The thing i could see us asking to be done atomically is really
   JUST a single flow-swap, aka: replace exactly one flow with
   another flow. 

   So ultimately, i think:

   -> For add/delete commands we ask for no atomicity and the error
      code returned should somehow point to the first flow within
      a packet that failed. And provide some additional error code
      why (which we could define the values for later). And this
      should allow us to have multiple flows as arguments to a
      single add/delete to be more efficient.
   
   -> a modify should be called "swap", and should support only 
      exactly two flows as the argument. This swap should work
      atomically, aka: the join would not be executed if the leave
      could not be done, and the leave should of course not be
      executed if the join would not work.
   
   -> So maybe overall the error return code would be
      
      command#, flow#, why

      where command# would be pointing to the command (numbered 1 t N)
      within the recplication control command that failed,
      flow# would be the flow (1..M) within that command (always 1 for
      a swap, as we only allow a single flow there), and why would be
      some eg: 8-bit error code where we could define values for that
      would help diagnosis.

h) The degree to which a platform is able to implement even this
   most simple atomic swap is of course subject to implementation.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 20:58:56 +0530

Einar,
 
In case of swap operation implemented by delete/add, if any one of them fails, some kind of error message has to be sent towards the NAS and the AN should not apply the changes partially also. Since the AN processes each message independtly, it might first delete a multicast flow and later while adding a flow if it encounters problems, it would try to revert back the delete operation which means the AN has to maintain some state of the command executed. Otherwise it might be required for the AN to scan the packet to see if there is sequence of delete/add operation to determine its a swap.
 
In case of modify command code, the AN need not maintain the state of previous command executed as it knows if changing multicast flow fails it can easily revert back to original without any state information. As for the error message it can still be the same as in previous case of delete/add, similar kind of error message can be sent in response to the NAS indicating swap operation failed. By having the modify option it is going to make the swap operation independent and sequencing the command codes need not be considered for swap operations.

Cheers
Vish

From: Einar Nilsen-Nygaard [mailto:[email-masked]]
Sent: Mon 4/21/2008 4:47 PM
To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Multicast Control Message

Vish,

I actually think that freedom in how a "swap" operation would be implemented in terms of the ordering of stopping the first multicast flow and starting the second is not desirable. By specifying that the delete must come before the add and that the operation should be terminated upon the first error, the current specification gives us what should be deterministic behavior between any and all conforming implementations.

In contrast, the freedom to implement a swap operation via some form of modify leaves the door open to multiple ways in which a modify request could fail, making error recovery more troublesome and vendor-specific which I do not see as at all desirable.

Cheers,

Einar

On 21/04/2008 20:12, "[email-masked]" <[email-masked]> scribbled:

	Einar,
	
	Thanks
	Vish

	
	Vish,

	
	Cheers,
	
	Einar

		Hi Woj,

		
		
		Thanks
		Vish

		
		Hi All,

		Regards,
		Woj & Matthew.

		
		
		      0                   1                   2                   3

		

		  0                   1                   2                   3
		
		     Addr Family

		 Number    Description
		
		     Encoding Type
		
		     Unicast Address

		

	
	
	 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 
	
	WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 
	
	www.wipro.com 

-- 
Einar Nilsen-Nygaard
Technical Leader, Cisco

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 21:09:52 +0530

Comments
a> It would be good to add Vlan tag as one of the parameters to the add/delete command, as this will indicate which VLAN should be used for multicasting. DSL TR 101,  discusses about the multicast flow being associated with a VLAN (Multicast-Vlan). In this case, the Access Node, needs to be informed about the VLAN ID on which a particular Multicast group is being associated by the NAS.
 
Cheers
Vish

From: Toerless Eckert [mailto:[email-masked]]
Sent: Mon 4/21/2008 6:00 PM
To: Einar Nilsen-Nygaard
Cc: Vishwanathan Somasundaram (WT01 - TES-Access Networks); [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Multicast Control Message

Some comments:

   

   or the like.

      for add/delete commands:

        

     

   So ultimately, i think:

  
     
      command#, flow#, why

Cheers
    Toerless