From: John E Drake <jdrake@juniper.net>
To: "stbryant@cisco.com" <stbryant@cisco.com>,
 "draft-ietf-mpls-entropy-label@tools.ietf.org"
 <draft-ietf-mpls-entropy-label@tools.ietf.org>,
 "mpls@ietf.org" <mpls@ietf.org>
Date: Fri, 15 Jun 2012 04:32:34 -0700
Thread-Topic: [mpls] draft-ietf-mpls-entropy-label - OAM text
Thread-Index: Ac1GHrjga4hmISbAR7WG07/k7qYwogEVOfvQ
Message-ID: <5E893DB832F57341992548CDBB333163A5A6B05AC0@EMBX01-HQ.jnpr.net>
References: <4FD31147.7090506@cisco.com>
In-Reply-To: <4FD31147.7090506@cisco.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [mpls] draft-ietf-mpls-entropy-label - OAM text
Precedence: list

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 di=
rected to its authors.  Briefly, though, the operation is basically the sam=
e whether using multipath types 4 & 8 (destination IP address) or type 9 (l=
abel) and types 4 & 8 have been in production networks for quite some time.

Thanks,

John

Sent from my iPhone


>-----Original Message-----
>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
>Stewart Bryant
>Sent: Saturday, June 09, 2012 2:03 AM
>To: draft-ietf-mpls-entropy-label@tools.ietf.org; mpls@ietf.org
>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
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls