Subject: RE: draft-ietf-mpls-lsr-mib-02.txt nits

From: Adrian Farrel <[email-masked]>
Date: Mon, 20 Mar 2000 15:15:42 -0000

Tom,

>> 1. LSPID
>>   
>>   In previous mail exchanges I asked why the LSPID Textual
>>   Convention needed to allow 63 bytes.  You answered that
>>   this was to allow space for IPv6 addresses.
>>
>>   There are three points here.
>>   - Why would you put an address in the LSPID?  The address
>>     is a separate part of the cookie
>>   - IPv6 addresses don't need 63 bytes
>>   - The current protocols only allow exchange of a 2 byte
>>     LSPID.  
>   I believe that we were looking to be flexible enough to
>accommodate any possible label. All of the implementations I
>know of use much shorter labels. However, we did not wish to
>preclude any longer ones. The MPLS framework does not specify a
>size, it just states that, "A label is a short, fixed length, 
>locally significant identifier which is used to identify a FEC."
>Depending on what you define as "short", you could have 1 byte,
>or 64 bytes, but probably closer to the lower number. We have 
>not heard from anyone else pro/con on the size which we had 
>chosen, so we left it as is. 

The LSPID is not the label.
I  don't  think the framework mentions LSPID at all.  This is
something in the protocols where 2 bytes is the currently defined
maximum.  
I don't suppose this is a big issue - just pushing you to try to 
understand why 63 bytes.
 
>> 2. Performance Tables Discontinuity Timestamps
>>   
>>   We discussed this at some length before, but left the issue
>>   when I ran out of bandwidth.
>>   
>>   I was asking for a discontinuity timer for each performance 
>>   table so that it is possible to understand the scope of the 
>>   reported values.  You responded that the discontinuity timer
>>   in the interfaceTable provides sufficient information.
>>   
>>   This may be the case for the mplsInterfacePerfTable but I
>>   don't see how this applies to mplsInSegmentPerfTable and 
>>   mplsOutSegmentPerfTable.  Perhaps you could explain, or
>>   reconsider adding these timestamps.
>
>   There is such a discontinuity timer available from the
>ifTable which can be used for all tables related to an
>MPLS interface. 

And that discontinuity timer will clearly only apply at the level
of the entire interface.  How do I tell when the counters for a 
segment have been reset? 
        
>>3. DiffServ
>>   
>>   I believe the question of storing DiffServ information was
>>   raised on the list recently.  Do you have plans to add such
>>   information to the LSR MIB?

>     If you are referring to the EXP Bits discussion, 
>I think that we are currently of the position that they
>should be left as is in the MIB.

I am referring to the EXP bits and the signaling extensions to 
support draft-ietf-mpls-diff-ext-04.  This draft is on the verge of
last call and it is entirely appropriate that support be added to the
TE MIB and LSR MIB.

By left "as is" I take it that you mean "not supported".

Please be aware that if you don't add this support, implementers
will either add their own extensions (breaking compatibility) or
will be forced through the pain of a new draft to extend yours.
Is it so much pain to add this support? I have already provided 
ASN.1 for the TE MIB.

Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 20 Mar 2000 16:11:57 -0500

Hi Adrian,

         My comments are in blue.

> >>   this was to allow space for IPv6 addresses.
[snip]
>I don't suppose this is a big issue - just pushing you to try to

         Agreed. We will make it 4 bytes.

>of the entire interface.  How do I tell when the counters for a

         Agreed. We will add a discontinuity timer to the
different tables.

>Is it so much pain to add this support? I have already provided

         We cannot reference it due to the fact that it is not in
last call right now. We have asked for last call on our document
at this point, which would stall this process. Besides, this change
can be added in a later revision of the MIB. As Arun mentioned last
week, the currently incarnation of the MIB is nearly 2 years
old at this point and needs to be advanced. We feel that if we
wait for everything to get in, then it will never be finished.

         --Tom (Arun and Cheenu)