Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label

[Eric Rosen <[e-mail]>]

Mach> My point is that the distribution mechanisms should be defined in
Mach> separate documents

I don't think anyone is really concerned right now with the number of
documents used to define the "source label" mechanisms.  The issue at hand
is whether the "source label" proposal is architecturally sound.  Any
proposal that uses scoped identifiers has to provide mechanisms that
prevent the identifiers from leaking out of their intended scope, either via
the control plane or the data plane.  Right now there is no draft or set of
drafts that we can look at to see how the scoping is enforced.  The
source-label draft is just one piece of the architecture, and I don't think
it can be accepted until we can determine whether the architecture can be
completed.  

If one looks at the two proposed distribution mechanisms for which there are
internet drafts (draft-chen-isis-source-label and
draft-chen-ospf-source-label), we see that these two proposals only
distribute the labels within a single IGP domain.  Since the scope of a
source label is not restricted to a single IGP domain, we can conclude that
these two proposals are not, by themselves, adequate.

The drafts also don't seem to have any procedures for dealing with the case
where two nodes advertise the same source label.

Mach> There may need other solutions (e.g., BGP extensions) for the
Mach> distribution in that case. This should be discussed when we start to
Mach> define the distribution mechanisms.

I think we need to see the proposal for the BGP extensions before the
source-label draft can be considered.  That is, I don't think the WG should
accept the SL draft until some progress has been made in defining the
distribution mechanisms.

Xiaohu> the SL advertisement could be done by a centralized mapping server

Sure, one could imagine a provisioning system that knows exactly which
egress LSRs need to know the source labels for which ingress LSRs, and would
provision the LSR accordingly.  However, unless the draft is going to say
that source labels MUST NOT be used unless there is such provisioning
system, this doesn't really help.  Also, this doesn't address the issue of
source labels in the data plane leaking outside the domain.

Eric> The ingress would have know, not only that the egress is capable of
Eric> processing the source label, but that the egress will interpret the
Eric> source label in the proper scope.  The draft doesn't address the issue
Eric> of how to ensure that ingress and egress agree on the intended scope
Eric> of the label.

Mach> For single domain case, the SLC will be only exchanged among the LSRs
Mach> within the domain, when the ingress knows the egress can support SLC,
Mach> it implicit indicates that the egress will interpret the SL in the
Mach> same scope of itself.

Mach> Actually, even for multiple domains, it is still the case, since SL
Mach> will be used across domains, the SL space should be shared by the
Mach> domains.

The question is, how does the ingress LSR know that the egress LSR is in the
same domain, or in a domain that shares the same SL space?  I think you're
assuming that the capability advertisement from the egress will not cross
the domain boundary.  Given that assumption, if an ingress LSR sees an SL
capability advertisement from an egress LSR, the ingress could assume that
the egress is in the same domain.  However, the SLC signaling mechanisms
described in the draft do not prevent the SL Capability signal from crossing
a domain boundary.  On the contrary, the mechanisms described in the draft
will cause the SLC to be signaled from egress to ingress with no regard for
domain boundaries.

Consider, for instance, the LDP extensions.  From section 6.1.1:

   "If all the advertised Mappings for F include the SLC TLV, then X
    MUST advertise its Mapping for F with the SLC TLV."

This will cause the SLC to go from egress to ingress, with no regard for
domain boundaries.   Perhaps the above should say "MAY advertise", and
should have some discussion of policy.

Section 6.1.2 proposes a BGP path attribute to signal the SL Capability:

    "When Border Gateway Protocol (BGP) [RFC4271] is used for distributing
    Network Layer Reachability Information (NLRI) as described in, for
    example, [RFC3107], [RFC4364], the BGP UPDATE message may include the
    SLC attribute as part of the Path Attributes.  This is an optional,
    transitive BGP attribute of value TBD3.  The inclusion of this attribute
    with an NLRI indicates that the advertising BGP router can process
    Source Labels as an egress LSR for all routes in that NLRI.

    ...

    Suppose a BGP speaker T receives an UPDATE U with the SLC attribute.  T
    has two choices.  T can simply re-advertise U with the SLC attribute if
    either of the following is true:

    B1: T does not change the NEXT_HOP attribute OR

    B2: T simply swaps labels without popping the entire label stack and
    processing the payload below."

Note that if the SLC attribute is an optional transitive attribute, then if
T does not understand this attribute, T will pass it along even if
conditions B1 and B2 do not hold.  (Perhaps the attribute needs to be
non-transitive.)

B2 is a little hard to understand.  Let P be the prefix in the NLRI of
update U.  I think the intention is that the SLC attribute be left on by T
if each of T's installed routes to P has the SLC attribute.  (B2 as written
seems to be about the data plane, but the context of this section is the
control plane.)

