internet-drafts | 30 Jan 19:48 2015
Picon

I-D Action: draft-ietf-rtgwg-remote-lfa-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR)
        Authors         : Stewart Bryant
                          Clarence Filsfils
                          Stefano Previdi
                          Mike Shand
                          Ning So
	Filename        : draft-ietf-rtgwg-remote-lfa-11.txt
	Pages           : 30
	Date            : 2015-01-30

Abstract:
   This document describes an extension to the basic IP fast re-route
   mechanism described in RFC5286, that provides additional backup
   connectivity for point to point link failures when none can be
   provided by the basic mechanisms.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-remote-lfa-11

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

Stewart Bryant | 30 Jan 19:10 2015
Picon

Adrian Farrel's Comments on draft-ietf-rtgwg-remote-lfa

Comment (2015-01-06 for -10)

SB> Adrian here is the commentary on the resolution
of your comments:

Although it causes some pain with abbreviations and a little more care
in explanation, you need to put the Introduction as the first section in
the document. The RFC editor will insist on this, so it is better if you
do it now and get the wording exactly how you would like it.

SB> I have put the following introduction before the definition of terms:

"RFC 5714 [RFC5714] describes a framework for IP Fast Re-route (IPFRR)
and provides a summary of various proposed IPFRR solutions. A basic
mechanism using loop-free alternates (LFAs) is described in  that
provides good repair coverage in many topologies, especially those
that are highly meshed. However, some topologies, notably ring based
topologies are not well protected by LFAs alone because there is no
neighbor of the point of local repair (PLR) that has a cost to the
destination without traversing the failure that is cheaper than the
cost to the destination via the failure."

"The method described in this document extends LFA approach
described in to cover many of these cases by tunneling the packets
that require IPFRR to a node that is both reachable from the
PLR and can reach the destination."

SB> Then the old introduction is renamed Overview of Solution and
starts with

(Continue reading)

Joel M. Halpern | 23 Jan 22:08 2015

RtgDir review: draft-ietf-rtgwg-cl-use-cases-06.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see ​ 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-rtgwg-cl-use-cases-06.txt
     Advanced Multipath Use Cases and Design Considerations
Reviewer: Joel M. Halpern
Review Date: 23-January-2015
IETF LC End Date: N/A
Intended Status: Informational

Summary: No issues found. This document is ready for publication.

Minor note: This draft appears to have expired.

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
(Continue reading)

Pascal Thubert (pthubert | 22 Jan 16:28 2015
Picon

FW: New Version Notification for draft-thubert-rtgwg-arc-03.txt

Dear all:

Please note that at long last, we submitted an update of the ARC draft
http://www.ietf.org/internet-drafts/draft-thubert-rtgwg-arc-03.txt  
This draft is an informative work that lays out the base concepts of the ARCs technology.

The update adds indications on:
- OAM frames
- Application of MPLS and Segment Routing techniques to implement ARCs, 
- reliable flooding over an ARC set,
- centralized ("SDN") computation and (microloop-less) update injection,
- problems that ARCs can help solve, such as Olympic Rings and multiple failures (SRLG). 

We also republished the ARC vs. MRT draft
(http://www.ietf.org/internet-drafts/draft-thubert-rtgwg-arc-vs-mrt-01.txt ) as a refresher,
with no significant change.

Cheers,

Pascal

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: jeudi 22 janvier 2015 14:18
To: Patrice Bellagamba (pbellaga); Pascal Thubert (pthubert); Patrice Bellagamba (pbellaga); Pascal
Thubert (pthubert)
Subject: New Version Notification for draft-thubert-rtgwg-arc-03.txt

A new version of I-D, draft-thubert-rtgwg-arc-03.txt has been successfully submitted by Pascal Thubert
and posted to the IETF repository.
(Continue reading)

internet-drafts | 19 Jan 19:17 2015
Picon

I-D Action: draft-ietf-rtgwg-mrt-frr-algorithm-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute
        Authors         : Gabor Sandor Enyedi
                          Andras Csaszar
                          Alia Atlas
                          Chris Bowers
                          Abishek Gopalan
	Filename        : draft-ietf-rtgwg-mrt-frr-algorithm-02.txt
	Pages           : 61
	Date            : 2015-01-19

Abstract:
   A complete solution for IP and LDP Fast-Reroute using Maximally
   Redundant Trees is presented in [I-D.ietf-rtgwg-mrt-frr-
   architecture].  This document defines the associated MRT Lowpoint
   algorithm that is used in the default MRT profile to compute both the
   necessary Maximally Redundant Trees with their associated next-hops
   and the alternates to select for MRT-FRR.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-algorithm/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-algorithm-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-algorithm-02
(Continue reading)

internet-drafts | 13 Jan 10:34 2015
Picon

I-D Action: draft-ietf-rtgwg-lfa-manageability-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Operational management of Loop Free Alternates
        Authors         : Stephane Litkowski
                          Bruno Decraene
                          Clarence Filsfils
                          Kamran Raza
                          Martin Horneffer
                          Pushpasis Sarkar
	Filename        : draft-ietf-rtgwg-lfa-manageability-07.txt
	Pages           : 22
	Date            : 2015-01-13

Abstract:
   Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
   ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic
   (and MPLS LDP traffic by extension).  Following first deployment
   experiences, this document provides operational feedback on LFA,
   highlights some limitations, and proposes a set of refinements to
   address those limitations.  It also proposes required management
   specifications.

   This proposal is also applicable to remote LFA solution.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/

There's also a htmlized version available at:
(Continue reading)

Alia Atlas | 5 Jan 19:10 2015
Picon

Re: Adrian Farrel's Discuss on draft-ietf-rtgwg-remote-lfa-09: (with DISCUSS and COMMENT)

[+rtgwg mailing list]

Adrian,

Thanks very much for working through the example.  It was very interesting
to see an understanding by someone who isn't as close to the problem-space
and helped pick up on imprecisions and lack of clarity in the definitions.

Not to speak for Stewart - whom I'm sure will be responding quite soon, but...

On Mon, Dec 29, 2014 at 11:09 AM, Adrian Farrel <adrian <at> olddog.co.uk> wrote:
Adrian Farrel has entered the following ballot position for
draft-ietf-rtgwg-remote-lfa-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-remote-lfa/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm placing this Discuss because I found the description of the
algorithm in 4.2.1 and the worked example in Section 2 to be at odds
with the definitions of P-space, extended P-space, and Q-space.

I have been able to make things work by messing with the algorithm and
keeping the current definitions. You could probably do it by keeping
the algorithm and messing with the definitions.

Yes - we want to keep the algorithm.  In particular, the pseudo-code gets it
write and the definitions are a little sloppy.   Stewart clarified a bit around the
extended P-space not including paths through the failed link in the text before
I put it to the IESG.

 
My workings were as follows, based on the example in Section 2:

>            S---E
>           /     \
>          A       D
>           \     /
>            B---C
>
>  In Figure 1 S can reach A, B, and C without going via E;
>  these form S's extended P-space.

First, this should say "via S-E" and "extended P-space with respect to
S-E".

But...
>  Extended P-space
>                 The union of the P-space of the neighbours of a
>                 specific router with respect to the protected link

(Noting that 4.2.1.2 changes this definition *significantly* by saying
that the neighbour at the far end of the failing link - i.e., E in this
case - must be excised from the list of neighbours whose P-spaces are
combined).

To be fair, the definition of P-space (below) includes that the paths
can't transit the protected link (S-E in the example).

I think that the definition needs to be updated to be "the neighbors of a
specific router that are reachable without going via the protected link".

When there's only a single link S-E, S has no direct way of forcing traffic
to E so E's P-space can't be included. 

...and...
>  P-space        P-space is the set of routers reachable from a
>                 specific router using the normal FIB, without any path
>                 (including equal cost path splits) transiting the
>                 protected link.

Now, S's neighbours are A and E.
The P-space of A with respect to S-E is {B, C}
And the P-space of E with respect to S-E is {C, D}
So the extended P-Space of S with respect to S-E is {B, C, D}

Something is broken!

Yes, can't include the P-space of E when the failed link is S-E and there's
no way to reach E directly (one hop) from S.
 
{A, B, C} is not even the (not extended) P-space of S with respect to
S-E which is {A, B} since C is not in that set because of SEDC.
On the other hand {A, B, C} *is* the extended P-space of E wrt S-E.

Although, I would observe that the pseudocode in 4.2.1 does derive
A, B, C as the extended P-space of S wrt S-E, but I think that is
because it has an entirely different definition of an extended P-space.

?? Because it omits E?  Do you see anything else different that needs
to be better clarified? 
 
Now...
>  Q-space        Q-space is the set of routers from which a specific
>                 router can be reached without any path (including
>                 equal cost path splits) transiting the protected link.
...so the Q-space of S wrt S-E is {A, B} since CDES.
And, for the record, the Q-space or E wrt S-E is {C, D}

Now, to compound the confusion, the example determines the PQ nodes for
S wrt S-E by taking the intersection of the extended P-space for S wrt
S-E  and the Q-space of E wrt S-E. This is done notwithstanding the
definition...

>  PQ node        A node which is a member of both the P-space and the
>                 Q-space.  Where extended P-space is in use it is a
>                 node which is a member of both the extended P-space
>                 and the Q-space.  In remote LFA this is used as the
>                 repair tunnel endpoint.

Yup - so clearly it means "of both the extended P-space of the PLR (S) and
the Q-space of the far-end of the failed link (E)".  Some improved definitions
are definitely needed. 
 
This definition gives the PQ nodes of S wrt SE as either
- the intersection of {A, B} and {A, B} if P-space is being discussed
or
- the intersection of {B, C, D} and {A, B} if extended P-space is being
  used.

So the correct tunnel end point for your example is B.
But it clearly doesn't work since traffic to E that is tunneled to B may
still be ECMP routed back along BAS.

So I think in this whole example, you sit at S and you say "I want to
protect traffic to E". Then you work out the extended P-space of *E* wrt
S-E (which is {A, B, C}) and the Q-space of *E* wrt S-E (which is
{C, D}) giving you the correct PQ node for S to use to protect traffic
to E in the event of a failure of S-E as C.

Extended-P space is the space that the PLR S can send traffic to - what nodes
can it reach without using the failed link.

Q-space is what nodes can reach the far-end E of the failed-link S-E without using
the failed link.

Obviously the definitions need improvement.
 
It is simple! All you have to do is update the text to describe the
actual process and not the wrong one. Then the right result will pop
out :-)

The replacement is
OLD
   In Figure 1 S can reach A, B, and C without going via E;
   these form S's extended P-space.
NEW
   In Figure 1 S can reach A and B without going via S-E, and
   D can reach B and C without going via S-E. So E's extended P-space
   with respect to S-E is the nodes A, B, and C.
END


BUT, given all of this, are you sure that Section 4.2.1 is right? I'm
not.

Yes, not concerned about that.  You are just high-lighting some imprecisions
and lack of clarity in the definitions. 
 
------

Shouldn't the pseudocode in 4.3 be enclosed in code component macros to
match with the copyright TLP etc.?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is not my area of expertise so please excuse the brevity of the
rest of this review.

---

Please s/draft/document/ throughout (except the boilerplate and
filename) so that it can be published as an RFC (which is not a draft).

---

Although it causes some pain with abbreviations and a little more care
in explanation, you need to put the Introduction as the first section in
the document.

---

You are using RFC 5714 as a Normative Reference by making me go there
for the definition of terms. Please move it to the correct section.

---

IMHO your definition of FIB is rather loose.  Fortunately (?) "FIB" is
barely used in this document, so it might not be important, but if you
wanted to fix it:
- you are talking about IP packets in this document

Mostly MPLS actually...
 
- the actions are, I think, limited to forwarding actions

---

This comment applies iff the resolution of the Discuss is not a complete
change to the terminology!

I think definitions need to be tighter or omitted from this part of the
document. The definitions in 4.2.1 are more verbose and probably for
good reason. If you feel you need to retain these definitions early in
the document and can't lift the text from 4.2.1 then you need to address
the concerns below.

   P-space        P-space is the set of routers reachable from a
                  specific router using the normal FIB, without any path
                  (including equal cost path splits) transiting the
                  protected link.

"the protected link"? There is only one protected link?

Since the example is worded as...

                  For example, the P-space of S with respect to link
                  S-E, is the set of routers that S can reach without
                  using the protected link S-E.

...I think you need...

   P-space        The P-space of a router with respect to a specific
                  protected link is the set of routers reachable from
                  the specific router using the normal FIB, without any
                  path (including equal cost path splits) transiting the
                  protected link.

Similarly, you need...

   Extended P-space
                  The union of the P-spaces of all of the neighbours of
                  a specific router with respect to a single specific
                  protected link (see Section 4.2.1.2).

But note that 4.2.1.2 makes a significant change to this definition.

   Q-space        The Q-space for a specific router with respect to a
                  specific protected link is the set of routers from
                  which the specific router can be reached without any
                  path (including equal cost path splits) transiting the
                  protected link.

   PQ node        A PQ node is a node which is a member of both the
                  P-space and the Q-space for the same router and with
                  respect to the same protected link.

                  Where extended P-space is being discussed, a PQ node
                  is a node which is a member of both the extended
                  P-space and the Q-space for the same router and with
                  respect to the same protected link.

                  In remote LFA the repair tunnel endpoint is a PQ node.

Throughout the text, however, the terms are used rather loosely. For
example, when discussing Figure 1 you say "S's extended P-space", but
this is really "S's extended P-space with respect to S-E". Someone
familiar with the work might say that it is obvious from the context
that we are discussing the link S-E, and it is, but the terminology
needs to be tight.

---

There is some difficult terminology in Section 2

   If all link costs are equal, the link S-E cannot be fully protected
   by LFAs.  The destination C is an ECMP from S, and so can be
   protected when S-E fails, but D and E are not protectable using LFAs.

Is it the link or the node that is protected (or the traffic)? Perhaps
this could be rewritten to be less ambiguous.

---

Section 2

   B
   has equal-cost paths via B-A-S-E and B-C-D-E and so may go through
   S-E.

I don't think B is going anywhere. Maybe...

   B
   has equal-cost paths to E via B-A-S-E and B-C-D-E and so may reach E
   through S-E.

---

Section 2

   In MPLS networks the targeted LDP
   protocol needed to learn the label binding at the repair tunnel
   endpoint is a well understood and widely deployed technology.

But it would still benefit from a citation or a forward reference to
section 7.

---

I enjoyed 3.2

   relatively rare as is the incidence of failure in a well managed
   network.

So, managing my network well is protection against back-hoes. Nice.

LOL - the argument is about the set-up time to be protected again and what
is the interval between failures.  The editors and WG have decided that this
trade-off is acceptable - but I'd also prefer to see it more clearly articulated.
 
---

In 3.2

   Multiple
   repairs MAY share a tunnel end point.

1. s/repairs/repair tunnels/
2. s/MAY/may/ since this is not an implementation or operational choice,
   but a fact of life.

---

In 4.2 you have truncated...

   The repair tunnel endpoint needs to be a node in the network
   reachable from S without traversing S-E.

...and...

   o  The repair tunneled point MUST be reachable from the tunnel source
      without traversing the failed link; and

You mean "reachable using the normal FIB" I think.

Not quite because if the repair tunnel endpoint is in the extended P-space and
not the P-space, then S has to force the first hop rather than send it via the normal FIB. 

 ---

Section 4.3

   The preceding text has mostly described the computation of the remote
   LFA repair target (PQ) in terms of the intersection of two
   reachability graphs computed using SPFs.

"mostly"?

"reachability graphs"? Were they? Or were they reachability sets?

---

Your pseducode in 4.3 invokes an unresolved (and undescribed) function
Compute_Forward_SPF().

Actually, I think this is a bogus line that can be deleted.

---

4.3 has

                          if ( D_opt(n, y) <
                                  D_opt(n,self) + D_opt)(self, y)

Surely this is

                          if ( D_opt(n, y) <
                                  D_opt(n,self) + D_opt(self, y) )

---

I think the introduction of "pseudonode" in 4.3 may be a little without
context.

---

Section 7
   If for any reason the TLDP session cannot
   not be established

s/cannot not/cannot/

---

I think [RFC5424] and [RFC3411] are pretty poor references to give in
section 7. You appear to be saying that an implementation that cannot
establish a TLDP session should write a MIB module, standardise it, and
then report an error.

Can't you find an existing LDP MIB module that reports Session-up
failures?

Or maybe just delete "using any well known mechanism such as Syslog
[RFC5424] or SNMP [RFC3411]."

---

Why is the discussion of microloops on network re-converges considered
to be a management consideration (by inclusion in Section 9). Surely it
is a deployment or operational consideration.

I wanted that text somewhere in the doc.  Adding an operational considerations
section to put it in would be fine. 

 
---

I think you can strengthen the security considerations. You have:

   To prevent their use as an attack vector IP repair tunnel endpoints
   (where used) SHOULD be assigned from a set of addresses that are not
   reachable from outside the routing domain.

1. "To prevent their use" is surely consistent with a "MUST".
   The fact that you want to say "SHOULD" means that you need to turn
   the text around...

   IP repair tunnel endpoints (where used) SHOULD be assigned from a set
   of addresses that are not reachable from outside the routing domain.
   This would prevent their use as an attack vector.

2. You can add a note about what traffic can be placed into a repair
   tunnel. You already have this earlier in the document, and it is
   worth restating.

3. I think you should also make note of whether the repair tunnel is
   advertised by the routing protocol as an available link.

I agree on the comments otherwise.

Regards,
Alia

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Yangang | 28 Dec 06:57 2014

About new route-policy yang model./////转发: New Version Notification for draft-yan-rtgwg-routing-policy-yang-00.txt

Hi, All

   My colleague and me just finish the draft of route-policy yang model, and submit on rtgwg yesterday. If you
have time, please review it and provide your comments.

   Right now, almost all routing protocol's yang model already is processing, just no policy model, so we
prepare it. 

   Through we know there are much different in route-policy, we still provide the most detail that we can
provide, we don't assume what is the basic model and what is the expansibility. We think maybe we can gather
all difference at first, and then we can get a abstract model that easy to expand. Maybe it can improve the progress.

   Finally, still about the review comments. All of your comments will be welcome always.

Thanks a lot.
Yangang.

-----邮件原件-----
发件人: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
发送时间: 2014年12月27日 15:12
收件人: Zhuangshunwan; Zhuangshunwan; Yangang; Yangang
主题: New Version Notification for draft-yan-rtgwg-routing-policy-yang-00.txt


A new version of I-D, draft-yan-rtgwg-routing-policy-yang-00.txt
has been successfully submitted by Shunwan Zhuang and posted to the IETF repository.

Name:		draft-yan-rtgwg-routing-policy-yang
Revision:	00
Title:		Yang Data Model for Routing Policy
Document date:	2014-12-27
Group:		Individual Submission
Pages:		50
URL:            http://www.ietf.org/internet-drafts/draft-yan-rtgwg-routing-policy-yang-00.txt

Status:         https://datatracker.ietf.org/doc/draft-yan-rtgwg-routing-policy-yang/

Htmlized:       http://tools.ietf.org/html/draft-yan-rtgwg-routing-policy-yang-00



Abstract:
   This document defines a YANG data model that can be used to configure
   and manage routing policies.


                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
internet-drafts | 15 Dec 16:11 2014
Picon

I-D Action: draft-ietf-rtgwg-rlfa-node-protection-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : Remote-LFA Node Protection and Manageability
        Authors         : Pushpasis Sarkar
                          Hannes Gredler
                          Shraddha Hegde
                          Chris Bowers
                          Stephane Litkowski
                          Harish Raghuveer
	Filename        : draft-ietf-rtgwg-rlfa-node-protection-01.txt
	Pages           : 16
	Date            : 2014-12-15

Abstract:
   The loop-free alternates computed following the current Remote-LFA
   [I-D.ietf-rtgwg-remote-lfa] specification gaurantees only link-
   protection.  The resulting Remote-LFA nexthops (also called PQ-
   nodes), may not gaurantee node-protection for all destinations being
   protected by it.

   This document describes procedures for determining if a given PQ-node
   provides node-protection for a specific destination or not.  The
   document also shows how the same procedure can be utilised for
   collection of complete characteristics for alternate paths.
   Knowledge about the characteristics of all alternate path is
   precursory to apply operator defined policy for eliminating paths not
   fitting constraints.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-protection-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-rlfa-node-protection-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Alia Atlas | 12 Dec 01:00 2014
Picon

AD review comments on draft-ietf-rtgwg-remote-lfa-08

I have done my usual AD review of this draft before progressing it.
Thanks for the hard work on this!

I have a number of different comments on the draft, as given below.
None of them are sufficient for me to be concerned about starting the 
IETF Last Call, but please address them as soon as possible.

Assuming an updated draft will appear and a quiet IETF Last Call, I expect
this to be on the IESG telechat in early Jan.


Minor Comments:

1) In Sec 2, 3rd paragraph, in the sentence: 
"The single node in both S's P-space and E's Q-space is C; thus node C is selected as the repair tunnel's end-point."
it should be "S's extended P-space"

