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

["Will Liu (Shucheng)" <[e-mail]>]

Folks,

We addressed the comments from Francesco by updating the MplsLSPID description as pasted below. Please let us know your thoughts, thanks.

      MplsLSPID ::= TEXTUAL-CONVENTION
      STATUS        current
      DESCRIPTION
      "A unique identifier within an MPLS network that is
      assigned to each LSP.  This is assigned at the head
      end of the LSP and can be used by all LSRs
      to identify this LSP.  This value is piggybacked by
      the signaling protocol when this LSP is signaled
      within the network.  This identifier can then be
      used at each LSR to identify which labels are
      being swapped to other labels for this LSP.  This
      object  can also be used to disambiguate LSPs that
      share the same RSVP sessions between the same
      source and destination.

      For LSPs established using CR-LDP, the LSPID is
      composed of the ingress LSR Router ID (or any of
      its own IPv4 addresses) and a locally unique
      CR-LSP ID to that LSR.  The first two bytes carry
      the CR-LSPID, and the remaining 4 bytes carry
      the Router ID.  The LSPID is useful in network
      management, in CR-LSP repair, and in using
      an already established CR-LSP as a hop in
      an ER-TLV.

      For LSPs signaled using RSVP-TE, the LSP_ID is a local             -- we mainly updated this paragraph
      number defined as a 16-bit (2 byte) identifier used
      in the SENDER_TEMPLATE and the FILTER_SPEC that can be
      changed to allow a sender to share resources with itself.
      The LSP_ID is only unique within the context of the
      SESSION and it cannot be used as network identifier.  RSVP-TE
      signaling use a 5-tuple to uniquely identify an LSP within an
      operator's network.  This tuple is composed of a
      Tunnel End-point Address, Tunnel_ID, Extended Tunnel ID,
      Tunnel Sender Address, and LSP_ID.

      The length of this object should only be 2 or 6 bytes.
      If the length of this octet string is 2 bytes, then it
      must identify an RSVP-TE LSP_ID, or it is 6 bytes, it must
      contain a CR-LDP LSPID."
      REFERENCE

      "RSVP-TE:  Extensions to RSVP for LSP Tunnels,
      [RFC3209].

      Constraint-Based LSP Setup using LDP,
      [RFC3212]."
      SYNTAX  OCTET STRING (SIZE (2|6))

Regards,
Will


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Will Liu (Shucheng)
> Sent: Monday, May 27, 2013 9:09 PM
> To: Francesco Fondelli
> Cc: [e-mail]
> Subject: Re: [mpls] FW: New Version Notification for
> draft-manral-mpls-rfc3811bis-02.txt
> 
> Hi Francesco,
> 
> Thanks for your comments. Please see below in-line.
> 
> > -----Original Message-----
> > From: Francesco Fondelli [mailto:[e-mail]]
> > Sent: Saturday, May 25, 2013 2:09 AM
> > To: Will Liu (Shucheng)
> > Cc: [e-mail]
> > Subject: Re: [mpls] FW: New Version Notification for
> > draft-manral-mpls-rfc3811bis-02.txt
> >
> > 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.
> 
> Agree.
> >
> > Can we also "fix" this in 3811bis ?
> 
> Yes. I think we can fix this in the next version.
> >
> > 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)
> > <[e-mail]> wrote:
> > > 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: [e-mail] [mailto:[e-mail]]
> > > 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
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls