Subject: [CCAMP] Fw: draft-shiomoto-ccamp-switch-programming-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Apr 2010 17:34:48 +0100

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

---

From: Weiqiang Sun <[email-masked]>
Date: Fri, 02 Apr 2010 09:42:11 +0800

Adrian,

I think it is a useful (though lightweight) document that captures something
beyond the RSVP-TE specs and would be good to continue to progress in CCAMP.

On the other hand, I think it might be better to add some text regarding the
LSP recovery case. We would be happy to contribute to that part as it
progresses.

Thanks,
Weiqiang

On 4/2/10 12:34 AM, "Adrian Farrel" <[email-masked]> wrote:

> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp