[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ANCP] Proposal for replacement of "Multicast Status" message, Part 2



This message describes the changes required in
draft-ietf-ancp-mc-extensions-00.txt if the Multicast Status message is replaced
by the base protocol Generic Response message I described in my previous note.

The actual text changes required are too extensive to put into an E-mail. This is an outline, which I will implement in detailed text in my role as co-author if the list agrees in principle.


1. Global change
================

Change "Multicast Status" to "Generic Response". Watch out for the figures,
where the message appears as "Multicast-Status".

2. Section 4.1 Provisioning Message
===================================

An editor's note calls for error responses to the Provisioning message to be added to base. I would suggest that the general Code value:

84      Unsupported TLV type

be added to the others I proposed in my previous E-mail, and this would be used for the error cases described in the editor's note. We could also define a sub-TLV to Status-info in base that provides the TLV identifier, if we think the NAS could use that information to modify its message. Base can then define a generic failure response to the Provisioning message (if we think this won't overload the NAS).

3. Section 4.3.  Multicast Replication Control Message
======================================================

Editorial note: some parts of this section should be reordered to provide a clean separation between sender behaviour and receiver behaviour.

The existing text says that a Multicast Status message MUST be sent "when a response is needed". I assume the text should really read that the receiver MUST send a Generic Response message with the appropriate contents if unable to execute the complete Multicast Replication Control message successfully. If I am correct, the Result field of the Multicast Replication Control message should be set to Nack rather than Ignore.

The specific error conditions described in the current text are:

*** unrecognized target TLV
-- Covered by existing code value 4, "One or more of the specified ports does not exist." (Note that this is the explanatory text that is shown in the IANA registry, and differs from the current text of the MC extensions document.)

*** command error
 -- Needs a new Code value, so add

85    Command error

to base, and define in base a sub-TLV of Status-info to carry the sequence number of the command within the message. This sub-TLV could also carry an additional diagnostic code with its own IANA registry if people think it might be useful. Extensions would define the actual code values and add them to the registry. Likely candidates are some of the errors listed in section 4.4:

- Command not supported

- Flag set but not supported

- M Flag set, but no IP Source address provided

- Unsupported Address Family

- Unsupported address encoding

- Malformed flow address

- Multicast flow does not exist



*** command flag error
-- The NAS isn't going to debug flag values in real time, but this would be a candidate for an additional diagnostic code value to help the operating staff who will be reviewing the NAS's log of errors. See above.



4. Section 4.4 Multicast Status Message
=======================================

Delete this section.


5. Section 4.5.  Multicast Admission Control Message
====================================================

Replace the text at the end talking about the content of the Multicast Status message with a statement that the content of the Generic Response message follows the rules described in section 4.3 failures of the Multicast Replication Control message.


I think I'll leave further changes to other notes, dealing primarily with other issues.

Tom Taylor