Subject: RE: MPLS TE MIB - Doubts

From: Adrian Farrel <[email-masked]>
Date: Mon, 15 May 2000 11:52:15 +0100

Hi Mani (again),

I'm sure Tom will want to comment again.

>1) Local Cookie, Remote Cookie. - How do I get this value, Do 
>I get this value by concatenating 
>   a) Extended Tunnel Id and Tunnel ID field values in case of 
>      RSVP path messages?
>   b) Ingress LSR Router ID and Local CRLS- Id in case of 
>      CRLDP Lbl Req messages?

Yes, the issues are
- how to "piggyback" the cookie on signaling so that 
  the remote end can re-assemble it
- what to do for CR-LSP

This is fundamentally an interop issue.
Both of your recommendations seem good to me.

>2) What is the significant difference between the MIB objects 
>"mplsTunnelOwner" and "mplsTunnelSignallingProto"? and how are
>these fields to be used?
>
>  a) If the field "mplsTunnelOwner" is set to snmp(1) and the 
>     "mplsTunnel SignallingProto" is set to "ldp" / "rsvp",
>     does this mean once the row status is made up, the tunnel
>     must be established using CRLDP or RSVP respectively?

That is my interpretation (except I would say once rowStatus and adminStatus
are made 'up').

'none' denotes that the tunnel is statically configured through the LSR MIB
at each hop and should not be signaled.

I think we should consider a new value of 'any' to allow the MPLS code to
choose a route through RSVP, CR-LDP or whatever based on its own routing
tables.

>  b) If the filed "mplsTunnelOwner" indicates "ldp" or "rsvp" 
>     does it mean that the tunnel is dynamically established 
>     using IGP (routing info) information? If so will the
>     "mplsTunnelSignallingProto" have value "ldp" or "rsvp" 
>     respectively?

I interpreted these settings of mplsTunnelOwner to refer to egress tunnels.
In this case mplsTunnelSignallingProto is somewhat redundant.

Regards,
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: Adrian Farrel <[email-masked]>
Date: Thu, 18 May 2000 21:22:13 +0100

Thanks Cheenu, Arun and Tom.
Good stuff.  Some responses (which appear to be in green for those following
the thread in html)
Adrian, 

Please see our comments to the questions you sent some time back about 
the TE MIB. (Your questions are in black.)  - blue?

3. LSPId explicit hop type 
   Is there any reason to prevent configuration of an explicit hop 
   of type LSPId?  I suggested some ASN.1 for this in an email to 
   Tom on 7th Jan. 

        If ldp is chosen to route the tunnel then we'll add this as 
        a choice for the hop type. 

I'm not quite sure what your answer means.  I think you're saying you'll add
the hop type but only allow it if the signaling protocol is flagged as
[CR-]LDP.  This would be great.

6. MPLS Tunnel Resource Table 
   This table is a welcome addition. 
   I believe you need to be very careful because of the differences 
   between forward and reverse resource reservation.  For example, 
   for an RSVP tunnel, what is configured here must be the TSpec.  
   Clearly, sharing TSpecs is useful from a configuration point of 
   view, but says nothing about sharing of resources which is 
   determined elsewhere in the network.  Is it your intention that 
   this table is updated on the reverse path? 

        - tunnels are unidirectional; so the issue of bidirectional     
                resource reservation does not arise 
It wasn't my intention to talk about bi-directional LSPs at this point
(although that is an interesting topic of conversation in this regard).
When I talk about forward and reverse reservation I am simply distinguishing
between CR-LDP where the resources are reserved as the Label_Request
traverses the network, and RSVP where the resources are (strictly speaking)
only reserved when the Resv travels back.  Thus the information in the MIB
row is far more likely to reflect the true reservation in CR-LDP than in
RSVP unless the table is updated by the protocol code on completion of LSP
setup to reflect the flowspec.
        - these objects are information provided by the one who wants to 
                set up the tunnels to the signaling protocol (if signaled); 
                how the signaling proto uses them is their business 
Well, true, but...
We normally give some guidance on the effect that the user can expect to see
when they set a certain set of values.
        - note: We shd add an OID pointer (as we did in the LSR MIB) which 
                can be used to point at either the resource table in the
MIB, 
                or your own extension. 
That would be a good idea.

7. MplsTunnelIndex 
   Although current MPLS tunnels signaling protocols only support 
   16 bits to identify a tunnel from a specific ingress, it may be 
   that some future protocol will allow a greater number of tunnels. 
   Would it be wise to prepare for this by allowing MplsTunnelIndex 
   to have a greater range? 

        We cannot. We can only support what is specified in the 
        protocols doc. 
I think you could (you already support some things that one of RSVP or
CR-LDP don't support).
I'm happy with you deciding that you don't see the need at the moment.

8. Cookies 
   These are defined as read-only. Do we need write access to 
   configure them for bi-directional tunnels? 

        Yes; make them writeable (or throw them out all together) 
Right!
So which way do we jump?  There is currently some interesting work going on
in the field of bi-directional tunnels, but I'd suggest that in the short
term cookies do provide a useful hook on which to hang b-directionality.

9. mplsTunnelHopTable 
   This is currently indexed by mplsTunnelIndex.  Does this mean that 
   different instances of a tunnel as defined by mplsTunnelInstance 
   cannot have different routes?  
    If you add mplsTunnelInstance as an index to the HopTable, it means 
   that each instance must have its own ER defined and cannot share the 
   definition for all instances of the same LSP. 

        Would could change the indexing of the hop table 
        to include a (hopListIndex, TunnelHopIndex) to allow the two 
        or more tunnelEntries to point to the same hopListEntry. We 
        could then point the tunnelTable to the new primary index. We 
        also need to make sure that the TunnelEntry has a poitner to the 
        tunnelARHopPtr so that the actual route (RRO) can be know. 
That sounds good. 

15. mplsTunnelXCIndex 
   It would be good to expand on the Description.  Explain that this 
   object is only writeable in conjunction with pre-existing entries 
   in the LSR MIB.  Say that in normal signaled operation this object 
   will be set by the LSR.  Explain the meaning of zero. 

        We'll see how to improve the description. 
How about...
       "This variable represents an index into the
        mplsXCTable. This table identifies the segments
        that compose this tunnel, their characteristics,
        and relationships to each other. 
        In the case where a signaling protocol is used
        to set up the tunnel, this field is set by the 
        MPLS code to reflect the row in the mplsXCTable
        that has been set up to describe the cross-
        connect for this LSP and SHOULD NOT be changed.
        In the case where the tunnel has been statically
        configured by writing to the tables in the LSR 
        MIB, this field MUST be set to indicate the 
        correct entry in the mplsXCTable."

Typographic 

mplsTunnelResourceInMaxRate etc. 
MplsBitRate is defined in the LSR MIB in 1,000 bits per second. 
The descriptions for these fields need updating.  Additionally, 
the UNITS tag is ood. 

        What do you mean by this sentence ("ood")? 
Sorry.  ood = out of date.
In other words, all of the UNITS definitions say "bits per second" and
should say "1,000s of bits per second".

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