Skip to main content

Using Conditional Router Advertisements for Enterprise Multihoming
RFC 8475

Revision differences

Document history

Date Rev. By Action
2018-10-12
08 (System)
Received changes through RFC Editor sync (created alias RFC 8475, changed abstract to 'This document discusses the most common scenarios of connecting an enterprise …
Received changes through RFC Editor sync (created alias RFC 8475, changed abstract to 'This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios.  The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic.  The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue.  It also proposes using Router Advertisements to influence the host source address selection.  It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases.  In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.', changed standardization level to Informational, changed state to RFC, added RFC published event at 2018-10-12, changed IESG state to RFC Published)
2018-10-12
08 (System) RFC published
2018-10-11
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-09-24
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-08-30
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-08-23
08 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2018-08-21
08 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-08.txt
2018-08-21
08 (System) New version approved
2018-08-21
08 (System) Request for posting confirmation emailed to previous authors: Jen Linkova , " mstucchi@ripe.net"
2018-08-21
08 Jen Linkova Uploaded new revision
2018-08-15
07 (System) IANA Action state changed to No IC from In Progress
2018-08-15
07 (System) IANA Action state changed to In Progress
2018-08-15
07 (System) RFC Editor state changed to EDIT
2018-08-15
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-08-15
07 (System) Announcement was received by RFC Editor
2018-08-15
07 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2018-08-15
07 Cindy Morgan IESG has approved the document
2018-08-15
07 Cindy Morgan Closed "Approve" ballot
2018-08-15
07 Cindy Morgan Ballot approval text was generated
2018-08-10
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-08-10
07 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-07.txt
2018-08-10
07 (System) New version approved
2018-08-10
07 (System) Request for posting confirmation emailed to previous authors: Jen Linkova , " mstucchi@ripe.net"
2018-08-10
07 Jen Linkova Uploaded new revision
2018-08-05
06 Warren Kumari
As discussed on telechat, if ietf-rtgwg-enterprise-pa-multihoming enters RFC Editor queue before draft-ietf-v6ops-conditional-ras is published as an RFC, we might ask for this to be held, …
As discussed on telechat, if ietf-rtgwg-enterprise-pa-multihoming enters RFC Editor queue before draft-ietf-v6ops-conditional-ras is published as an RFC, we might ask for this to be held, and the reference to ietf-rtgwg-enterprise-pa-multihoming to be replaced with the RFC.
2018-08-05
06 Warren Kumari Discussion 2018-08-05:  Jen Linkova will submit a new version (-07) addressing Sureshe's comments.
2018-08-02
06 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2018-08-02
06 Cindy Morgan Changed consensus to Yes from Unknown
2018-08-02
06 Suresh Krishnan
[Ballot comment]
* Section 3.1.1.

I think a reference to RFC3704 (specifically written for describing ingress filtering for multihomed networks) might be a good addition …
[Ballot comment]
* Section 3.1.1.

I think a reference to RFC3704 (specifically written for describing ingress filtering for multihomed networks) might be a good addition here to RFC2827

* Sections 3.2.1., 3.2.2. etc.

=> I think it is important to specify (at least the bounds of) the valid lifetimes here as well. e.g. when the preferred lifetime is getting set to zero it is important to specify that the valid lifetime is set to a non zero value so that the host will form an address at all (even though it will not be used when there are preferred addresses). This is important to reduce the potential packet losses when the preferred uplink goes down.

* Section 3.2.2.

I think there is some text missing here about VRRP priorities here. There seems to be an assumption in the draft that the uplink A failure will lead to R1 becoming backup ("If ISP_A uplink is down, then R1 becomes a backup.") and this is not obvious at all. There needs to be a priority change with interface tracking if this has to happen and the backup has to take over as the master.
2018-08-02
06 Suresh Krishnan [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan
2018-08-02
06 Jean Mahoney Request for Telechat review by GENART Completed: Ready. Reviewer: Wassim Haddad.
2018-08-01
06 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-08-01
06 Benjamin Kaduk
[Ballot comment]
I'll echo Mirja and Spencer's question about the "empty" security considerations.  (I actually don't much
care for the "This memo introduces no new …
[Ballot comment]
I'll echo Mirja and Spencer's question about the "empty" security considerations.  (I actually don't much
care for the "This memo introduces no new security considerations" formulation in general, unless it's
literally the only content of the section -- it's either followed by new security considerations, in which
it's just wrong, or followed by calling out specific portions of the referenced security considerations that
are particularly relevant.  In the latter case, it seems useful to provide more of a lead-in like "The general
security considerations of [X] and[Y] apply, and in particular [...]".)

Unfortunately, I don't seem to be in a good position to comment on actual additions to the security considerations
section, since I don't have a clear picture of what the proposal in this document actually changes when compared
to current/normal practices.  This is presumably just a matter of my lacking the appropriate background knowledge
for the routing bits, but in a scenario like Figure 3, with distinct edge and first-hop routers, what kind of RAs would the
first-hop routers normally be sending?  Would they be announcing the routes in question here just without the
PIO markings, or not advertising anything at all, or something else?

Other than that, thanks for the well-written document!
2018-08-01
06 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-08-01
06 Ben Campbell [Ballot comment]
I share the confusion about the relationship to ietf-rtgwg-enterprise-pa-multihoming in the abstract.
2018-08-01
06 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-08-01
06 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-08-01
06 Alissa Cooper
[Ballot comment]
I, too, was confused about the references to ietf-rtgwg-enterprise-pa-multihoming in the abstract, so would support the fixes previously suggested. Furthermore, the places where …
[Ballot comment]
I, too, was confused about the references to ietf-rtgwg-enterprise-pa-multihoming in the abstract, so would support the fixes previously suggested. Furthermore, the places where that document is named should be replaced with direct citations to it, which can then be updated to point to the corresponding RFC if it gets published in time or if it gets converted to a normative reference. Using 'the "ietf-rtgwg-enterprise-pa-multihoming" draft' is not going to age well since it won't always be a draft.

In Section 5.1, I wonder if it's worth pointing out that by supporting enterprise multihoming the techniques described in this document can provide a privacy benefit to users, since remote peers view their traffic as having multiple source addresses?
2018-08-01
06 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-08-01
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-08-01
06 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-06.txt
2018-08-01
06 (System) New version approved
2018-08-01
06 (System) Request for posting confirmation emailed to previous authors: Jen Linkova , " mstucchi@ripe.net"
2018-08-01
06 Jen Linkova Uploaded new revision
2018-08-01
05 Adam Roach
[Ballot comment]
Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It …
[Ballot comment]
Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It should be noted that in IPv4 multihoming with NAT, when the egress
>  interface is chosen without taking packet source address into account
>  (as internal hosts usually have addresses from [RFC1918] space),
>  sessions can not be preserved after an uplink recovery.

This isn't necessarily true. For example, if the NAT is tracking which
ISP-facing interface is associated with a given established session, the
sessions will survive restoration of an uplink.  I have exactly such an IPv4
multi-homing configuration working on my home network (with RFC 1918 addresses
assigned to all local devices), and will happily share details of my
configuration with interested parties.

I propose striking this paragraph from the document.

---------------------------------------------------------------------------

§1:

>  general multihoming scenario for enterprise networks and proposes
>  solution which relies heavily on the rule 5.5 of the default address

Nit: "...proposes a solution..."

---------------------------------------------------------------------------

§3.2.6:

>  (as there is no preferred addresses available) and the source address

Nit: "...as there are no..."

---------------------------------------------------------------------------

§3.3:

>  into account any other uplinks properties (such as latencyetc), so

Nit: "...latency, etc.), so..."

---------------------------------------------------------------------------

§3.3.1:

>  interrupted as there is no egress path for those packets and there is
>  not return path from the Internet to the correspodning prefix.  In

Nit: "...there is no return path..."

Nit: "...corresponding..."

---------------------------------------------------------------------------
2018-08-01
05 Adam Roach Ballot comment text updated for Adam Roach
2018-08-01
05 Adam Roach
[Ballot comment]
Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It …
[Ballot comment]
Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It should be noted that in IPv4 multihoming with NAT, when the egress
>  interface is chosen without taking packet source address into account
>  (as internal hosts usually have addresses from [RFC1918] space),
>  sessions can not be preserved after an uplink recovery.

This isn't necessarily true. For example, if the NAT is performing connection
tracking and recording which ISP-facing interface is associated with a given
established session, the sessions will survive restoration of an uplink.
I have exactly such an IPv4 multi-homing configuration working on my home
network (with RFC 1918 addresses assigned to all local devices), and will
happily share details of my configuration with interested parties.

I propose striking this paragraph from the document.

---------------------------------------------------------------------------

§1:

>  general multihoming scenario for enterprise networks and proposes
>  solution which relies heavily on the rule 5.5 of the default address

Nit: "...proposes a solution..."

---------------------------------------------------------------------------

§3.2.6:

>  (as there is no preferred addresses available) and the source address

Nit: "...as there are no..."

---------------------------------------------------------------------------

§3.3:

>  into account any other uplinks properties (such as latencyetc), so

Nit: "...latency, etc.), so..."

---------------------------------------------------------------------------

§3.3.1:

>  interrupted as there is no egress path for those packets and there is
>  not return path from the Internet to the correspodning prefix.  In

Nit: "...there is no return path..."

Nit: "...corresponding..."

---------------------------------------------------------------------------
2018-08-01
05 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-07-31
05 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-07-31
05 Deborah Brungard
[Ballot comment]
Agree with Spencer - I needed to reread the abstract and intro several times to understand the relationship
of this document with rtgwg's. …
[Ballot comment]
Agree with Spencer - I needed to reread the abstract and intro several times to understand the relationship
of this document with rtgwg's. As Spencer noted, I think the first sentence throws the reader off. Suggest
deleting it so as to be more direct.

Same as Spencer - "area" had me wondering if there was/had been such an IETF area, suggest:
in the Source Address Dependent Routing (SADR) area/s/on Source Address Dependent Routing (SADR)
2018-07-31
05 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-07-31
05 Warren Kumari
[ Edits by Warren Kumari marked with [WK]]
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? …
[ Edits by Warren Kumari marked with [WK]]
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes using IPv6's RA capabilities to enable simple multihoming for networks connected to two or more upstream Internet Service Providers (ISPs). This document describes tying the advertisement of avaialble address space through the RA to hosts in a network in response to the availability of upstream connectivity, including sample policies.

Working Group Summary:

The v6ops working group discussed this draft extensively, and the authors made several changes to account for working group input. The document did not raise any controversy,; the authors addresses all the comments quickly.

Document Quality:

There are a number of nits to be addressed, according to the id-nits tool. The overall quality of the document is good; the writing style is easily readable, and the explanations are clear. There was no MIB doctor or other outside review required.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Russ White is the document shepherd. The responsible Area Director is [WK]: Warren Kumari.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Other than the nits mentioned above, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the text of the document, examined the WG discussion on the mailing list archive, verified the referenced documents, and ran the document through the id-nits tool. Other than the id-nits issues, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are none that I am aware of.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

[WK]: Yes, all authors have confirmed:
https://mailarchive.ietf.org/arch/msg/v6ops/KZvakIi1t3o56H38h2iLiqp39D8
https://mailarchive.ietf.org/arch/msg/v6ops/BUMmLrjR1pLPR93y3ofc0X50-Sk

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

[WK]: No IPR Disclosures filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Examining the list, it appears there is a solid concensus among the working group in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. . Boilerplate checks are not enough; this check needs to be thorough.

The document has some nits according to the id-nit tool. Specifically, the abstract contains a reference which should be "straight text," and there are a number of unused references. There are some other minor nits, specifically in a number of lines which exceed 72 characters, but these appear to be related to figures would be difficult to reformat and remain meaningful.

The document appears to be missing the RFC2119 boilerplate for MUST and SHOULD statements. There are five MUST statements in the document; the authors should either convert these statements to lower case, or include the boilerplate.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not appear to need any of the mentioned formal reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There are no new requirements for IANA mentioned in the document. The IANA section of the document accurately reflects this.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are none.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The only check required for this document was the id-nits check, with results as described above.

2018-07-29
05 Spencer Dawkins
[Ballot comment]
I echo Mirja's thanks for a well-written document (and her curiosity about the near-null Security Considerations - there's at least one recommendation in …
[Ballot comment]
I echo Mirja's thanks for a well-written document (and her curiosity about the near-null Security Considerations - there's at least one recommendation in this document, so it seems possible that some security consideration is worth mentioning). But I think I understand this topic, and now I think I understand it much better. Thanks for that.

I do have some minor comments, but they are non-blocking, so do the right thing.

This text toward the bottom of the abstract

  this document
  adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-
  multihoming" draft to provide a solution for a limited number of
  common use cases.

is pretty easy to miss. If the reader misses it, the first sentence is kind of misleading - it just says

  This document discusses the most common scenarios of connecting an
  enterprise network to multiple ISPs using an address space assigned
  by an ISP.

Perhaps it's worth pointing that out in the first sentence, rather than towards the end of the abstract?

I've been on the IESG far too long, but I have tried repeatedly to read

  While some work is being done in the Source Address Dependent Routing
  (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]),

without thinking "but SADR isn't an (IETF) area?!?", and I can't do it. If

  While some work is being done on Source Address Dependent Routing
  (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]),

that would stop startling at least one reader ...

In 3.2.5.  Topologies with Dedicated Border Routers

  For simplicity, all topologies above show the ISP uplinks terminated
  on the first-hop routers.  Obviously, the proposed approach can be
  used in more complex topologies when dedicated devices are used for
  terminating ISP uplinks.  In that case VRRP mastership or interface
  status can not be used as a trigger for conditional RAs and route
  presence as described above should be used instead.

"as described above" might be easier to navigate if it was "as described above in Section 3.1.2" - it's a six-page jump, if I'm tracking this cross reference correctly, and if I'm not, an explicit section reference would be even more appreciated.

I'm not sure that

  It should be noted that the proposed approach is not a silver bullet
  for all possible multihoming scenarios.

"silver bullet" is clear for readers from cultural contexts that don't include werewolves or vampires ... but do the right thing, of course.

It's a nit, but "such as latencyetc".

It's a nit, but "correspodning".
2018-07-29
05 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2018-07-25
05 Mirja Kühlewind
[Ballot comment]
Thanks for the well-written document. Please find some comments below:

1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and …
[Ballot comment]
Thanks for the well-written document. Please find some comments below:

1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate is missing...

2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be a normative reference (and that the abstract should be updated with the respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is published). Any even if it is not a normative reference, should those docs be published together in order to refer to the RFC in the abstract (instead of an draft)?

3) Would it makes sense to also discuss what to do when one ISP is down but packets from that address space are received at the border router? Should those packet be forwarded to that ISP anyway or dropped? Or should they be forwarded to the other ISP with or without address translation?

