Subject: Re: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt

From: Juergen Quittek <[email-masked]>
Date: Mon, 08 May 2006 00:31:13 +0200

Benoit,

Thank you for solving these issues.  Please find
text suggestions inline.

--On 27.04.2006 23:44 Uhr +0200 Benoit Claise wrote:

> Hi Juergen,
>> Hi Bert,
>>
>> Many thanks for the detailed comments.
>> Please find replies inline.
>>
>> Dear all,
>>
>> Please check my replies and please speak up quickly
>> if you have problems with what I suggested.
>>
>> Most issues should be closed by the replies.
>>
>> The following ones definitely need further work.
>> I will address them in a follow-up message:
>>
>>  - INFO-AD#1: Do reported statistics include or exclude the
>>    reporting IPFIX message?  Affected IEs are
>>        # 40 exportedOctetTotalCount
>>        # 41 exportedMessageTotalCount
>>        # 42 exportedFlowTotalCount
> All of the counters exclude the reporting IPFIX Message

Suggestion:

append to description of #40 exportedOctetTotalCount
    "The reported number excludes octets in the message that
     carries the counter value."

append to description of #41 exportedMessageTotalCount
    "The reported number excludes the message that carries the
     counter value."

append to description of #40 exportedFlowTotalCount
    "The reported number excludes flow records in the message
     that carries the counter value."

>>
>>  - INFO-AD#2: Does IE #42 exportedFlowTotalCount
>>    report the number of flows or the number of flow records?
>>
>>  - INFO-AD#3: Is it OK to change dataty of IEs
>>        # 16 bgpSourceAsNumber
>>        # 17 bgpDestinationAsNumber
>>    from unsiogned16 to unsigned32?
> RFC 3954 specifies already 32 bits
>
>                                            Source BGP autonomous
>    SRC_AS                       16   N     system number where N could
>                                            be 2 or 4. By default N is
>                                            2
>
>                                            Destination BGP autonomous
>    DST_AS                       17   N     system number where N could
>                                            be 2 or 4. By default N is
>                                            2
>
> Anyway, we've got the reduced size encoding, so unsigned32 makes sense.

Good.

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

Thanks,

    Juergen

> Regards, Benoit.
>>
>>  - INFO-AD#5: Explain in the capabilities and limitations of the
>>    different dateTimeXX data types.
>>
>>  - INFO-AD#6:
>>    Review last paragraph of section 7.
>>
>>  - INFO-AD#7:
>>    Elaborate security considerations
>>
>> Thanks,
>>
>>    Juergen
>>
>>
>>> - sect 5.5.x
>>>   Would it be useful to add a line of text to explain how long
>>>   (how many minutes, months, years) each granularity allows
>>>   based on the underlying datatype?
>>
>> I will work on a text suggestion.
>>
>>
>> --On 17.03.2006 17:42 Uhr +0100 Wijnen, Bert (Bert) wrote:
>>
>>> Sorry that it took so long (if I say it 4 times, i.e.
>>> for each doc I have reviewed, will you please forgive me).
>>>
>>> Seems that a new rev might be in order ??
>>>
>>> Bert
>>>
>>> - bottom of page 8. enterpriseId -
>>>   it speaks about "Information Element Identifier described above"
>>>   I do not see where "above" it is described. In fact, I think the
>>>   Identifier is described in sect 4, no?
>>
>> Oooops, the Element Id is a mandatory element and not listed above.
>> This was a problem of the code generating this section from the schema.
>> Now, the list of mandatory IE properties contains in addition between
>> 'name' and 'description' the following property:
>>
>>  "elementId - A numeric identifier of the Information Element.  If this
>>      identifier is used without an enterprise identifier (see below),
>>      then it is globally unique and the list of allowed values is
>>      administered by IANA.  It is used for compact identification of an
>>      Information Element when encoding templates in the protocol."
>>
>>> - In the 3 paragraphs of sect 3 and 3.1, I would insert the word
>>> "abstract"
>>>   in from of each occurrence of "data type(s)".
>>>   Also the title of sect 3.1 probably reads better as "Abstract Data
>>> Types".
>>
>> done.
>>
>>> - sect 3.1.9
>>>   "it is expected that strings will be encoded in UTF-8"
>>>   That does not make it interoperable, does it?
>>>   Would it not be better to say "strings MUST be encoded..."
>>>   And I would add a citation and reference to RFC3629.
>>
>> done.
>> added RFC3629 as normative reference.
>>
>>> - sect 3.2
>>>   s/future protocol extensions/future information model extensions/ ??
>>
>> fixed, and also in section 3.1.
>>
>>> - page 16
>>>   What are ID 211 and 212 ?? blank ?? reserved?? something else?
>>>   I see the explanation on page 17. I'd suggest to make them RESERVED
>>>   or OBSOLLETE or DEPRECATEd or give them some name with the note
>>>   that they are not part of the standard.
>>
>> I used RESERVED. Maybe we can solve the issues of these two elements
>> before submitting the next version.
>>
>>> - section 5 1st sentence
>>>   s/Flow attributes/Information Elements/ ??
>>
>> fixed.
>>
>>> - sections 5.1.3, 5.1.4., 5.1.5 and 5.1.6
>>>   I worry about referential integrety when the ifIndex gets stored
>>>   in offline/archive storage. On a reboot, many devices renumber the
>>>   ifIndex for various interfaces.
>>>   Is this not a problem? I'd think it is at least something to
>>>   mention/discuss/warn for.
>>
>> added
>>
>>       "Please note that ifIndex
>>        values are not assigned statically to an interface.
>>        Interfaces may be renumbered every time the device is
>>        rebooted."
>>
>> to the description of 5.1.3 and 5.1.4.
>>
>> added
>>
>>       "Please note that
>>        process identifiers are typically assigned dynamically.
>>        After a reboot, a system failure, a crash of the Metering
>>        Process, etc. the Metering Process may be re-started
>>        with a different ID.
>>
>> to the description of 5.1.5 and 5.1.6.  For 5.1.6 "Metering"
>> was replaced with "Exporting".
>>
>>> - sect 5.2.3
>>>   Is the message that contains this Information Element included in the
>>>   count?? May want to make that clear for better interoperability.
>>>   Same for some of the other exportXXXCounters
>>
>> INFO-AD#1:
>> These IEs are specified to be compatible with NetFlow v9.
>> I'm checking with my co-authors from Cisco which alternative
>> was chosen for NF v9.
>>
>> When I have this information, I will remove the ambiguity
>> from the descriptions of IEs
>>    # 40 exportedOctetTotalCount
>>    # 41 exportedMessageTotalCount
>>    # 42 exportedFlowTotalCount
>>
>>> - sect 5.2.5
>>>   Text says: number of flow records
>>>   But in Units it says: flows
>>>   So what is it?
>>>   Same for sect 5.2.9
>>
>> INFO-AD#2:
>> This is another NF v9 compatible IE.  As above, I will check
>> and make sure that description and units are consistent.
>>
>>> - sect 5.2.8
>>>   Does the count include header octets?
>>
>> added clarification:
>>
>> OLD
>>   Description:
>>      The total number of octets in observed IP packets that the
>>      Metering Process did not process since the (re-)initialization of
>>      the Metering Process.
>> NEW
>>   Description:
>>      The total number of octets in observed IP packets (including the
>>      IP header) that the Metering Process did not process since the
>>      (re-)initialization of the Metering Process.
>>
>>> - sect 5.2.12
>>>   It is not clear/sopecific as to which bit is bit zero, bit one etc.
>>
>> I am not sure what is the problem here, but I tried to clarify
>> the description:
>>
>> OLD
>>   Description:
>>      This set of bit fields is used for marking the Information
>>      Elements of a Data Record that serve as Flow Key. Each bit
>>      represents an Information Element in the Data Record with the n-th
>>      bit representing the n-th Information Element.  A set bit with
>>      value 1 indicates that the corresponding Information element is a
>>      Flow Key of the reported Flow.  A value of 0 indicates that this
>>      is not the case.  ...
>> NEW
>>   Description:
>>      This set of bit fields is used for marking the Information
>>      Elements of a Data Record that serve as Flow Key. Each bit
>>      represents an Information Element in the Data Record with the n-th
>>      bit representing the n-th Information Element.  A bit set to value
>>      1 indicates that the corresponding Information element is a Flow
>>      Key of the reported Flow.  A bit set to value 0 indicates that
>>      this is not the case.
>>
>>> - Sect 5.2.3 and 5.2.5
>>>   Is it best to speak about Mask?
>>>   Or would speaking of (and naming it) PrefixLength be better?
>>
>> renamed sourceIPv4Mask to sourceIPv4PrefixLength
>> and sourceIPv6Mask to sourceIPv6PrefixLength
>>
>>> - Sect 5.6.3
>>>   I worry about the fact that there is discussion already about AS
>>> numbers
>>>   of 32-bit length. So are we future proof here?
>>>   In the MIB/SMI world we have made it a 32bit unsigned, see
>>>   InetAutonomousSystemNumber in RFC4001.
>>
>> INFO-AD#3:
>> change data type of
>>    # 16  bgpSourceAsNumber
>>    # 17  bgpDestinationAsNumber
>>    # 128 bgpNextAdjacentAsNumber
>>    # 129 bgpPrevAdjacentAsNumber
>> from unsigned16 to unsigned32.
>>
>>> - sect 5.6.9
>>>   How are new values of Labeltypes be added in the future?
>>>   last line in this section, remove "and IP addresses" ??
>>
>> INFO-AD#4:
>> I have no good answer on this comment. Does anyone else have?
>>
>>> - sect 5.8
>>>   Just for my understanding, why do you need all 4 levels
>>>   of granularity here (i.e. sec, milisec, microsec and nanosec)??
>>
>> For efficient reporting from probes with different precisions and for
>> applications with different precision requirements.
>>
>>> - sect 5.5.x
>>>   Would it be useful to add a line of text to explain how long
>>>   (how many minutes, months, years) each granularity allows
>>>   based on the underlying datatype?
>>
>> INFO-AD#5:
>> I will work on a text suggestion.  We avoid duplication if we put
>> this text to the data type descriptions in section 3.1.
>>
>>> - sect 5.9.11 to 5.9.14
>>>   I wondered if it makes sense to say some thing more about
>>>   "packet treatment". Like what sort of treatment? Any
>>>   reference to an RFC?
>>
>> We discussed this issue several times in the past, but did not
>> find a good solution for it.
>>
>>> - sect 5.10.2 speaks about flowInactiveTimeout while sect 5.10.3
>>>   speaks about idle timeout. Should you have flowIdleTimeout
>>>   instead of flowInactievTimeout for consistency?
>>
>> renamed flowInactiveTimeout to flowIdleTimeout.
>>
>>> - sect 5.10.11
>>>   Make it clear that the value is hex 00 (0 could be read
>>>   as decimal zero)
>>
>> OLD
>> 5.11.1.  paddingOctets
>>
>>   Description:
>>      The value of this Information Element is always 0.
>> NEW
>> 5.11.1.  paddingOctets
>>
>>   Description:
>>      The value of this Information Element is always a sequence of 0x00
>>      values.
>>
>>> - sect 6, page 69
>>>   I think I would make it MUST instead of SHOULD in 2nd
>>>   and 3rd para.
>>
>> These paragraphs are
>>
>>  "Names of new Information Elements SHOULD be chosen according to the
>>   naming conventions given in section 2.3.
>>
>>   For extensions, the type space defined in section 3 can be used.  If
>>   required, new data types can be added.  New data types SHOULD be
>>   defined in IETF standards track documents."
>>
>> For IE naming I think that a SHOULD is OK, because fully consistent IE
>> naming appears to be very difficult.  There might be situations where
>> deviations from a fixed scheme improve the readability and intuitive
>> understanding of IE semantics.  For example we inconsistently use "IPv4"
>> instead of "IpV4" in IE names, because several people did not like
>> "IpV4".
>>
>> For new data types I agree.  Changed SHOULD to MUST.
>>
>>> - sect 7
>>>   first para, pls add a ptr to the list of Information
>>>   Element Identifiers that need to be recorded as the
>>>   initially assigned values for this registry.
>>>   I guess you need to point them to sect 4.
>>>   I doubt it is clear to IANA though what exactly to record
>>>   from that section. You can check directly with iana to
>>>   ask if things are clear or not and if not to work out
>>>   text with them that they understand.
>>
>> I tried to address this comment:
>> OLD
>> 7.  IANA Considerations
>>
>>   This documents defines an initial set of IPFIX Information Elements.
>>   For extending them in the future, IANA needs to create a new registry
>>   for IPFIX Information Element identifiers.
>>
>>   New assignments for IPFIX Information Elements will be administered
>>   by IANA, on a First Come First Served basis [RFC2434], subject to
>>   Expert Review [RFC2434], i.e. review by one of a group of experts
>>   designated by an IETF Operations and Management Area Director.  The
>>   group of experts must double check the Information Elements
>>   definitions with already defined Information Elements for
>>   completeness, accuracy, redundancy, and correct naming following the
>>   naming conventions in section 2.3.  Those experts will initially be
>>   drawn from the Working Group Chairs and document editors of the IPFIX
>>   and PSAMP Working Groups.
>>
>>   Appendix B defines an XML schema which may be used to create
>>   consistent machine readable extensions to the IPFIX information
>>   model.  This schema introduces a new namespace, which will be
>>   assigned by IANA according to RFC 3688.  Currently the name space for
>>   this schema is identified as http://www.ietf.org/ipfix.
>> NEW
>> 7.  IANA Considerations
>>
>>   This document specifies an initial set of IPFIX Information Elements.
>>   The list of these Information Elements with their identifiers is
>>   given in section 4.  IANA needs to create a new registry for IPFIX
>>   Information Element identifiers and fill it with the initial list in
>>   section 4.
>>
>>   New assignments for IPFIX Information Elements will be administered
>>   by IANA, on a First Come First Served basis [RFC2434], subject to
>>   Expert Review [RFC2434], i.e. review by one of a group of experts
>>   designated by an IETF Operations and Management Area Director.  The
>>   group of experts must double check the Information Elements
>>   definitions with already defined Information Elements for
>>   completeness, accuracy, redundancy, and correct naming following the
>>   naming conventions in section 2.3.  The specification of new IPFIX
>>   Information Elements MUST use the template specified in section 2.1
>>   and MUST be published using a well established and persistent
>>   publication medium.  The experts will initially be drawn from the
>>   Working Group Chairs and document editors of the IPFIX and PSAMP
>>   Working Groups.
>>
>>   Appendix B defines an XML schema which may be used to create
>>   consistent machine readable extensions to the IPFIX information
>>
>>>   I wonder if it would not be much better to have new
>>>   Information Elements require a Standards Track action.
>>>   I think that ensure much better review and evaluation
>>>   and certainly ensure well-documented registrations.
>>
>> We discussed the issue several times and concluded that this
>> procedure would be too time consuming and too slow.
>>
>>>   In any event, if you do do FCFS with expert review,
>>>   then I would
>>>   - require proper documentation to be publicly available
>>>   - maybe setup some sort of template that MUST be filled
>>>     out and approved to request registration.
>>
>> I added these two requirements to the new version of section 7
>> that you find above.
>>
>>>   You speak about an Appendix B as having a schema/example
>>>   on how to extend. It is however (I think) the Schema
>>>   for the currently assigned values.
>>
>> INFO-AD#6:
>> Yes, but it should also be used for extensions.  However, I
>> still need to investigate the XML schema issues that you posted
>> in a different email.  I will come back to this issue, when
>> the XML schema issue is closed.
>>
>>> - Sect 8.
>>>   I am pretty sure that the Security ADs will want to see
>>>   more detail here. They probably want to understand which
>>>   Information Elements contain sensitive data (and why it
>>>   is sensitive) or privacy sensitive data (and why so).
>>>   Probably similar to why they want to see that a MIB
>>>   document lists the objects that are sensitive and
>>>   why so and what the risks are if the data gets
>>>   intercepted.
>>
>> INFO-AD#7:
>> Let's come back to this after the security AD review.
>>
>>> - Appendix A and B
>>>   I am a bit confused when I read as title
>>>   "Formal Specification..." and then in the first para
>>>   I read that it is informational and not normative.
>>>
>>>   If it is a "formal machine readable spec.." is it then not
>>>   intended as input to tools, code-generators, data-structure
>>>   generators and such? In that case I would be very worried
>>>   if no this schema but the text earlier in the document
>>>   is normative and authoritative.
>>
>> It is not a formal specification. But it is machine readable
>> and intended as input to tools.  In one of the many passed
>> IPFIX sessions and on the mailing list we discussed the issue
>> and concluded that the text in section 5, which is generated
>> from the appendix with a tool would be normative, because this
>> is human readable.
>>
>>>   Anyway, I asked an APPS AD if he could check the "formal"
>>>   machine readable schema, but he does not recognize it as
>>>   a schema that can be checked by any of his tools. So
>>>   what is it? How can we (or anyone) check it for correctness?
>>
>> We got this review in a separate email.
>> Issues raised will be addressed in a reply to it.
>>
>>> administrative/bureaucracy/nits/spelling:
>>>
>>> - sect 5.10.4
>>>
>>>   "bewtween in time" in first sentence ??
>>
>> fixed.
>>
>>>   same in sect 5.10.5
>>
>> fixed.
>>
>>> - 3rd para in sect 1. I suspect that the ptrs to the various sections
>>>   do not completely match with the actual content claimed to be
>>>   in those sections. Specifically, the ptrs to 4 and 5 should probably
>>>   be 5 and 6 ??
>>
>> fixed.
>>
>>> - I see that you use MUST (i.e. rfc2119 type) language and
>>>   so there MUST be a normative citation/reference to RFC2119.
>>
>> added.
>>
>>> - problems with references/citations.
>>>   Note that my tool may give false warnings, so just check
>>>   them.
>>
>> In most of the cases below we cited "see RFC XXXX" in the
>> reference section.  I replaced all these references with
>> "see RFC XXXX [RFCXXXX]".
>>
>>>   !! Missing citation for Informative reference:
>>>   P071 L006:    [IEEE.802-11.1999]
>>>
>>>   !! Missing citation for Informative reference:
>>>   P071 L015:    [IEEE.802-3.2002]
>>>
>>>   !! Missing citation for Informative reference:
>>>   P071 L023:    [IEEE.P802-1Q.2003]
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L026:    [RFC2460]  Deering, S. and R. Hinden, "Internet
>>> Protocol, Version 6
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L029:    [RFC2463]  Conta, A. and S. Deering, "Internet
>>> Control Message
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L033:    [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs",
>>> RFC 2547,
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L036:    [RFC2629]  Rose, M., "Writing I-Ds and RFCs using
>>> XML", RFC 2629,
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L039:    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The
>>> Interfaces Group
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L042:    [RFC2960]  Stewart, R., Xie, Q., Morneault, K.,
>>> Sharp, C.,
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L047:    [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon,
>>> "Multiprotocol
>>>
>>>   !! Missing citation for Informative reference:
>>>   P072 L050:    [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G.,
>>> Rekhter, Y.,
>>>
>>>   !! Missing citation for Informative reference:
>>>   P073 L006:    [RFC3036]  Andersson, L., Doolan, P., Feldman, N.,
>>> Fredette, A., and
>>>
>>>   !! Missing citation for Informative reference:
>>>   P073 L012:    [RFC3260]  Grossman, D., "New Terminology and
>>> Clarifications for
>>
>> The three references below are not cited. removed them.
>>
>>>   !! Missing citation for Informative reference:
>>>   P073 L015:    [RFC3667]  Bradner, S., "IETF Rights in
>>> Contributions", RFC 3667,
>>>
>>>   !! Missing citation for Informative reference:
>>>   P073 L018:    [RFC3668]  Bradner, S., "Intellectual Property Rights
>>> in IETF
>>>
>>>   !! Missing citation for Informative reference:
>>>   P073 L021:    [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S.
>>> Zander,
>>>
>>> --
>>> 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/
>>>
>>
>>
>>
>> --
>> 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/
>
>

--
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: Wed, 24 May 2006 10:30:44 +0200

Juergen,
> Would this be worth the effort?
Do we have another solution?

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 25 May 2006 16:26:14 +0200

Benoit,

> 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.
sub-issue 2: Shall we add a value for known but not encoded types, for
             example, by adding  "0x06 other label types"?
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

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 26 May 2006 10:35:43 +0900

Hello,

I'm sorry to interrupt your discussion.

On Thu, 25 May 2006 16:26:14 +0200
>              MPLS manaement systems do not find this information useful.

I have lightly checked relationship between IPFIX informtion element and MPLS-MIB.
I couldn't find  such a MPLS label type object from MPLS-MIB.

But, in my opinion, it is useful information that we can find which MIB 
modules should be selected when we collect other information from MIB.

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.

Thanks,
Atsushi KOBAYASHI

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 26 May 2006 04:57:42 +0200

Dear Kobayashi-san,

> I'm sorry to interrupt your discussion.

You are very welcome.

> I couldn't find  such a MPLS label type object from MPLS-MIB.

Thank you for this investigation.

> 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

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 26 May 2006 13:28:36 +0900

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. 

Thanks,
Atsushi KOBAYASHI

---