2) In Sec 2, it says: "The non-failure traffic distribution is not disrupted by the provision of such a tunnel since it is only used for repair traffic and MUST NOT be used for normal traffic."
This is obviously correct and good - but I think it would be very useful to clarify that OAM traffic to test the rLFA may transit the tunnel at any time.  Otherwise, the MUST NOT could cause some confusion - depending on how one thinks about "normal traffic".

3) In Sec 3:  I can't parse "Examples of worse failures are node failures (see Section 6 ), and through the failure of a shared risk link group (SRLG), the through the independent concurrent failure of multiple links, and these are out of scope for this specification."

I think you mean "Examples of worse failures are node failures (see Section 6), the failure of a shared risk link group (SRLG), the independent concurrent failures of multiple links; protecting against such worse failures is out of scope for this specification."  I would add in the failure of broadcast interfaces and NBMA interfaces for completeness, even though that was mentioned in Sec 2.

4) In Sec 4.2: " Provided both these requirements are met, packets forwarded over the repair tunnel will reach their destination and will not loop."  Please change to:
"will not loop after the single link failure".  Of course, looping can happen if a worse failure than protected against occurs - as with LFA.  This could also be mitigated by requiring that the PQ node is downstream of the PLR, as  is mentioned in Sec 4.2.2.

5) In Sec 4.2.1.2: "This may be calculated by computing an SPT at each of S's neighbors (excluding E) and excising the subtree reached via the path N->S->E."  
As described here, a node Y that is reached via N->S->A would be considered to be in S's extended P-space.  I realize that one would assume that Y would be in S's P-space anyway and thus it is safe to not care about this edge case.  However, the ECMP considerations make it more complex so please at a minimum add in the same caveat as in Sec 4.2.1.2  "(including those routers which are members of an ECMP that includes link S-E)" suitably modified.  In the cost-based version in Compute_Extended_P_Space, this is handled by ignoring any potential node from N whose shortest path goes back through S.  It'd be nice if the two methods were consistent.

6) In Sec 4.2.2: "As described in [RFC5286], always selecting a PQ node that is downstream with respect to the repairing node, prevents the formation of loops when the failure is worse than expected."  Could you clarify that the PQ node is downstream with respect to the repairing node and the destination - rather than the proxy destination E?  I'm fairly certain that the latter wouldn't work (but don't have an example topology created).  If you disagree, let me know and I'll work on creating one.   This is the constraint that is expressed in Apply_Downstream_Constraint().

7) In Sec 4.3: "The reader is referred to [I-D.psarkar-rtgwg-rlfa-node-protection] for further information on the use of RLFA for node repairs." Can you add "and broadcast or NBMA link repairs"?   Do you feel that is accurate? 

