Subject: Re: [ANCP] ANCP Multicast Control Message

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 16 May 2008 13:20:54 +0200

Hi Vish,
 
adding the VLAN tag as a mandatory parameter seems undesirable. The use or otherwise of "multicast VLANs" is a local configuration issue on the AN which could be set to a default, or at best an optional parameter in the ANCP request message.

Regards,
Woj.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 22 April 2008 17:40
	To: Toerless Eckert (eckert); Einar Nilsen-Nygaard (einarnn)
	Cc: [email-masked]
	Subject: Re: [ANCP] ANCP Multicast Control Message

	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:
	
	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
	     
	On Mon, Apr 21, 2008 at 09:47:06PM +0100, Einar Nilsen-Nygaard wrote:
	> 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
	> > 
	> >
	> >
	> > 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,
	> >> 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,
	> >>
	> >> 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
	> >>
	> >>
	> >> _______________________________________________
	> >> ANCP mailing list
	> >> [email-masked]
	> >> https://www.ietf.org/mailman/listinfo/ancp
	> >
	> >  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
	> >
	>
	
	> _______________________________________________
	> ANCP mailing list
	> [email-masked]
	> https://www.ietf.org/mailman/listinfo/ancp

	--
	---
	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: "DE CNODDER Stefaan" <[email-masked]>
Date: Fri, 16 May 2008 15:33:13 +0200

Hi Vish, Woj,
 
I agree with Woj that the VLAN should be at most an optional parameter.  According to me, putting the multicast VLAN in the command message is also not correct because there can be quite a lot of commands send from the NAS to the AN and each message would always repeat this same information.  It looks better to me to configure the multicast VLAN at the level of the partition, that looks to be more than enough (if at all something is needed).  It is suffcient to me that the protocol is extensible enough to add it later when it is clear that there is a real need for it.
 
regards,
Stefaan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: vrijdag 16 mei 2008 13:21
To: VISHWANATHAN SOMASUNDARAM; Toerless Eckert (eckert); Einar Nilsen-Nygaard (einarnn)
Cc: [email-masked]
Subject: Re: [ANCP] ANCP Multicast Control Message

Hi Vish,

Regards,
Woj.

	Comments
	 
	Cheers
	Vish

	Some comments:

	   

	

	

	   or the like.

	
	
	      for add/delete commands:

	

	

	     

	

	   So ultimately, i think:

	  
	     
	      command#, flow#, why

	
	Cheers
	    Toerless