Subject: Re: INFO-AD#4, was Re: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt

From: Benoit Claise <[email-masked]>
Date: Thu, 01 Jun 2006 09:49:57 +0200

Juergen,
> Benoit,
>
> --On 24.05.2006 10:30 Uhr +0200 Benoit Claise wrote:
>>
>>>>>  - INFO-AD#4: How to add new label types to the definition of
>>>>>    IE #46 mplsTopLabelType?
>>>> The references from RFC 3954 have been assigned by the NetFlow
>>>> development team
>>>>
>>>>    MPLS_TOP_LABEL_TYPE          46   1     MPLS Top Label Type:
>>>>                                            0x00 UNKNOWN
>>>>                                            0x01 TE-MIDPT
>>>>                                            0x02 ATOM
>>>>                                            0x03 VPN
>>>>                                            0x04 BGP
>>>>                                            0x05 LDP
>>>>
>>>> I could not find any IANA registry for that.
>>>> So I guess we have only one choice, i.e. assign a new registry for it
>>>> in IANA.
>>>
>>> Would this be worth the effort?
>> Do we have another solution?
>
> The alternative would be a fixed list that cannot be extended.
> We could add a value '0x06 other' for cases not known today.
>
> If we decide to go to IANA, we probably would have to revise
> the IE definition in order to avoid ambiguities:
> The current definition says:
>
>        - 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label
>        - 0x02 Pseudowire: Any PWE3 or Cisco AToM based label
>        - 0x03 VPN: Any label associated with VPN
>        - 0x04 BGP: Any label associated with BGP or BGP routing
>        - 0x05 LDP: Any label associated with dynamically assigned
>                    labels using LDP
>
> sub-issue 1: We should add value 0x00 for unknown types. I will do so.
Fine.
> sub-issue 2: Shall we add a value for known but not encoded types, for
>             example, by adding  "0x06 other label types"?
"others" is somehow incompatible with the IANA registration.
"others" contains everything until you have a new type...

Regards, Benoit.
> sub-issue 3: We should eliminate potential ambiguities.  "Any label
>             associated with ..." seems to be a bit vague.
>             Can we exclude that labels for TE tunnel, PW3, VPNs
>             are created using LDP?  If not we should comment on this
>             case, for example by requesting that the lowest (or highest?)
>             matching type number should be used in cases where more
>             than one applies.
> sub-issue 4: Has anyone yet checked if there is any MIB module that
>             defines something like an MPLS label type?  If yes,
>             we might find useful hints there.  If not, I wonder why
>             MPLS manaement systems do not find this information useful.
>
>
> Thanks,
>
>    Juergen
>
>> Regards, Benoit.

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Benoit Claise <[email-masked]>
Date: Thu, 01 Jun 2006 09:52:17 +0200

Hi,
> Dear Juergen,
>
> This type seems to present what protocols allocates this label and how to
> allocate it. I can find that this label is allocated by RSVP-TE, if this type
> is 0x01 TE-MIDPT.
> In the case of 0x02 PW, it is allocated by target-LDP with VCID.
> But, in the case of 0x03 VPN, I don't sure what protocols allocates this label.
> It can apply several patterns, for example, there are L3VPN, PW, VPLS.
> I would like to eliminate such vague in this type, if it is not clear.
>
> If I receive 0x03 VPN, I cannot decide which MIB modules should be
> selected. 
>   
Actually, the 0x03 VPN should really be BGP.
An older version of our code did return VPN, but we decided it is more 
accurate to return BGP instead.

Regards, Benoit.
> Thanks,
> Atsushi KOBAYASHI
>
>   
>>> For example, if this type is TE-MIDPT, we can get related TE
>>> informations from MPLS-TE-MIB. If it is LDP, we can select MPLS-LSR-MIB.
>>> If it is PW, we can select MPLS-PW-MIB. If it is BGP, we can't select
>>> particular MIB. In that case, there is not particular MIB and it is only
>>> method that we search information from BGP full dump.
>>>
>>> I think that this type is more useful if this type is related with each MIB
>>> module. I felt that 0x03 VPN type is vague, in that point.
>>>       
>> Would you (or someone else) have a suggestion how to improve the description
>> of this type?
>>
>> Thanks,
>>
>>     Juergen
>>
>>     
>>> Thanks,
>>> Atsushi KOBAYASHI
>>>
>>>
>>>
>>>
>>>
>>> ---
>>> Atsushi KOBAYASHI  <[email-masked]>
>>> NTT Information Sharing Platform Lab.
>>> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652
>>>
>>>
>>>       
>>
>> --
> --- 
> Atsushi KOBAYASHI  <[email-masked]>
> NTT Information Sharing Platform Lab.
> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652
>