Subject: RE: suggested added text for multipath in draft-ietf-mpls-lsp-pin g-01

From: [email-masked]
Date: Wed, 8 Jan 2003 21:18:00 -0000

Dave, 1 minor remark below.  regards, Neil
<snipped>
> > > - not clear why MP index is requried, downstream mapping 
> > would provide a
> > > specific label reference which could also be used. 
> > > Is there any time that MP index would not correspond 
> > directly to the offset
> > > in the downstream multipath mapping TLV.
> > 
> > The index is in case we invent new queries in the future or for some
> > reason want to ask for further information with a MIB (like
> > periodically asking for packet and byte counts).
> 
> So you are assuming that the local node will administrate a 
> path ingress
> identifier that will remain constant across load balancing 
> changes. Wouldn't
> it be simpler to use an I/F index or somthing else already 
> defined (and
> therefore could provide useful information to a management 
> system) rather
> than create a new value. I'll risk the flaming and suggest 
> the TTSI from
> 1711.
NH=> You are right to suggest this for sound technical reasons.  The source
identifier of an LSP should (though 'must' is more appropriate IMO) be an
invariant property of the user-plane and decoupled from how that LSP was
created (either in the control or management planes).  Currently, it seems
we have different source identifiers for LSPs that are dependent on the
signalling protocol that created them.  This creates disjoint MPLS networks,
ie a BGP4 LSP access point cannot be connected to a RSVP-TE LSP access
point, etc....and whilst this is OK per se, it means defects *between* such
LSPs are now not universally resolvable via a common source identifier.  You
may get flamed for suggesting using the TTSI, but the principle here is
actually very sound and should not attract such ridicule.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Jan 2003 21:32:56 -0500

In message <[email-masked]
> actually very sound and should not attract such ridicule.

Just currious.  Is the TTSI appropriate to handle multipath, which is
what we are talking about here?  At a midpoint there would be multiple
indices, each index representing one branch of the multipath at
midpoint.

In any case, TTSI should not be used because it created a completely
unnecessary tie to an ITU document.  Ifindex (and maybe TTSI) would
not be appropriate if the multipath split were in a proprietary link
bundle.

Curtis