4) It doesn’t seem right to me that the security consideration section is empty.

5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2.
2018-07-25
05 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-07-25
05 Mirja Kühlewind
[Ballot comment]
Thanks for the well-written document. Please find some comments below:

1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and …
[Ballot comment]
Thanks for the well-written document. Please find some comments below:

1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate is missing...

2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be a normative reference (and that the abstract should be updated with the respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is published). Any even if it is not a normative reference, should those docs be published together in order to refer to the RFC in the abstract (instead of an draft)?

3)Would it makes sense to also discuss what to do when one ISP is down but packets from that address space are received at the border router? Should those packet be forwarded to that ISP anyway or dropped? Or should they be forwarded to the other ISP with or without address translation?

4) It doesn’t seem right to me that the security consideration section is empty.

5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2.
2018-07-25
05 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from No Record
2018-07-25
05 Mirja Kühlewind
[Ballot comment]
1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate …
[Ballot comment]
1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate is missing...

2) It seems that ietf-rtgwg-enterprise-pa-multihoming should be a normative reference (and that the abstract should be updated with the respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is published).
2018-07-25
05 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-07-15
05 Sheng Jiang Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Sheng Jiang. Sent review to list.
2018-07-12
05 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Sheng Jiang
2018-07-12
05 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Sheng Jiang
2018-07-11
05 Yoshifumi Nishida Request for Telechat review by TSVART Completed: Ready with Nits. Reviewer: Yoshifumi Nishida.
2018-07-06
05 Warren Kumari Simply clearing AD Followup flag (forgot to when it was put in IESG Eval state)
2018-07-06
05 Warren Kumari IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2018-07-06
05 Magnus Westerlund Request for Telechat review by TSVART is assigned to Yoshifumi Nishida
2018-07-06
05 Magnus Westerlund Request for Telechat review by TSVART is assigned to Yoshifumi Nishida
2018-07-05
05 Jean Mahoney Request for Telechat review by GENART is assigned to Wassim Haddad
2018-07-05
05 Jean Mahoney Request for Telechat review by GENART is assigned to Wassim Haddad
2018-07-04
05 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-07-04
05 Cindy Morgan Placed on agenda for telechat - 2018-08-02
2018-07-04
05 Warren Kumari IESG state changed to IESG Evaluation::AD Followup from Waiting for Writeup::AD Followup
2018-07-04
05 Warren Kumari Ballot has been issued
2018-07-04
05 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2018-07-04
05 Warren Kumari Created "Approve" ballot
2018-06-22
05 Warren Kumari Adding comment to assure this wasn't forgotten -- 'draft-ietf-rtgwg-enterprise-pa-multihoming' (a dependency) changed state to PubReq 2018-06-11
2018-06-18
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-06-18
05 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-05.txt
2018-06-18
05 (System) New version approved
2018-06-18
05 (System) Request for posting confirmation emailed to previous authors: Jen Linkova , " mstucchi@ripe.net"
2018-06-18
05 Jen Linkova Uploaded new revision
2018-05-25
04 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Wassim Haddad.
2018-05-21
04 Min Ye Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Ravi Singh.
2018-05-21
04 Warren Kumari IESG state changed to Waiting for Writeup::AD Followup from Waiting for Writeup
2018-05-21
04 Warren Kumari Ballot writeup was changed
2018-05-21
04 Sheng Jiang Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Sheng Jiang. Sent review to list.
2018-05-21
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-05-18
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2018-05-18
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2018-05-17
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2018-05-17
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2018-05-15
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-05-15
04 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-v6ops-conditional-ras-04, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-v6ops-conditional-ras-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-05-13
04 Min Ye Request for Last Call review by RTGDIR is assigned to Ravi Singh
2018-05-13
04 Min Ye Request for Last Call review by RTGDIR is assigned to Ravi Singh
2018-05-10
04 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2018-05-10
04 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2018-05-07
04 Min Ye Request for Last Call review by RTGDIR is assigned to John Scudder
2018-05-07
04 Min Ye Request for Last Call review by RTGDIR is assigned to John Scudder
2018-05-07
04 Alvaro Retana Requested Last Call review by RTGDIR
2018-05-07
04 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-05-07
04 Amy Vezza
The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: v6ops@ietf.org, russ@riw.us, v6ops-chairs@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, Russ …
The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: v6ops@ietf.org, russ@riw.us, v6ops-chairs@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using Conditional Router Advertisements for Enterprise Multihoming) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Using Conditional Router Advertisements
for Enterprise Multihoming'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document discusses the most common scenarios of connecting an
  enterprise network to multiple ISPs using an address space assigned
  by an ISP.  The problem of enterprise multihoming without address
  translation of any form has not been solved yet as it requires both
  the network to select the correct egress ISP based on the packet
  source address and hosts to select the correct source address based
  on the desired egress ISP for that traffic.  The "ietf-rtgwg-
  enterprise-pa-multihoming" document proposes a solution to this
  problem by introducing a new routing functionality (Source Address
  Dependent Routing) to solve the uplink selection issue and using
  Router Advertisements to influence the host source address selection.
  While the above-mentioned document focuses on solving the general
  problem and on covering various complex use cases, this document
  describes how the solution proposed in the "ietf-rtgwg-enterprise-pa-
  multihoming" draft can be adopted for a limited number of common use
  cases.  In particular, the focus is on scenarios where an enterprise
  network has two Internet uplinks used either in primary/backup mode
  or simultaneously and hosts in that network might not yet properly
  support multihoming as described in RFC8028.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-05-07
