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

[Sriganesh Kini <[e-mail]>]

Hi Carlos,

Pls see inline.

On Fri, Apr 22, 2011 at 6:23 PM, Carlos Pignataro (cpignata)
<[e-mail]> wrote:
> Hi Sriganesh,
>
> Thanks for the quick response and low RTT, please find some follow-ups inline.
>
> Carlos P.
>
> On Apr 22, 2011, at 2:20 PM, "Sriganesh Kini" <[e-mail]> wrote:
>
>> Hi Carlos,
>>
>> The applicability of draft-kini-pwe3-inband-cc-offset is when CW is
>> not present, but the intermediate LSR looks beyond the PW label to do
>> multipath decisions. The draft is independent of any (even proprietary
>> logic) for multipath decision taken by intermediate nodes looking
>> beyond PW label and also independent of any heuristic the intermediate
>> routers may use to guess the packet type (beyond label stack) being
>> carried.
>
> I think that this statement is a bit too optimistic and too generalized. It seems to me that, in addition, the PE needs to understand the flows carried inside the PW, have some clue as to the type of ECMP in the core, and there should have correlation between these two. This dramatically limited the applicability as you say below:
>

Correct that the PE needs to know the flow that the operator is trying
to troubleshoot ! However the PE does not need to know the type of
ECMP that is implemented in the core (P router). That algorithm would
be typically proprietary. Not sure if you are saying that the PE
should know the co-relation between the flow and the ECMP-type before
the problem occurs. The draft is not a multi-path algorithm discovery
mechanism. That is an important problem, but due to the proprietary
nature of those algorithms a solution has limitations. The draft
provides a PE a mechanism to troubleshoot a flow without having
precise knowledge a-priori of how the multi-path algorithm is behaving
for a specific flow.

Regarding applicability, consider an encapsulation that has a single
label stack in the core consisting of the adaptation label stack (PW
in this case) and the label stack of a MPLS packet received from the
client CE. This kind of encapsulation is in
draft-kini-pwe3-pkt-encap-efficient-ip-mpls when CW is not used. I
believe a similar encap is used in the network layer adaptation sec
3.4.5 RFC 5921 for a client layer that is MPLS enabled. In such a case
too it is possible to troubleshoot a flow (that includes the client
labels and the packet being carried below) of the combined label
stack.

Also note that this mechanism has some similarity to
draft-nadeau-pwe3-vccv-2. The primary difference being that in
draft-nadeau the GAL is used to identify an OAM packet instead of TTL,
hence the presence of GAL in the hash computation is an issue.
Moreover due to the offset, the inband-vccv draft  is also independent
of the pkt (and multi-path decision based on that) being carried below
the label stack.

>> The most common heuristic is of course looking at the first
>> nibble beyond label stack to determine that it is an IP packet. So
>> this would also apply for an IP PW, IPLS, etc in addition to
>> draft-kini-pwe3-pkt-encap-efficient-ip-mpls.
>
> Right. I think it would apply to an IP PW, where there are existing techniques to walk multipaths. But it would not to say an Ethernet PW (without CW): even if the PE sees the flows inside the Ethernet (e.g., TCP flows over IP over Ethernet), the is no ECMP in the core based on those.
>

I would like to believe that too. But I have heard that
implementations do different things with some packet inspection.

>> LSP-Ping uses the 127
>> address and it is not easy to co-relate this to a problem reported for
>> real (non 127) addresses.
>
> I think LSP-Ping can do better: identify and walk all ECMPs.

If the ECMP algorithm is proprietary and info about that is not
available to the PE, there will be issues.

> I also think that the assumption of a problem being reported on a given flow, only for an IP PW Type is too expensive for the return.
>
> Thanks,
>
> -- Carlos.
>
>>
>> Thanks
>>
>>
>> On Thu, Apr 21, 2011 at 9:48 PM, Carlos Pignataro <[e-mail]> wrote:
>>> 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
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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