Subject: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

From: "Susan Hares" <[email-masked]>
Date: Fri, 10 Apr 2015 09:45:28 -0400

This is a 2 week WG LC on draft-ietf-as-migration.  As discussed in the IETF
92 session, the feedback on this draft ask for a few changes in format and
generalization of implementation terms.  The authors and shepherd believe
this has been accomplish with draft-ietf-as-migration-04.txt.   This WG LC
is to determine if these revisions are acceptable to the IDR WG. 

You can see the latest document at: 

http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

Please indicate in your response "support for this version" or "no support".

Sue Hares and John Scudder

---

From: "Russ White" <[email-masked]>
Date: Fri, 10 Apr 2015 10:49:18 -0400

Support.

Russ

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
> Sent: Friday, April 10, 2015 9:45 AM
> To: idr wg
> Cc: [email-masked]
> Subject: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to
4/23/2105
> 
> This is a 2 week WG LC on draft-ietf-as-migration.  As discussed in the
IETF 92
> session, the feedback on this draft ask for a few changes in format and
> this has been accomplish with
> draft-ietf-as-migration-04.txt.   This WG LC is to determine if these
> revisions are acceptable to the IDR WG.
> 
> 
>

---

From: Jon Mitchell <[email-masked]>
Date: Sat, 11 Apr 2015 22:50:56 -0400

Support.

-Jon

> On Apr 10, 2015, at 9:45 AM, Susan Hares <[email-masked]> wrote:
> 
> This is a 2 week WG LC on draft-ietf-as-migration.  As discussed in the IETF 92 session, the feedback on this draft ask for a few changes in format and generalization of implementation terms.  The authors and shepherd believe this has been accomplish with draft-ietf-as-migration-04.txt.   This WG LC is to determine if these revisions are acceptable to the IDR WG.
>  
> Please indicate in your response “support for this version” or “no support”.
>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 12 Apr 2015 11:09:35 +0200

support for this version

Thx,
r.

On Fri, Apr 10, 2015 at 3:45 PM, Susan Hares <[email-masked]> wrote:

> IETF 92 session, the feedback on this draft ask for a few changes in format
> and generalization of implementation terms.  The authors and shepherd
> believe this has been accomplish with draft-ietf-as-migration-04.txt.
>  This WG LC is to determine if these revisions are acceptable to the IDR
> WG.
>
>
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 13 Apr 2015 20:50:40 +0000

On 4/10/15, 9:45 AM, "Susan Hares" <[email-masked]<mailto:[email-masked]>> wrote:

Hi!

<AD Hat on>

I believe that the updated document is almost where we want it to be.  In general, there is some tentative language and other things I would like fixed (most minor or nits).  Please see my comments below.

I do have one item that I think may be above “minor”: when using “Local AS”, when should the ASN be prepended?  When sending eBGP-received UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiving those eBGP UPDATEs?  If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border router will have a shorter AS_PATH).  I think this can lead to inconsistent route selection (given that the attributes are inconsistent inside the AS), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks in many (but not all) cases.   I would really like to hear others’ (beyond the authors) opinions.  [My comments #3 and #7 in the Minor section below are related to this.]

I support this document moving forward.

Wes/Shane:  Thanks for the work on this!

Alvaro.

[BTW, it may look like a lot of comments, but most of them are editorial.]

Minor Issues:

  1.  3.1 s/Within the Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer C would appear as: 64510/Within the Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer C would appear as: 64496
  2.  The word “capability” is used in several places.  While it is used correctly (from a language point of view), I think it may cause confusion with a BGP Capability (for example: “the "Internal BGP AS Migration"  capability is enabled on all iBGP sessions on that device”).  I know that in this case there is no negotiation of capabilities; just trying to make the text clearer.
  3.  3.1 (see comment #7 below) (second paragraph): s/when advertising UPDATES received from customer C/when receiving UPDATES from customer C
  4.  3.2 s/CE-A would have seen an AS_PATH of: 64496 64510 64500/CE-A would have seen an AS_PATH of: 64500 64510 64496
  5.  3.3 "Implementations MAY support a more flexible model..”  I like this, but I wonder about the relationship of this “MAY” with the “MUST NOT” in "BGP router MUST NOT use the ASN configured globally within the BGP process”.  It sounds as if there’s a contradiction: MUST NOT use it, but you MAY.  I think this contradiction can be easily solved by using “SHOULD NOT” instead of “MUST NOT”.
  6.  This document should be marked as updating rfc4271 because of the processing of the UPDATEs (section 3.3).
  7.  3.3 (See comment #3 above) "the router MUST append the configured "Local AS" ASN in the AS_PATH attribute before advertising the UPDATE to an iBGP neighbor.”  If the Local AS is not appended to the incoming UPDATE, then the border router will have a different AS_PATH than the rest of the network (which is the reason for my comment #3 above).  If you think this is a valid comment, then there are a couple of places that should be cleaned up.
  8.  3.3 I think that the “MUSTs” in the Local AS description should be “SHOULD” given that you later define the options.
  9.  4.2
     *   It may be clearer if instead of "globally configured” and "locally configured”, “New_ASN” and “Old_ASN” (or something to that effect) are used.
     *   In 3.3 you talked about the mechanism being available per-neighbor.  Do we need that same granularity here?

Nits:

  1.  Intro:
     *   Take this ("and may be vendor-specific in exact implementation”) out.
     *   s/These mechanisms are local to a given BGP Speaker and do not require negotiation with or cooperation of BGP neighbors. The deployment of these mechanisms do not need to interwork with one another to accomplish the desired results, so slight variations between existing vendor implementations exist, and will not necessarily be harmonized due to this document. However, it is necessary. . ./These mechanisms are local to a given BGP Speaker and do not require negotiation with or cooperation of BGP neighbors.  It is necessary. . .
  2.  3.1 Take out "usually configured on a per-neighbor basis."
  3.  3.2 s/legacy AS, (AS64510)./legacy AS (AS64510).
  4.  3.2 Delete the second paragraph, which starts with “In some existing implementations”.   Then for the third paragraph: s/[Third paragraph]/A tertiary mechanism, referred to as "Replace Old AS” is used to prevent routers from appending the globally configured ASN in outbound BGP UPDATEs toward directly attached eBGP neighbors that are using the "Local AS” mechanism.  Instead, only the ASN specified using “Local AS" will be prepended in the outbound BGP UPDATE toward the customer's network, restoring the AS_PATH length to what it what was before AS Migration occurred.
  5.  3.3 Delete the first paragraph.
  6.  3.3 s/These mechanisms/The mechanisms introduced in this section
  7.  3.3  Is “peer-group” a well known construct for any implementation?  If it is, then no change is needed..if not, then maybe saying a “group of peers” might work.
  8.  3.3 "When the "Local AS” capability is used, a local ASN will be provided in the configuration that is different from the globally-configured ASN of the BGP router.”  Do you want to provide some guidance here?  SHOULD/MUST it be different?  I guess there’s no real harm (from the point of view of the mechanisms defined) if it is the same..  [Later in the paragraph it says "MUST NOT use the ASN configured globally”, so I guess it is implicit that it has to be different or nothing should happen.]
  9.  3.3 s/using the local ASN configured/using the “Local AS”
  10. 4.1 s/iBGP session, (using identical ASNs)/iBGP session (i.e. using identical ASNs)
  11. 4.1 This sub-section is titled “BGP Alias”, but the mechanism is called "Internal BGP AS Migration”.  Either name is fine with me; you may want to title the section using the same name as the feature, or (if not using alias) with a more descriptive title.
  12. Ordering: Put Section 9 in an actual appendix.  It might be nice to put the Acks after the Security Considerations.

---

From: "George, Wes" <[email-masked]>
Date: Tue, 21 Apr 2015 15:26:15 -0400

Alvaro, thanks for the review, a few comments below inline:

From: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 13, 2015 at 4:50 PM
To: "George, Wes" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "John G. Scudder" <[email-masked]<mailto:[email-masked]>>, Idr <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

I do have one item that I think may be above “minor”: when using “Local AS”, when should the ASN be prepended?  When sending eBGP-received UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiving those eBGP UPDATEs?  If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border router will have a shorter AS_PATH).  I think this can lead to inconsistent route selection (given that the attributes are inconsistent inside the AS), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks in many (but not all) cases.   I would really like to hear others’ (beyond the authors) opinions.

WG] So it seems like we got only one opinion from Juan (though it was couched in terms of "C does this better than J") that we should change this and recommend appending when receiving, rather than when sending in order to maintain route consistency. This makes sense to me. Since Alvaro asked for other opinions, any opinions to the contrary before I assume that the WG supports this and make the change to the draft? Maybe someone from Juniper that has explanation on why they do it the other way, or was Juan mistaken in that assumption?

Minor Issues:

This document should be marked as updating rfc4271 because of the processing of the UPDATEs (section 3.3).

WG] Happy to make that change, but the reason that it wasn't there is that this isn't mandatory to implement. It's not globally changing the behavior of UPDATEs, but rather documenting how they change when this specific optional feature set is invoked. Someone recently gave me guidance on a different draft that it isn't always appropriate to have a draft update an old RFC if the new thing isn't mandatory to implement as a part of the old RFC I.e. A formal update in the metadata means that the two (or more) RFCs together represent a complete BGP implementation, while only implementing the original RFC (the one being updated) would be an incomplete implementation. I don't know if there is an official stance on this as far as the RFC series is concerned, so I'm open to do it either way, need guidance on how to proceed.

Nits:
WG] some of these are a little more than nits given that you're suggesting removing whole paragraphs. I'll take them under advisement and consultation with my co-author.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 21 Apr 2015 20:39:12 +0000

On 4/21/15, 1:26 PM, "George, Wes" <[email-masked]<mailto:[email-masked]>> wrote:

Wes:

Hi!

I interpret it the other way: when implementing this optional mechanisms the base RFC is updated..and only when the optional mechanisms are implemented.

Let’s go with the update marking and we can talk about it in the IESG if it comes up.

Thanks!

Alvaro.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Apr 2015 16:41:36 -0400

Alvaro,

On Mon, Apr 13, 2015 at 08:50:40PM +0000, Alvaro Retana (aretana) wrote:
> I do have one item that I think may be above ?minor?: when using ?Local AS?, when should the ASN be prepended?  When sending eBGP-received UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiving those eBGP UPDATEs?  If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border router will have a shorter AS_PATH).  I think this can lead to inconsistent route selection (given that the attributes are inconsistent inside the AS), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks in many (but not all) cases.   I would really like to hear others? (beyond the authors) opinions.  [My comments #3 and #7 in the Minor section below are related to this.]

Obviously there's a long standing history with both variations on the
feature along with a number of related but poorly (if ever) documented
behaviors to worry about.  A few here:

RFC 4271, 5.1.2 notes we don't modify the AS_PATH on advertisement to an
internal peer.  Obviously implementations do that, semantic quibbling about
doing it as part of modification of a route in adj-rib-in/loc-rib vs.
adj-rib-out aside.  Mostly a note of historical significance rather than
saying "we shouldn't do that".

Somewhat more relevant is in section 9.1.2:

:   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
:   route should be excluded from the Phase 2 decision function.  AS loop
:   detection is done by scanning the full AS path (as specified in the
:   AS_PATH attribute), and checking that the autonomous system number of
:   the local system does not appear in the AS path.  Operations of a BGP
:   speaker that is configured to accept routes with its own autonomous
:   system number in the AS path are outside the scope of this document.

That last sentence was provided to provide the little documentation
implementations had at the time on local-as.  What is not stated is the
somewhat problematic issue of the above paragraph.

The issue has to do with where an implementation does its loop detection.
Some implementations do loop detection at every BGP speaker.  Some do them
only at an ebgp edge.  Some bias this behavior based on local-as being
enabled or not.  How you do your loop detection and when heavily biases your
choice of implementation.  In implementations that only requires local-as at
your ebgp edges but do loop detection at route reflectors/external confederation
routers, adding your local-as as part of import is a problem.

So, consistency isn't only a big deal as part of when/where you do your
local-as prepend, it's also a matter of where you do loop detection.  If
implementations in the absence of some "outside the scope" implementation
were to pedantically implement the base BGP RFC, the migration mechanisms
would be a bit biased to a given solution.

-- Jeff

---

From: "George, Wes" <[email-masked]>
Date: Wed, 22 Apr 2015 17:03:59 -0400

Date: Tuesday, April 21, 2015 at 4:39 PM

WG] I thought that was the right interpretation too, but enough folks who have been at this far longer than I told me otherwise. Have a look at this thread: https://mailarchive.ietf.org/arch/search/?q=errata+rfc4659
I was never able to get a solid pointer to BCP or normative text or even RFC Editor policy to support either interpretation of what "updates" actually means in the metadata so I now have no opinion on the matter and will go with your guidance, just thought you'd want the background of what I was referring to above.

Thanks
Wes

---

From: "George, Wes" <[email-masked]>
Date: Tue, 28 Apr 2015 15:43:58 -0400

Alvaro – A few outstanding items that we may need to discuss inline below. I've posted a –05 that I believe addresses your comments and snipped them out of my response, except where noted below.

Thanks,

Wes

WG] in the appropriate places in section 3.1 and 3.3, I added "installing the route" to clarify that the behavior that it is prescribes before it sends updates is also done locally. I think this is probably the best compromise between the two different implementations that we can give short of writing a lengthy discussion along the lines of Jeff's email, including discussing this in the context of where one does loop detection, and the fact that it's a SHOULD gives us the right amount of wiggle room. Let me know if you think more changes are necessary.

Minor Issues:

WG]  Shane and I believe that the current text is correct. Can you explain why you think this needs to be changed?

 1.  The word “capability” is used in several places.  While it is used correctly (from a language point of view), I think it may cause confusion with a BGP Capability (for example: “the "Internal BGP AS Migration"  capability is enabled on all iBGP sessions on that device”).  I know that in this case there is no negotiation of capabilities; just trying to make the text clearer.

WG] you have a valid point, but we aren't exactly sure what a better word would be – tool? Switch? Feature? Option?
We thought feature sounded too vendor-y, and option was already used to identify subsets of the features we're standardizing. FWIW, 4271 uses capability in a similar way, I.e. capitalization is important to disambiguate between the two. I've left it as-is for now, because I'm not convinced that any of the alternatives I've suggested actually works well enough to change it globally.

 1.  4.2
 2.

