Subject: Some questions(label space, NHLFE, ldp peers for an address prefix)

From: Eric Miao <[email-masked]>
Date: Sun, 7 Jan 2001 14:33:13 +0800

Hi, everybody,

Here are some questions about MPLS-ARCH.
Can someone give me explanation?
Thanks in advance.

1. Label Space
==============

<draft-ietf-mpls-arch-07> 3.14. Scope and Uniqueness of Labels says

     In general, Rd can only tell whether it was Ru1 or Ru2 that put the
     particular label value L at the top of the label stack if the
     following conditions hold:

        - Ru1 and Ru2 are the only label distribution peers to which Rd
                              ~~~~
          distributed a binding of label value L, and
        - Ru1 and Ru2 are each directly connected to Rd via a point-to-
                                                              ~~~~~~~~~
          point interface.
          ~~~~~

     When these conditions hold, an LSR may use labels that have "per
     interface" scope, i.e., which are only unique per interface.  We may
     say that the LSR is using a "per-interface label space".  When these
     conditions do not hold, the labels must be unique over the LSR which
     has assigned them, and we may say that the LSR is using a "per-
     platform label space."

Why must Ru1 and Ru2 be only label distribution peers to which Rd distributed a
binding of label value L, and be each directly connected to Rd via a p2p interface?

2. NHLFE
========

<draft-ietf-mpls-arch-07> 3.10. The Next Hop Label Forwarding Entry (NHLFE) says

   the operation to perform on the packet's label stack; this is
   one of the following operations:
          a) replace the label at the top of the label stack with a
             specified new label
          b) pop the label stack
          c) replace the label at the top of the label stack with a
             specified new label, and then push one or more specified
             new labels onto the label stack.

Since there is FEC to NHLFE map (FTN) which determines what label an unlabeled packet
should be labeled with, why no  PUSH operation in NHLFE.

3. Label distribution peers for an address fix
==============================================

<draft-ietf-mpls-arch-07>   4.1.2.1. Label Distribution Peers for an Address Prefix says

   LSRs R1 and R2 are considered to be label distribution peers for
   address prefix X if and only if one of the following conditions   holds:
      1. R1's route to X is a route which it learned about via a
         particular instance of a particular IGP, and R2 is a neighbor
                    ~~~~~~~~
         of R1 in that instance of that IGP
      2. R1's route to X is a route which it learned about by some
         instance of routing algorithm A1, and that route is
                             ~~~~~~~~~~~~
         redistributed into an instance of routing algorithm A2, and R2
         ~~~~~~~~~~~~~
         is a neighbor of R1 in that instance of A2
      3. R1 is the receive endpoint of an LSP Tunnel that is within
         another LSP, and R2 is a transmit endpoint of that tunnel, and
         R1 and R2 are participants in a common instance of an IGP, and
                                         ~~~~~~~~~~~~~~~
         are in the same IGP area (if the IGP in question has areas),
                    ~~~~~~~~~~~~~ 
         and R1's route to X was learned via that IGP instance, or is
         redistributed by R1 into that IGP instance
         ~~~~~~~~~~~~~
      4. R1's route to X is a route which it learned about via BGP, and
         R2 is a BGP peer of R1

Above sentences are not easy to understand. Can someone make detailed and
clear description?(examples using RIP, OSPF, BGP)

            Eric Miao
            [email-masked]

---

From: Josue Kuri <[email-masked]>
Date: Mon, 8 Jan 2001 09:41:37 +0100 (MET)

Hi Eric,

> 1. Label Space

You can think about this otherwise:
Rd distributes label "L".
{Ru1, Ru2, Ru3...RuN} is a set of upstream LSRs (peers of Rd). If Rd
has distributed the SAME label value "L" to all the LSRs in the set, when
a packet with label "L" arrives to Rd, Rd can determine which LSR in the
set sent the packet based on the interface the packet came through. Note
that this is possible only if each LSR in the set is connected to Rd by a
DIFFERENT interface.

>              specified new label, and then push one or more specified
                                             ^^^^
> should be labeled with, why no  PUSH operation in NHLFE.

There is a push operation in (c).

Regards,

	Josue

---

From: Saurabh Shrivastava <[email-masked]>
Date: Mon, 08 Jan 2001 11:33:45 -0800

I think, it should be stated like this - the LSR should make sure that
when it recieves a packet, it can look at the label and the interface it
was received from and know what to do with packet unambiguously. That is
all. The standards should not enforce more rules.

Now it is upto the LSR to decide how it can make this unambiguous decision
- maybe with different labels/or with same labels on different interfaces/or LSR
maynot wish to distinguish packets coming from different Ru's (so that
the LSR in question has its job simplified)...

-- 

--------------------------------------------------------------------
  Wisdom has 2 parts:
         Having a lot to say, Not Saying Anything

 Saurabh Shrivastava         [email-masked]

 Electronics for Imaging     650.357.3820 (office-direct)
 http://www.efi.com/         650.592.2634 (residence)
--------------------------------------------------------------------

---

From: Josue Kuri <[email-masked]>
Date: Tue, 9 Jan 2001 09:31:53 +0100 (MET)

Hi Saurabh,

> the LSR in question has its job simplified)...

The statement in the draft just points out the _necessary_ conditions for
the label to be correctly interpreted (i.e., it is not enforcing
superfluous conditions). Stating the conditions differently to better
understand them doesn't change the content.

Regards,

	Josue

---

From: Ben Black <[email-masked]>
Date: Tue, 9 Jan 2001 01:09:43 -0800

> understand them doesn't change the content.

Actually, the draft says that the labels MUST be unique, it doesn't
merely state conditions.  I agree that the draft is overly restrictive
in this regard, but it seems rather likely that, once again, the draft
process will be railroaded and no improvements will be made.

Ben

---

From: Eric Rosen <[email-masked]>
Date: Tue, 09 Jan 2001 12:46:48 -0500

> when it receives a  packet, it can look at the label  and the interface it
> was received from and know what to do with packet unambiguously. 

I think that's what section 3.14 says.

> That is all. The standards should not enforce more rules. 

I don't see that any more rules are imposed by section 3.14. 

When this  draft was being actively  reviewed a couple of  years ago, people
seemed to  want a few more clues  about just what the  conditions were under
which the  same label value  could be used  to represent different  FECs, so
some additional clues were provided.