Source-Specific Routing in the Babel Routing Protocol
draft-ietf-babel-source-specific-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-08-19
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-02
|
08 | (System) | RFC Editor state changed to AUTH48 |
2021-04-30
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-04-26
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-04-26
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-04-26
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-04-26
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-04-23
|
08 | (System) | RFC Editor state changed to EDIT |
2021-04-23
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-04-23
|
08 | (System) | Announcement was received by RFC Editor |
2021-04-23
|
08 | (System) | IANA Action state changed to In Progress |
2021-04-23
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-04-23
|
08 | Amy Vezza | IESG has approved the document |
2021-04-23
|
08 | Amy Vezza | Closed "Approve" ballot |
2021-04-23
|
08 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2021-04-23
|
08 | Martin Vigoureux | Ballot approval text was generated |
2021-04-22
|
08 | Alvaro Retana | [Ballot comment] [Thanks for addressing my DISCUSS.] |
2021-04-22
|
08 | Alvaro Retana | [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss |
2021-04-21
|
08 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2021-04-21
|
08 | Martin Duke | [Ballot comment] Thanks for answering the question in my DISCUSS. |
2021-04-21
|
08 | Martin Duke | [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss |
2021-04-21
|
08 | Warren Kumari | [Ballot comment] Thanks for addressing my concerns - DISCUSS cleared. |
2021-04-21
|
08 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2021-04-21
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-04-21
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-04-21
|
08 | Juliusz Chroboczek | New version available: draft-ietf-babel-source-specific-08.txt |
2021-04-21
|
08 | (System) | New version approved |
2021-04-21
|
08 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Matthieu Boutier |
2021-04-21
|
08 | Juliusz Chroboczek | Uploaded new revision |
2020-11-05
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-11-05
|
07 | Robert Wilton | [Ballot discuss] Please see the comment below for further description. My specific discuss issue relates to clarifying the indexes of the 'source' and 'route' tables … [Ballot discuss] Please see the comment below for further description. My specific discuss issue relates to clarifying the indexes of the 'source' and 'route' tables to indicate whether they are replacing the 'prefix-len' elements of the existing 3 tuple indexes, or adding additional elements to the existing index, effectively making them 5 tuple indexes. |
2020-11-05
|
07 | Robert Wilton | [Ballot comment] Hi, Caveat, I'm not familiar with the Babel routing protocol, and I might be getting the wrong end of the stick. In some … [Ballot comment] Hi, Caveat, I'm not familiar with the Babel routing protocol, and I might be getting the wrong end of the stick. In some ways I found the content and concepts of this document easy to understand, but the choice of particular terminology made is hard for me to know for sure that I am correctly interpreting this document. In particular, I am confused between the definition of "source", "destination prefix" and "source prefix" between this document and draft-ietf-babel-rfc6126bis. I might be completely confused, but my understanding is that what is called the "destination prefix" in this document, is effectively what is referred to as the "source" in draft-ietf-babel-rfc6126bis (e.g., in the Route Table in section 3.2.5), that also happens to be a prefix. Is that right? A further confusion is that this draft seems to sometimes describes prefixes differently from how they are described in the Babel RFC that it is extending. E.g., it seems that in some cases the prefix-length is implicitly part of the prefix, and in other cases it is described as a separate element (e.g., in the 'source' and 'route' table indexes). Specifically: 3.1. The Source Table Every Babel node maintains a source table, as described in [BABEL] Section 3.2.5. A source-specific Babel node extends this table with the following field: o The source prefix specifying the source address of packets to which this entry applies. The source table is now indexed by triples of the form (prefix, source prefix, router-id). According to 3.2.5 of draft-ietf-babel-rfc6126bis, the table is already index by a triple, i.e. prefix, prefix-len, router-id. Is the intention of this document to remove prefix-len as one of the keys to the index? I presume not, and that the new table is really indexed by a 5-tuple, i.e., adding source-prefix and source-prefix length to the existing keys. Note that the route entry contains a source (see sections 2 and 3.2.5 of [BABEL]) which itself contains a source prefix. These are two very different concepts that should not be confused. Should this reference be to 3.2.6? It may be helpful to expand on what the original "source" in a route entry means to avoid any confusion. If my understanding is right, then I think that this document would greatly benefit from being very clear on the differences in terminology and probably be very specific about what they mean in the context of this document. Regards, Rob |
2020-11-05
|
07 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2020-11-05
|
07 | Éric Vyncke | [Ballot comment] [Dear all, please accept my apologies for the wrong DISCUSS point... a copy and paste error done without enough coffee... There are NO … [Ballot comment] [Dear all, please accept my apologies for the wrong DISCUSS point... a copy and paste error done without enough coffee... There are NO DISCUSS point in my ballot] Thank you for the work put into this document. The document is easy to read albeit not always clear and specific (see later). The topic of source address dependent routing is really critical for IPv6 deployment, so, I really appreciate your work on the topic Please find below some non-blocking COMMENT points, and some nits. I also second Warren's DISCUSS on the lack of clarity in the section 4 example I hope that this helps to improve the document, Regards, -éric == COMMENTS == Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is an expired RTG WG adopted document and is not even cited as informative reference. Same for reference to RFC 8678. -- Section 3.1 -- Is the first "prefix" the "destination prefix" in the following text? If so, then I suggest to write "destination prefix" or explain what is this "prefix" with reference to the Bable RFC: "The source table is now indexed by triples of the form (prefix, source prefix, router-id)." -- Section 4 -- May I suggest to add another example with 2 entries have the same destination prefix but different source prefixes ? -- Section 6 -- May be my lack of knowledge in Babel is the reason why I do not understand the loop avoidance description... As written in the text, a single non-source-aware router in the network could be enough to introduce loop (in specific configurations). Writing the following text appear to me as a little hand waving because how can this be ensure (I was about to file a block DISCUSS on this but I am trusting the routing AD on this topic): " Consequently, this extension MUST NOT be used with routers implementing RFC 6126, otherwise persistent routing loops may occur." -- Section 6.2 -- The last paragraph is also a little hand waving where it is assumed that network topology/configuration is specific to avoid a route starvation. -- Section 7.1 -- Should the text state the obvious by stating that the prefix (non 8 multiple) is padded with bits set to 0 on transmission and those bits are ignored on reception ? == NITS == -- Section 4 and possibly others -- Please use RFC 5952 to write IPv6 addresses. -- Section 5.2 -- Please introduce the "AE" acronym at first use (even if guessable in the context). |
2020-11-05
|
07 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2020-11-04
|
07 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. The document is easy to read albeit not always clear and specific (see later). … [Ballot discuss] Thank you for the work put into this document. The document is easy to read albeit not always clear and specific (see later). The topic of source address dependent routing is really critical for IPv6 deployment, so, I really appreciate your work on the topic Please find below one blocking DISCUSS point (trivial to fix), some non-blocking COMMENT points, and some nits. I also second Warren's DISCUSS on the lack of clarity in the section 4 example I hope that this helps to improve the document, Regards, -éric == DISCUSS == Please update IPv6 reference from RFC 2460 to RFC 8200: I told you that this was an easy to fix DISCUSS point |
2020-11-04
|
07 | Éric Vyncke | [Ballot comment] == COMMENTS == Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is an expired RTG WG adopted document and is not even … [Ballot comment] == COMMENTS == Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is an expired RTG WG adopted document and is not even cited as informative reference. Same for reference to RFC 8678. -- Section 3.1 -- Is the first "prefix" the "destination prefix" in the following text? If so, then I suggest to write "destination prefix" or explain what is this "prefix": "The source table is now indexed by triples of the form (prefix, source prefix, router-id)." -- Section 4 -- May I suggest to add another example with 2 entries have the same destination prefix but different source prefixes ? -- Section 6 -- May be my lack of knowledge in Babel is the reason why I do not understand the loop avoidance description... As written in the text, a single non-source-aware router in the network could be enough to introduce loop (in specific configurations). Writing the following text appear to me as a little hand waving because how can this be ensure (I was about to file a block DISCUSS on this but I am trusting the routing AD on this topic): " Consequently, this extension MUST NOT be used with routers implementing RFC 6126, otherwise persistent routing loops may occur." -- Section 6.2 -- The last paragraph is also a little hand waving where it is assumed that network topology/configuration is specific to avoid a route starvation. -- Section 7.1 -- Should the text state the obvious by stating that the prefix (non 8 multiple) is padded with bits set to 0 on transmission and those bits are ignored on reception ? == NITS == -- Section 4 and possibly others -- Please use RFC 5952 to write IPv6 addresses. -- Section 5.2 -- Please introduce the "AE" acronym at first use (even if guessable in the context). |
2020-11-04
|
07 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2020-11-04
|
07 | Murray Kucherawy | [Ballot comment] What's an example of when one might deviate from the SHOULD in Section 4? |
2020-11-04
|
07 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-11-04
|
07 | Martin Duke | [Ballot discuss] I am concerned about the congestion implications of this architecture. If there are P prefixes in the network, the number of TLVs exchanged … [Ballot discuss] I am concerned about the congestion implications of this architecture. If there are P prefixes in the network, the number of TLVs exchanged potentially goes from P to P^2. Perhaps this is an unrealistic use case. But are there any safeguards in the protocol against this happening (e.g. limitations on size/freq of updates?) Or ought there to be some operational guidance to be somewhat selective about source prefixes? |
2020-11-04
|
07 | Martin Duke | [Ballot Position Update] Position for Martin Duke has been changed to Discuss from No Objection |
2020-11-04
|
07 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-11-04
|
07 | Erik Kline | [Ballot comment] [[ nits ]] [ section 4 ] * Per RFC 5952 section 4.3, please s/2001:DB8/2001:db8/g |
2020-11-04
|
07 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-11-04
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-11-03
|
07 | Warren Kumari | [Ballot discuss] I apologize for being rushed, and not balloting earlier, but I feel like I must have missed something fundamental here. The example in … [Ballot discuss] I apologize for being rushed, and not balloting earlier, but I feel like I must have missed something fundamental here. The example in Section 4 (Data Forwarding) illustrates an issue, but doesn't actually *state* which (A or B) next hop will be used. The text then says that: "A Babel implementation MUST choose routing table entries by using the so-called destination-first ordering,". I interpret this to mean that the packet "with source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57" should use next-hop A. This means that you will be sending the packet to the destination with no regard for if the provider connected to next-hop A carries/announces 2001:DB8:0:2::/64. If if it doesn't, this will look like a spoofing attack, and the ISP will (rightly) drop it. The only way that I can see this working is if: 1: destination routes never point "outside" the network (and so will never hit inbound BCP38 filters) or 2: destination routes always "match" - if you install x:y:z::/q pointing at next-hop A, you also install the same router pointing at next-hop B (this is pointless). Please help me understand what I'm missing here -- routing on destination to an ISP (which is what I'm assuming based on the "small networks" statement) seems like it will route packets with ISP B sources addresses to ISP A, running into BCP38/anti-spoofing filters. BCP84 also covers a number of scenarios - it sounds like you are referring to Section 4.3. Send Traffic Using a Provider Prefix Only to That Provider, but that is exactly what is not happening above. Again, I'm assuming that I'm just missing something blindingly obvious here, but it would be good to figure out what, so the document can be clarified and others don't fall into the same trap... |
2020-11-03
|
07 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2020-11-03
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-11-03
|
07 | Alvaro Retana | [Ballot discuss] I am balloting DISCUSS because I believe that the document is missing important considerations/details related to the operation of Babel in a network. … [Ballot discuss] I am balloting DISCUSS because I believe that the document is missing important considerations/details related to the operation of Babel in a network. I hope these points should be easy to address. This draft describes destination-first forwarding. If I understand correctly, for the table in §4: destination source next-hop 2001:DB8:0:1::/64 ::/0 A ::/0 2001:DB8:0:2::/64 B ...and the example presented of a "source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57", the result is that the packet is forwarded to A. Is this the correct interpretation? If so, then I believe there are important assumptions made that are not mentioned. In line with this document being "applicable to small networks" (§1), BCP 84/§4.3 recommends the following: For smaller edge networks that use provider-based addressing and whose ISPs implement ingress filters (which they should do), the third option is to route traffic being sourced from a given provider's address space to that provider. Given that the draft provides no details, I assume that being "compatible with [BCP84]" (§1) means at least that Babel nodes aim to "route traffic being sourced from a given provider's address space to that provider". (a) While I understand the table above is just an example, it can be interpreted as indicating that B is the provider that assigned the 2001:DB8:0:2::/64 prefix. If traffic sourced from that prefix is sent to A, then there's a good chance that the packet will be dropped (in line with BCP 84, BCP 38, etc.). Maybe the table is not intended to illustrate the routing table at a multihomed edge router. Still, it shows how easy it is to define a policy that may not result in the expected behavior because of the destination-first operation. Please add some guidance on the advertisements and how they may interact in the routing table. Note that what I'm asking for may just be a good example of what to do/not to do. rfc8678/§5 presents an example of how the forwarding table is constructed based on a set of routes -- something like that would be great! (b) How is the source address selected by the host? rfc8678 uses guidance from rfc8028 and other RFCs as part of a set of "Mechanisms for Hosts To Choose Good Default Source Addresses in a Multihomed Site". rfc8678 significantly differs from this document in that it assumes source-first forwarding when discussing the selection of the source address. Are any of the recommendations in rfc8678 applicable here? I may be missing something, but it seems to me that the current standards-based recommendations/mechanisms don't easily apply to this specification. I don't think there's anything wrong with doing things a different way -- but I expect those differences to be explicitly explained. SS-ROUTING suggests a trial-and-error mechanism: for "destination addresses...the sending host tries them all...similarly, all possible source addresses are tried in turn." Is that the expectation here? Even though this document is about Babel and not the host, I would like to see a (short) discussion about how the host is expected to behave (or what it needs to consider) in light of the destination-first operation. |
2020-11-03
|
07 | Alvaro Retana | [Ballot comment] (1) §4 talks about "lower layers", what are those? Please be specific. (2) The second bullet in §4 says that "Babel...MUST either silently … [Ballot comment] (1) §4 talks about "lower layers", what are those? Please be specific. (2) The second bullet in §4 says that "Babel...MUST either silently ignore any source-specific routes, or disambiguate..." Given the required (use of MUST) nature of the disambiguation, I would like to see an algorithm for it, not just an example. I do not include this point in the DISCUSS section because I think there are ways not to require disambiguation; perhaps something along the lines of: ...SHOULD silently ignore any source-specific routes. A router can also choose to use a disambiguation algorithm (see SS-ROUTING for an example), but the details are out of this document's scope. (3) §7.1: "Source Plen The length of the advertised source prefix." Indicate in bits. |
2020-11-03
|
07 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2020-11-02
|
07 | Roman Danyliw | [Ballot comment] Thank you to Rifaat Shekh-Yusef for performing the SECDIR review and thank you to the authors for responding to it. |
2020-11-02
|
07 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-10-30
|
07 | Benjamin Kaduk | [Ballot comment] Section 3.1 Note that the route entry contains a source (see sections 2 and 3.2.5 of [BABEL]) which itself contains a … [Ballot comment] Section 3.1 Note that the route entry contains a source (see sections 2 and 3.2.5 of [BABEL]) which itself contains a source prefix. These are two very different concepts that should not be confused. I appreciate having this note; thanks. I wonder if it is worth reiterating that the stock [BABEL] "source prefix" is the prefix of the source of the routing information, to jog the reader's memory. Section 5.1 Prefix sub-TLV. When a node receives a source-specific Update (prefix, source prefix, router-id, seqno, metric) from a neighbour neigh, it behaves as described in [BABEL] Section 3.5.4, except that It looks like some section renumbering has occurred, as §3.5.3 of draft-ietf-babel-rfc6126bis-20 looks much more relevant than §3.5.4 does. the entry under consideration is indexed by (prefix, source prefix, neigh) rather than just (prefix, neigh). [The two prefix lengths are implicit now, though were explicit in [BABEL]?] Section 5.2 We should probably expand "AE" on first use. Section 6.2 Is there also the possibility of a kind of starvation where source-specific routers do not get source-specific routes because the source-specific routes are dropped by non-source-specific routers between them and the source of the route advertisement? Intuitively, it seems that once you have a connected backbone of source-specific routers this would only happen if a given source-specific router only has paths to the backbone that go through non-source-specific routers, and so the router in question is effectively operating in a non-source-specific mode, but perhaps there are more interesting scenarios in the absence of such a backbone. A simple yet sufficient condition for avoiding starvation is to build a connected source-specific backbone that includes all of the edge routers, [...] I'm not sure I understand what "connected backbone that includes all of the edge routers" is intended to mean. If the edge routers are to be included in the connected backbone (i.e., to implement source-specific), then wouldn't that make the connected backbone basically all routers? Or is the intent that any given edge router has a link to a router in the backbone? Or something else? Section 7.1 If I recall correctly, Babel sub-TLVs do not admit sub-sub-TLVs, so we would treat a sub-TLV "length" that indicates more bytes of payload than indicated by the "source plen" as an encoding error and reject the sub-TLV, right? Source Plen The length of the advertised source prefix. This MUST NOT be 0. Please use "length in bits" to match 6126bis. Section 7.3 Should we consider being consistent about the use of parentheses around "route" in the section heading and section body? Section 7.4 Just to check my understanding: we do not expect issues where (e.g.) a source-specific seqno request is sent to a non-source-specific node and thus dropped, because seqno requests are supposed to be sent only to nodes that are or in the past were advertising a (possibly non-feasible) route for that prefix. Such a source-specific advertisement would only be sent by a source-specific node, that would accordingly not drop the seqno request. Section 9 I was surprised to see in a quick check of 6126bis that there did not seem to be a prominent mention in the security considerations of "make sure your parser handles TLVs that indicate a length larger than the size of the packet". Should there be one? Other than that (which is not really even a comment on this document), I like the security considerations here: they're clear on the consequences of the new behaviors from this protocol extension, and give enough examples of how that might impact the security properties of the system as a whole. Thank you! The extension defined in this document adds a new sub-TLV to three TLVs already present in the original Babel protocol, and does not change the security properties of the protocol itself. However, the We might as well toss another [BABEL] in here; they're cheap. Section 11.1 We cite BCP84 as part of the line "which is compatible with [BCP84]". That in and of itself does not necessarily seem like enough to justify a normative relationship, though perhaps there are other reasons why it is needed. |
2020-10-30
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-10-30
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-10-29
|
07 | Barry Leiba | [Ballot comment] Thanks for an easy read. I have only some minor comments: — Section 5.2 — Please expand “AE” on first use. You should … [Ballot comment] Thanks for an easy read. I have only some minor comments: — Section 5.2 — Please expand “AE” on first use. You should also do the same in Section 4.1.4 of draft-ietf-babel-rfc6126bis. A node MUST NOT send a wildcard retraction with an attached source prefix, and a node that receives a wildcard retraction with a source prefix MUST ignore it. The “it” here is ambiguous: please specify “MUST ignore the source prefix” or “MUST ignore the retraction”. The same comment applies also to the subsequent paragraph. — Section 6.1 — For what it’s worth, I don’t find the diagram to add anything to the text, and I wouldn’t have a clue what the diagram was trying to say without the text. Packets destined to D but not sourced in S will be forwarded by A to B, and by B to A, causing a persistent routing loop That text is describing not what will happen with this standard, but what *would* happen if this standard didn’t correct for it. So please change “will be forwarded” to”would be forwarded”, or perhaps “would then be forwarded”. And in the previous sentence, change “merely ignores” to “merely ignored”. These make it clearer that they’re talking about a hypothetical situation that’s counter to what’s specified herein. |
2020-10-29
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-10-28
|
07 | Amy Vezza | Placed on agenda for telechat - 2020-11-05 |
2020-10-28
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-10-28
|
07 | Juliusz Chroboczek | New version available: draft-ietf-babel-source-specific-07.txt |
2020-10-28
|
07 | (System) | New version approved |
2020-10-28
|
07 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Matthieu Boutier |
2020-10-28
|
07 | Juliusz Chroboczek | Uploaded new revision |
2020-10-28
|
06 | Martin Vigoureux | Ballot has been issued |
2020-10-28
|
06 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2020-10-28
|
06 | Martin Vigoureux | Created "Approve" ballot |
2020-10-28
|
06 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-10-28
|
06 | Martin Vigoureux | Ballot writeup was changed |
2020-10-27
|
06 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: He Jia. |
2020-10-27
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-10-26
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2020-10-26
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-babel-source-specific-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-babel-source-specific-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the Babel Sub-TLV Types registry on the Babel Routing Protocol registry page located at: https://www.iana.org/assignments/babel/ the early allocation for the following Sub-TLV Type: 128 Name: Source Prefix will have its reference changed to [ RFC-to-be ]. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-10-25
|
06 | Rifaat Shekh-Yusef | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Rifaat Shekh-Yusef. Sent review to list. |
2020-10-24
|
06 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2020-10-24
|
06 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2020-10-22
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef |
2020-10-22
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef |
2020-10-20
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2020-10-20
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2020-10-19
|
06 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to He Jia |
2020-10-19
|
06 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to He Jia |
2020-10-19
|
06 | Luc André Burdet | Assignment of request for Last Call review by RTGDIR to Geoff Huston was rejected |
2020-10-19
|
06 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Geoff Huston |
2020-10-19
|
06 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Geoff Huston |
2020-10-15
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-10-15
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-10-13
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-10-13
|
06 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-10-27): From: The IESG To: IETF-Announce CC: draft-ietf-babel-source-specific@ietf.org, martin.vigoureux@nokia.com, babel-chairs@ietf.org, babel@ietf.org, Donald … The following Last Call announcement was sent out (ends 2020-10-27): From: The IESG To: IETF-Announce CC: draft-ietf-babel-source-specific@ietf.org, martin.vigoureux@nokia.com, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Source-Specific Routing in Babel) to Proposed Standard The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'Source-Specific Routing in Babel' as Proposed Standard 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 last-call@ietf.org mailing lists by 2020-10-27. 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 Source-specific routing (also known as Source-Address Dependent Routing, SADR) is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ No IPR declarations have been submitted directly on this I-D. |
2020-10-13
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-10-13
|
06 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2020-10-13
|
06 | Martin Vigoureux | Last call was requested |
2020-10-13
|
06 | Martin Vigoureux | Ballot approval text was generated |
2020-10-13
|
06 | Martin Vigoureux | Ballot writeup was generated |
2020-10-13
|
06 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-10-13
|
06 | Martin Vigoureux | Last call announcement was generated |
2020-10-10
|
06 | Juliusz Chroboczek | New version available: draft-ietf-babel-source-specific-06.txt |
2020-10-10
|
06 | (System) | New version approved |
2020-10-10
|
06 | (System) | Request for posting confirmation emailed to previous authors: Matthieu Boutier , Juliusz Chroboczek |
2020-10-10
|
06 | Juliusz Chroboczek | Uploaded new revision |
2020-09-14
|
05 | Martin Vigoureux | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2020-08-14
|
05 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2019-04-28
|
05 | Donald Eastlake | draft-ietf-babel-source-specific-05 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this … draft-ietf-babel-source-specific-05 (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? Proposed Standard as indicated on the title page. This document extends the Babel routing protocol so that the routing of a packet can depend on the source address as well as the destination address. (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: Source-specific routing (also known as Source-Address Dependent Routing, SADR) is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. Working Group Summary: Discussion of the draft during WG Last Call extended to one aspect of the rfc6126bis draft but WG consensus supported both this draft and not changing rfc6126bis. Document Quality: The quality of the document is good. There are two known implementations: babeld in the currently unreleased 1.9 branch and Toke Høiland-Jørgensen's code in BIRD. Personnel: Document Shepherd: Donald Eastlake Responsible Area Director: Martin Vigoureux (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review is here https://mailarchive.ietf.org/arch/msg/babel/S4QVnhDZ38bsph2qOvw06qzEfoU Discussion on the list of the review comments lead to the -05 version. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No review concerns. In addition to the Shepherd review and general review by the Working Group there was an early Routing Directorate review as shown here: https://mailarchive.ietf.org/arch/msg/babel/-V3XN6IHqAEVjIyCpztO9PsoCvA (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. There was an early Routing Directorate review (see 4 above). (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? No special concerns. (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? Yes, see https://mailarchive.ietf.org/arch/msg/babel/ne-KW9H84FgApfcbWegSNA5v94I https://mailarchive.ietf.org/arch/msg/babel/vd9Tht3TaVH5DC_D4IwpmZWGi8g (8) Has an IPR disclosure been filed that references this document? No. (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? There is a reasonable consensus for this document. All commenters during Last Call supported the document except for one who objected to the provision in draft-ietf-babel-rfc6126bis that left the version number at 2 and possible interaction of this with the source specific draft. This issues was discussed during the Last Call of source specific and a consensus favored leaving the source-specific and rfc6126bis drafts as is. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Two of the references to drafts reference a version number one less than the current version number. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria apply to this document. (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? There is a normative reference to draft-ietf-babel-rfc-6126bis publication of which as an RFC has been requested and which is currently in the AD Review state. (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. There are no downward references. (There is a reference to a BCP.) (16) Will publication of this document change the status of any existing RFCs? This document does not affect the status of any existing RFC. (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). The only required IANA action is the allocation of a Babel sub-TLV type number. This action has already occurred and is documented in this draft. (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. This document does not create any IANA registries. (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. No such formal language appears in this document. |
2019-04-28
|
05 | Donald Eastlake | Responsible AD changed to Martin Vigoureux |
2019-04-28
|
05 | Donald Eastlake | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-04-28
|
05 | Donald Eastlake | IESG state changed to Publication Requested from I-D Exists |
2019-04-28
|
05 | Donald Eastlake | IESG process started in state Publication Requested |
2019-04-28
|
05 | Donald Eastlake | draft-ietf-babel-source-specific-05 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this … draft-ietf-babel-source-specific-05 (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? Proposed Standard as indicated on the title page. This document extends the Babel routing protocol so that the routing of a packet can depend on the source address as well as the destination address. (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: Source-specific routing (also known as Source-Address Dependent Routing, SADR) is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. Working Group Summary: Discussion of the draft during WG Last Call extended to one aspect of the rfc6126bis draft but WG consensus supported both this draft and not changing rfc6126bis. Document Quality: The quality of the document is good. There are two known implementations: babeld in the currently unreleased 1.9 branch and Toke Høiland-Jørgensen's code in BIRD. Personnel: Document Shepherd: Donald Eastlake Responsible Area Director: Martin Vigoureux (3) Briefly describe the review of this document that was performed by the Document Shepherd. Shepherd review is here https://mailarchive.ietf.org/arch/msg/babel/S4QVnhDZ38bsph2qOvw06qzEfoU Discussion on the list of the review comments lead to the -05 version. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No review concerns. In addition to the Shepherd review and general review by the Working Group there was an early Routing Directorate review as shown here: https://mailarchive.ietf.org/arch/msg/babel/-V3XN6IHqAEVjIyCpztO9PsoCvA (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. There was an early Routing Directorate review (see 4 above). (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? No special concerns. (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? Yes, see https://mailarchive.ietf.org/arch/msg/babel/ne-KW9H84FgApfcbWegSNA5v94I https://mailarchive.ietf.org/arch/msg/babel/vd9Tht3TaVH5DC_D4IwpmZWGi8g (8) Has an IPR disclosure been filed that references this document? No. (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? There is a reasonable consensus for this document. All commenters during Last Call supported the document except for one who objected to the provision in draft-ietf-babel-rfc6126bis that left the version number at 2 and possible interaction of this with the source specific draft. This issues was discussed during the Last Call of source specific and a consensus favored leaving the source-specific and rfc6126bis drafts as is. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Two of the references to drafts reference a version number one less than the current version number. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria apply to this document. (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? There is a normative reference to draft-ietf-babel-rfc-6126bis publication of which as an RFC has been requested and which is currently in the AD Review state. (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. There are no downward references. (There is a reference to a BCP.) (16) Will publication of this document change the status of any existing RFCs? This document does not affect the status of any existing RFC. (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). The only required IANA action is the allocation of a Babel sub-TLV type number. This action has already occurred and is documented in this draft. (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. This document does not create any IANA registries. (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. No such formal language appears in this document. |
2019-04-11
|
05 | Juliusz Chroboczek | New version available: draft-ietf-babel-source-specific-05.txt |
2019-04-11
|
05 | (System) | New version approved |
2019-04-11
|
05 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Matthieu Boutier |
2019-04-11
|
05 | Juliusz Chroboczek | Uploaded new revision |
2018-10-23
|
04 | Juliusz Chroboczek | New version available: draft-ietf-babel-source-specific-04.txt |
2018-10-23
|
04 | (System) | New version approved |
2018-10-23
|
04 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Matthieu Boutier |
2018-10-23
|
04 | Juliusz Chroboczek | Uploaded new revision |
2018-08-04
|
03 | (System) | Document has expired |
2018-03-26
|
03 | Donald Eastlake | IETF WG state changed to In WG Last Call from WG Document |
2018-03-26
|
03 | Donald Eastlake | Notification list changed to Donald Eastlake <d3e3e3@gmail.com> |
2018-03-26
|
03 | Donald Eastlake | Document shepherd changed to Donald E. Eastlake 3rd |
2018-01-31
|
03 | Juliusz Chroboczek | New version available: draft-ietf-babel-source-specific-03.txt |
2018-01-31
|
03 | (System) | New version approved |
2018-01-31
|
03 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Matthieu Boutier |
2018-01-31
|
03 | Juliusz Chroboczek | Uploaded new revision |
2018-01-20
|
02 | Juliusz Chroboczek | New version available: draft-ietf-babel-source-specific-02.txt |
2018-01-20
|
02 | (System) | New version approved |
2018-01-20
|
02 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Matthieu Boutier |
2018-01-20
|
02 | Juliusz Chroboczek | Uploaded new revision |
2017-11-04
|
01 | Joel Halpern | Request for Early review by RTGDIR Completed: Not Ready. Reviewer: Joel Halpern. Sent review to list. |
2017-11-01
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Joel Halpern |
2017-11-01
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Joel Halpern |
2017-10-29
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Hannes Gredler |
2017-10-29
|
01 | Min Ye | Request for Early review by RTGDIR is assigned to Hannes Gredler |
2017-10-29
|
01 | Donald Eastlake | Added to session: IETF-100: babel Fri-0930 |
2017-10-28
|
01 | Donald Eastlake | Requested Early review by RTGDIR |
2017-10-28
|
01 | Donald Eastlake | Changed consensus to Yes from Unknown |
2017-10-28
|
01 | Donald Eastlake | Intended Status changed to Proposed Standard from None |
2017-08-22
|
01 | Matthieu Boutier | New version available: draft-ietf-babel-source-specific-01.txt |
2017-08-22
|
01 | (System) | New version approved |
2017-08-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Matthieu Boutier |
2017-08-22
|
01 | Matthieu Boutier | Uploaded new revision |
2017-08-11
|
00 | (System) | This document now replaces draft-boutier-babel-source-specific instead of None |
2017-08-11
|
00 | Matthieu Boutier | New version available: draft-ietf-babel-source-specific-00.txt |
2017-08-11
|
00 | (System) | New version approved |
2017-08-11
|
00 | Matthieu Boutier | Request for posting confirmation emailed to submitter and authors: Juliusz Chroboczek , Matthieu Boutier |
2017-08-11
|
00 | Matthieu Boutier | Uploaded new revision |