8) In Sec 6: s/"When the failure is a node failure rather than a link failure"/"When the failure is a node failure rather than a point-to-point link failure"

9) In Sec 6: "Alternatively one might choose to assume that the probability of a node failure and microloops forming is sufficiently rare that the case can be ignored."  Can you please clarify from microloops to "microloops forming due to use of alternates"?  We know that in cases where a rLFA is necessary, that neighbor isn't loop-free and so regular microloops due to reconvergence will form.

10) In Sec 7: "In the absence of a protocol to learn the preferred IP address for targeted LDP, an LSR should attempt a targeted LDP session with the Router ID [RFC2328] [RFC5305] [RFC5340], unless it is configured otherwise."  Can you please add in some text for how this would work for IPv6?  I believe that there are current drafts discussing carrying Routable IP addresses (e.g. http://datatracker.ietf.org/doc/draft-ietf-ospf-routable-ip-address/ ).  We know that there is interest in having IPv6 only networks with MPLS - so it'd be good not to create new gaps.

11) In Sec 8.4: "In an MPLS network, this is achieved without any scaleability impact, as the tunnels to the PQ nodes are always present as a  property of an LDP-based deployment."  The targeted LDP sessions don't have a scaleability impact?  That the repair tunnels don't need to be specifically created as new tunnels, I agree with - but this statement is overselling.  Please make the technical point more clearly.

