Re: Reconvergence micro-loops: problem and solutions overview

[Albert Tian <[e-mail]>]

Hi, Stewart,

Stewart Bryant wrote:
> 
> >>- 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.

If we use MPLS, then why not use a stack of LDP labels as proposed in
draft-tian-mpls-lsp-source-route-01.txt? I went extra length in the draft trying
to avoid the LDP full mesh problem, which now seems to be a non-issue (according
to the feedback I got). Remove the domain wide label part from the draft, just
use a stack of LDP labels to build a source routed repair path seems better than
the mixed GRE/MPLS solution (less overhead, more efficient, no MTU issue,
support multiple hops, support all strict/loose combinations).

Thanks,

Albert

> 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

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