Fw: new version of LSP DPPM draft

["Adrian Farrel" <adrian@olddog.co.uk>]

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