12) In Sec 9:  I feel like here is a good place at least mention the issues with microloops from reconvergence.  Since reconvergence after rLFA is going to result in a local microloop (depending on timing), at least a reference to https://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-03 with a recommendation to consider it is important.  Otherwise, the rLFA repair happens and then traffic microloops and is lost.  The fact that these local microloops occur with real impact much more with rLFA (or any advanced FRR technique) is an important management consideration.

13) Sec 12:  Saying "To prevent their use as an attack vector the repair tunnel endpoints SHOULD be assigned from a set of addresses that are not reachable from outside the routing domain." is basically empty words without more behind Sec 7 default of using Router IDs.  Can you find a reference that talks about a BCP for Router IDs not being reachable addresses outside the routing domain?  Can you describe how to use the IGP extensions?

Nits:

a) In Sec 4.2.1.1: "The exclusion of routers reachable via an ECMP that includes S-E prevents the forwarding subsystem attempting to a repair endpoint via the failed link S-E."
s/attempting to a repair/from attempting to use a repair

b) In Sec 10: "We propose "Remote LFA" as a natural second step."  This is going to be an RFC - so rather than propose, try specify.

Thanks,
Alia

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Alia Atlas | 9 Dec 23:46 2014
Picon

routing area design team on dataplane encapsulation considerations

