The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Kishan,

    The approach you describe below seems to reflect the discussion
about implicit peering in RFC 3031 fairly accurately.  However, there
are pieces missing.  Also note that this discussion seems to be the
last you see of the concept in the evolution of MPLS.

    The intent seem to have been to allow the routers at the edge of
an MPLS domain to advertise to other routers at the edge of the same
domain labels that help them to forward packets - but without scaling
problems associated with either distributing all of these labels at
the same hierarchical level, or explicitly peering with these other
routers.

    Using multiple hierarchical levels lets the edge LSR distribute a
single label that gets packets to it and extra labels that tell it how
to forward packets onward - instead of distributing separate labels for
each forwarding case.  This might (in theory) reduce the total number
of labels that have to be distributed in a domain by at least roughly
the average number of interfaces leaving the domain at each domain
egress router.

    Implicit peering eliminates 'overhead' associated with maintaining
per-peer state with large numbers of remote peers.  Instead, the edge
router only maintains a 'peer relationship' with an amorphous 'everyone
else'.  As discussed below, this is a problem with implicit peering.

    The concept is simple enough to implement at the LSR distributing
these labels.  That LSR simply distributes a label to its immediate
neighbors that it will interpret as 'look at the next label', and then
distributes more specific labels as 'attributes' of this label.  These
attributes are then distributed like you said except where they collide
with similar attributes for the same FEC(s), received from other peers.

    In theory, the concept is just as easy to implement at the ingress
LSR that elects to use these labels (one of a potentially large number
of 'implicit peers').  It simply stores both the label it receives from
an immediate neighbor and all of the label 'attributes' it received from
a corresponding remote peer.  A simplistic 'brute force' approach might
be to create 'label stacks' for all FECs for packets that are forwarded
into the MPLS domain.  But the ingress must be able to tell which stack
to associate with each packet it receives.

    Intermediate LSRs, however, pick up a little extra complexity.  All
intermediate LSRs will have to:

o    store both the labels and all attributes they receive from other
     intermediate LSRs or egress routers and
o    determine the resultant labels and attributes to propagate to all
     upstream peers based on labels and attributes received from each
     downstream peer.

The RFC says that the intermediate LSRs do not have to know about these
attributes, but they do have to store them.  This would not work - even
in theory - because each successive upstream LSR has to know what set
of attributes apply to any given label they receive from their local
peers. Otherwise, the ingress router would not be able to tell, from
the FEC alone, which 'label stack' to apply to any given packet. Hence,
each intermediate LSR needs to select the attributes associated with
its own next hop for the associated FEC in determining which attributes
to attach to labels it forwards to upstream peers.  Also, since it is
not necessarily possible to determine that a given egress router will
want to provide these attributes, their use would effectively impose a
downstream unsolicited distribution discipline - which could be a big
problem from some label distribution protocols.  Finally, note that a
requirement to distribute these labels and their attributes means that
this approach does not really reduce the number of labels that have to
be distributed.

    Even if it was acceptable to impose this additional complexity on
intermediate LSRs, there are issues.  One is security, because any LSR
receiving the combination of labels and attributes could elect to be
an ingress for the corresponding LSPs - but this could be dealt with if
the ingress LSR to a 'trust domain' doesn't further propagate attributes
(instead becoming an ingress for LSPs corresponding to these attributes).
Another is how to invalidate these label attributes once they have been
distributed - but this could be handled by re-distributing the implicit
NULL label as a label attribute for those hierarchical LSPs that are
being invalidated.  Finally, there is the issue that no existing label
distribution protocol supports this capability, possibly excepting
BGP-MPLS - which, in earlier iterations at least, allowed distribution
of 'label stacks'.

    I can't be sure, but I think that - for a number of reasons -
the concept of implicit peering has been shelved for what may turn
out to be the foreseeable future.  For example, even if you could use
BGP-MPLS to distribute labels in this fashion, a requirement that they
not be distributed beyond a single trust domain cripples this usage in
BGP.

--
Eric Gray

You wrote:

> Here is what I know/understood !!
>
> There are two ways to distribute labels between remote label
> distribution peers.
> One way is through explicit peering. The second way is through
> implicit peering. In implicit peering the labels between two remote
> label distribution peers are carry
> forwarded by the local label distribution peers.
>
> For example, consider four LSRs(A,B,C,D).Assume that A and B are
> remote label distribution peers and A,B,C,D are local label
> distribution peers.
>
> The LSP from A to D is of heirarchy-2.
> In implicit peering, D will distribute to C a Label(L1) with another
> label (L2) as attribute of L1. C will propagate this to B as Label L3
> with attribute L2.
> B will propagate this to A as Label L4 with attribute L2.
>
> A------B-------C-------D
>  +++++   +++++  ++++
>
> Finally when the a packet P is sent from A to D using the above LSP,
> the outgoing label stack at    A --> {L4,L2}
>                 B --> {L3,L2}
>                 C --> {L1,L2}
>
> Here you have to note that, if LDP is the Label Distribution Protocol
> being used,
> there exists no LDP session between A and D. Also LSR B and LSR C
> carry forward
> a label L2 which is of no interest to them.
>
> The same LSP can be set up using explicit peering, but it requires a
> LDP session
> between LSR A,LSR D and LSR B, LSR C need not know anything about
> label L2.
>
> Correct me If I missed anything ?
>
> -- Kishan
>
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf
> > Of Mareline
> > Sheldon
> > Sent: Monday, September 17, 2001 12:26 AM
> > To: mpls@UU.NET
> > Subject: Implicit Peering
> >
> >
> > Hi,
> > This concept is not very clear to me. In explicit peering a
> > LSR distributes
> > labels to a peer by sending label distribution protocol
> > messages which are
> > addressed to some explicit peer. So what is done in implict
> > peering. RFC
> > 3031 section 3.27 explains it but is really not clear to
> > me. Can anybody
> > please help me in this.
> >
> > ~Mary
> >
> >
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >