Subject: RE: MPLS TE MIB - Doubts

From: Cheenu Srinivasan <[email-masked]>
Date: Wed, 17 May 2000 15:32:31 -0400

Adrian,

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

1. Control of Notifications
   I regard it as important to allow a facility for the 
   Management Tool to disable notifications to save resources.
   In an email to Tom on 5th Jan I suggested some ASN.1 for two
   top level objects to achieve this.
   Do you have any objections to adding this function?
   Would you like me to resend you the ASN.1?

        That is fine. We will add these.

2. Support for configuring DiffServ LSPs
   draft-ietf-mpls-diff-ext is well progressed. I think it would
   be sensible to offer support for configuring E-LSPs and L-LSPs
   at the ingress. Do you agree?
   In the above-mentioned email to Tom, I suggested some ASN.1 to
   achieve this.  Would you like me to resend it?
   I suspect that the ASN.1 should be run past the authors of the
   diff-ext draft to check that it is in line with their 
   requirements.

	Similar objects are not supported in the LSR MIB for reasons we
	explained earlier.

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.

4. Non-use of ERO
   This is a bit philosophical :-Z
   If I know my egress but I have no requirement to specify an ER, I
   can set up just one hop showing a loose hop to the egress.
   How can the protocol code tell the difference between a request to
   use an ER object/TLV with a single hop, and a request to use no 
   ER object/TLV?

   Things that influence this are
   - is the route pinned?
   - do all of the LSRs on the route support ER?
   Clearly the protocol code can make a local policy decision on 
   whether to include the ER object/TLV based on this information. 
   Without appropriate configuration, it may be necessary (e.g. in 
   RSVP) to experiment by sending an ER and finding out if the LSRs
   on the path reject it.

   Would it be worth adding mplsTunnelEgress to the main TunnelTable
   thereby allowing the ER to be omitted?

	We don't want to replicate all the objects from the hop table
	in the tunnel table
	by allowing the last hop to be specified in the tunnel table
	itself. As the hope table stands, the tunnel endpoint is the
	last hop in the hop table. If there is only one hop (the last
	hop) for a particular tunnel, the signaling protocol can
	discover this and avoid sending the ERO object.

Questions/Clarifications

5. Make before break
   I think that the TunnelInstance object gives the facility for 
   controlling make before break, but I believe it would enhance the
   draft to add some explanation of how this field can be used.

        Sure.

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

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.

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)

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.

10. mplsTunnelHopTable
   The description says that you can specify the outgoing interface at 
   the tunnel ingress through the first hop of the ER.  Is this done
   using the IP address for the interface?

	You must specify the IP address. Perhaps the description
	needs a bit of updating?

Editorial

11. Example
   The example in section 7 needs updating in line with the changes
   to the tables.
   - IsMergeable, IsPersistent and LocalProtectInUse are no longer
     objects in the table.
   - TunnelIfIndex, LocalCookie and RemoteCookie are read-only so 
     shouldn't be modified here.
   - The example values for some of the objects are, perhaps, a 
     little unusual for some of the objects (e.g. TunnelDirection,
     RemoteCookie)
   - Would you expect to set the In and Out resource values for an
     'in' tunnel.

        Okay.

12. References
   The version numbers of the referenced drafts in DESCRIPTION fields
   in the MIB tables need updating.  I believe that any drafts 
   referenced in this way need to be flagged as "work in progress".

        Yes.

13. Terminology
   In a couple of places you have used ERLSP.  It's a bit pedantic,
   but I think we should refer to CRLSP (or perhaps just LSP) since 
   explicit routes don't have to be used.

	We just made an acronym out of "explicitly routed LSPs" from
	section 4.2.1 in the MPLS architecture doc.                

14. Textual Convention for IP Addresses
   I believe that there is a move to define a single textual convention 
   to cover IPv4 and IPv6 addresses.  The aim is to avoid the need for 
   each new MIB to define its own textual convention.  It might be worth 
   looking into this.

	We need to update these (just as we did for the LSR MIB).

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.

