Re: Reconvergence micro-loops: problem and solutions overview

[Stewart Bryant <[e-mail]>]

>>- A node instructed to directed forward must do as it is told, even
>>  if it "knows better" - See para 4.2
>>    
>>
>
>So what type of tunnel has a "pop and IP directed forward" already
>defined for it?  Even putting an IP source route option in there
>doesn't override the forwarding at A.  
>
Exactly the vector need to be a vector.

A new tunnel type is not strictly necessary, one obvious mechanism
is a GRE tunnel with an MPLS Ethertype (0x8847) followed by an MPLS LSE.
Alternatively one could use L2TPv3 and vector off the session IP.
This would then we the same as an IP pseudo-wire carried over L2TPv3.

The tunnel can therefore be built with existing IETF defined
encapsulations.

>
>Did we just invent a new IP option field or its equivalent?  I also
>notice that the spec says:
>
>   3.2.3. Directed forwarding.
>
>   Directed forwarding must be supported such that the router at the
>   tunnel endpoint (P) can be directed by the router at the tunnel
>   source (A) to forward the packet directly to a specific neighbor.
>   Specification of the directed forwarding mechanism is outside the
>   scope of this document.
>
>A lot of things to make this work are out of scope and this may be
>part of the problem that people are having, myself included.
>
We put it out of scope because there is no novelty to it - see above
- and we did not want the choice of the specific implementation
technology to cloud our description of the repair mechanism.

>A lot of us have been looking for an existance proof to the many
>things that have been declared out of scope.  Note that there were
>prior complaints on this list about you proposing a new forwarding
>mechanism in this.
>
>[... lots of stuff deleted ...]
>
Neither MPLS nor GRE are new, nor is the use of them in combination.
The MPLS world does it all the time to hop between disjoint MPLS islands.

>>>At
>>>the very least this should be reflected in the internet-draft.
>>>
>>>      
>>>
>>If we had found a case that did not work, we would have stated it.
>>We have not yet found such a case in symmetric cost networks.
>>    
>>
>
>Thanks for the clarification.  I can see how you can find some node,
>in the above cases a node immediately adjacent to the destination,
>which can be reached by the IGP and needs only one hop reversed by the
>directed forwarding.  It was the directed forwarding that I missed.
>I stand corrected on the examples I gave being a coverage issue.
>
>I can also see why you've done things the way you have.  The tunnel
>can always follow the IP path in reverse for assymetric paths at worst
>case up to one hop from the destination, then reverse the forwarding
>on that one hop.  The advantage over an explicit-path all the way to
>the destination to that is plain IP directed tunneling can be used to
>reach the point where the one directed forwarding has to be used.
>
Correct

>The only cases that it appears cannot be covered are those related to
>assymetric path and possibly SRLG.
>
We have always stated that there was a problem with asymetric costs,
however you will see from the analysis of the networks that we have
presented that it is a very rare problem easily fixed by making the
costs symetric. Now before you say "so you need to modify the topology"
I should point out that when we were given the topologies we asked
how common asymetry was and we were told in most cases that there
was none. When we looked at the asymetric costs that we could not
repair we found that there was usually some typo at the root of it
(ie 6666 vs 66666). Again before anyone asks we did NOT fix these
typos before analysing the networks, so our results are illustrative
of the repair coverage degradation that you get in a real network
that includes misconfiguration.

SRLG is something that we have given little thought to, mainly
because we have little confidence in the validity of SRLG marking.
(i.e. we are concerned at how often failure correlation is
predicted correctly). The approach that we have considered is to
start by triming both P and Q space by excluding nodes with a
reachable path that includes members of the SRLG. If that does
not produce a solution then we would need to analyse the repair
strategy of each of the SRLG guardians and try to find a set that
were not mutually repairing. But note that the special SRLG case of node
failure is covered.

>
>You've acknowledged that when assymetric paths are present there may
>not be a viable backup using this method.  The question of SRLG has
>come up but has not been addressed.
>  
>
Actually I am not sure that any of the proposed (non TE) methods
have a good SRLG strategy. However given that we have more control
over the packet for the first two hops than U-turn (we push the
first hop and DF the second), I would have thought that our
longer reach approach was at worst identical in coverage to
U-turn, and at best more likely to find a solution.

>Consider the following:
>
>     Z -- N -- X -- E
>  6  |         |    |
>     A -- B -- C -- D
>
>Link cost on Z-A is 6.  X-N and X-C share an SRLG.  Note that U-turn
>does not cover this either, however if router D was not there (E and C
>directly connected) it would.
>
N-X and X-C as a SRLG is equivelent to a node failure of X, which
we cover in the draft.

I guess that you are trying to go from Z to E?

Z forwards normally to N.
N, knows that there is a failure, and assumes that it is node X
N encaps to C (nearest reachable neighbour of X) and then
repairs to X
To repair to X, N tunnels to Z with a DF vector to A.
Packet goes from N to Z
Z decaps.
Z looks at the DF vector and pushes to A.
A now has a packet addressed to C, and the packet
follows normal forwarding to C.
C decaps and finds a packet addressed to E.
If CX *is* still up the packet goes to E via normal path
If CX is down, C notices and uses the pathsplit to E via D.
If the cost CD or DE was greater such that there was no
path split, then our usual combination of first hop push
of a tunneled packet with a DF vector would get the packet
safely to E.

>If you want to consider SRLG then you need explicit paths.
>  
>
In some cases, but not the one above.

>It is more clear to me now why you are pursueing this.  You give up TE
>and SRLG support but you don't have any path setup.  
>
Strictly we have not properly considered any SRLG case except the case of
node failure which we have given considerable thought to. However
if we were prepared to undertake the extra SPFs I am sure we could
address additional SRLG cases.

>OTOH unless I've
>missed something you have just invented a new forwarding type in the
>directed forwarding which raises compatibility issues with current
>hardware 
>
Not really. See above. I am sure I can find a better reference, but
draft-ietf-l3vpn-gre-ip-2547-02.txt illustrates the point.
On the other hand U-turn is a completely novel forwarding mechanism
that I do not recall seeing in any RFC.

>t raise some intellectual property snags if the
>directed forwarding on which this strongly depends has issues.
>
I cannot comment on IPR, other than to note that all of the drafts
under consideration include IPR statements.

>
>I personally think MPLS FRR is a better solution, but at least I see
>that there is greater simplicity to this, giving up a few things for
>that simplicity.  Prior to this discussion I didn't see any advantage
>over MPLS FRR tunneling so thanks for the response.
>
You are welcome.

- Stewart



_______________________________________________
Rtgwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg