Re: Reconvergence micro-loops: problem and solutions overview

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Stewart Bryant writes:
>  
>  
> >>- 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.


Both of these forwarding mechanism require prior setup.  The third
party setup of the "vector" as you call it, is not defined.


> >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.


Infinite choice leads to total lack of interoperability.  Unless of
course that is an explicit goal, it would be considered to be bad.


> >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.


Yes but it did take a while to get the tunnel technologies that are
being considered out of this.  A few other choices were mentioned for
tunneling in other threads, IP-in-IP, L2TPv3.


[... stuff deleted ...]
>  
> 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.

There are many cases where SRLG are very helpful.  If two core links
over DWM traverse a common length of fiber, an SRLG is certainly
helpful.  Putting the backup for one of these links on the other would
certainly be undesirable if an alternate existed, even if the
alternate had a higher cost.

There are two types of SRLG that can be supported (terminology
varies).  One where if the SRLG cannot be avoided the backup is not
considered viable due to very high probability of correlated failure.
A second where backup paths are in effect ranked or biased (often by
artificially increasing the cost of the link) so that backup paths
with a relatively low but non-zero probability of correlated failure
can be avoided.

Some providers are more interested in making use of SRLGs than others.

> >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?

Same as all of the other examples, from X to Z.  I mistyped again.
Node failure of N.

[... stuff deleted ...]

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

Sorry.  I mistyped in giving the example but we do agree on this.


> >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.


Fine.  Maybe you should say that in the draft.  Perhaps you can
revisit the handling of SRLG later.


> >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.

The setup of the forwarding is undefined.

> On the other hand U-turn is a completely novel forwarding mechanism
> that I do not recall seeing in any RFC.

By your definition we have not invented a new forwarding.  It is IP
forwarding based on the IP destination.

The difference is that the IP forwarding in the outbound interface is
normally set up to generate ICMP if the packet comes in on that
interface.  Instead it is set up to go a different way since it will
be used for backup in case of a failure at the next node and will
forward to the next best path which does not use the downstream node
on the best path.

So it is IP forwarding and it is a matter of setup.

Furthermore, no signailing extension is needed except an indication of
capability which is passed among peers.  Not only that but Alia has
specified what that signaling is.

So unlike your draft, all of the details are on the table rather than
remaining a mystery, and interoperability is possible, unlike your
draft where interoperability is impossible given what you have
specified.

> >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.

And the critical details that are out of scope are of course not
covered by the IPR statements.  So we have no chance for
interoperability based on the draft and probably have IPR noose
waiting if we try to interoperate by some other means.

This doesn't seem like something that would be in the best interest
of the overall community for the IETF to move forward with.  It seems
like a proprietary solution.

> >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

We might have to add impossible to interoperate with to the list of
things that are given up with this method of IPFRR.

Curtis

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