Adrian,
1. Thanks for the forward.
2. Observation: nice productive dialogue on the technical merits of the draft
Best/m
Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer
-----Original Message-----
From: owner-ccamp@ops.ietf.org on behalf of Adrian Farrel
Sent: Tue 12/9/2008 2:56 AM
To: ccamp@ops.ietf.org
Subject: Fw: new version of LSP DPPM draft
Forwarded on behalf of Guoying Zhang:
----- Original Message -----
From: "gyzhang" <gyzhang@sina.com>
Sent: Tuesday, December 09, 2008 2:14 AM
Subject: new version of LSP DPPM draft
Hi all,
A new version of DPPM draft (LSP Dynamic Provisioning Performance Metrics in
GMPLS Networks) has just been posted on the IETF website. This draft was
discussed in the Dublin meeting. The authors have now updated the draft
according to the discussions during and after the meeting. The following are
the summary of discussion and modifications made to the draft.
1. During and after the meeting, some discussion was made about the data
plane and control plane synchronization. Thanks to Adrian, some rules
clarifying their relations were identified in existing documents.
(1) Three documents stated the rules in the forward direction
RFC 3471 section 3.4: an ingress node should not transmit data traffic on a
suggested label until the downstream node passes a label upstream. The
implication here is that an ingress node may (safely) start to transmit data
when it receives a label in a Resv message.
This also shows in RFC 3473 section 2.5: An ingress node SHOULD NOT
transmit data traffic using a suggested label until the downstream node
passes a corresponding label upstream.
Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL object
as part of the Resv message to the previous hop. The node SHOULD be prepared
to forward packets carrying the assigned label prior to sending the Resv
message. "before" is very telling. It means that the XC must be in place to
forward traffic before Resv is sent.
(2) For the reverse direction
We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate a
label that is valid for forwarding at the time the Path message is sent.
"valid for forwarding" should be taken to mean that it is OK to receive data
and it will be forwarded. But it can also be taken to mean "acceptable for
use" i.e. available to be cross-connected.
This is clarified later in RFC 3473 section 3.1: Terminator nodes process
Path messages as usual, with the exception that the upstream label can
immediately be used to transport data traffic associated with the LSP
upstream towards the initiator. This is pretty clear. When a Path message
has been fully processed by an egress node, it is completely safe to
transmit data toward the ingress (i.e. reverse path data).
(3) To clarify this assumption (that the these rules are followed) we
include the following text into the discussion section (section 15)
This document assumes that the correct procedures for installing the data
plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. That
is, that by the time the egress receives and processes a Path message, it is
safe for the egress to transmit data on the reverse path, and that by the
time the ingress receives and processes a Resv message it is safe for the
ingress to transmit data on the forward path. This document does not include
any verification that the implementations of the control plane software are
conformant, although such tests could be constructed with the use of
suitable signal generation test equipment.
2. During the Dublin meeting, the authors raised the open issue of using
two way signaling or three way signaling. After some discussions within the
editor team, an agreement has been reached and the following text was added
to the discussion section (section 15)
o Bidirectional LSPs may be setup using three way signaling, where the
initiate node will send a RESV_CONF message downstream upon receiving the
RESV message. The RESV_CONF message is used to notify the terminate node
that it can transfer data upstream. Actually, both directions should be
ready to transfer data when the RESV message is received by the initiate
node. Therefore, the bidirectional LSP setup delay defined in this document,
does not take the confirmation procedure into account.
We thank to Lou, Igor and Adrian for their valuable comments and discussions
during and after the meeting. The authors would like to have more experts
from the WG to review this draft. And we hope to request a WG last call
soon.
best regards,
????????Guoying Zhang
????????gyzhang@sina.com
??????????2008-12-08