Even if B1 does hold, it may still be incorrect for router T to pass along the
SLC.  For example, suppose the data path from R1 to R2 is as follows:

      R1---ASBR1---ASBR2---R2

but suppose that R1 and R2 exchange VPN routes through a different path:

      R1---T1---T2---R2

where T1 and T2 aren't in the data path at all.  This could occur in an
"option C" type of interconnect. (RFC4364 section 10 option c.)  Suppose
that R1 and R2 are in different domains.  T1 and T2 would leave the next hop
unchanged.  When R1 has data to send to P, it would find R2 to be the next
hop, and then would do recursive route resolution to find that ASBR1 is its
next hop to R2.  In this scenario, R1's route to P would have the SLC
attribute, but R2 would not properly interpret R1's source label.

To make this work at all, you'd have to mandate that the SLC attribute
be attached to a route that travels along the data path (i.e., goes through
the ASBRs), and there would have to be policy at the ASBRs that strips off
the SLC if the ASBRs are at a domain boundary.  The proper behavior when
recursive route resolution is done would also have to be specified.

I'm having some trouble understanding the following paragraph from the draft:

   "However, if T changes the NEXT_HOP attribute for U and in the data plane
   pops the entire label stack to process the payload, T MAY include an SLC
   attribute for UPDATE U' if both of the following are true:"

   C1: T sets the NEXT_HOP attribute of U' to itself AND

   C2: T can process source labels.  Otherwise, T MUST remove the SLC
   attribute."
    
The term UPDATE U' doesn't appear to have been defined anywhere, though I
assume this is meant to be the update you get when you take Update U and
change the next hop.  Does the phrase "and in the data plane pops the entire
label stack to process the payload" mean that T is the egress LSR for the
prefix in U's NLRI?  If so, I don't think this entire paragraph is needed,
as T will be originating an Update for that prefix, and will include the SLC
attribute if necessary.

Eric> With no structure and no "domain identifier" in the source label, it
Eric> is very easy end up with non-unique labels within a domain.

Mach> There are also many non-structure cases, for example, Router ID,
Mach> Segment ID, VE ID of BGP VPLS
Mach> (http://tools.ietf.org/html/rfc4761#section-3.4.4 ), they work fine.

I have to admit that I have always regarded the VPLS VE IDs as a very bad
idea.  However, they do have a well-defined scope, namely a single VPLS.
RT-based mechanisms are used to constrain their distribution so that they
don't leak unintentionally into other VPLSes.  And the VE IDs do not appear
in the data packets.  These characteristics make it possible to get away
with an unstructured identifier space.  SLs don't seem to have a
well-defined scope, or a well-defined distribution mechanism, and they do
get carried by data packets.  Leakage out of the intended domain is thus
much more of a problem.  So I don't think SLs can be compared to VPLS VE
IDs.

With regard to router ids, if you've ever followed any of the vituperative
discussions that arise when router ids are discussed (e.g., when discussing
whether a 32-bit id is appropriate for an IPv6-based protocol), you'll see
that there are quite a few issues in the management of that numbering space.

Mach> In addition, even for your RT example, for L3VPN inter-AS scenario,
Mach> the RT has to be considered as single space, the domain identifier
Mach> does not help here.

RTs are structured so that a SP can allocate RT values that are globally
unique, not just unique within a domain.  So a "domain identifier" is not
needed.  I believe it is true that some SPs use  RTs that are not globally
unique, but that is a choice they have made for themselves, not a choice
that is forced upon them by the architecture.

Eric> One might also ask why there is a need to use a 20-bit label to
Eric> identify a node, instead of using some other format.

Mach> We are talking about identifying the source of an LSP, and the label
Mach> stack is the MPLS header and there are only labels, then seems that a
Mach> label to identify the ingress LSR is a naturally choice.

A couple of other possibilities come readily to mind:

- Treat the SLI as the bottom of the stack, and follow it with a 32-bit
  address (or even a 128-bit address) of the ingress.  (Or maybe use
  something based on the "generic associated channel".)

- Use two label stack entries and stuff a 32-bit "router id" in them,
  using more per-packet overhead but eliminating the need to manage a 20-bit
  domain-wide numbering space.

But perhaps the use case is easier to implement if the SL fits into the same
20 bits usually used for labels.  If so, that would be worth mentioning.

With regard to the name,

Xiaohu> What about IIL (Ingress Identification Label)?

I do like that better.

However, getting all the details right is going to be a lot of work,
especially for something that has only one use case, and a controversial one
at that.