Subject: [CCAMP] reply to draft-shiomoto-ccamp-switch-programming-01

From: "zhangguoying2010" <[email-masked]>
Date: Sun, 4 Apr 2010 09:47:44 -0700

Hi Adrian and all,

This draft summarizes and clarifies the relationship between control plane and data plane behavier for LSP in GMPLS/MPLS networks which are dispersed in a number of related RFCs. 

The information and analysis provided in this draft is not only useful to interpret the LSP establishment performence measurement, and also help the GMPLS device vendors to better implement the data plane behaviour and avoid misdilivery of user data.

And as it has been discussed in Anaheim meeting, this draft has a strong relationship with RFC5814 and draft-sun-DPM-darft, provide supportive evidence and information.

Therefore, I think it would be a better idea for CCAMP to progress this work as WG document.

Guoying

Adrian Farrel 
2010-04-01  09:34:48 
[email-masked] 
 
[CCAMP] Fw: draft-shiomoto-ccamp-switch-programming-01.txt 
Hi,
Just noticed that I sent this to the old CCAMP address while undergoing 
sleep deprivation torture in Anaheim.
Cheers,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Kohei Shiomoto" <[email-masked]>
Sent: Tuesday, March 23, 2010 5:55 PM
Subject: draft-shiomoto-ccamp-switch-programming-01.txt
> Hi,
>
> We just discussed this document at the microphone in Anaheim.
>
> The question was, what to do with it.
>
> To remind you, the Abstract says:
>
>   The Resource Reservation Protocol (RSVP) has been extended to support
>   Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and
>   Generalized MPLS (GMPLS) networks. The protocol enables signaling
>   exchanges to establish Label Switched Paths (LSPs) that traverse
>   nodes and links to provide end-to-end data paths. Each node is
>   programmed with "cross-connect" information as the signaling messages
>   are processed. The cross-connection information instructs the node
>   how to forward data that it receives.
>
>   End points of an LSP need to know when it is safe to start sending
>   data so that it is not misdelivered, and so that safety issues
>   specific to the data plane technology are satisfied. Likewise, all
>   label switching routers along the path of the LSP need to know when
>   to programme their data planes relative to sending control plane
>   messages.
>
>   This document clarifies and summarises the RSVP-TE protocol exchanges
>   with relation to the programming of cross-connects along an LSP for
>   both unidirectional and bidirectional LSPs. This document does not
>   define any new procedures or protocol extensions, and defers
>   completely to the documents that provide normative references. The
>   clarifications set out in this document may also be used to help
>   interpret LSP establishment performance figures for MPLS-TE and GMPLS
>   devices.
>
> The purpose of the draft, therefore, was not to define any new procedures, 
> but to attempt to clarify the existing protocol RFCs. The draft is 
> Informational.
>
> The WG needs to decide (with the chairs judging the consensus and 
> determining the action) how we should pursue this.
>
> I gave three options at the meeting:
>
> 1. Kill the work (no interest or not helpful)
> 2. Adopt as WG draft
> 3. Pursue as independent RFC
>
> I would be happy to hear people's comments on the draft and the options.
>
> No doubt the WG chairs will want to make any calls for consensus according 
> to their priorities for the WG.
>
> Thanks,
> Adrian 

2010-04-03 

zhangguoying