Subject: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Wed, 22 May 2013 03:02:41 +0000

Folks, 

We updated the draft by modifying the introduction, typos in section 5, and adding a section highlighting the changes on rfc3811.

Your review and comments are highly appreciated. 

Regards,
Will

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 22, 2013 3:30 AM
To: Tina TSOU; Will Liu (Shucheng); Vishwas Manral; Will Liu (Shucheng)
Subject: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt

A new version of I-D, draft-manral-mpls-rfc3811bis-02.txt
has been successfully submitted by Vishwas Manral and posted to the
IETF repository.

Filename:	 draft-manral-mpls-rfc3811bis
Revision:	 02
Title:		 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management
Creation date:	 2013-05-20
Group:		 Individual Submission
Number of pages: 22
URL:             http://www.ietf.org/internet-drafts/draft-manral-mpls-rfc3811bis-02.txt
Status:          http://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis
Htmlized:        http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-manral-mpls-rfc3811bis-02

Abstract:
   This memo defines a Management Information Base (MIB) module which
   contains Textual Conventions to represent commonly used Multiprotocol
   Label Switching (MPLS) management information.  The intent is that
   these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS
   related MIB modules that would otherwise define their own
   representations.

   This document obsoletes RFC3811 as it addresses the need to support
   IPv6 extended TunnelID's by defining a new TC-
   MplsNewExtendedTunnelID which suggests using IPv4 address of the
   ingress or egress LSR for the tunnel for an IPv6 network.  Changes
   from RFC3811 and the effect of the new TC to other related documents
   are summarized in Section 4 and 5, respectively.

The IETF Secretariat

---

From: Francesco Fondelli <[email-masked]>
Date: Fri, 24 May 2013 20:09:23 +0200

Hi Will, all,

I have always thought MplsLSPID description in 3811 was misleading (or
inconsistent): "A unique identifier within an MPLS network that is assigned
to each LSP...".  For LDP this is 6 bytes 'IP addr + local ID' and can
be used as a network-unique handle.  However, for LSPs signaled using
RSVP-TE, RFC3811 suggests to use the LSP_ID (2 byte) used in the
SENDER_TEMPLATE obj.  This is just a local number (it is unique within
the scope of the SESSION) so it cannot be used to uniquely identify an
LSP on a network.

Can we also "fix" this in 3811bis ?

We can simply state (in the MplsLSPID description) that for LSPs signaled
using RSVP-TE this is just a local number.  Alternatively, we can make
room (now is max 6 octets) for full network level LSP identification:
5-tuple { Destination Address, Tunnel_ID, Extended Tunnel ID, Sender Address,
LSP_ID }.

thank you
ciao
fra

On Wed, May 22, 2013 at 5:02 AM, Will Liu (Shucheng)
<[email-masked]> wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls