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

[Carlos Pignataro <[e-mail]>]

Hi Sriganesh,

Do you see the applicability of draft-kini-pwe3-inband-cc-offset
strictly limited to the encapsulation proposed in
draft-kini-pwe3-pkt-encap-efficient-ip-mpls?

Specifically, for a PW that carries say Ethernet without CW (or any of
the other encap modes with non-mandatory CW), there is no "flow" that is
being ECMP-ed in the core that you want to mimic/imitate in a
load-balancing pseudo-header. Conversely, for "IP PWs", LSP-Ping can
take different Equal-cost paths (all of them, one by one) based on
choosing the destination IP address. And there is no need for this when
there is a CW.

I am trying to understand how common is the use case for what this
optimizes for.

Thanks,

-- Carlos.

On 3/31/2011 4:08 AM, Sriganesh Kini wrote:
> 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 <[e-mail]> wrote:
>>
>> Loa, Dave, Sasha,
>>
>> I've snipped from various posts on the thread that Sasha started.  See
>> inline.
>>
>> In message <[e-mail]>
>> 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 <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
> 
> 
>