Subject: Re: Label Space Partitioning

From: [email-masked]
Date: Fri, 3 Sep 1999 14:33:39 +0800

If I have not misunderstood Makarand,
What he feels may be the following

Considering the network (Ethernet LAN) below
		
		|
		|-------------B------(FEC b)
		|
(FEC a)----A--------------|
		|
		|------------C-------(FEC c)
		|
		|

All the LSRs A, B and C are using Downstream unsolicited Adv method
Also all the LSRs use Platform-wide label space
A:0, B:0, C:0 are the LDP IDs

C advertises a label 'x' for FEC c to A
B also advertises a label 'x' for FEC b to A

Now A has a similar label but from different peers
So Makarand may be thinking that A's label space cannot accomodate
same label from different peers.

Again, Makarand correct me if I am wrong.

But if we quote a small text from LDP-Draft-5

"2.7. LDP Identifiers and Next Hop Addresses

   An LSR maintains learned labels in a Label Information Base (LIB).
   When operating in Downstream Unsolicited mode, the LIB entry for an
   address prefix associates a collection of (LDP Identifier, label)
   pairs with the prefix, one such pair for each peer advertising a
   label for the prefix."

I think <FEC c, [C:0, x]>
and <FEC b, [B;0, x]> storage
may solve the problem

Anyone, correct me if this does not solve the issue

cheers,
chetan

Original message follows:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Makarand, et al,

	What may be part of the confusion here is the
issue with unidirectionality when allocating labels.
One of the parameters recently added, for ATM and FR,
is 'directionality' - IOW, are labels depleted in each
direction, when they are assigned in one direction.

	This might seem to imply that labels are being
used in each direction.  This is simply not the case.
Whatever hardware or switch architecture issues there
may be that would cause the same label to be consumed
in each direction, consumption and use are NOT the same
thing.

	Consider a scenario in which some degree (any
amount is enough) of merging is going on.  Information 
about sources is lost at each merge point, thus it is
not possible to 'reverse route' traffic by taking some
advantage of the fact that some of the switches will
be setup for reverse flow across one link using labels
setup in the forward direction.  It is possible - via
normal routing - for a new LSP segment to be chosen
at each hop where there is a merge point, but it is not
very clear that this would be worth the trouble to
specify and it is fairly clear that it would not always
be supported.

	The fact that labels are depleted from the label
space of the upstream LSR peer - if it is 'unidirectional'
- every time that a label is provided to that LSR by a
downstream peer, only means that label might not be usable
for another peer.  Since - at least in current definitions
- the downstream peer is NOT allowed to use the reverse
label, it should not make any difference if the upstream
LSR were to issue that label to another peer (or has done
so already).

	Let's look at some scenarios and see if there is 
a problem.

         .-----. 1   4 .-----.
FEC q ___| A:0 |-------| B:0 |___ 
         |     |-------|     |    FEC r
         `-----' 2   3 `-----'

If both A and B advertised a per platform label space (by
using label space '0') and either A or B is unidirectional,
it is not possible that A may give a label for FEC q to B 
that B wants to give to A for FEC r.  This is because the
label allocation discipline with A or B unidirectional will
result in one always using odd labels and the other always
using even labels.  Since B is not able to give the label 
given to it by A, there would be no problem.

         .-----. 1   4 .-----.
FEC q ___| A:0 |-------| B:4 |___ 
         |     |-------| B:3 |    FEC r
         `-----' 2   3 `-----'

If only A advertises a per platform label space, there 
will be two sessions (A:0 <=> B:4 and A:0 <=> B:3).
In this case, A may give a label to B:4 for FEC q that
B:3 wants to give to A for FEC r.  This should NOT be a
problem, however, unless B:3 attempts to use the Label
that A gave to B:4, because the labels are associated 
with different interfaces.  From the protocol's point 
of view, these are different peers as well as different 
interfaces - so it would be incorrect for B to attempt
to use a label given to it by A's distribution to B:4
when forwarding packets on the interface associated 
with B:3.  In fact, this should not be allowed by the
implementation at A - even if it's not 'unidirectional'.
If either A or B is unidirectional, the label allocation
discipline again limits one to allocating odd labels and
the other even (the choice is based on comparison of the
LDP IDs of the two LSRs - which should produce the same
result unless B uses different addresses for the first
4 bytes of the LDP IDs)

         .-----. 1   3 .-----.
FEC q ___| A:0 |-------| B:# |--- FEC r
         |     |--.    `-----'
         `-----' 2 \   .-----.   
                    `--| C:# |--- FEC s
                     4 `-----'

If A advertises a per platform label space to B and C
- irrespective of the label spaces advertised by them
- it should not be important to either B or C which
labels have been distributed by C or B, respectively.
If A gives a label to B that C subsequently gives to
A as well, this should not be a problem.  The labels
apply to different interfaces and different peers.  In
other words, when A gives a label to B, this depletes
the label only for the interface associated with B.  
When C subsequently gives the same label to A, this 
depletes that label only for the interface associated
with C.

"Makarand Kulkarni (98307005)" wrote:
> 
> Hi Eric & all,
>         I am restating the problem here :
> 
> 
>                      B
>                     / 144.16.100.23 / 12
>                    /
>                   /
>            ---->A
>                   \
>                    \
>                     \
>                      C 144.16.100.21 / 12
> 
>         Here A has 2 peers. Let C initially do the address binding on a
> Label_Request made by A. Later A again makes a requests B for binding and
> B decides to bind same label (here 12), then what should A do  ? Eric,
> you pointed out that A and B keep each other informed about their free
> labels. But the problem is what happens if the non-overlapping label
> spaces are only the free ones ? Doesn't the situation sound like blocking
> in 2 - stage switching N/W's ? We can't bind a label even when we have
> lots of them free !
> 
> Regards
> Makarand