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 <thomas.mo...@orange.com>:
> 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 <gl...@cysols.com>:
>> > 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
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
