[mpls] draft-ietf-mpls-entropy-label - OAM text

[Stewart Bryant <[e-mail]>]

6. Operations, Administration, and Maintenance (OAM) and Entropy Labels

<snip>
    The LSP traceroute procedures of [RFC4379] allow an ingress LSR to
    obtain label ranges that can be used to send packets on every path to
    the egress LSR.

SB> I know this is what RFC4379 says, but I am concerned about
SB> how well this work in practical applications.
SB> What you are asking the LSR to do is to invert the hash and
SB> return the set of ranges that it will sent down each path.
SB> Depending on the hash this could be a very large response.
SB> In the pathological case this could be 10^6/(ECMP splits)
SB> returned values.

    It works by having ingress LSR sequentially ask the
    transit LSRs along a particular path to a given egress LSR to return
    a label range such that the inclusion of a label in that range in a
    packet will cause the replying transit LSR to send that packet out
    the egress interface for that path.

SB> Again help me to understand this. Depending on the hash and
SB> depolarization constants it seems to me that you could have
SB> to try all of the ranges returned from the first hop before
SB> you get to a value that causes the packet to go down the path
SB> you need to use in the last hop. In the pathological case
SB> (and remember the hash is not defined) that could require
SB> testing  10^6 label values.

    The ingress provides the label
    range returned by transit LSR N to transit LSR N + 1, which returns a
    label range which is less than or equal in span to the range provided
    to it.  This process iterates until the penultimate transit LSR
    replies to the ingress LSR with a label range that is acceptable to
    it and to all LSRs along path preceding it for forwarding a packet
    along the path.

SB> This is not clear to me, it depends on the hash. If the hash
SB> simply chops the label range up into ranges and allocates
SB> sequential groups, that would work. However the hash is not
SB> defined, and could be somewhat crypto like (indeed I would
SB> hope it was to extract maximum entropy from the labels
SB> which would tend to be systematically allocated). In the
SB> latter case, I am not sure that you could trace the path
SB> within the stability interval of the network.

    However, the LSP traceroute procedures do not specify where in the
    label stack the value from the label range is to be placed, whether
    deep packet inspection is allowed and if so, which keys and key
    values are to be used.

    This memo updates LSP traceroute by specifying that the value from
    the label range is to be placed in the entropy label.  Deep packet
    inspection is thus not necessary, although an LSR may use it,
    provided it do so consistently, i.e., if the label range to go to a
    given downstream LSR is computed with deep packet inspection, then
    the data path should use the same approach and the same keys.

SB> That would allow you to get a TR to go the way you wanted, although
SB> it is not obvious to me that you can easily map this to the path
SB> of a data packet, or an IP ping being carried between the two
SB> PEs.

    In order to have a BFD session on a given path, a value from the
    label range for that path should be used as the EL value for BFD
    packets sent on that path.

SB> Again I am concerned that you are making a number of assumptions
SB> here about the ECMP behaviour of the P routers and in
SB> particular their hash function and hash function input
SB> parameters.

It maybe that I am misunderstanding things here, but I am
not convinced that this provides the required functionality
when deployed across a network with the currently deployed
LSRs.

- Stewart