I have chartered a Routing Area Design Team to work on data-plane encapsulation considerations.

I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant.  Please keep any conversation in one place on routing-discussion.

Erik Nordmark has kindly agreed to lead this design team.  The members of the design
team are:

  Erik Nordmark <nordmark <at> sonic.net>
  Jesse Gross <jgross <at> vmware.com>
  Jon Hudson <jon.hudson <at> gmail.com>
  Larry Kreeger (kreeger) <kreeger <at> cisco.com>
  Pankaj Garg <Garg.Pankaj <at> microsoft.com>
  Pat Thaler <pthaler <at> broadcom.com>
  Tom Herbert <therbert <at> google.com>

The mailing list, rgt-dt-encap-considerations <at> ietf.org, is closed but the archives are
publicly available at:

The Design Team is chartered as follows:

There have been multiple efforts over the years that have resulted in new or modified data plane behaviors involving encapsulations. That includes IETF efforts like MPLS, LISP, and TRILL but also industry efforts like Vxlan and NVGRE.  These collectively can be seen as a source of insight into the properties that data planes need to meet.  The IETF is currently working on potentially new encapsulations in NVO3 and SFC and considering working on BIER. In addition there is work on tunneling in the INT area.

This is a short term design team chartered to collect and construct useful advice to parties working on new or modified data plane behaviors that include additional encapsulations.  The goal is for the group to document useful advice gathered from interacting with ongoing efforts.  An Internet Draft will be produced for IETF92 to capture that advice, which will be discussed in RTGWG.

Data plane encapsulations face a set of common issues such as:

  * How to provide entropy for ECMP
  * Issues around packet size and fragmentation/reassembly
  * OAM - what support is needed in an encapsulation format?
  * Security and privacy.
  * QoS
  * Congestion Considerations
  * IPv6 header protection (non-zero UDP checksum over IPv6 issue)
  * Extensibility - e.g., for evolving OAM, security, and/or congestion control
  * Layering of multiple encapsulations e.g., SFC over NVO3 over BIER

The design team will provide advice on those issues. The intention is that even where we have different encapsulations for different purposes carrying different data, each such encapsulation doesn’t have to reinvent the wheel for the above common issues.

The design team will look across the routing area in particular at SFC, NVO3 and BIER. It will not be involved in comparing or analyzing any particular encapsulation formats proposed in those WGs and BoFs but instead focus on common advice.

Regards,
Alia
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Gmane