WG] Shane and I disagree. We think that global vs local is useful, because there is a notion of a global BGP config that applies to all neighbors vs things that are neighbor-specific i.e. Local to a given neighbor.

Nits:

 1.  Intro:

WG] I removed the vendor-specific part from the abstract and intro, but I believe that the other part that you suggest removing in your second bullet above is important. We can't force vendors to implement exactly what's documented here, especially retroactively, so I think it's reasonable to acknowledge this fact.

 1.  3.2 Delete the second paragraph, which starts with “In some existing implementations”.   Then for the third paragraph: s/[Third paragraph]/A tertiary mechanism, referred to as "Replace Old AS” is used to prevent routers from appending the globally configured ASN in outbound BGP UPDATEs toward directly attached eBGP neighbors that are using the "Local AS” mechanism.  Instead, only the ASN specified using “Local AS" will be prepended in the outbound BGP UPDATE toward the customer's network, restoring the AS_PATH length to what it what was before AS Migration occurred.

WG] we think that the second paragraph is documenting existing practice/implementations deployed in the field for the purpose of context and background and think it should remain in place, and thus the proposed changes to the third paragraph are duplicative.

 1.  3.3 "When the "Local AS” capability is used, a local ASN will be provided in the configuration that is different from the globally-configured ASN of the BGP router.”  Do you want to provide some guidance here?  SHOULD/MUST it be different?  I guess there’s no real harm (from the point of view of the mechanisms defined) if it is the same..  [Later in the paragraph it says "MUST NOT use the ASN configured globally”, so I guess it is implicit that it has to be different or nothing should happen.]

WG] I'm not inclined to explicitly disallow it unless someone can think of a failure case we're trying to avoid. One would think that most implementers would be smart enough to do the right thing here, especially in light of our guidance in a few sentences about what to do if you successfully establish a BGP session with the global ASN

 1.  3.3 s/using the local ASN configured/using the “Local AS”

WG] we are not referring to the command "Local AS" but rather the actual autonomous system number provided as a parameter for the local (neighbor-specific) config, so I think the original text is more accurate.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 28 Apr 2015 21:49:45 +0000

On 4/28/15, 3:43 PM, "George, Wes" <[email-masked]<mailto:[email-masked]>> wrote:

Wes:

Hi!

. . .

Honestly, I don’t like this solution.    Your draft shouldn’t cater to a specific implementation, which is why it came back to the WG in the first place.

I would prefer to see a definite statement.  If you don’t want to exclude one of the options then pick one (SHOULD — for the "right amount of wiggle room") and then mention the other as an option (MAY).  In the end the effect is the same (no one is excluded), but the answer to “When should I prepend?” is clearer:  do it when you SHOULD (but you MAY also do it at other times).

Regardless of which way you go, the text explaining “No Prepend Inbound” can be simplified (for example, in 3.3): s/MUST NOT append the "Local AS" ASN value in the AS_PATH attribute when installing the route or advertising that UPDATE to iBGP neighbors, but/MUST NOT append the "Local AS" ASN value in the AS_PATH attribute, but

Minor Issues:

Yes.

Figure 1 looks like this:

         ------                  ------
       / ISP  A \              / ISP  B \
      | AS 64500 |            | AS 64510 |
       \        /              \        /
        -------                 -------
           |                       |
           |                       |
     ------------             -------------
     |  Cust D  |             |  Cust C   |
     | AS 64499 |             | AS 64496  |
     ------------             -------------

                        Figure 1: Before Migration

So "the AS_PATH toward customer C” (which I interpret as the path to get to C) should be simply 64496 (from B’s point of view).

