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

[John E Drake <[e-mail]>]

Stewart,

The Entropy Label draft does not change the behavior of RFC 4379, so these questions are really on the operation of RFC 4379 and should probably be directed to its authors.  Briefly, though, the operation is basically the same whether using multipath types 4 & 8 (destination IP address) or type 9 (label) and types 4 & 8 have been in production networks for quite some time.

Thanks,

John

Sent from my iPhone


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Stewart Bryant
>Sent: Saturday, June 09, 2012 2:03 AM
>To: [e-mail]; [e-mail]
>Subject: [mpls] draft-ietf-mpls-entropy-label - OAM text
>
>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 how well
>SB> this work in practical applications.
>SB> What you are asking the LSR to do is to invert the hash and return
>SB> 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) returned
>SB> 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 to try
>SB> all of the ranges returned from the first hop before you get to a
>SB> value that causes the packet to go down the path you need to use in
>SB> the last hop. In the pathological case (and remember the hash is not
>SB> defined) that could require 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 simply
>SB> chops the label range up into ranges and allocates sequential
>SB> groups, that would work. However the hash is not defined, and could
>SB> be somewhat crypto like (indeed I would hope it was to extract
>SB> maximum entropy from the labels which would tend to be
>SB> systematically allocated). In the latter case, I am not sure that
>SB> you could trace the path within the stability interval of the
>SB> 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 of
>SB> a data packet, or an IP ping being carried between the two 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 particular
>SB> their hash function and hash function input 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
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls