Please see more comments inline
- Stewart
On 08/12/2015 12:07, Anil Kumar S N (VRP Network BL) wrote:
Hi Stewart,
Request you to see inline for reply.
Thanks & Regards
Anil S N
“Be liberal in what you accept, and conservative in what you send” -
Jon Postel
*From:*Stewart Bryant [mailto:[email protected]]
*Sent:* 07 December 2015 19:29
*To:* Anil Kumar S N (VRP Network BL);
[email protected]; [email protected];
Alvaro Retana
*Cc:* Mike Shand
*Subject:* Re: WGLC for draft-rtgwg-mrt-frr-architecture
On 07/12/2015 11:11, Stewart Bryant wrote:
Resending with the correct draft alias
On 07/12/2015 11:07, Stewart Bryant wrote:
Hi Anil
Please see inline.
Note that here we are just discussion some of the points raised.
- Stewart
On 06/12/2015 04:38, Anil Kumar S N (VRP Network BL) wrote:
Hi Bryant,
Please find my observation on your comments in line.
Thanks & Regards
Anil S N
“Be liberal in what you accept, and conservative in what
you send” - Jon Postel
*From:*rtgwg [mailto:[email protected]] *On Behalf Of
*Stewart Bryant
*Sent:* 04 December 2015 02:22
*To:* [email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>; Alvaro Retana
*Subject:* WGLC for draft-rtgwg-mrt-frr-architecture
Resend due to problem sending to the document alias
Hi,
I am sorry that this review is late, but a number of personal
matters
needed priority. Hopefully you can accept it still.
Firstly my high order bit, and I suspect I will be in the rough on
this.
I am not convinced that this is the best solution that we can
produce to
this problem, and I am concerned about the operational issues that
result from the non-intuitive repair paths when compared to other
methods. I am also concerned about our ability to get a solution as
complicated as this right first time in all of the corner cases.
Thus I think that rather than recommend this to the industry
as a standard, we should issue it as informational and see how it
works
out at scale.
===========
1. Introduction
This document gives a complete solution for IP/LDP fast-reroute
[RFC5714]. MRT-FRR creates two alternate trees separate from
the
primary next-hop forwarding used during stable operation.
These two
trees are maximally diverse from each other, providing link and
node
protection for 100% of paths and failures as long as the
failure does
not cut the network into multiple pieces.
SB> I am concerned that this is an overstatement.
SB> Firstly you cannot handle multiple concurrent failures in
SB> even simple pathological cases. If the network is two
SB> connected and you have both a red and blue failure
SB> that you need to traverse, you (say) commit to the red
SB> the you will fail at blue transition, even though the network is
SB> is still connected at the link level.
[Anil >>] I don’t think once packet moved into red path
will fall back to blue path in case of red path failure.
No other FRR technologies can handle simultaneous multiple
failure without loops[Loop may or may not occur which is
unknown].
MRT is one of the FRR technologies which provide alternate
path which tries to move away from failure point to reach
the destination.
I feel we can count on the positive advantage of MRT.
SB> I do not think that is correct.
SB> Methods that construct a repair to the next-hop (link) or
next-next-hop (node)
SB> and refuse to repair a repair can cope with some types of
multiple failure.
SB> For example a repair based on not-via or strict
source-routing can deal
SB> with concatenated repairs. They get tricky when the second
failure is in the
SB> repair path. Mike Shand and I looked at this but I cannot
remember what the
SB> outcome was. However to a limited extent I think that even
that might be
SB> feasible.
SB> I think that what is important here is that you specify
the degree of completeness
SB> which is single-link, cluster of links with a single
common node and node
SB> failure.
SB> The root cause of this constraint is the use of a pair of
trees with a single root.
SB> This contrasts with SR and NV which have a tree rooted at
every PLR and
SB> reset the repair constraint once the packet has left the
repair domain.
SB> As to your point about moving away from the failure, NV
certainly does this
SB> and with SR it depends on whether you set the repair
target as the far
SB> side of the failure or Q space.
SB> The root cause of the loops in Q space is that you may not
have used
SB> a sufficiently limited estimate of Q space. However if you
require that the
SB> packet get to the next-next hop it is always safe to
release it into a
SB> network that had previously converged.
[ANIL 2 >> ]
I remember Bruno pointed out a simple topology with multiple
failure can cause LOOP in SR,
I am yet to understand Not Via
Below is the topology, Where all links have a metric of 10,
except AD which has 100
For the traffic from A to C, if both AC and BD links fails at
the same time (and were not identified as SRLG),
there will be a loop between A and B. (and funnily (is it? ;-)
) as packets are looped,
the label stack seems to increase to “infinity” as additional
P nodes (alternatively C and D) are used.
A – B
| \ |
C – D
So multiple failure, the behavior could be undesirable. There
could many unforeseen topologies
Where the extent of multiple failure and behavior might be
undesired. Please check NV against this topology.
MRT guarantees one thing for sure; if in case of multiple
failure Packets would be dropped but it will not be looped.
Which is very important, looping congests line card and will
be trigger for further failures. J
SB1> We addressed this problem in NV by not repairing repairs. At A the
packet would
SB1> have gone into a tunnel from A to C via B and D with address C
not-via AC.
SB1> B and D would of course populate their forwarding tables with the
normal next
SB1> hop for the NV address, but instead of having a repair for the
address, they would
SB1> have a drop for it. The result is unconditional safety of the type
you seek with MRT.
SB1> I assume that the SR folks are trying to use the same segment
identifiers for both
SB1> traffic engineering and repair. This is surely a mistake. By using
a different set of identifiers
SB1> for repair, and not repairing packets that arrive with a repair SI,
i.e. following the
SB1> the approach that we proposed in NV the SR approach would also be
unconditionally
SB1> safe against an unexpected failure.
SB> The text should start with the invariants and assumptions to
SB> correctly scope the claims in the introduction.
SB> I think you have to say where the trees are routed since only
SB> two mean you need a root, and you need to note that this is
SB> different from the underlying IGP in which there is a tree
SB> per node.
Summary Comparison of IP/LDP FRR Methods
+---------+-------------+-------------+-----------------------------+
| Method | Coverage | Alternate | Computation (in SPFs)
|
| | | Looping? |
|
+---------+-------------+-------------+-----------------------------+
| MRT-FRR | 100% | None | less than 3
|
| | Link/Node | |
|
| | | |
|
| LFA | Partial | Possible | per neighbor
|
| | Link/Node | |
|
| | | |
|
| Remote | Partial | Possible | per neighbor (link) or
|
| LFA | Link/Node | | neighbor's neighbor (node)
|
| | | |
|
| Not-Via | 100% | None | per link and node
|
| | Link/Node | |
|
| | | |
|
| TI-LFA | 100% | Possible | per neighbor (link) or
|
| | Link/Node | | neighbor's neighbor (node)
|
+---------+-------------+-------------+-----------------------------+
SB> I really wonder how important the computational complexity is
SB> given that we are moving to an SDN world where these calculations
SB> can be offloaded?
[Anil >>] JIts not wrong to claim MRT consumes much less
computation compared to other FRR technologies.
Be it SDN controlled or distributed.
SB> ... but it is important to consider the importance of the
computation constraint.
SB> In SDN you potentially have a lot more compute power
available than you
SB> have in the small processor/memory systems. You also have
the potential
SB> (due to massive storage) to maintain a history of common
network states
SB> and thus have the configuration of the post-failure or
post-repair states
SB> on file.
SB> You also need to consider how long it takes to do
loop-free reconvergence
SB> to see whether the new state repair time calculation is a
factor or not.
SB> For example, if you could do 50 SPF/sec it would take 10s
to run one
SB> per node on a 500 node network. So then you get to the
question of
SB> whether the LF strategy can be executed, and its
completion notifed
SB> in 10s? If not, then the SPF computation time is not a factor.
[ANIL 2 >> ]
Let’s compare TI-LFA and MRT computation constraints, I
believe MRT need less computation than TI-LFA
TI-LFA need to calculate Extended P-Space for set of
destination which used each other nexthop.
Number of SPF directly depends on Number of Neighbors. If Node
protection is desired then more computation is expected.
In contrary, MRT has to prepare a graph and select alternates.
If preparation of GADAG is considered as one SPF then it boils
down to be very simple.
Since GADAG root is fixed, If central controller in place, if
controller can collect link state information from topology
Using BGP LS or by forming IGP peer. The GADAG calculation can
be delegated to controller.
Only alternate information can be downloaded by Controller.
This cannot be achieved
With this ease in case where LFA calculation done for tree
rooted at every PLR
My point is measurement can be of any form/measurement units,
MRT has computation advantage but with
implementation/understanding/algorithm complexity.
SB1> If we are going to publish a comparison, then it needs to be
complete, objective, and
SB1> we need to properly understand what the true importance is.
SB1> My contention, and surely the big-data and machine learning people
will support this
SB1> is that the compute power in a data center is so large that you can
disregard many
SB1> historic concerns about compute limitation. If the repairs are
being computed in an
SB1> SDN controller we have massive compute power and huge storage and
so need to be
SB1> far less concerned with the compute limitations that have
constrained our thinking.
SB1> So in this particular case what is being done is to accept
limitations in the repair
SB1> strategy in order to minimise computational overhead, at a time
when we are moving
SB1> into a world where computational overhead is no longer a limiting
factor.
SB1> BTW as I pointed out in another email, the GADAG root is not fixed
in the event of
SB1> the failure of that node or the introduction of a new node that
becomes the minimum.
SB>
SB> I think that it is fair to note that the other method use the
SB> existing routing protocol and calculate alternate paths using
SB> the methods of that routing protocol. Whereas with MRT you
SB> really have a new routing protocol with all of the associated
SB> operations overhead.
[Anil >>] As you stated in previous comment, Moving to SDN
world overhead can be offloaded J
But I don’t feel there is much overhead compared to R-LFA or
TI-LFA
SB> You miss my point. With MRT you have the complexity and
SB> operation characteristics of a new routing protocol to
take into
SB> account. That is also the case for some of the other FRR
methods
SB> but by no means all of them.
[ANIL 2 >> ]
In fact , MRT provides less operation complexity, If
administrator know what is GADAG, he could easily figure out
what would be alternate path visually for an extent.
In simple case, if primary path matches with blue then
alternate path is red. The same cannot be expected with R-LFA
or TI-LFA.
It’s even difficult to send OAM packets to verify backup path
in case of R-LFA and TI-LFA.
For MRT administrator can send OAM packets on RED or on BLUE
path to a specific path.
SB1> The first question I have is how may admins know what a GADAG is?
Remember up until now
SB1> all you needed to think about was what is the shortest path from
where the packet currently
SB1> is to the destination.
SB1> I do not understand your comment about OAM. You can send OAM over
the repair path
SB1> with any of the repair techniques. You have to send it from the
PLR, but what is wrong with
SB1> that?
MRT is quite different from traditional FRR technologies,
which really has unique positive qualities.
Only thing I feel which is lacking in MRT is capability to
handle multiple failure and that should not be only criteria
to reject a good protocol J
Hope its gets due appreciation for its unique capabilities J
============
1.1. Importance of 100% Coverage
Fast-reroute is based upon the single failure assumption - that the
time between single failures is long enough for a network to
reconverge and start forwarding on the new shortest paths. That
does
not imply that the network will only experience one failure or
change.
SB> The above needs to be much earlier to qualify "complete"
===========
4. Maximally Redundant Trees (MRT)
SB> Please remind me is there one red topology or one per failure.
SB> There is just one - correct - so it would be useful to
SB> explain what happens in a number of instances of failure.
[Anil >>] Each devices will maintain three forwarding tables,
one for default SPF calculated topology and other two for RED
and BLUE topologies.
Default forwarding table would have backup path on red or blue
forwarding table based on alternate selection.
On failure if Blue is selected as alternate path, packet will
switch to Blue forwarding table.
Packet stays in blue path till it reaches the destination
If any failure is detected on blue path, packet will be
dropped till SPF convergence.
SB> This needs to be highlighted, together with the mechanism
that you will use
SB> to abandon the LF reconvergence.
[ANIL 2 >> ] I am not an author, I wish I would; since I like
this protocol J,
I am sure authors will update it.
SB1> I hope so, although so far they have been very quiet.
============
5. Maximally Redundant Trees (MRT) and Fast-Reroute
When there is a link or node failure affecting, but not
partitioning,
SB> that should be "a single link or single node"
[Anil >>] In case of MRT there is Cut-Vertex and Cut-Link,
When these vertex or link fails then network is partitioned
Otherwise there exists a path to reach destination, the same
would have been selected by MRT
SB> Strictly it is partitioned in the chosen MRT topology. I
think it can
SB> be unpartitioned in base or the other MRT topology, it is
just that
SB> they are not available to you.
[ANIL 2 >> ] I request you to elaborate this point. I didn’t
understand.
As far I can say, If network has no cut vertex or cut link.
MRT can provide alternate path for single failure without any
issue.
Cut-vertex and Cut-Link is a issue for any FRR technologies.
So it finally boils down to multiple failure which MRT doesn’t
support.
SB1> In the event of a single failure there is no problem, but the draft
does not make that constraint clear.
SB1> In the event of a double serial failure (which some of the other
methods can handle) then you
SB1> may find that there exists a path to every destination in base, but
because one of the paths needed
SB1> was in red and the other in blue you cannot repair.
============
6. Unicast Forwarding with MRT Fast-Reroute
As mentioned before, MRT FRR needs multi-topology forwarding.
Unfortunately, neither IP nor LDP provides extra bits for a packet
to
indicate its topology. Once the MRTs are computed, the two sets of
MRTs can be used as two additional forwarding topologies. The same
considerations apply for forwarding along the MRTs as for handling
multiple topologies.
SB> It would be good to explain how you solve the problem mentioned
SB> in the previous para. Maybe a forward ref to a later section?
=============
6.1.1.1. Topology-scoped FEC encoded using a single label (Option 1A)
[RFC7307] provides a mechanism to distribute FEC-Label bindings
scoped to a given MPLS topology (represented by MPLS MT-ID). To use
multi-topology LDP to create MRT forwarding topologies, we associate
two MPLS MT-IDs with the MRT-Red and MRT-Blue forwarding topologies,
in addition to the default shortest path forwarding topology with
MT-
ID=0.
SB> Presumably you could MRT a topology other than default?
SB> To be clear - you need 3 * the number of delivery labels in the
SB> network, and in some cases these labels identify prefix or a
SB> VPN exit point.
SB> This is a lot more labels than some of the competing schemes
SB> and so I think we really need a label table size comparison
SB> in the comparison section earlier in the document.
[Anil >>] Yes MRT needs multiple tables only then packet can
be guided to take disjoint path to destination.
The devices with higher forwarding entry capacity can choose
to use MRT.
In case of TI-LFA label stack size is a constraint, for older
devices with limited label stack capacity that would be a
serious restriction.
So point is it’s a tradeoff
SB> Indeed, it is a tradeoff, but I don't think you set out
the full tradeoff
SB> earlier in the text, and it is by no means clear that MRT
is always
SB> the best trade-off.
SB> Also you need to make it clear how large the tables are.
[ANIL 2 >> ] MRT can be a best trade off in cases where ,
Network device has low computing powers but better forwarding
capacity (access devices),
Network devices has small label stack support etc...
May be to prove the point Comparison section is needed J
SB1> If that is the constraint, then it needs to be made clear up front,
and as I noted
SB1> earlier in the thread, the comparison needs to be expanded to be
complete
SB1> and objective.
=============
6.1.1.2. Topology and FEC encoded using a two label stack (Option 1B)
With this forwarding mechanism, a two label stack is used to encode
the topology and the FEC of the packet. The top label (topology-id
label) identifies the MRT forwarding topology, while the second
label
(FEC label) identifies the FEC. The top label would be a new FEC
type with two values corresponding to MRT Red and Blue topologies.
When an MRT transit router receives a packet with a topology-id
label, the router pops the top label and uses that it to guide the
next-hop selection in combination with the next label in the stack
(the FEC label). The router then swaps the FEC label, using the
FEC-
label bindings learned through normal LDP mechanisms. The router
then pushes the topology-id label for the next-hop.
As with Option 1A, this forwarding mechanism also has the useful
property that the FEC associated with the packet is maintained in
the
labels at each hop along the MRT.
This forwarding mechanism has minimal usage of additional labels,
memory and LDP communication. It does increase the size of packets
and the complexity of the required label operations and look-ups.
This forwarding option is consistent with context-specific label
spaces, as described in [RFC 5331]. However, the precise LDP
behavior required to support this option for MRT has not been
specified.
SB> So I wonder if this should be normative text given that the
underlying
SB> control plane behavior is currently unknown?
SB> You should comment on the impact on forwarding moving from
SB> a one to a two label action at every hop along the repair path.
SB> This is not an issue that the competing approaches have and so
SB> should feature in the comparison section.
[Anil >>] I agree to move to comparison section.
============
6.1.2. MRT IP tunnels (Options 2A and 2B)
IP tunneling can also be used as an MRT transit forwarding
mechanism.
Each router supporting this MRT transit forwarding mechanism
announces two additional loopback addresses and their associated MRT
color. Those addresses are used as destination addresses for MRT-
blue and MRT-red IP tunnels respectively. The special loopback
addresses allow the transit nodes to identify the traffic as being
forwarded along either the MRT-blue or MRT-red topology to reach the
tunnel destination. Announcements of these two additional loopback
addresses per router with their MRT color requires IGP extensions,
which have not been defined.
SB> So help me understand here. How do you do this with just two
SB> loopback addresses. If I have red to a, red to b etc how
SB> do I distinguish them. Presumably you have to do this by
SB> looking inside the tunnel to find the payload. Unlike MPLS
SB> this is a much larger departure from the standard forwarding
SB> process isn't it? Again this needs to go in the comparision.
[Anil >>] I agree to move to comparison section.
Either IPv4 (option 2A) or IPv6 (option 2B) can be used as the
tunneling mechanism.
Note that the two forwarding mechanisms using LDP Label options do
not require additional loopbacks per router, as is required by the
IP
tunneling mechanism. This is because LDP labels are used on a hop-
by-hop basis to identify MRT-blue and MRT-red forwarding topologies.
6.2. Forwarding LDP Unicast Traffic over MRT Paths
In the previous section, we examined several options for providing
MRT transit forwarding functionality, which is independent of the
type of traffic being carried. We now look at the MRT ingress
functionality, which will depend on the type of traffic being
carried
(IP or LDP). We start by considering LDP traffic.
We also simplify the initial discussion by assuming that the network
consists of a single IGP area, and that all routers in the network
participate in MRT. Other deployment scenarios that require MRT
egress functionality are considered later in this document.
In principle, it is possible to carry LDP traffic in MRT IP tunnels.
However, for LDP traffic, it is very desirable to avoid tunneling.
Tunneling LDP traffic to a remote node requires knowledge of remote
FEC-label bindings so that the LDP traffic can continue to be
forwarded properly when it leaves the tunnel. This requires
targeted
LDP sessions which can add management complexity.
SB> I have been thinking a lot about this problem just recently
SB> whilst gardening, and you could take page from the SR playbook and
use the
SB> known offset approach. I guess that is a big change, but
SB> I think we might be able to use it to avoid the longstanding
distribution
SB> issue - i.e. convert the problem to offset math.
The two MRT LDP
Label forwarding mechanisms have the useful property that the FEC
associated with the packet is maintained in the labels at each hop
Atlas, et al. Expires April 17, 2016 [Page 14]
Internet-Draft MRT Unicast FRR Architecture October 2015
along the MRT, as long as an MRT to the originator of the FEC is
used. The MRT IP tunneling mechanism does not have this useful
property. Therefore, this document only considers the two MRT LDP
Label forwarding mechanisms for protecting LDP traffic with MRT
fast-
reroute.
SB> I do not understand the preceding text
===========
6.2.3. Other considerations for forwarding LDP traffic using MRT LDP
Labels
Note that forwarding LDP traffic using MRT LDP Labels requires that
an MRT to the originator of the FEC be used. For example, one might
find it desirable to have the PLR use an MRT to reach the primary
next-next-hop for the FEC, and then continue forwarding the LDP
packet along the shortest path tree from the primary next-next-hop.
SB> Does this mean that the packet looses it's MRT marking at this
point?
SB> If so can't this result in a multi-failure repair loops?
=============
6.3. Forwarding IP Unicast Traffic over MRT Paths
For IP traffic, there is no currently practical alternative except
tunneling to gain the bits needed to indicate the MRT-Blue or
MRT-Red
forwarding topology.
SB> Well isn't there a possible solution based on IPv6 options?
The choice of tunnel egress MAY be flexible
since any router closer to the destination than the next-hop can
work.
SB> Again isn't there an SRLG or other multiple failure issue with
this?
==========
6.3.1.2. Tunneling IP traffic using MRT LDP Labels (Option 1B)
The MRT LDP Label option 1B forwarding mechanism encodes the
topology
and the FEC using a two label stack as described in Section 6.1.1.2.
When a PLR receives an IP packet that needs to be forwarded on the
Red MRT to a particular tunnel endpoint, the PLR pushes two labels
on
the IP packet. The first (inner) label is the normal LDP label
learned from the next-hop on the Red MRT, associated with a FEC
originated by the tunnel endpoint. The second (outer) label is the
topology-identification label associated with the Red MRT.
For completeness, we note here a potential optimization. In order
to
tunnel an IP packet over an MRT to the destination of the IP packet
(as opposed to an arbitrary tunnel endpoint), then we could just
push
a topology-identification label directly onto the packet. An MRT
transit router would need to pop the topology-id label, do an IP
route lookup in the context of that topology-id , and push the
topology-id label.
SB> What are you optimizing - certainly not the forwarding cycles.
=============
12.2. MRT Recalculation
When a failure event happens, traffic is put by the PLRs onto the
MRT
topologies. After that, each router recomputes its shortest path
tree (SPT) and moves traffic over to that. Only after all the PLRs
have switched to using their SPTs and traffic has drained from the
MRT topologies should each router install the recomputed MRTs into
the FIBs.
At each router, therefore, the sequence is as follows:
1. Receive failure notification
2. Recompute SPT
3. Install new SPT
4. If the network was stable before the failure occured, wait a
configured (or advertised) period for all routers to be using
their SPTs and traffic to drain from the MRTs.
Atlas, et al. Expires April 17, 2016 [Page 34]
Internet-Draft MRT Unicast FRR Architecture October 2015
5. Recompute MRTs
6. Install new MRTs.
While the recomputed MRTs are not installed in the FIB, protection
coverage is lowered. Therefore, it is important to recalculate the
MRTs and install them quickly.
SB> that is one way of doing it, anothey way is to have n MRTs running
SB> ships in the night as each failure occurs and clean up later. I
think
SB> that this makes the migration timing less critical. I an not
SB> sure whether you don't need some approach like "new labels" to make
SB> this unconditionally safe.
===========
15. IANA Considerations
Please create an MRT Profile registry for the MRT Profile TLV. The
range is 0 to 255. The default MRT Profile has value 0. Values
1-200 are by Standards Action. Values 201-220 are for
experimentation. Values 221-255 are for vendor private use.
SB> I am suprised that this is not in a protocol documnet rather than
the
SB> architecture since you have no data structures or encodings in here.
16. Security Considerations
This architecture is not currently believed to introduce new
security
concerns.
SB> I suppose you could express this in terms of the parameters being
SB> carried in the existing routing and thus you inherit their security
SB> mechanisms, and that the topology boundary is set by their boundary
SB> and thus you inherit their security and privacy characteristics.
SB> I am supprised that the draft does not say anything about the
SB> management of this new approach to FRR and the OAM that you will
SB> need to test it.
===========
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
