Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

From: <[email-masked]>
Date: Wed, 1 Apr 2015 08:11:45 +0000

Hi Chris,

Thanks for the addition.
Please see inline some comments. [Bruno]

Thanks,
Regards,
Bruno

From: rtgwg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, April 01, 2015 3:10 AM
To: Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Anil,

Thanks for your input and proposed text.  I added the text below (which is a slightly modified version of your proposed text) to the most recent version which is being maintained at:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture

Tell me if you are OK with the final sentence that I added as well, or you can propose some other wording.

Thanks,
Chris

   TI-LFA:    Topology Independent Loop-free Alternate Fast Re-route
      (TI-LFA) [I-D.francois-spring-segment-routing-ti-lfa] aims to
      provide link and node protection of node and adjacency segments
      within the Segment Routing (SR) framework.  It has improved
      coverage over LFA and Remote LFA for link and node protection and
      also guarantees complete coverage.
[Bruno] The last sentence could probably be shortened by only keeping the last part. "It guarantees complete coverage"

The trade-off of looping
      traffic to improve coverage is still made.
[Bruno] I'm not sure to see what you mean. Contrary to LFA & RLFA, I don't think TI-LFA makes such tradeoff.

  The computation
      required is quite high with added complexity.
[Bruno] As in the RLFA description you have made the distinction between link and node protection, it would be fair to do the same for TI-LFA. (Link protection computation is much easier)

  TI-LFA is supported
      only for the MPLS data plane due to the requirement for the PLR to
      impose an MPLS label stack on link failure.  On certain topologies
      the label stack size can grow significantly based on repair path.
[Bruno] I agree for node failure. For link failure, this is more debatable as compared to RLFA it may require at most 1 additional label. (assuming symmetric link costs)

      Note that TI-LFA requires shortest path forwarding based on SR
      Node-SIDs, as opposed to LDP labels, in order to construct label
      stacks for backups paths without relying on a large number of
      targeted LDP sessions to learn remote FEC-label bindings.
[Bruno] It also requires Adj-SID (in order to provide 100% coverage).

From: Anil Kumar S N (VRP Network BL) [mailto:[email-masked]]
Sent: Saturday, March 28, 2015 8:10 AM
To: Alia Atlas; Robert Kebler; Chris Bowers; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Authors,

      In  "comparison of IP/LDP FRR Methods" section of the document , I feel we should add comparison with TI-LFA (draft-francois-spring-segment-routing-ti-lfa-01) where TI-LFA approach achieves guaranteed coverage  against link or node failure, in any IGP network, relying on the  flexibility of SR. This will give readers better picture and enables them with more information so that they can choose MRT if they feel it suites their requirement better; compared to IT-LFA...
Changes :

1.  Introduction :

   Other existing or proposed solutions are partial solutions or have
   significant issues, as described below.

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

                                  Table 1

   TI-LFA: Topology Independent Loop-free Alternate Fast
   Re-route (TI-LFA), aimed at providing link and node protection of
   node and adjacency segments within the Segment Routing (SR)
   framework [draft-francois-spring-segment-routing-ti-lfa-01].
   Has improved coverage over LFAs and Remote LFA for link and node
   protection and also guarantees complete coverage. The trade-off
   of looping traffic to improve coverage is still made.
  The computation required is quite high with added complexity.
   TI-LFA is supported only MPLS data plane with a requirement to
   carry additional MPLS label stack on the link failure; on certain
   topologies stack size can grow significantly based repair path.

Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Chris Bowers <[email-masked]>
Date: Wed, 1 Apr 2015 16:43:29 +0000

Bruno,

Here is proposed text to address your comments.  Tell me if this works.

With respect to the sentence: "The trade-off of looping traffic to improve coverage is still made."  I had assumed that Anil was referring to the scenario where an SRLG produces correlated link failures such that two nodes have different opinions about what the "new" topology is.  I haven't seen a specific topology that will produce looping for TI-LFA, but I also haven't seen a proof that TI-LFA avoids this type of looping.  Perhaps Anil has some insight into this topic since he proposed the text in question.  For the moment, I have removed that sentence until we get clarification.

                <t hangText="TI-LFA: ">Topology Independent Loop-free
                Alternate Fast Re-route (TI-LFA) <xref
                target="I-D.francois-spring-segment-routing-ti-lfa"/> aims to
                provide link and node protection of node and adjacency
                segments within the Segment Routing (SR) framework.  It
                guarantees complete coverage.  The TI-LFA computation for
                link-protection is fairly straightforward, while the
                computation for node-protection is more complex.  For
                link-protection with symmetric link costs, TI-LFA can provide
                complete coverage using an MPLS label stack with two labels.
                For node protection on arbitrary topologies, the label stack
                size can grow significantly based on repair path.  Note that
                TI-LFA requires shortest path forwarding based on SR
                Node-SIDs, as opposed to LDP labels, in order to construct
                label stacks for backups paths without relying on a large
                number of targeted LDP sessions to learn remote FEC-label
                bindings.  It also requires the use of Adj-SIDs to achieve
                100% coverage.

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 01, 2015 3:12 AM
To: Chris Bowers; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Chris,

Thanks for the addition.

Thanks,
Regards,
Bruno

From: rtgwg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, April 01, 2015 3:10 AM
To: Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Anil,

Thanks,
Chris

The trade-off of looping

  The computation

  TI-LFA is supported

Hi Authors,

1.  Introduction :

                                  Table 1

Thanks & Regards
Anil S N

Thank you.

---

From: <[email-masked]>
Date: Thu, 2 Apr 2015 07:42:52 +0000

Chris,

Please see inline. [Bruno]

From: Chris Bowers [mailto:[email-masked]]
Sent: Wednesday, April 01, 2015 6:43 PM
To: DECRAENE Bruno IMT/OLN; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Bruno,

With respect to the sentence: "The trade-off of looping traffic to improve coverage is still made."  I had assumed that Anil was referring to the scenario where an SRLG produces correlated link failures such that two nodes have different opinions about what the "new" topology is.
[Bruno] On my side, I had assumed that it was related to the "downstream" condition of (R)LFA.

I haven't seen a specific topology that will produce looping for TI-LFA, but I also haven't seen a proof that TI-LFA avoids this type of looping.
[Bruno] A priori, I see 2 aspects
- At least in theory, TI-LFA should be able to get 100% coverage for any considered planned failure (link, node, SRLG, any arbitrary set of "single link" failures). Hence I don't think there is a need to "improve coverage", not to mention "trade-off looping traffic"
- Any FRR solution assumes a specific failure that it wants to protect from. In reality, the failure may be more extensive than planned. A question is what happens in this case. e.g. traffic is dropped, traffic may be FRR multiple time (by multiple PLR) to provide "de facto protection" in the good cases at the risk of creating loops in the bad cases, traffic may be FRR multiple time with no risk of loops (a priori though some in-band knowledge of the previous failure). Eventually, one may further distinguish the path from the PLR to the "Merge point" (first Q node) and the path from the "Merge point" to the destination.

Perhaps Anil has some insight into this topic since he proposed the text in question.  For the moment, I have removed that sentence until we get clarification.
[Bruno] ok, thanks.

[Bruno] I would propose
OLD: using an MPLS label stack with two labels
NEW: by pushing up to two additional labels

Motivation:
- it's not _always_ 2 labels (could be 0 or 1)
- these are _additional_ labels, in addition to the size of the received stacks (or more importantly, "generated" stack for PE. pushing 2 labels looks relatively easy for a PLR but if the PLR is a L3 VPN PE using entropy label, it may have to push up tp of 6 labels (TI-LFA (2), remote PE, EL (2), VPN)

[Bruno] Looks good.
Thanks Chris.

Bruno

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 01, 2015 3:12 AM
To: Chris Bowers; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Chris,

Thanks for the addition.

Thanks,
Regards,
Bruno

Anil,

Thanks,
Chris

The trade-off of looping

  The computation

  TI-LFA is supported

Hi Authors,

1.  Introduction :

                                  Table 1

Thanks & Regards
Anil S N

Thank you.

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 2 Apr 2015 08:53:19 +0000

Hi Bruno,Chris,

          Lets not talk about number of labels. With respect to TI LFA, In our implementation we have extended number labels much more than two, Ex: when there is no PQ node also when there no adjacency b/w any  P and Q node pair.  We find a shortest path from P & Q form; a label stack that will be pushed. In case L3 VPN PE label stack could become much more. This consumes more computation.

Best effort label for a destination is Destination Label , SR FRR label for the same destination is [P Node -> Label stack to reach Q Node -> Destination label].

[Bruno] I would propose

There is a possibility of Looping in TI-LFA; We can expect in case of multiple simultanious failure:
Consider the case where packet is been forwarded towards destination from a source on backup FRR path with TI LFA backup path Statck  as below :
P Node Lable
P-Node to Q-Node Adj lable
Q-Node Lable
Destination Lable

Topology :
P----Q (Cost 10)
Q----Destination(Cost 10)
P----Destination (Cost 100)

Faliure happens on the only link b/w Q-Node towards destination; Reachability to destination with SPF calculation or with FRR falls back towards P-Node (Q's TI LFA calculation).

So there could be a loop.
So I still feel there is a tradeoff.

Thanks & Regards
Anil S N

From: [email-masked] [mailto:[email-masked]]
Sent: 02 April 2015 15:43
To: Chris Bowers
Cc: [email-masked]; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Chris,

To: DECRAENE Bruno IMT/OLN; Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Bruno,

[Bruno] I would propose

Motivation:

[Bruno] Looks good.
Thanks Chris.

Bruno

Hi Chris,

Thanks for the addition.

Thanks,
Regards,
Bruno

Anil,

Thanks,
Chris

The trade-off of looping

  The computation

  TI-LFA is supported

Hi Authors,

1.  Introduction :

                                  Table 1

Thanks & Regards
Anil S N

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 2 Apr 2015 10:32:26 +0000

Re-sending as my previous email was apparently too big.
( "too big to fail" does not work for email ;-) )

From: DECRAENE Bruno IMT/OLN
Sent: Thursday, April 02, 2015 12:24 PM To: 'Anil Kumar S N (VRP Network BL)'

Hi Anil,

Please see inline [Bruno]

From: Anil Kumar S N (VRP Network BL) [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 10:53 AM

Hi Bruno,Chris,

          Lets not talk about number of labels. With respect to TI LFA, In our implementation we have extended number labels much more than two,
[Bruno] Good job.
- For link protection only, in network with symmetric link cost, up to 2 labels may be required for. Never more than 2.
- For others cases, in particular node and/or SRLG protection, more than 2 labels may be required. In theory, there is no limit. In practice, there is a limit. In our networks, the max found was 4 labels. So it's good to be able to push more than 2 labels to enforce the FRR detour.
Ex: when there is no PQ node also when there no adjacency b/w any  P and Q node pair.  We find a shortest path from P & Q form; a label stack that will be pushed. In case L3 VPN PE label stack could become much more. This consumes more computation.

[Bruno] I would propose

There is a possibility of Looping in TI-LFA; We can expect in case of multiple simultanious failure:
[Bruno] You are right. In case of independent/non FRR planned failures, the first PLR can't avoid all failures since those failures were expected to not planned/expected to occur at the same time. The second PLR will try to protect the second failure. In good cases, the two protections are complementary and will achieve "de facto" protection. In bad cases, forwarding loop will occur. In theory, the handling of the second independent failure, is a (difficult) choice, between dropping or trying to repair. In theory TI-LFA could do both, but as of today, it tries the second protection
This is not specific to TI-LFA. FRR assumes _local_ protection (hence local knowledge) of a _pre_computed_ (hence pre-planned) failure.
I have been told ARC could handle multiple consecutive FRR (through some localize notification mechanism) but I don't have the details.
Consider the case where packet is been forwarded towards destination from a source on backup FRR path with TI LFA backup path Statck  as below :
P Node Lable
P-Node to Q-Node Adj lable
Q-Node Lable
Destination Lable

Topology :
P----Q (Cost 10)

Faliure happens on the only link b/w Q-Node towards destination; Reachability to destination with SPF calculation or with FRR falls back towards P-Node (Q's TI LFA calculation).
[Bruno] In this specific case, I don't see a loop. Q, acting as the second PLR (in a row), has computed that  node "P" is its P node and node "D" is its Q node. P is reached via a node-SID (possibly implicit label) which is not affected by the first failure. Q is reached by a Adj-sid, which is not affected by the first failure.

So there could be a loop.
[Bruno] I could not find one in this example, but I agree that we could find examples with loops.
e.g. the following topology
A - B
|  \  |
C - D

Where all links have a metric of 10, except AC 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.
So I still feel there is a tradeoff.
[Bruno] There are many tradeoff ;-). But this one is about handling a second independent failure. Not about increase coverage of a protected resource (link/node/SRLG/any)

Thanks
Regards
/Bruno

Thanks & Regards
Anil S N

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 2 Apr 2015 11:54:01 +0000

Hi Bruno,

                :) Lets finalize on the rephrased statement which need to be updated.
                Please see inline [Anil]

Thanks & Regards
Anil S N

From: [email-masked] [mailto:[email-masked]]
Sent: 02 April 2015 18:24
To: Anil Kumar S N (VRP Network BL)
Cc: [email-masked]; Alia Atlas; Robert Kebler; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Anil,

From: Anil Kumar S N (VRP Network BL) [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 10:53 AM
To: DECRAENE Bruno IMT/OLN; Chris Bowers
Cc: [email-masked]<mailto:[email-masked]>; Alia Atlas; Robert Kebler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Bruno,Chris,

[Anil] : Agreed

[Bruno] I would propose

[Anil] : I also suggested authors to add comparison with respect to ARC too.

Topology :
P----Q (Cost 10)

[Anil] : Here P would send a packet to Q and as primary path to D is lost Q would return packet back to P till P learns link b/w Q and D is down.

[Anil] : I understand Loop here but Label stack increase can you help me to understand.
Here primary path would be A->D->C  [Cost 20]  for A (LFA A->B->D->C), Primary path for B to would be B->D->C [Cost 20] (LFA B->A->D->C).
On A->C link failure A chooses A->B->D->C, On B->D failure B chooses B->A->D->C. A would send packet to B and B would send packet to A.

Here which label is inserted ?

         10
   A           B
    +---------+
    | \       |
    |  \      |
    |   \     |
    |    \10  | 10
100 |     \   |
    |      \  |
    |       \ |
    |        \|
    +---------+
 C      10      D

So I still feel there is a tradeoff.
[Bruno] There are many tradeoff ;-). But this one is about handling a second independent failure. Not about increase coverage of a protected resource (link/node/SRLG/any)
[Anil] : This Could be explicitly specified :)

