----- Original Message -----
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> ;
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>
>
*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...
> - 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.
> ...
>
> >
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.
> - Section 4.1:
>
>
...
>
> Also, don't you also need to
specify out of order processing for the
> new
messages? see the top of Page 24 in RFC4202.
>
[Author] Do you mean Page 24 of RFC4204?
yes.
> The following
text is added
> in section
4.1:
> Nodes processing incoming messages SHOULD
check to see if a newly
> received message is
out of order and can be ignored. Out-of-order
>
messages can be identified by examining the value in the
Message_Id
> field. If a message is determined
to be out-of-order, that message
> should be
silently dropped.
>
Well, this duplicates text from 4204 and
should not be included. I was
pointing the subsequent paragraphs on
the page and suggesting something
along the lines
of:
If the message is a Confirm Data Channel Status
message, and the
Message_Id value is less
than the
largest Message_Id value previously received from the
sender
for the ????, then the message SHOULD be treated
as being out-of-
order.
[Authors]
Okay. Removed the text which is copied from 4204, and added the
following
text:
If the message is a Confirm Data Channel Status message, and the
Message_Id
value is less than the largest Message_Id value previously
received from the
sender for the specified TE link, then the message
SHOULD be treated as being
out-of-order.
>
...
>
> > Data Channel
ID
>
> Isn't this field redundant with the
DATA_LINK object's interface_ids?
> Please keep
in mind that LMP already has a notion of data
channels
> that are represented in the 4204/4209
CHANNEL_STATUS objects. Am I
> missing
something?
> [Authors] In the case of SDH/SONET,
Data Channel ID is the
> timeslot label (32
bits), which is encoded as following:
> 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
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
| S | U | K | L | M |
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
We
don't need to do in circles here, but 4204/4209 uses a fundamentally
different model, i.e. one based on data channel (interface) IDs and ID
groups rather than labels. Your approach is not at all consistent
with
existing LMP, but we've already established this with the use of new
messages so be it.
> - 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.
-----
>
...
>
> > 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.
-----