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

[Hiroshi Tsunoda <[e-mail]>]

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


2017-08-11 16:50 GMT+02:00 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