Subject: [bess] A question about Tunnel Identifier in PMSI Tunnel Attribute etc.

From: Hiroshi Tsunoda <[email-masked]>
Date: Tue, 8 Aug 2017 22:20:02 +0200

Hi,

Please forgive my insufficient knowledge about MVPN,
but I need some advice to answer the MIB doctor's
questions (attached in the end of this mail)
on L2L3-VPN-MCAST-{TC-MIB, MIB}.

a) Format and examples of Tunnel Identifier in PMSI Tunnel Attribute

   L2L3-VPN-MCAST-TC-MIB provides a textual convention
   (L2L3VpnMcastProviderTunnelId) representing
   the Tunnel Identifier of a P-tunnel.

   a-1) I would like to know if there is  any preferred format
          when a Tunnel Identifier is printed.

   a-2) In the case that there is no preferred format,
          the MIB doctor request us to show some actual
          examples of the Tunnel Identifier.
          Is there any good reference to see the actual examples?

b) Required information to identify a particular P-tunnel

    l2L3VpnMcastPmsiTunnelAttributeTable defined in L2L3-VPN-MCAST-MIB
    is a table to provide P-tunnel information.
    Currently the index of this table is composed of
    information objects representing Flags, Tunnel Type,
    MPLS Label, and Tunnel Indentifier in
    delivered in PMSI Tunnel Attribute.
    I think the index must be composed only of minimal
    objects to identify a particular P-tunnel.
    Thus, Tunnel Type and Tunnel Indentifier are required
    for the index as described in Sec. 7.4.1.1 of RFC6513,
    but Flags is not required.

    b-1) How about MPLS Label? Is it required to be included in the index?

I hope that someone could give me some help.

Thanks in advance,

-- tsuno

2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni <[email-masked]>:
> L2L3-VPN-MCAST-TC-MIB is almost OK.
> smilint gives warnings
> (snip)
>   L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning: type
>   `L2L3VpnMcastProviderTunnelId' has no format specification
> This may be avoided by specifying a format in which the
> L2L3VpnMcastProviderTunnelId should be printed.
> Is there a preferred format? How will this be printed?
> One continuous octet string?
>
> (snip)
>
> But before we go on to the next stage could you please confirm that
> A. The l2L3VpnMcastPmsiTunnelAttributeTable needs all of the following
>    four MOs as index for its rows
>              l2L3VpnMcastPmsiTunnelAttributeFlags,
>              l2L3VpnMcastPmsiTunnelAttributeType,
>              l2L3VpnMcastPmsiTunnelAttributeLabel,
>              l2L3VpnMcastPmsiTunnelAttributeId
>    The l2L3VpnMcastPmsiTunnelAttributeId by itself is inadequate? If yes
>    please explain it to me. Or point to the text that contains the
>    explanation.
> I have been unable to confirm the above from the draft - that is very
> likely due to my lack of understanding of the l2L3VpnMcast technology.

---

From: Thomas Morin <[email-masked]>
Date: Fri, 11 Aug 2017 16:50:51 +0200

Hi Tsuno,

(below)

>           when a Tunnel Identifier is printed.

For each different type, there is a natural/preferred format, but
there is no format valid across all different types.

When the type is for IP multicast tree, it would be natural to display
it as an IP adress, but when the type is for an LSP, it depends on the
MPLS signaling protocol (mLDP, P2MP RSVP-TE)...

I don't know if there is a better solution than to display a
hexadecimal byte string.

>           Is there any good reference to see the actual examples?

Not as far as I know.
I don't think there is any canonical way to display, e.g. the <Extended
Tunnel ID, Reserved, Tunnel ID, P2MP ID> tuple of an RSVP-TE P2MP LSP
SESSION Object.

>     b-1) How about MPLS Label? Is it required to be included in the

Doing lookups in this table based on an MPLS label does not look like
something natural to do, given that the label allocated may change over
time. I would be tempted to answer no to your question.

-Thomas

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

---

From: Hiroshi Tsunoda <[email-masked]>
Date: Sat, 12 Aug 2017 10:03:20 +0200

Hi Thomas,

Thank you very much for your answer.  It is really helpful for me.
I am going to update the draft taking into account your answer.

Best regards,

-- tsuno