Re: [trill] TRILL OAM Requirements: available paths

On 4/28/12 9:54 PM, Sam Aldrin wrote:
> Erik,
>
> Every hop in mpls does hashing based on label stack and other header details. I do not see any difference between TRILL and mpls in this case.

That's not consistent with what I heard from others when I discussed 
MPLS OAM. But that isn't the main point.

>   The requirement is to specify the ability to test each of those ecmp paths available. Doesn't matter if the active traffic is taking that path or not. This is part of pro-active monitoring.

OK. Then please make that clear in the requirements document. For 
instance, that can be done by including a careful definition of 
"available ecmp paths" in the document.

FWIW I don't think any of the solutions that have been discussed so far 
are capable of testing all the available paths; that just means there is 
some more work needed on solutions.

    Erik

> Cheers
> Sam
>
>
> Sent from my iPad
>
> On Apr 28, 2012, at 8:45 PM, Erik Nordmark<nordmark@acm.org>  wrote:
>
>> On 4/27/12 5:12 PM, Tissa Senevirathne (tsenevir) wrote:
>>> Of course it is possible. The IS-IS topology table provide the
>>> information on all available ECMP paths to a specific destination when
>>> the egress RBRidge nickname is known. That is what TRILL unicast
>>> forwarding table all about. Not sure why you are saying it is not
>>> possible to know all ECMP paths.
>>
>> You are talking about what Santosh called "all theoretically available paths". Those can be determined from IS-IS.
>>
>> But the document talks about "all available paths" and I don't know what that is supposed to mean. Do you have a succinct definition?
>>
>> What is clear to me is that there can be a subset of the paths that are determined from IS-IS that would never be used, because no entropy in a packet would every pick that path.
>>
>> Is the requirement in the document that the OAM solution should be able to test those paths?
>>
>>> What path among available paths to be selected for a specified is a
>>> local matter. That is what all about flow entropy discovery. Like I
>>> stated earlier how it is discovered is a framework and solution issue.
>>
>> Agreed.
>>
>>> If you need some reference how it is done in the MPLS world RFC 4379 is
>>> a good reference.
>>
>> AFAIK MPLS doesn't have a locally defined ECMP hash function in every hop. TRILL does, which makes these aspects different.
>>
>> Regards,
>>    Erik
>>
>>> -----Original Message-----
>>> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf
>>> Of Erik Nordmark
>>> Sent: Friday, April 27, 2012 4:07 PM
>>> To: Santosh Rajagopalan
>>> Cc: trill@ietf.org
>>> Subject: Re: [trill] TRILL OAM Requirements: available paths
>>>
>>> On 4/27/12 2:15 PM, Santosh Rajagopalan wrote:
>>>> I agree, the wording needs to be tightened to say "all possible ecmp
>>>> paths" rather than "all available paths". An operator working out
>>>> R1-R2 communication is interested in all possible paths data traffic
>>>> could take rather than all theoretically available paths.
>>>
>>> The issue is that there is nothing in the TRILL dataplane nor IS-IS
>>> control plane which helps the operator determine that some paths
>>> (through RB121 and RB112 in the example) are not possible; the ECMP
>>> input and hashing is a completely local matter on each RBridge.
>>>
>>> It isn't useful to state a requirement around something that can't be
>>> determined.
>>>
>>>      Erik
>>>
>>>>
>>>>
>>>> From: Erik Nordmark<nordmark@acm.org>
>>>> To: trill@ietf.org
>>>> Date: 04/27/2012 09:53 AM
>>>> Subject: [trill] TRILL OAM Requirements: available paths Sent by:
>>>> trill-bounces@ietf.org
>>>> ----------------------------------------------------------------------
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>> Two requirements use the wording "all available paths." and "all
>>>> available ECMP paths.", respectively and I'm not sure I know what that
>>>
>>>> means.
>>>>
>>>> Take the following example picture:
>>>>
>>>> R1
>>>> / \
>>>> / \
>>>> / \
>>>> / \
>>>> / \
>>>> RB11 RB12
>>>> / \ / \
>>>> / \ / \
>>>> RB111 RB112 RB121 RB122
>>>> \ \ / /
>>>> \ \ / /
>>>> \ \/ /
>>>> ------R2------
>>>>
>>>> We can see that there are 4 paths with 3 hops to get from R1 to R2,
>>>> with two layers of ECMP decisions. But how many available paths are
>>> there?
>>>>
>>>> Given that the RBridges make independent ECMP decisions, and how they
>>>> do that is a local matter, it could be the case that for any packet,
>>>> if R1 picks the left link, then R11 would also pick the left link; if
>>>> R1 picks the right link, then R12 also picks the right link.
>>>> Thus there would be no packet (data or OAM) that would cause packets
>>>> between R1 and R2 to pass via RB112 or RB121.
>>>>
>>>> Even if we ignore that as unlikely, there is still the fact that R1
>>>> can't easily tell how many (shortest) paths there might be between it
>>>> and R2. With single-level TRILL the LSDB could be used to tell, but if
>>>
>>>> we ever go to multi-level that wouldn't be the case any more.
>>>> And even if R1 knows that there are 4 potential paths, it can't format
>>>
>>>> a data packet (or format the flow entropy in an OAM packet) in such a
>>>> way that particular paths get chosen by downstream ECMP decisions.
>>>>
>>>> Thus for any notion of "all available paths" that make sense to me,
>>>> we'd need an OAM approach that can explore the topology one hop at a
>>>> time and at each hop explore all the possible ECMP choices. Using the
>>>> entropy doesn't help with this (but the entropy is critical for
>>>> following the path taken by a particular flow of data packets).
>>>>
>>>> Hence it would be good to clarify what the assumptions are behind this
>>>
>>>> notion of all available paths.
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>> _______________________________________________
>>>> trill mailing list
>>>> trill@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/trill
>>>>
>>>>
>>>
>>> _______________________________________________
>>> trill mailing list
>>> trill@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trill
>>>
>>
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
>