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

[Sriganesh Kini <[e-mail]>]

Sasha,

Can you point to the text in RFC 6073 that in your interpretation
results in the number of segments in a PW dynamically changing but the
PE being unaware of it (and using the incorrect TTL value).

Thanks

2011/3/31 Alexander Vainshtein <[e-mail]>:
> Sriganesh,
> Please see inline below.
>
> Regards,
>     Sasha
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Sriganesh Kini
>> Sent: Thursday, March 31, 2011 11:18 AM
>> To: Alexander Vainshtein
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [PWE3] GAL above and below the PW label
>>
>> Sasha, that issue with VCCV Type-3 (without CW) is not addressed by
>> the draft.
> [[[Sasha]]] That is what I said:-(
>> > 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.
> [[[Sasha]]] If you mean SS-PW, then the chance for an error(sending an OAM packet with TTL > 1
> or sending a data packet with TTL = 1) is small and should be treated as an implementation bug.
> With  dynamic MS-PWs, the number of segments of a MS-PW can change with time, so that the originally
> Correct TTL setting would suddenly result in leakage of OAM packets out of the AC.
> All this is described in detail in 6073.
>>
>> Also, what I heard at the mic regarding impl results is that it
>> doesn't make sense to deprecate what is already deployed.
>>
> [[[Sasha]]] To the best of my recollection, what has been said at the mike is that you cannot
> change optional CW usage to mandatory when you progress from PS to DS.
> But, to the best of my understanding of the IETF process and practice, nothing prevents us
> from publishing a BCP document that would declare non-usage of the CW deprecated.
> This would push the vendors to support it in their new boxes (SW upgrades), and it would
> be understood by the operators as a suggestion to transit to using the CW if their equipment
> supports it -- all that without outlawing non-usage of the CW.
>
>> 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
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>



-- 
- Sri