Note that the rest of the sentence reads: "whereas the same RIB on ISP A' (ISP B routers post-migration) would contain AS_PATH: 64510 64496.”, which corresponds to Figure 2:

                ---------------
              /                \
             |     ISP A'       |
             |     AS 64500     |
              \                /
                ---------------
             /                  \
           /                      \
          |                         |
     ------------             -------------
     |  Cust D  |             |  Cust C   |
     | AS 64499 |             | AS 64496  |
     ------------             -------------

                         Figure 2: After Migration

Where 64510 is the Local AS.

Mechanism..?

As I said before, just trying to make the text clearer.   No one else mentioned this item (that I know), so it may be clear to everyone else.

  1.  4.2
  2.

I see where you’re coming from.  It would be nice to clarify then what you mean by global and local, maybe in the “Documentation Note” section.

Nits:

  1.  Intro:

We can’t force vendors to implement anything exactly as documented, for any case.  But we don’t call that out in all documents.

It’s nit..  I don’t think that it’s needed, but it’s just a nit.

The first paragraph says that ""Local AS" and "No Prepend Inbound", only modify the AS_PATH Attribute received…”, which seems to me to be the same thing as (in the second paragraph) ""Local AS" and "No Prepend Inbound” does not concurrently modify the AS_PATH Attribute for BGP UPDATEs that are transmitted”.  IOW, first you say that only received is modified, and then later say that outbound is not, which of course leads to the problem.

To me the second paragraph was the repetitive one and the illustration of the problem would be enough without talking about existing implementations.

Again, just a nit.

Thanks!

Alvaro.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 29 Apr 2015 11:08:50 -0400

From: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 28, 2015 at 5:49 PM

WG] I don't understand how that caters to a specific implementation, especially since several folks in the WG seem to agree that the better solution is to add the AS on receipt so that the route is consistent within the AS in order to avoid loops.

WG] Well, I'm trying to avoid either re-hashing the apparent disagreement between the vendors, having to discuss deep details about multiple vendors' implementation choices to explain the should vs may and/or being responsible for fixing an existing ambiguity in the BGP spec, especially since at least one of those things is, as you said, the reason that this draft came back to the WG in the first place. Since email is bad at conveying tone, I should be clear that while I am a bit frustrated, I'm not trying to be combative here. It appears to me that there isn't a single right answer to the question you're posing, so I don't really know what the definite statement should be, which is why I didn't make it.

The closest I've found is the last bit of Jeff's April 21 email, but even that is only discussing the gotchas, not making a definite statement:
"The issue has to do with where an implementation does its loop detection.
Some implementations do loop detection at every BGP speaker.  Some do them
only at an ebgp edge.  Some bias this behavior based on local-as being
enabled or not.  How you do your loop detection and when heavily biases your
choice of implementation.  In implementations that only requires local-as at
your ebgp edges but do loop detection at route reflectors/external confederation
routers, adding your local-as as part of import is a problem.

would be a bit biased to a given solution."

Would something like this text be the right level of background info to provide unambiguous but unbiased guidance without requiring pages of additional discussion?

WG] Ok, that seems to be a potentially useful change. Does it address your problem though? I'm kind of at a loss on how to address this better (which is why I'm frustrated, not because I don't appreciate the feedback), and could use some feedback from some other WG folk on the new text or ways to fix it without dramatically expanding the scope of the discussion in this document.

…

WG] Ah. That's the issue. It's not the path to get TO C. It's the path ANNOUNCED by B toward C. Since it's looking like there's one more revision coming, I'll  clarify that.

WG] no, but typically we're not retroactively standardizing something that’s already implemented, so it's not necessary to call it out in all documents.

Thanks
Wes

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 29 Apr 2015 16:59:04 +0000

On 4/29/15, 11:08 AM, "George, Wes" <[email-masked]<mailto:[email-masked]>> wrote:

Wes:

Hi!

Thanks for talking this out with me — I really appreciate the patience.  As you, I would also like to hear more from others; this is an important document!

. . .
WG] . . . several folks in the WG seem to agree that the better solution is to add the AS on receipt so that the route is consistent within the AS in order to avoid loops.

Ok..how about this:

       Internal: the router SHOULD append the configured "Local AS" ASN
       in the AS_PATH attribute either before installing the route or
       before advertising the UPDATE to an iBGP neighbor.  Please see section 3.3.1
       for additional guidance.

Then we would need to add a new 3.3.1 section with a short discussion of pros/cons related to the consistency and loop detection angles.

If this works for you, then we can work on the text that goes there.  [I haven’t looked at Jeff’s text in detail yet.]

Thanks!

Alvaro.