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, "vishwanathan.sundaram at wipro.com"
> <vishwanathan.sundaram at wipro.com> 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:einarnn at cisco.com]
> > Sent: Sun 4/20/2008 11:12 AM
> > To: Vishwanathan Somasundaram (WT01 - TES-Access Networks); wdec at cisco.com;
> > ancp at ietf.org
> > 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, "vishwanathan.sundaram at wipro.com"
> > <vishwanathan.sundaram at wipro.com> 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: ancp-bounces at ietf.org on behalf of Wojciech Dec (wdec)
> >> Sent: Mon 4/14/2008 11:00 AM
> >> To: ancp at ietf.org
> >> 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
> >> 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
> >
> > 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
> ANCP at ietf.org
> https://www.ietf.org/mailman/listinfo/ancp

--
---
Toerless Eckert, eckert at cisco.com
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark