Re: [PWE3] GAL above and below the PW label

[venkatesan mahalingam <[e-mail]>]

Hi,

>> > You don't want ECMP to hash on PW payload.  With CW and without
>> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP
>> > containing many PW.
>>
>> When the PW payload is IP, the hashing it for ECMP is useful (If the
>> payload is not IP then use CW). FAT-PW may not be present in all
>> deployments.
>
> I really don't know that any PW are carrying IP.  That was not in the
> survey.  L3VPN would be carrying IP.

Why are we very much concerned about the ECMP in MPLS-TP networks?
I think, as per the RFC-5960,

   Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on
   an MPLS-TP LSP.


Thanks,
Venkat.
Re: [PWE3] GAL above and below the PW label
------------------------------

   - *To*: curtis at occnc.com <[e-mail]>
   - *Subject*: Re: [PWE3] GAL above and below the PW label
   - *From*: Sriganesh Kini <sriganesh.kini at
ericsson.com<[e-mail]>
   >
   - *Date*: Thu, 31 Mar 2011 06:35:55 -0700
   - *Cc*: "pwe3 at ietf.org <[e-mail]>" <pwe3 at
ietf.org<[e-mail]>
   >
   - *Delivered-to*: pwe3 at core3.amsl.com <[e-mail]>
   - *Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com;
   s=gamma;
   h=domainkey-signature:mime-version:sender:in-reply-to:references:from
   :date:x-google-sender-auth:message-id:subject:to:cc:content-type
   :content-transfer-encoding; bh=A+vOatCHfOjZApN0E5yyinhuXIRZkYjTT7i6/+y5GRI=;
   b=OFt+lkWg+fovMGSRWve+7FsSjiqfq272VYgTC7TlwERM0yzysYgCBAsCB5m3odhT2N
   0EyO74FE/X6wILVxasY1LH8mMxD6D392XLS8GRfnqIIqGnJxX2Yf6PTJzDN+9wZtq6dd
   w/NhWavvVJM7iCESsjJF38Id8YgUq+z95WMxg=
   - *Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
   h=mime-version:sender:in-reply-to:references:from:date
   :x-google-sender-auth:message-id:subject:to:cc:content-type
   :content-transfer-encoding;
   b=CvmfIfuKmyWajzqum1g4zmHnattN67oLkrAHwMKMO45NU6eQ9B4lC0or/0Coow2naZ
   d5nqj+Ulcwo221mbSGynICRBrHshs8ppnDeGatxlk2Mu4ot75YHcVk39xPW1szv9WbUN
   A9+fjVEqqWZyJO4pcmbHXXv2ydnhHLn3r9dXk=
   - *In-reply-to*: <201103311249.p2VCnU9Y085450 at
harbor.orleans.occnc.com<[e-mail]>
   >
   - *List-archive*: <http://www.ietf.org/mail-archive/web/pwe3>
   - *List-help*:
<mailto:[e-mail]?subject=help<[e-mail]?subject=help>
   >
   - *List-id*: Pseudo Wires Edge to Edge <pwe3.ietf.org>
   - *List-post*: <mailto:[e-mail] <[e-mail]>>
   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/pwe3>, <
   mailto:[e-mail]?subject=subscribe<[e-mail]?subject=subscribe>
   >
   - *List-unsubscribe*: <https://www.ietf.org/mailman/listinfo/pwe3>, <
   mailto:[e-mail]?subject=unsubscribe<[e-mail]?subject=unsubscribe>
   >
   - *References*: <AANLkTi=fuSg1iBy+jz0SvsfNpGrd-=32p+KMV7Q=hOSv at
   mail.gmail.com<[e-mail]>>
   <201103311249.p2VCnU9Y085450 at
harbor.orleans.occnc.com<[e-mail]>
   >
   - *Sender*: sriganeshkini at gmail.com <[e-mail]>

------------------------------

inline

On Thu, Mar 31, 2011 at 5:49 AM, Curtis Villamizar <curtis at occnc.com> wrote:
>
> In message <AANLkTi=fuSg1iBy+jz0SvsfNpGrd-=32p+KMV7Q=hOSv at mail.gmail.com>
> Sriganesh Kini writes:
>>
>> See inline
>>
>> On Thu, Mar 31, 2011 at 4:40 AM, Curtis Villamizar <curtis at occnc.com> wrote:
>> >
>> > Sriganesh, Sasha, Loa, Dave,
>> >
>> > Would you please not top post.  See inline.
>> >
>> > Curtis
>> >
>> > In message <AANLkTimGJTVa42CFsj-PRcLiPLGTBhZ-t3sNRcTadHHe at mail.gmail.com>
>> > Sriganesh Kini writes:
>> >>
>> >> Sasha, that issue with VCCV Type-3 (without CW) is not addressed by
>> >> the draft. Practically, is that a major issue ? Especially setting TTL
>> >> > 1 for SS PW is possible I guess but would be some kind of serious
>> >> operational oversight. Besides such a packet would fail some check
>> >> along the path.
>> >
>> > End to end OAM should set TTL>1 and not use VCCV Type-3.  The T-PE may
>> > not have reliable information to set TTL, so in MS-PW it might be
>> > worth discouraging VCCV Type-3 except for use as a traceroute
>> > capability or to address S-PEs by node distance along the path.
>>
>> If there is indeed a concern of TTL exceeding number of segments (with
>> Type-3 and no CW), the same concern would apply when tracing. So
>> tracing would be impossible.
>
> traceroute stops when it hits the egress.

That is exactly the point I am trying to make. Why would the TTL from
that information not be reliable for other OAM operations ?

>
>> >> Also, what I heard at the mic regarding impl results is that it
>> >> doesn't make sense to deprecate what is already deployed.
>> >
>> > Yes.  But VCCV Type-3 with MS-PW is not already deployed.
>>
>> I am not aware of the survey addressing this.
>
> AFAIK Type-1 is being used, but I could be wrong.  Maybe someone who
> has implemented and knows of a deployment or someone who has deployed
> can reply so we don't need another survey.
>
>> >> Note that CC Type 1 prevents ECMP (when FAT-PW is not available).
>> >> Using GAL below PW also requires ECMP based on label hashing to ignore
>> >> reserved labels.
>> >
>> > You don't want ECMP to hash on PW payload.  With CW and without
>> > fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP
>> > containing many PW.
>>
>> When the PW payload is IP, the hashing it for ECMP is useful (If the
>> payload is not IP then use CW). FAT-PW may not be present in all
>> deployments.
>
> I really don't know that any PW are carrying IP.  That was not in the
> survey.  L3VPN would be carrying IP.

IPLS would be another case.

