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

From: "David Allan" <[email-masked]>
Date: Wed, 8 Jan 2003 09:22:55 -0500

hi Curtis:

<snipped>
> > 
> > - hash key type 5 has an unclear role, presumably the TLV 
> length tells me
> > how many label entries to expect.
> 
> I just wanted to reserve a number for "unspecified" meaning either
> non-deterministic or proprietary (both are bad - imho).

Not multiple type 5, hash key 5 (no more labels)

> 
> > - hash key type 7 has an unclear role. Does no match imply 
> "cannot get there
> > from here...period". 
> 
> It has a role.  If a prior multipoint branch provided a bit map (or
> other indication of how to exercise the path that the packet traversed
> so far) none of the addresses specified as exercising the prior branch
> will exercise a specific branch at the current multipoint.

OK , so can't get there from here was a correct assumption.
> 
> > - 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.

<snip>

> > What would be best is if the downstream mapping TLV had a 
> field to indicate
> > the label transfer function. If I were to explicitly align 
> with what is
> > defined in the MIBs, this would best be expressed as a pop 
> count and a push
> > count.
> 
> I can't see a clear way to completely eliminate the risk of packets
> going off the end of the egress on a VPN.  All that can be done is
> recognize that that router is not MPLS-ping capable and omit the last
> packet if it is both the egress and the next hop in the prior mapping.
> 
> If you see a solution to this please speak up.

Agreed that it cannot be completely and authoritatively eliminated. However
if the downstream mapping TLV provided the stack push and pop counts, then
if an egress LSR where TTL expired implements LSP ping then the response to
the ping originator would provide it with sufficient information to know not
to try higher TTL values. If it does not implment PING, there is no response
and the originating node will probably try higher TTL values. IMHO this also
addresses the issue where an LSP enters a tunnel (which means subsequent TTL
values in uniform mode will return FEC errors) as the ping originator would
know that the TOP label where TTL expired was not associated with the FECs
in the Ping request.

> 
> I think I understand what you mean by the label transfer function, 

what stack operations are performed.

> but
> I don't see how it helps with the VPN egress problem.  The penultimate
> router either does a swap and passes the packet, or a pop if doing PHP
> and passed the packet. If the egress is MPLS-ping capable, then it
> doesn't forward the packet further and provides a Echo Reply.  If it
> is not MPLS-ping capable, it may forward the packet to the VPN.  Are
> you just suggesting that having the additional information would be
> useful?

Discussed above....

rgds
Dave

<snipped to end>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 09 Jan 2003 10:46:46 -0500

At 09:43 AM 1/9/2003 -0500, David Allan wrote:

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

         It is my recollection that the TTSI value as defined in Y.1711
is unusable due to its size. In short, it is too small to identify all
of the possibilities.

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

         I this it is a bad idea to explicit tie to the ITU-defined TTSI 
value. If it is
deemed that we really need some sort of ID, lets make up our own.

         --Tom

>A node administered access point identifier should be able to work even for
>propreitary bundles.
>
>cheers
>Dave

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto

http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X

---

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

Tom:

2**32 is sufficient for a node to enumerate the number of LSP ingresses it
supports (this provides for 2**12 label spaces), which is what it is
intended to do.

It is too small to enumerate the number of fields required to identify an
LSP in all current protocol instantiations, which is what it is not intended
to do.

No problem exists.

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 10:47 AM
> To: [email-masked]
> Subject: RE: suggested added text for multipath in
> draft-ietf-mpls-lsp-pin g-01 
> 
>