[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working group last call: draft-ietf-ccamp-confirm-data-channel-status-02
Dan,
It looks like the rev attached to your email was an older version,
i.e., it doesn't have all the updates discussed in this and earlier
e-mails. Do you have an more current rev?
I'll wait to comment on the attachment until you have a fully updated
rev so we don't re-discuss closed topics.
On 5/18/2009 10:50 PM, Dan Li wrote:
Hi all,
Issues from previous email exchange are listed below:
1) Soft State - combined with the suggestions from Lou and Julien:
In [RFC2205] and [RFC3209], a soft state mechanism was defined to
prevent state discrepancies between LSRs.
I suggest dropping the following clause:
> With RSVP-TE uses moving to "firm states",
(end drop)
RSVP-TE restart processes ([RFC3473], [RFC5063])
have been defined: adjacent LSRs may resynchronize their control
plane state to reinstate information about LSPs that have persisted
in the data plane. Both mechanisms aim at keeping state consistency
among nodes and allow LSRs to detect mismatched data plane states.
The data plane handling of such mismatched state can be treated as a
local policy decision. Some deployments may decide to automatically
clean up the data plane state so it matches the control plane state,
but others may choose to raise an alert to the management plane and
leave the data plane untouched just in case it is in use.
2) Section 2.3 - the last sentence caused the confusion.
Since the scenario described in section 2.3 is not very typical, and
keeps causing confusion, so this section is removed.
3) Section 4.3 - use RFC2119 language for any required protocol behavior.
4.3. Message Construction
Data_Link Class is included in ConfirmDataChannelStatus and
ConfirmDataChannelStatusAck messages, which is defined in section 13.12
in [RFC4204].
The status of the TE link end SHOULD be carried by the Data Channel
Status subobject which is defined in section 4.2 of this document. The
new subobject SHOULD be part of Data_Link Class.
Why SHOULD vs MUST?
In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD be
used to identify each timeslot of the data link.
4) At the end of section 5 - take the proposed text from Lou:
ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
transmission mechanisms. If after the retry limit is reached, a
ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
message is not received by the SENDER, the SENDER SHOULD terminate the
data channel confirmation procedure.
Please let us know if you have more comments.
Once we have the revision with all discussed updates I'll let you know
if I think anything got missed/dropped.
Thanks,
Lou
Thanks,
Dan