The MPLS WG Archive

[Adrian Farrel <AF@datcon.co.uk>]

Hi again Tom.

I've given up with colours - too messy.

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

>If any of the signaling protocols can handle such an option,
>then we will extend the MIB to handle this. At present, none of
>the MPLS signaling protocols officially support this.

Ah but they do or have I missed a new version of the drafts?
Specifically, in draft-ietf-mpls-cr-ldp-03.txt CR-LDP allows this...

4.7.4. ER-Hop 4: LSPID

   The LSPID is used to identify the tunnel ingress point as the next
   hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an
   already established CR-LSP. It also allows for splicing the CR-LSP
   being established with an existing CR-LSP.

   If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may
   splice the CR-LSP of the incoming Label Request to the CR-LSP that
   currently exists with this LSPID.  This is useful, for example, at
   the point at which a Label Request used for local repair arrives at
   the next ER-Hop after the loosely specified CR-LSP segment.  Use of
   the LSPID Hop in this scenario eliminates the need for ER-Hops to
   keep the entire remaining ER-TLV at each LSR that is at either
   (upstream or downstream) end of a loosely specified CR-LSP segment
   as part of its state information. This is due to the fact that the
   upstream LSR needs only to keep the next ER-Hop and the LSPID and
   the downstream LSR needs only to keep the LSPID in order for each
   end to be able to recognize that the same LSP is being identified.

   If the LSPID Hop is not the last hop in an ER-TLV, the LSR must
   forward the remaining ER-TLV in a Label Request message, using the
   CR-LSP specified by the LSPID, to the LSR that is the CR-LSP's
   egress. That LSR will continue processing of the CR-LSP Label
   Request Message.  The result is a tunneled, or stacked, CR-LSP.

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

>The ARHopTable is captures the actual reservation, and is
>applicable to both signaling protocols.

I think I have missed something here.  We are still talking about version 03
of the draft aren't we?  In my copy the ARHopTable contains only the output
from the Recorded Route object.

So back to the question about recording the difference between requested
traffic parameters and actual reservations.

- Are you saying that the mplsTunnelResourceTable is updated
  to reflect the actual resources reserved?  This would
  intuitively be the job of mplsTrafficParamTable in the LSR
  MIB.
- If this is what you are saying then you will need to update
  most of the text which describes the movement of data from
  mplsTunnelResourceTable to mplsTrafficParamTable but not
  vice versa.
- Do you intend that sharing entries in mplsTunnelResourceTable 
  between rows in mplsTunnelTable reflects sharing TSpecs or 
  sharing real reservations?  These can be very different 
  matters in RSVP.

>>>>15. mplsTunnelXCIndex 
>We would prefer the following:
>       "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 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."

Fine. You have only removed the bit about who sets the field in the signaled
case from my text, right?

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