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

From: "David Allan" <[email-masked]>
Date: Thu, 9 Jan 2003 09:43:09 -0500

Hi Curtis:

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

TTSI is an access point identifier, so it would work. Some folks wanted to
avoid having to request signalling changes by suggesting existing RSVP
fields COULD be used to populate TTSI at the egress (tunnel ID) and this has
resulted in a lot of confusion as to whether TTSI identified an access point
or a path. Each LSP ingress will have a unique TTSI.

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

Only suggestion I would make is that MPIndex should then be 32 bits, so that
folks that want to use the (albeit poorly named) LSP ID part of TTSI could
do so (and this would not require an explicit tie to any ITU documents). A
node administered access point identifier should be able to work even for
propreitary bundles.

cheers
Dave

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 09 Jan 2003 09:50:20 -0500

In message <[email-masked]>, "Da
> node administered access point identifier should be able to work even for

The intent was that it was an index indicating the Nth branch of the
multipath branch point.  N would typically ba a small integer and very
seldom would have to even approach 100.

Curtis