Subject: [mpls] MPLS TC's

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 11 Mar 2008 15:36:58 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Mar 2008 05:35:30 -0000

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Mar 2008 12:22:18 -0000

But, if your question is "how do I handle an IPv6 extended tunnel ID" then 
see RFC 4990.

Adrian

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 12 Mar 2008 07:57:53 -0700

Hi Adrian,

You have confused me. I have attached the diagram showing the 16 bytes
of "Extended Tunnel ID" so that there is no confusion about what I am
talking about. It is 16 bytes for IPv6.

Please check section 4.6.1.2 which I have attached earlier too below:

      Extended Tunnel ID

         A 16-byte 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 IPv6 address here as a
         globally unique identifier.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 12 Mar 2008 08:28:53 -0700

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