>
>> >> 2011/3/31 Alexander Vainshtein <Alexander.Vainshtein at ecitele.com>:
>> >> > Sriganesh, Curtis and all,
>> >> > IMHO and FWIW I think that the only problem with VCCV Type 3 is the
>> >> > risk of OAM packets leaking out of T-PE towards the AC (if you
>> >> > accidentally set the TTL value too high). To the best of my
>> >> > understanding the offset proposal does not solve that - or did I miss
>> >> > something?
>> >> >
>> >> > One way to solve it is to use VCCV Type 1 (clean where applicable).
>> >> > Another way would be by using GAL below the PW label (possible but
>> >> > messy). If the industry moves towards deprecating Ethernet PWs
>> >> > without CW,  it becomes completely unnecessary.
>> >> >
>> >> > My 2c,
>> >> >     Sasha
>> >
>> > This is the context suggesting a potential problem with VCCV Type 3.
>> >
>> >> >> -----Original Message-----
>> >> >> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces <pwe3-bounces> at ietf.org] On Behalf Of
>> >> >> Sriganesh Kini
>> >> >> Sent: Thursday, March 31, 2011 10:09 AM
>> >> >> To: curtis at occnc.com
>> >> >> Cc: pwe3 at ietf.org
>> >> >> Subject: Re: [PWE3] GAL above and below the PW label
>> >> >>
>> >> >> All,
>> >> >>
>> >> >> Just an FYI that a proposal for fate-sharing PW OAM and data given in
>> >> >> draft-kini-pwe3-inband-cc-offset
>> >> >>
>> >> >> Just to summarize the proposal.
>> >> >> 1. It does not require GAL in PW. TTL expiry is used to alert the S/T-
>> >> >> PE.
>> >> >> 2. It is mainly applicable when CW is not used in the PW.
>> >> >> 3. It uses a fixed offset (negotiated between PW endpoints) after the
>> >> >> label stack before starting the OAM msg.
>> >> >> 4. The bytes between the label-stack and the fixed offset is referred
>> >> >> to as a pseudoflow header and is filled with byte-values (by the PE)
>> >> >> that represent the flow for which OAM is desired. This helps PW OAM
>> >> >> and data to fate-share even when the intermediate node looks beyond
>> >> >> label stack to do multipath forwarding decisions.
>> >> >>
>> >> >>
>> >> >> On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar <curtis at occnc.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > Loa, Dave, Sasha,
>> >> >> >
>> >> >> > I've snipped from various posts on the thread that Sasha started.
>> >> >>  See
>> >> >> > inline.
>> >> >> >
>> >> >> > In message <4D92F5D3.6080609 at pi.nu>
>> >> >> > Loa Andersson writes:
>> >> >> >>
>> >> >> >> All,
>> >> >> >>
>> >> >> >> missed a nuance in Sasha subject line.
>> >> >> >>
>> >> >> >> We have two issues
>> >> >> >>
>> >> >> >> - where the GAL is placed relative to the PW label, I  believe it is
>> >> >> >>    necessary to have the GAL below the PW label.
>> >> >> >>
>> >> >> >> - whether the the GAL label needs to be bottom of stack or not, it
>> >> >> >>    figure that this is really a discussion if it is possible to have
>> >> >> >>    a FAT label below the GAL or not. I'm not sure  about my
>> >> >> preferences
>> >> >> >>    but I think it is possible.
>> >> >> >>
>> >> >> >> /Loa
>> >> >> >
>> >> >> > I agree with Loa's summary.  Not putting GAL at the bottom may
>> >> >> confuse
>> >> >> > some LSR, but putting it above the PW label is likely to be even more
>> >> >> > problematic.
>> >> >> >
>> >> >> >
>> >> >> > In message
>> >> >> <60C093A41B5E45409A19D42CF7786DFD51D5310B53 at EUSAACMS0703.eamcs.ericsson
>> >> >> .se>
>> >> >> > David Allan I writes:
>> >> >> >>
>> >> >> >> It does become a new behavior, GAL with S=3D0. However the
>> >> >> combination of G=
>> >> >> >> AL being top label at the S-PE and TTL being encoded in the PW label
>> >> >> means =
>> >> >> >> that fate sharing is broken at every S-PE. Life only gets a little
>> >> >> more str=
>> >> >> >> ange if there is a FAT label as well...
>> >> >> >>
>> >> >> >> That being said, GAL as bottom label is broken in any ECMP
>> >> >> environment, whi=
>> >> >> >> ch is why GAL is a TP construct.
>> >> >> >>
>> >> >> >> my 2 cents
>> >> >> >> D
>> >> >> >
>> >> >> > Dave,
>> >> >> >
>> >> >> > If GAL is broken for ECMP, which it is, then all TP OAM is broken.
>> >> >> > If all it takes to fix it is simple then lets just fix it.
>> >> >> >
>> >> >> > This is what we'd have to do.
>> >> >> >
>> >> >> >  1) Relax the requirement that GAL be at the bottom
>> >> >> >
>> >> >> >  2) Have the ingress insert GAL in the stack immediately below the
>> >> >> >     label for which the measurement is made, keeping the rest of the
>> >> >> >     label stack in place.
>> >> >> >
>> >> >> > The only thing the midpoing LSR at a multipath (LAG, link bundle for
>> >> >> > MPLS) has to do is skip over the GAL when hashing, as if the GAL
>> >> >> > wasn't there.  That will yield the same hash value and it will
>> >> >> > preserve fate-sharing across multipath.
>> >> >> >
>> >> >> > I prefer that we fix things rather than complain that they are
>> >> >> broken.
>> >> >> >
>> >> >> > Curtis
>> >> >> > _______________________________________________
>> >> >> > pwe3 mailing list
>> >> >> > pwe3 at ietf.org
>> >> >> > https://www.ietf.org/mailman/listinfo/pwe3
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> - Sri
>> >> >> _______________________________________________
>> >> >> pwe3 mailing list
>> >> >> pwe3 at ietf.org
>> >> >> https://www.ietf.org/mailman/listinfo/pwe3
>> >> > _______________________________________________
>> >> > pwe3 mailing list
>> >> > pwe3 at ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/pwe3
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> - Sri
>> >>
>> >>