[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 [resend]
Dan,
See below for in-line responses.
On 5/11/2009 5:29 AM, Dan Li wrote:
Lou,
See below for in-line response, start with [Authors].
Thanks,
Dan
----- Original Message -----
*From:* Lou Berger <mailto:lberger@labn.net>
*To:* Dan Li <mailto:danli@huawei.com>
*Cc:* Xu Huiying <mailto:xuhuiying@huawei.com> ;
zhangfatai@huawei.com <mailto:zhangfatai@huawei.com> ; Bardalai,
Snigdho <mailto:Snigdho.Bardalai@us.fujitsu.com> ; MEURIC Julien
RD-CORE-LAN <mailto:julien.meuric@orange-ftgroup.com> ; Diego
Caviglia (GA/ERI) <mailto:diego.caviglia@ericsson.com> ;
ccamp@ops.ietf.org <mailto:ccamp@ops.ietf.org>
*Sent:* Thursday, May 07, 2009 3:24 AM
*Subject:* Re: Working group last call:
draft-ietf-ccamp-confirm-data-channel-status-02
Dan,
See below for in-line response. Closed points are replaced with "...".
Lou
On 5/5/2009 4:31 AM, Dan Li wrote:
> Hi Lou and all,
> Thanks for the comments!
> The corresponding changes are made in 03 version.
> Please see below.
> Thanks,
> Dan
>
> ----- Original Message -----
> *From:* Lou Berger <mailto:lberger@labn.net>
> *To:* Dan Li <mailto:danli@huawei.com> ; Xu Huiying
> <mailto:xuhuiying@huawei.com> ; zhangfatai@huawei.com
<mailto:zhangfatai@huawei.com>
> <mailto:zhangfatai@huawei.com> ; Bardalai, Snigdho
> <mailto:Snigdho.Bardalai@us.fujitsu.com> ; MEURIC Julien RD-CORE-LAN
> <mailto:julien.meuric@orange-ftgroup.com> ; Diego Caviglia (GA/ERI)
> <mailto:diego.caviglia@ericsson.com>
> *Cc:* ccamp@ops.ietf.org <mailto:ccamp@ops.ietf.org>
<mailto:ccamp@ops.ietf.org>
> *Sent:* Friday, May 01, 2009 4:27 AM
> *Subject:* Re: Working group last call:
> draft-ietf-ccamp-confirm-data-channel-status-02
>
>
> Authors,
>
> Here are some LC comments:
>
> - Section 2.2:
>
> > RSVP-TE restart processes [RFC3473], [RFC5063] define mechanisms
> > where adjacent LSRs may resynchronize their control plane state to
> > reinstate information about LSPs that have persisted in the data
> > plane.
>
> The same can be said for RFC2205's (and consequently RFC3209's) soft
> state mechanisms.
> [Authors] Two references (RFC2205 and RFC3209) are added.
>
RFC2205 and RFC3209 don't have "restart processes". They do have "soft
state".
[Authors] Sorry, my mistake. With following text, put the reference of
RSVP-TE restart processes and soft state mechanisms:
RSVP-TE restart processes [RFC3473], [RFC5063] define mechanisms where
adjacent LSRs may resynchronize their control plane state to reinstate
information about LSPs that have persisted in the data plane. The soft
state mechanisms are defined in [RFC2205] and [RFC3209]. The mechanisms
allow LSRs to detect mismatched data plane...
humm. So the whole paragraph of the proposed text is:
RSVP-TE restart processes [RFC3473], [RFC5063] define mechanisms where
adjacent LSRs may resynchronize their control plane state to reinstate
information about LSPs that have persisted in the data plane. The soft
state mechanisms are defined in [RFC2205] and [RFC3209]. The mechanisms
allow LSRs to detect mismatched data plane state after the expiry of
the Recovery Timer. It is a
local policy decision how this mismatched state is handled. 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.
Is this correct? If so, Soft State and Recovery Timer don't go
together. How about:
RSVP-TE restart processes [RFC3473], [RFC5063] define mechanisms where
adjacent LSRs may resynchronize their control plane state to reinstate
information about LSPs that have persisted in the data plane. The
mechanisms
allow LSRs to detect mismatched data plane state after the expiry of
the Recovery Timer.
RSVP soft state [RFC2205] also supports the identification of state
mismatches between neighbors.
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.
> - Section 2.3:
> > operations on a cross-connect such as forced protection switch,
> > red-line,
>
> Please provide references or definitions of "forced protection
> switch" and "red-line".
> [Authors] Replaced with following text:
> In transport nodes it is possible to perform certain manual
operations
> on a cross-connect such as forced protection switch (refer to
[G.841])
> on a protected link. These operations will make it impossible to
release
> the cross-connect when an LSP is being deleted.
>
G.841 uses the terms "Lockout of Protection" and "Forced Switch", it
looks like you're combining the two.
[Authors] The command should be "Forced Swtich to protection",
change the
text to (may need further reword on this scenario):
In transport nodes it is possible to perform certain manual operations
on a cross-connect by issuing command such as "Forced Switch to
protection"
(refer to [G.841])on a protected link. These operations will make it
impossible
to release the cross-connect when an LSP is being deleted.
okay, "Forced Switch to Protection" is defined in G.841, so that's
clear. Why do you say that "These operations will make it impossible to
release the cross-connect when an LSP is being deleted."? GMPLS doesn't
precluded LSP deletion based on a "Recovery Command", see rfc4872.
> ...
>
> > As LMP is already used to verify data plane connectivity, it is
> > considered to be an appropriate candidate to support this feature.
>
> This is a fairly major point as it defines the scope of
> use/applicability of this document. I suggest that you repeat this
> point in both the abstract and introduction.
> [Authors] This statement is repeated in both the abstract and
> introduction.
>
okay. You might want to move the pasted sentence to the end of the
paragraphs to improve flow, but this is your call.
[Authors] Pasted sentence is moved to the end of the paragraphs.
> - Section 4.1:
>
> > Three new messages are defined to check data channel status.
Message
> > Type numbers are found in Section 7.1.
>
> So why define new message types? It seems that the same effect
> could have been obtained using new Channel_Status values in
> channelstatus messages.
> [Author] Yes, there are several approaches. If one node doesn't
support
> this function, it can simply ignore the new messages defined in this
> document.
>
humm, well this doesn't really answer my question, i.e. why didn't you
use the existing types rather than define new types?
I'm not asking for a change (at this late date) just some justification.
[Authors] When we look at the existing 20 LMP messages, it can be
grouped into
several functions. For example, messages 17-20 are defined to get
the channel
status information. We think Data channel consistency check is a
little bit
different from the channel status collection function. It's better
to define
new messages to support this function. Furthermore, we don't need to
touch the
inside of LMP, so the messages process can be done at the beginning
of LMP
module. If a node doesn't support this function, the message can be
ignored at
the message process stage.
Thank you for the explanation. While the current approach clearly can
work, I'm not I really agree, but it's too late in the process to move a
way from a viable approach.
...
> - Section 5:
> > ... The RECEIVER also
> > sends the ConfirmDataChannelStatusAck message which carries all
> > the local end statuses of the requested data channels to the
> > SENDER.
>
> If the DATA Channel ID remains, you'll need to define how it's used
> in this message.
> [Authors] DATA LINK class is defined in RFC4204. In DATA LINK class,
> a new
> subobject - Data Channel Status subobject is defined in section 4.2
> of this
> document. In this new subobject, the DATA Channel ID is introduced.
> In the
> case of SDH/SONET, DATA Channel ID is used to identify each timeslot
> of the
> data link. So the reference to RFC4204 section 13.12 will be added
> in this
> section.
>
Yes. Please add some normative language on ConfirmDataChannelStatusAck
message construction.
[Authors] Added a new section 4.3 to describe the message construction:
-----
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 is carried by the Data Channel Status
subobject
which is defined in section 4.2 of this document. The new subobject
is part
of Data_Link Class.
In the case of SDH/SONET, DATA Channel ID in the new subobject is
used to
identify each timeslot of the data link.
-----
Please just make sure to use RFC2119 language for any required protocol
behavior.
> ...
>
> > to the SENDER. In this case, if the ConfirmDataChannelStatusAck or
> > ConfirmDataChannelStatusNack message is not received by the SENDER
> > within the configured time, the SENDER SHOULD terminate the data
> > channel confirmation procedure. A default value of 1 minutes is
> > suggested for this timer.
>
> It might be worth identifying this "compatibility" case separately
> from the case where no ConfirmDataChannelStatusAck is received due
> to message loss.
> [Authors] This clause is replaced by the following text:
> If the ConfirmDataChannelStatus message is not recognized by the
> RECEIVER,
> the RECEIVER will not send out an acknowledgment message to the
> SENDER.
> Due to message loss problem, the SENDER may not be able to
receive the
> acknowledgment message.
> In the above two cases, if the ConfirmDataChannelStatusAck or
> ConfirmDataChannelStatusNack message is not received by the SENDER
> within the configured time, the SENDER SHOULD terminate the data
> channel
> confirmation procedure. A default value of 1 minutes is suggested
> for this timer.
>
I'm surprised you don't want to leverage LMP's message retransmission
procedures.
[Authors] The retransmission procedure is added:
-----
In the above two cases, the SENDER SHOULD retransmit the unacknowledged
ConfirmDataChannelStatus message until the message is acknowledged
or until
a retry limit is reached. In the case of the retry limit is reached,
the
SENDER SHOULD terminate the data channel confirmation procedure.
A default value of 20 seconds is suggested for the retransmission
interval,
and 3 times is suggested for the retry limit.
-----
How about: "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. "
...
Lou