16. mplsTunnelSignallingProto
   Assuming future protocols will come along, would it be tidier to 
   set the value of 'other' higher to allow space for future extension?

	We can instead change the value of other to 2 and move ldp and
	rsvp up. That way newer protocols will be added after.

17. BITS
   I'm uneasy about the use of BITS for mplsTunnelSessionAttributes.
   Asides from whether this is standard in MIBs, I don't see the need.
   Why not keep the bit fields as separate objects?

	BITS is a standard object that has been used in other RFCs as
	well. For example, see RFC 2558.

18. Defaults for mplsTunnelSessionAttributes, 
   mplsTunnelInstancePriority and mplsTunnelAdminStatus

	ok.

19. MplsTunnelResourceEntry.
   Most of the objects describe mappings to the objects in the 
   mplsTSpecTable of the LSR MIB in terms of "copying".  I think you
   should relax your text a bit and just say that the values correspond
   to the values of the objects in the mplsTSpecTable.

	ok; we will change the wording to say "values are reflected"
	in the traffic param table (or any other table that they may
	choose to implement)

20. MplsTunnelARHopEntry
   I can see that mplsTunnelARHopAsNumber would be useful or 
   interesting to ISPs (perhaps they would edit the RRO on exit from
   their AS, but this is currently not supported by the signaling
   protocols.

	Since the RRO does not contain the AS number we shd remove
	it from this table (and leave it only in the hop table since
	the ERO supports it); see section 4.4.3, RSVP LSP Tunnels -
	05.txt

21. Notifications
   Add mplsTunnelInstance.

	OK.

Typographic

Section 7, paragraph 1, line two.
Insert "a" to read "create a loosely routed"

Formatting needs a little tidying up in places
- section 7, mplsTunnelIsPersistent
- section 8, Imports
- MplsTunnelEntry
- mplsTunnelOperStatus
- mplsTunnelResourceEntry
- mplsTunnelGroup

Integer options
It is usual to list these with each entry on a new line (e.g. 
mplsTunnelDirection).

mplsSessionAttributes.
- The Description refers to fastReroute, the bit is called
  ingressMayReroute
- localProtectionAvailable "det4ected"
- isPinned "Indicates" read "indicates"

mplsTunnelOwner.  Value 2 is called 'ldp'.  Risking the dangerous
political field, can I suggest that this should be 'crldp'.

mplsTunnelInstancePriority first line for "which" read "the"

mplsTunnelInstancePriority line 8 for "particular a" read "a
particular"

mplsTunnelResourceIndexNext/mplsTunnelResourceIndex
Decide on common syntax.  Zero should not be a valid value for
mplsTunnelResourceIndex

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

mplsTunnelHopStrictOrLoose  Delete "is" to read "this tunnel hop"

mplsTunnelARHopEntry "represents an currently"

	We will fix all these typos.

Thanks,

Cheenu, Arun, Tom

---

From: Paul Langille <[email-masked]>
Date: Thu, 18 May 2000 16:14:39 -0400

Hi Cheenu, Arun, and Tom.

> the TE MIB. (Your questions are in black.)

(A bunch of stuff removed)

>                 resource reservation does not arise

I am confused by the "tunnels are unidirectional" statement. (The
mplsTunnelDirection object specifies bi-directional as an option
("in-out(3)"). Am I missing some basic concept?
Did you mean to say that the Resource Tunnel is unidirectional in
nature? This is the way I interpreted the Resource Table so I have the
same concerns as Adrian in that I am curious about the reverse path.

    Thanks Paul

>                 can be used to point at either the resource table in
> the MIB,
>                 or your own extension.
>
> Thanks,
>
> Cheenu, Arun, Tom
>

--
Paul Langille                e-mail: [email-masked]
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824