[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls] MPLS TC's
From:       "Vishwas Manral" <vishwas.ietf () gmail ! com>
Date:       2008-03-12 15:28:53
Message-ID: 77ead0ec0803120828y14fbff6esbae8cefdf30eb519 () mail ! gmail ! com
[Download RAW message or body]

Hi Adrian,

Thanks a lot for the reply this one was helpful. I have some more
doubts. I read the particular section in RFC4990 regarding the use of
Extended Tunnel Id.  I really appreciate the good work done by the
authors.

The document seems to talk about:

   The aim is to facilitate interworking of GMPLS-capable Label
   Switching Routers (LSRs).

I am not working on GMPLS, just basic MPLS for IPv6. It seems that the
document we have is an informational RFC, and is some very good patch
work. Would it be better to actually update the MIB itself to be able
to handle Extended Tunnel Id and the likes with a value of 16 bytes
too (RFC3811 and RFC3812)?

Thanks,
Vishwas

On Wed, Mar 12, 2008 at 5:22 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> But, if your question is "how do I handle an IPv6 extended tunnel ID" then
>  see RFC 4990.
>
>  Adrian
>
>
> ----- Original Message -----
>  From: "Adrian Farrel" <adrian@olddog.co.uk>
>  To: "Vishwas Manral" <vishwas.ietf@gmail.com>; <mpls@ietf.org>
>  Cc: "Tom Nadeau" <tom.nadeau@bt.com>
>  Sent: Wednesday, March 12, 2008 5:35 AM
>  Subject: Re: [mpls] MPLS TC's
>
>
>  > Vishwas,
>  >
>  > A little more care with your reading, please.
>  >
>  > From RFC 3209 section 4.6.1.1
>  >
>  >      Extended Tunnel ID
>  >
>  >         A 32-bit identifier used in the SESSION that remains constant
>  >         over the life of the tunnel.  Normally set to all zeros.
>  >         Ingress nodes that wish to narrow the scope of a SESSION to the
>  >         ingress-egress pair may place their IPv4 address here as a
>  >         globally unique identifier.
>  >
>  > Pray tell where the 16 byte reference comes from.
>  >
>  > Adrian
>  >
>  > ----- Original Message -----
>  > From: "Vishwas Manral" <vishwas.ietf@gmail.com>
>  > To: <mpls@ietf.org>
>  > Cc: <tnadeau@cisco.com>
>  > Sent: Tuesday, March 11, 2008 10:36 PM
>  > Subject: [mpls] MPLS TC's
>  >
>  >
>  >> Hi,
>  >>
>  >> I found that the following textual convention for MplsExtendedTunnelId
>  >> may not be right. It is defined as an Unsigned32 in the RFC3811, which
>  >> is incorrect. It is defined as 16 bytes in RFC3209.
>  >>
>  >> Do let me know what you think is the best solution further from here?
>  >>
>  >> Thanks,
>  >> Vishwas
>  >>
>  >> Quoting RFC3811:
>  >>
>  >>       MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
>  >>          STATUS        current
>  >>          DESCRIPTION
>  >>             "A unique identifier for an MPLS Tunnel.  This may
>  >>              represent an IPv4 address of the ingress or egress
>  >>              LSR for the tunnel.  This value is derived from the
>  >>              Extended Tunnel Id in RSVP or the Ingress Router ID
>  >>              for CR-LDP."
>  >>          REFERENCE
>  >>             "RSVP-TE: Extensions to RSVP for LSP Tunnels,
>  >>              [RFC3209].
>  >>
>  >>              Constraint-Based LSP Setup using LDP, [RFC3212]."
>  >>          SYNTAX  Unsigned32(0..4294967295)
>  >>
>  >> Quoting RFC3209:
>  >>
>  >> 4.6.1.2. LSP_TUNNEL_IPv6 Session Object
>  >>
>  >>   Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
>  >>
>  >>    0                   1                   2                   3
>  >>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  >>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >>   |                                                               |
>  >>   +                                                               +
>  >>   |                   IPv6 tunnel end point address               |
>  >>   +                                                               +
>  >>   |                            (16 bytes)                         |
>  >>   +                                                               +
>  >>   |                                                               |
>  >>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >>   |  MUST be zero                 |      Tunnel ID                |
>  >>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >>   |                                                               |
>  >>   +                                                               +
>  >>   |                       Extended Tunnel ID                      |
>  >>   +                                                               +
>  >>   |                            (16 bytes)                         |
>  >>   +                                                               +
>  >>   |                                                               |
>  >>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  >> _______________________________________________
>  >> mpls mailing list
>  >> mpls@ietf.org
>  >> https://www.ietf.org/mailman/listinfo/mpls
>  >>
>  >
>  > _______________________________________________
>  > mpls mailing list
>  > mpls@ietf.org
>  > https://www.ietf.org/mailman/listinfo/mpls
>  >
>
>
>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]