Thanks
Regards
/Bruno

Thanks & Regards
Anil S N

---

From: <[email-masked]>
Date: Thu, 2 Apr 2015 13:05:44 +0000

Re-sending...

From: DECRAENE Bruno IMT/OLN
Sent: Thursday, April 02, 2015 3:00 PM
To: 'Anil Kumar S N (VRP Network BL)'
Cc: [email-masked]; Alia Atlas; Robert Kebler; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Anil,

Please see inline [Bruno2]

Thanks,
Regards,
Bruno

From: Anil Kumar S N (VRP Network BL) [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 1:52 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]; Alia Atlas; Robert Kebler; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Bruno,

Thanks & Regards
Anil S N

[...]

Consider the case where packet is been forwarded towards destination from a source on backup FRR path with TI LFA backup path Statck  as below :
P Node Lable
P-Node to Q-Node Adj lable
Q-Node Lable
Destination Lable
[Bruno2] As a side note, "Q-Node Label" is not required. (with previous label, you reach "Q". Then "Q" can directly reach the destination "D")

Topology :
P----Q (Cost 10)

[Bruno2] I understand the following topology
     10         10
P ------ Q ------- D
|                         |
+--------------+
      100

[Anil] : Here P would send a packet to Q and as primary path to D is lost Q would return packet back to P till P learns link b/w Q and D is down.
[Bruno2] Q sees the failure of QD for destination D. It will swap Node_SID (D) to  Node_SID (P), Adj_SID PD, Node_SID (D).  (In MPLS, with PHP, first and last SID may be encoded with no label)
P will see, at the topo of the stack "Adj_SID PD" and hence will send the traffic to D.
No loop.

[Anil] : I understand Loop here but Label stack increase can you help me to understand.
[Bruno2] My mistake. Sorry. I meant all links have a metric of 10, except AD which has 100
Notation:
Prefix --> Nominal Next-Hop
           => LFA Next-Hop

On node A:
C --> C
   => B, push Node_SID(D),  Node_SID(C)

On node B:
D --> D
   => A, push  Node_SID(C), Node_SID(D)

If both links AC & BD fails, each PLR (A & B) push 1 additional label (respectively to D & C). Since C & D are never reached, label are never poped. So at each iteration in the loop, an additional label is pushed.

         10
   A           B
    +---------+
    | \       |
    |  \      |
    |   \     |
    |    \10  | 10
100 |     \   |
    |      \  |
    |       \ |
    |        \|
    +---------+
 C      10      D

So I still feel there is a tradeoff.
[Bruno] There are many tradeoff ;-). But this one is about handling a second independent failure. Not about increase coverage of a protected resource (link/node/SRLG/any)
[Anil] : This Could be explicitly specified :)
[Bruno2] Indeed, how each solution handles independent failure may be indicated. However, if space is limited in the draft, this is probably not the most important metric (IMHO) has this situation should rarely happen (assuming SRLG are known and the solution protects from SRLG)

Thanks
Regards
/Bruno

Thanks & Regards
Anil S N

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 2 Apr 2015 13:15:35 +0000

Hi Bruno,

                Understood , Thanks a lot.

Thanks & Regards
Anil S N

From: rtgwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 02 April 2015 21:06
To: [email-masked]
Subject: FW: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Re-sending...

Cc: [email-masked]<mailto:[email-masked]>; Alia Atlas; Robert Kebler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers

Hi Anil,

Thanks,
Regards,
Bruno

Cc: [email-masked]<mailto:[email-masked]>; Alia Atlas; Robert Kebler; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers

Hi Bruno,

Thanks & Regards
Anil S N

[...]

Topology :
P----Q (Cost 10)

On node A:
C --> C

On node B:
D --> D

         10
   A           B
    +---------+
    | \       |
    |  \      |
    |   \     |
    |    \10  | 10
100 |     \   |
    |      \  |
    |       \ |
    |        \|
    +---------+
 C      10      D

Thanks
Regards
/Bruno

Thanks & Regards
Anil S N

Thank you.