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 11:16:46 -0500

So what you are saying is that in your implementation you need counters
nested deeper than I/F index + outsegment.

OK, if we're going to tolerate all manners of proprietary implementations,
I'm still on the reuse page for MP index. Lets just make it 32 bits, and
make no further representations as to what you put in it.

cheers
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 11:08 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: suggested added text for multipath in
> draft-ietf-mpls-lsp-pin g-01 
> 
> 
> 
> In message 
> <[email-masked]>, "Da
> vid Allan" writes:
> > 
> > 
> > If I have I/F index, I also have the label value from the 
> downstream mapping
> > TLV so I can access counts at the label level. That's what 
> I had in mind
> > when suggesting IF index. 
> > 
> > cheers
> > Dave
> 
> 
> The neat thing about multipath is that if there are branch points,
> there are also merge points.  If there is more than one ingress, then
> it helps to be able to measure each independently.  A LSR can be both
> a merge point for a prior multipath split and a branch point.
> 
>       B   E	  For example: a minimal configuration in which
>      / \ / \	  D can be both a merge point and branch point if
>     A   D   G	  multipath is used.
>      \ / \ /
>       C   F
> 
> This goes along with the rule of thumb that "if you can count it
> create a MIB variable for it".  Some providers take the trouble to
> occasionally check that counters that can be cross checked are
> incrementing in a consistent manner.
> 
> Another really good example of both a merge point and a branch point
> is a router supporting proprietary link bundles (for example: Avici
> CompositeLink tm) in which that router has a bundle of oc192c on the
> incoming (composite link) interface and the outgoing (composite link)
> interface.  The ifindex gives the sum of the traffic.  To figure out
> the split you have to dig further.  [For example, Avici demo'd an 80
> Gb link of this type a few years ago made of 8 oc48c before anyone had
> oc192c working and now can bundle oc192c and mix interface speeds in a
> bundle.  MIB counters on the ifindex or ifindex plus outsegment give
> the sum of all of the physical interfaces].  More specific counters
> are good.  In an 8 link bundle, each of the 8 incoming physical
> interfaces gets 1/8 of the traffic and should split the traffic among
> the 8 out going physical interfaces.  If one stops working, 1/64 of
> the traffic will disappear.  A counter that is not incrementing at all
> points to the problem where one output side interface with 1/8 too
> little traffic is both not as obvious and doesn't point to the source
> of the problem.  If you just look at the insegment and outsegment MIBs
> (which sum the physical interface outsegment counters) then 1/64 of
> the traffic is missing which makes it a little harder to detect and
> diagnose.  The faster such a problem is identified the better.  Of
> course the router should not just happily sit there pitching traffic
> into a bit bucket, but ISPs don't want to just trust their supplier to
> do the right thing, they also want as many counters as they can get to
> verify it.
> 
> Curtis
> 
> 
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:[email-masked]]
> > > Sent: Thursday, January 09, 2003 10:04 AM
> > > To: Allan, David [CAR:NS00:EXCH]
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: suggested added text for multipath in
> > > draft-ietf-mpls-lsp-pin g-01 
> > > 
> > > 
> > > 
> > > In message 
> > > 
> <[email-masked]>, "Da
> > > vid Allan" writes:
> > > > Hi Curtis:
> > > > 
> > > > I gathered the intent, I'm just seeking to align MPIndex 
> > > with some other
> > > > node administered value (such as TTSI or IFIndex) so we do 
> > > not require
> > > > further changes to make the relevant stuff accessable via 
> > > MIBs or CLI
> > > > 
> > > > Dave
> > > 
> > > 
> > > The counter that tells you how much can in for Label L 
> and went out
> > > Path N is different from the counter that tells you how 
> much traffic
> > > went out interface I.  So you can't reuse MIB values and 
> get useful
> > > counters.
> > > 
> > > For example - It you expect a 50:50 split, its nice to 
> poll a MIB and
> > > see that the result of the hash is at least close.  It would also
> > > diagnose different problems.  You may see lots of traffic on the
> > > outbound interface, but if you see one of these smaller 
> counters stop
> > > incrementing then you know you have a problem.
> > > 
> > > Curtis
> > > 
> > > 
> > > > > -----Original Message-----
> > > > > From: Curtis Villamizar [mailto:[email-masked]]
> > > > > Sent: Thursday, January 09, 2003 9:50 AM
> > > > > To: Allan, David [CAR:NS00:EXCH]
> > > > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > > > Subject: Re: suggested added text for multipath in
> > > > > draft-ietf-mpls-lsp-pin g-01 
> > > > > 
> > > > > 
> > > > > 
> > > > > In message 
> > > > > 
> > > 
> <[email-masked]>, "Da
> > > > > vid Allan" writes:
> > > > > > 
> > > > > > 
> > > > > > 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
> > > > > 
> > > > > 
> > > > > 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
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 09 Jan 2003 13:49:19 -0500

In message <[email-masked]>, "Da
> make no further representations as to what you put in it.

Fine.  We'll make it 32 bits and make no indication of what to put in
it as long as the index is unique within the split.

Curtis