Subject: RE: ILM mappings

From: Shahram Davari <[email-masked]>
Date: Mon, 8 May 2000 10:52:34 -0700

Hi Eric,
 
There are two scenarios that a single label may correspond to multiple
NHLFEs:
 
1) Some part of an LSP is E-LSP and another part is L-LSP
2) In case of Multicast.
 
Regards,
Shahram Davari 
Product Research 
PMC-Sierra Inc. 
555 Legget drive, 
Suit 834, Tower B, 
Ottawa, ON K2K 2X3, Canada 
Phone: +1 (613) 271-4018 
Fax  : +1 (613) 271-7007 

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Monday, May 08, 2000 12:51 PM
To: 'Trilok Chand'
Cc: [email-masked]
Subject: RE: ILM mappings

TrilokChand,
 
    An interesting question.  How did there get to be multiple
NHLFEs for a single incoming label?  Suspending disbelief
on this for a moment, however, and supposing there was a
reason for this to happen - the implementer must have had
some plan for demultiplexing the single label to determine
which NHLFE would be used.  One way might be to pop the
label and look at what comes after it - but a pop instruction
should be a single NHLFE (with - in this case - a next hop 
of "self").  Is there a useful application for this scenario?
 
    It seems to me that there would not be multiple NHLFE
entries for a single label as this will defeat the purpose for 
having a label.  But, even if there was a reason to do this,
the implementation that causes this to happen is the same
implementation that has to deal with the outcome.
 
    If you shoot yourself in the foot, it will hurt. :-)
 
--
Eric Gray

-----Original Message-----
From: Trilok Chand [mailto:[email-masked]]
Sent: Monday, May 08, 2000 3:25 AM
To: [email-masked]
Subject: ILM mappings

Hi,
        Can anybody tell where can i get information about choosing an ILM
mapping when there are multiple NHLFEs existing for an incoming label? 
 
Thanks in advance,
TrilokChand

---

From: ksreeni <[email-masked]>
Date: Tue, 09 May 2000 09:43:42 +0530

Hi Sharam,
                The first scenario you mentioned is diffserv supported LSP. In
the constraint based routing an LSR can maintain more than one LSP ( more than
one NHLFE ) for backup path . This is also one more case we can consider.

Sreeni.

---

From: Eric Gray <[email-masked]>
Date: Mon, 08 May 2000 22:07:45 -0700

Sreeni,

    To save someone else the trouble of pointing it out,
the architecture draft specifically mentions load balancing
as an application for more than one NHLFE.  You could
stretch a point and say that - when using liberal retention
- you have a veritable horde of NHLFEs for each ILM.
This assumes that you actually store an entire NHLFE
for each redundant Label Mapping (rather than just the
peer-label-FEC tuple) - but this is the same assumption
made in the redundant path example you mentioned.

    So you have multicast, multipath, E-LSP DiffServ,
redundancy and possibly other uses for having more
than one NHLFE for any given ILM.  The point is that
you would need to ensure - within your implementation -
that the LSR is able to determine what NHLFE is to be
used for any ILM.

    The architecture draft punts on how this is to be done,
but the only case I can come up with where the LSR may
not be able to correctly determine which NHLFE to pick
is the case where the implementation allows more than one
NHLFE to be associated with a single ILM (for example,
via configuration) with out requiring a context within which
to interpret this association (e.g. - load balancing, multicast,
redundancy, etc.).

    This is probably a mildly pathological case.  Even in this
case, you can simply document what the implementation
will do (since it must chose exactly one NHLFE for every
individual packet) and let the user figure out whether or not
that is what they want to happen.  Maybe the implementation
always picks the first one configured, maybe it picks the one
associated with the lowest interface ID or maybe it round
robins all associated NHLFEs.  In other cases mentioned
so far, you won't get to the point where you have more than
one NHLFE per ILM without being able to deal with it.

    So the question is an interesting one and it still comes down
to "how did there get to be multiple NHLFEs for a single
incoming label?"  And the discussion comes full circle and I
sit out the next few dances.

--
Eric Gray

---

From: "Steven Wright" <[email-masked]>
Date: Wed, 17 May 2000 08:25:02 -0400

Eric,Sreeni,
While the architecture draft does mention load balance as an example
application of multiple NHLFEs, this seems more of an aside than a
specification. As Eric notes the Architecture spec does not specify how to
do this.
If we leave multicast and Load balance as both applications that use this, I
think we are confusing the semantics of this table. It seems to me that a
replicated entry in the NHLFE corresponds to replication i.e.. multicast,
but not to load balance, which perhaps should be treated in other ways.
Does anyone know whether there was extensive discussion on this by the
architecture team ?
regards
Steven Wright

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Eric Gray
> Sent: Tuesday, May 09, 2000 1:08 AM
> To: ksreeni
> Cc: Shahram Davari; mpls
> Subject: Re: ILM mappings
>
>
> Sreeni,
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 17 May 2000 06:21:43 -0700

Steven,

    Oh dear, must be my turn again. :-)

    Multiple NHLFEs for a single ILM does not necessarily
mean that the entries are replicated.  They could be spares
or alternatives.

    I guess that one reason why the question of what to do
when there are multiple NHLFEs comes up is based on an
assumption that the implementation just sort of woke up
and found them there.  I can't say that this is necessarily a
bad assumption.

    So I think the answer has to be that there is an implied
field in each NHLFE that defines the action to be taken if
the NHLFE is one of many.  That does not mean that a
specific implementation has to do it that way.

    If you assume that an NHLFE cannot be created without
some value being plugged into this implied field, then the
ambiguity is diminished, right?  However, it's not so simple
that the ambiguity goes away with just this piece.  What do
you do if the value in this implied field is not consistent for
all NHLFE matched by any particular ILM?

    Stuff that helps is that there are other ways to determine
what to do.  For example, the encapsulation draft defines
specific code points to be used for unicast and multicast for
PPP and Ethernet.  Frame Relay and ATM assume that labels
are assigned such that unicast and multicast use distinct labels
(implying that ILM to NHLFE mappings for ATM/FR cannot
have unicast/multicast ambiguity, further implying that the
implementation must enforce this restriction).  Thus, at least
the unicast/multicast issue was finessed some time back.

    The implementation can work out what to do in some of
the other cases, but not all of them.  So, an implementation
either has a means to resolve ambiguous ILM to NHLFE
mappings, it explicitly prevents them from being created or
it is headed for a nervous break-down.

--
Eric Gray

---

From: "Steven Wright" <[email-masked]>
Date: Wed, 17 May 2000 09:35:10 -0400

My turn 8^}
I agree multiple NHLFEs is somewhat unusual.
I agree the router can find a way to resolve the ambiguity, but that was not
my concern.
I have two questions...
1)
I think the netwok management must be able to understand what is happening
in this case and this implies that the "implicit" NHLFE entry should be made
explicit in some device MIB.If this is standard behavior then this should be
a standard MIB.

2)Even though the router may be constructed do it this way, is it the right
thing to do? Was there a rationale for the architecture team to mix
replication and load balancing in this way ? I think there are other
approaches for load balancing that are more intuitive and avoid having these
multiple NHLFE entries in the first place...

regards
Steven Wright

> From: Eric Gray [mailto:[email-masked]]
> Sent: Wednesday, May 17, 2000 9:22 AM
> To: Steven Wright
> Cc: [email-masked]; Shahram Davari; MPLS List