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

[Sriganesh Kini <[e-mail]>]

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.

Also, what I heard at the mic regarding impl results is that it
doesn't make sense to deprecate what is already deployed.

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.

2011/3/31 Alexander Vainshtein <[e-mail]>:
> 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
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Sriganesh Kini
>> Sent: Thursday, March 31, 2011 10:09 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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 <[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]
>> .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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/pwe3
>> >
>>
>>
>>
>> --
>> - Sri
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>



-- 
- Sri