04 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-05-07
04 Warren Kumari Last call was requested
2018-05-07
04 Warren Kumari Last call announcement was generated
2018-05-07
04 Warren Kumari Ballot approval text was generated
2018-05-07
04 Warren Kumari Ballot writeup was generated
2018-05-07
04 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2018-05-04
04 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-04.txt
2018-05-04
04 (System) New version approved
2018-05-04
04 (System) Request for posting confirmation emailed to previous authors: Jen Linkova , " mstucchi@ripe.net"
2018-05-04
04 Jen Linkova Uploaded new revision
2018-04-26
03 Ron Bonica
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes using IPv6's RA capabilities to enable simple multihoming for networks connected to two or more upstream Internet Service Providers (ISPs). This document describes tying the advertisement of avaialble address space through the RA to hosts in a network in response to the availability of upstream connectivity, including sample policies.

Working Group Summary:

The v6ops working group discussed this draft extensively, and the authors made several changes to account for working group input. The document did not raise any controversy,; the authors addresses all the comments quickly.

Document Quality:

There are a number of nits to be addressed, according to the id-nits tool. The overall quality of the document is good; the writing style is easily readable, and the explanations are clear. There was no MIB doctor or other outside review required.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Russ White is the document shepherd. The responsible Area Director is Ron Bonica.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Other than the nits mentioned above, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the text of the document, examined the WG discussion on the mailing list archive, verified the referenced documents, and ran the document through the id-nits tool. Other than the id-nits issues, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are none that I am aware of.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

TBD

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

TBD

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Examining the list, it appears there is a solid concensus among the working group in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. . Boilerplate checks are not enough; this check needs to be thorough.

The document has some nits according to the id-nit tool. Specifically, the abstract contains a reference which should be "straight text," and there are a number of unused references. There are some other minor nits, specifically in a number of lines which exceed 72 characters, but these appear to be related to figures would be difficult to reformat and remain meaningful.

The document appears to be missing the RFC2119 boilerplate for MUST and SHOULD statements. There are five MUST statements in the document; the authors should either convert these statements to lower case, or include the boilerplate.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not appear to need any of the mentioned formal reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There are no new requirements for IANA mentioned in the document. The IANA section of the document accurately reflects this.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are none.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The only check required for this document was the id-nits check, with results as described above.

2018-04-26
03 Ron Bonica Responsible AD changed to Warren Kumari
2018-04-26
03 Ron Bonica IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-04-26
03 Ron Bonica IESG state changed to Publication Requested
2018-04-26
03 Ron Bonica IESG process started in state Publication Requested
2018-04-26
03 Ron Bonica Intended Status changed to Informational from None
2018-04-18
03 Ron Bonica Changed document writeup
2018-04-09
03 Ron Bonica IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2018-04-09
03 Ron Bonica Notification list changed to Russ White <russ@riw.us>
2018-04-09
03 Ron Bonica Document shepherd changed to Russ White
2018-03-30
03 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-03.txt
2018-03-30
03 (System) New version approved
2018-03-30
03 (System) Request for posting confirmation emailed to previous authors: "J. Linkova" , " mstucchi@ripe.net"
2018-03-30
03 Jen Linkova Uploaded new revision
2018-03-18
02 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-02.txt
2018-03-18
02 (System) New version approved
2018-03-18
02 (System) Request for posting confirmation emailed to previous authors: v6ops-chairs@ietf.org, " stucchi-lists@glevia.com" , "J. Linkova"
2018-03-18
02 Jen Linkova Uploaded new revision
2018-03-08
01 Fred Baker Added to session: IETF-101: v6ops  Mon-0930
2018-02-27
01 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-01.txt
2018-02-27
01 (System) New version approved
2018-02-27
01 (System) Request for posting confirmation emailed to previous authors: " stucchi-lists@glevia.com" , "J. Linkova"
2018-02-27
01 Jen Linkova Uploaded new revision
2017-10-09
00 Ron Bonica This document now replaces draft-linkova-v6ops-conditional-ras instead of None
2017-10-09
00 Jen Linkova New version available: draft-ietf-v6ops-conditional-ras-00.txt
2017-10-09
00 (System) WG -00 approved
2017-10-09
00 Jen Linkova Set submitter to "Jen Linkova ", replaces to draft-linkova-v6ops-conditional-ras and sent approval email to group chairs: v6ops-chairs@ietf.org
2017-10-09
00 Jen Linkova Uploaded new revision