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

[Thomas Morin <[e-mail]>]

Hi Tsuno,

(below)

Hiroshi Tsunoda, 2017-08-08 22:20:
> 
> 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.

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.

>    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?

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) 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?

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



> 2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni <[e-mail]>:
> > 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.
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess