Re: [trill] TRILL OAM Requirements: available paths

No, I am talking about all equal cost paths. As IS-IS run through path
calculations it only maintain best cost paths. You cannot by default
obtain all theoretical paths.

Whether entrophy covers a subset or all equal cost paths is a
implementation/solution issue. That is the reason requirements are in
place to include real payloads. I am not sure whether I am getting the
explanation correctly. May be I should call you or you can dial in to
the design team meeting and I can explain.

-----Original Message-----
From: Erik Nordmark [mailto:nordmark@acm.org] 
Sent: Saturday, April 28, 2012 8:46 PM
To: Tissa Senevirathne (tsenevir)
Cc: Santosh Rajagopalan; trill@ietf.org
Subject: Re: [trill] TRILL OAM Requirements: available paths

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
>