OSPFv3 Extensions for Segment Routing
draft-ietf-ospf-ospfv3-segment-routing-extensions-23
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-11-18
|
23 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-11-05
|
23 | (System) | RFC Editor state changed to AUTH48 from REF |
2019-11-05
|
23 | (System) | RFC Editor state changed to REF from AUTH48-DONE |
2019-10-29
|
23 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-10-23
|
23 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-08-20
|
23 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-07-25
|
23 | (System) | RFC Editor state changed to REF from EDIT |
2019-05-28
|
23 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-01-17
|
23 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-01-17
|
23 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-01-17
|
23 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-01-16
|
23 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-01-11
|
23 | (System) | RFC Editor state changed to MISSREF |
2019-01-11
|
23 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-01-11
|
23 | (System) | Announcement was received by RFC Editor |
2019-01-11
|
23 | (System) | IANA Action state changed to In Progress |
2019-01-11
|
23 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-01-11
|
23 | Cindy Morgan | IESG has approved the document |
2019-01-11
|
23 | Cindy Morgan | Closed "Approve" ballot |
2019-01-11
|
23 | Cindy Morgan | Ballot approval text was generated |
2019-01-11
|
23 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-01-10
|
23 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss point! [Original COMMENT section preserved unchanged below] Section 1 Is there a start of the separate document … [Ballot comment] Thank you for addressing my Discuss point! [Original COMMENT section preserved unchanged below] Section 1 Is there a start of the separate document that covers SR with the IPv6 data plane that we could reference from here? Section 5 In some cases it is useful to advertise attributes for a range of prefixes. The Segment Routing Mapping Server, which is described in [I-D.ietf-spring-segment-routing-ldp-interop], is an example of where a single advertisement is needed to advertise SIDs for multiple prefixes from a contiguous address range. I note that the referenced document does not use the word "range" to describe the prefix being assigned multiple SIDs; it might be helpful to say a few more words about how the range of prefixes gets mapped to what is discussed in the linked document. I'm also not entirely sure how to construct the prefix range just given this format description. Suppose I have an IPv4 prefix of 18.18/16 and a range size of 4; my prefix length is 16 and the address prefix is encoded as 0x120120000. Am I then representing the four prefixes 18.18/16, 18.19/16, 18.20/16, and 18.21/16? Or am I constrained to be a subset of 18.18/18 (in which case I don't know what the actual distinct prefixes would be)? The examples in Section 6 suggests the former, but I would suggest stating this explictly, here. Section 6 Should there be any discussion of the historical or future reasons why V and L are separate flag bits, given that the only legal combinations are currently 00 and 11, i.e., fully redundant? It may not be necessary to expand ASBR on first usage here, since it's in the terminology section (and marked as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt). If the NP-Flag is not set, then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane. If the NP-flag is not set, then the received E-flag is ignored. Is it going to be clear that "pop" only applies when this Prefix-SID is the outermost label? (Or am I super-confused about how this is supposed to work?) A similar consideration may apply to the discussion of the NP flag as well. Also some redundantly expanded ABR and ASBR here as well. This is useful, e.g., when the originator of the Prefix- SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. Are we still supposed to call these the EXP bits after RFC 5462? (I had to look up what they were; not sure if this means that we should put a reference in for them or not, given that I'm not a practitioner here.) When the M-Flag is set, the NP-flag and the E-flag MUST be ignored on reception. Do I understand this correctly that this is because the mapping server may not know the needs of the individual routers, and if the routers had specific needs they should advertise the SIDs directly (which would take precedence over the mapping server's advertisement)? If so, given the following discussion, I wouldn't suggest adding any extra text about it, but I do want to make sure I'm understanding it properly. When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a starting SID/Label value. Am I remembering correctly that Prefix-SID can appear multiple times within OSPFv3 Extended Prefix Range? Then each Prefix-SID would be indicating a distinct range but adhering to the same parameters of the range that are indicated in the Extended Prefix Range TLV? This seems a little weird on the face of it (as opposed to a single Prefix-SID sub-TLV per Extended Prefix Range), but maybe there's a use case that I'm missing on first glance. Section 7.1 (Probably off-topic: what's the use case for assigning the same Adj-SID to different adjacencies?) Section 7.2 Perhaps add DR to the terminology section (or expand on first usage)? Section 8.1 When a Prefix-SID is advertised by the Mapping Server, which is indicated by the M-flag in the Prefix-SID Sub-TLV (Section 6), the route type as implied by the LSA type is ignored and the Prefix-SID is bound to the corresponding prefix independent of the route type. Is this considered to be Update-ing the behavior of another RFC? Advertisement of the Prefix-SID by the Mapping Server using an Inter- Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV [RFC8362] does not itself contribute to the prefix reachability. The NU-bit MUST be set in the PrefixOptions field of the LSA which is used by the Mapping Server to advertise SID or SID Range, which prevents the advertisement from contributing to prefix reachability. This MUST reads like it is restating an existing normative requirement from elsewhere (in which case we should probably just state it as fact and provide a reference). Or is it a new requirement (in which case Updates: might be in order)? Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between areas. Similar to propagation of prefixes between areas, an ABR only propagates the OSPFv3 Extended Prefix Range TLV that it considers to be the best from the set it received. The rules used to pick the best OSPFv3 Extended Prefix Range TLV are described in Section 5. I don't see any usage of "best" in Section 5; I do see direction to use the numerically smallest Instance ID when multiple Extended Prefix Range TLVs advertise *the exact same range*. But this in and of itself does not safisfy the claim here that there is guidance to pick a single best Extended Prefix Range TLV, so I'm left confused as to what's supposed to happen. Perhaps this was intended as a transition to Section 8.2 instead of referring back to Section 5 (especially considering that Section 8.1 is supposed to be intra-area but this topic is inter-area)? (This sort of dangling/unclear internal reference would normally be a DISCUSS, but it seems very likely this is just a stale section number and not a real problem, so I'm keeping it in the COMMENT section for now.) Section 8.4.1 Do we need a reference for 2-Way and FULL? Section 9 I would normally expect some text about "IANA has made permanent the following temporary allocations" or similar, so the reader can quickly tell that this is not a case of codepoint squatting. |
2019-01-10
|
23 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-01-09
|
23 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-23.txt |
2019-01-09
|
23 | (System) | New version approved |
2019-01-09
|
23 | (System) | Request for posting confirmation emailed to previous authors: lsr-chairs@ietf.org, Stefano Previdi , Peter Psenak |
2019-01-09
|
23 | Peter Psenak | Uploaded new revision |
2019-01-02
|
22 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-22.txt |
2019-01-02
|
22 | (System) | New version approved |
2019-01-02
|
22 | (System) | Request for posting confirmation emailed to previous authors: lsr-chairs@ietf.org, Stefano Previdi , Peter Psenak |
2019-01-02
|
22 | Peter Psenak | Uploaded new revision |
2018-12-14
|
21 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-12-14
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-12-14
|
21 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-21.txt |
2018-12-14
|
21 | (System) | New version approved |
2018-12-14
|
21 | (System) | Request for posting confirmation emailed to previous authors: lsr-chairs@ietf.org, Stefano Previdi , Peter Psenak |
2018-12-14
|
21 | Peter Psenak | Uploaded new revision |
2018-12-06
|
20 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-12-06
|
20 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-12-05
|
20 | Suresh Krishnan | [Ballot comment] * I share Benjamin's confusion regarding the prefix ranges and would like this to be clarified. * For the address family, I do … [Ballot comment] * I share Benjamin's confusion regarding the prefix ranges and would like this to be clarified. * For the address family, I do have a suggestion. There is an IANA registry for Address Family Numbers that can provide the extensibility needed. If future extensibility of this space is desired, this might be an option to consider. https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml |
2018-12-05
|
20 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-12-05
|
20 | Ben Campbell | [Ballot comment] I had the same comment as Alissa. |
2018-12-05
|
20 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-12-05
|
20 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-12-05
|
20 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-12-04
|
20 | Benjamin Kaduk | [Ballot discuss] What is the extensibility model for the "AF" (address family) field in the OSPFv3 Extended Prefix Range TLV? That is, what do we … [Ballot discuss] What is the extensibility model for the "AF" (address family) field in the OSPFv3 Extended Prefix Range TLV? That is, what do we need to say about current implementations' behavior to allow future changes? (I also a little bit wonder if we really need a full eight bits, but that's basically aesthetic.) Some of the text in Section 8.1 (see the COMMENT section) reads like it might have an "Updates" relationship with other documents, but I don't know enough to be sure. Hopefully we can have a conversation to clarify the situation. |
2018-12-04
|
20 | Benjamin Kaduk | [Ballot comment] Section 1 Is there a start of the separate document that covers SR with the IPv6 data plane that we could reference from … [Ballot comment] Section 1 Is there a start of the separate document that covers SR with the IPv6 data plane that we could reference from here? Section 5 In some cases it is useful to advertise attributes for a range of prefixes. The Segment Routing Mapping Server, which is described in [I-D.ietf-spring-segment-routing-ldp-interop], is an example of where a single advertisement is needed to advertise SIDs for multiple prefixes from a contiguous address range. I note that the referenced document does not use the word "range" to describe the prefix being assigned multiple SIDs; it might be helpful to say a few more words about how the range of prefixes gets mapped to what is discussed in the linked document. I'm also not entirely sure how to construct the prefix range just given this format description. Suppose I have an IPv4 prefix of 18.18/16 and a range size of 4; my prefix length is 16 and the address prefix is encoded as 0x120120000. Am I then representing the four prefixes 18.18/16, 18.19/16, 18.20/16, and 18.21/16? Or am I constrained to be a subset of 18.18/18 (in which case I don't know what the actual distinct prefixes would be)? The examples in Section 6 suggests the former, but I would suggest stating this explictly, here. Section 6 Should there be any discussion of the historical or future reasons why V and L are separate flag bits, given that the only legal combinations are currently 00 and 11, i.e., fully redundant? It may not be necessary to expand ASBR on first usage here, since it's in the terminology section (and marked as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt). If the NP-Flag is not set, then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane. If the NP-flag is not set, then the received E-flag is ignored. Is it going to be clear that "pop" only applies when this Prefix-SID is the outermost label? (Or am I super-confused about how this is supposed to work?) A similar consideration may apply to the discussion of the NP flag as well. Also some redundantly expanded ABR and ASBR here as well. This is useful, e.g., when the originator of the Prefix- SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. Are we still supposed to call these the EXP bits after RFC 5462? (I had to look up what they were; not sure if this means that we should put a reference in for them or not, given that I'm not a practitioner here.) When the M-Flag is set, the NP-flag and the E-flag MUST be ignored on reception. Do I understand this correctly that this is because the mapping server may not know the needs of the individual routers, and if the routers had specific needs they should advertise the SIDs directly (which would take precedence over the mapping server's advertisement)? If so, given the following discussion, I wouldn't suggest adding any extra text about it, but I do want to make sure I'm understanding it properly. When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a starting SID/Label value. Am I remembering correctly that Prefix-SID can appear multiple times within OSPFv3 Extended Prefix Range? Then each Prefix-SID would be indicating a distinct range but adhering to the same parameters of the range that are indicated in the Extended Prefix Range TLV? This seems a little weird on the face of it (as opposed to a single Prefix-SID sub-TLV per Extended Prefix Range), but maybe there's a use case that I'm missing on first glance. Section 7.1 (Probably off-topic: what's the use case for assigning the same Adj-SID to different adjacencies?) Section 7.2 Perhaps add DR to the terminology section (or expand on first usage)? Section 8.1 When a Prefix-SID is advertised by the Mapping Server, which is indicated by the M-flag in the Prefix-SID Sub-TLV (Section 6), the route type as implied by the LSA type is ignored and the Prefix-SID is bound to the corresponding prefix independent of the route type. Is this considered to be Update-ing the behavior of another RFC? Advertisement of the Prefix-SID by the Mapping Server using an Inter- Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV [RFC8362] does not itself contribute to the prefix reachability. The NU-bit MUST be set in the PrefixOptions field of the LSA which is used by the Mapping Server to advertise SID or SID Range, which prevents the advertisement from contributing to prefix reachability. This MUST reads like it is restating an existing normative requirement from elsewhere (in which case we should probably just state it as fact and provide a reference). Or is it a new requirement (in which case Updates: might be in order)? Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between areas. Similar to propagation of prefixes between areas, an ABR only propagates the OSPFv3 Extended Prefix Range TLV that it considers to be the best from the set it received. The rules used to pick the best OSPFv3 Extended Prefix Range TLV are described in Section 5. I don't see any usage of "best" in Section 5; I do see direction to use the numerically smallest Instance ID when multiple Extended Prefix Range TLVs advertise *the exact same range*. But this in and of itself does not safisfy the claim here that there is guidance to pick a single best Extended Prefix Range TLV, so I'm left confused as to what's supposed to happen. Perhaps this was intended as a transition to Section 8.2 instead of referring back to Section 5 (especially considering that Section 8.1 is supposed to be intra-area but this topic is inter-area)? (This sort of dangling/unclear internal reference would normally be a DISCUSS, but it seems very likely this is just a stale section number and not a real problem, so I'm keeping it in the COMMENT section for now.) Section 8.4.1 Do we need a reference for 2-Way and FULL? Section 9 I would normally expect some text about "IANA has made permanent the following temporary allocations" or similar, so the reader can quickly tell that this is not a case of codepoint squatting. |
2018-12-04
|
20 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-12-04
|
20 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-12-04
|
20 | Alissa Cooper | [Ballot comment] Please use the RFC 8147 boilerplate rather than the RFC 2119 boilerplate. |
2018-12-04
|
20 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2018-12-04
|
20 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-12-04
|
20 | Warren Kumari | [Ballot comment] Thanks to Joe Clarke for his OpsDir review: https://datatracker.ietf.org/doc/review-ietf-ospf-ospfv3-segment-routing-extensions-16-opsdir-lc-clarke-2018-10-26/ , and thank you authors for addressing them. |
2018-12-04
|
20 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2018-12-04
|
20 | Warren Kumari | [Ballot comment] Thanks to Joe Clarke for his OpsDir review: https://datatracker.ietf.org/doc/review-ietf-ospf-ospfv3-segment-routing-extensions-16-opsdir-lc-clarke-2018-10-26/ I'd encourage the authors to ensure they have addressed all the comments. |
2018-12-04
|
20 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-12-04
|
20 | Spencer Dawkins | [Ballot comment] The Introduction would have been much clearer for me if these paragraphs were much closer to the top of the section - they're … [Ballot comment] The Introduction would have been much clearer for me if these paragraphs were much closer to the top of the section - they're at the bottom of the section now. This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are described in [RFC7855]. With that change, I'm not sure how much of the discussion in the Introduction would still be required, but do the right thing, of course. I'd make the same suggestion for the Abstract, Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. if it was more than two paragraphs long ... I am thinking that the reference There are additional segment types, e.g., Binding SID defined in [RFC8402]. would be more useful at the beginning of Section 3, because that's where you list the additional segment types, but the reference is back in the Introduction (with only one example of the segment types). I'm thinking the SHOULD in this text Existing security extensions as described in [RFC5340] and [RFC8362] apply to these segment routing extensions. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. is not an RFC 2119 SHOULD that describes interworking, so something like In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] are needed. would be better, but if this IS a SHOULD, I'm curious why you wouldn't use stronger authentication mechanisms if they're needed. You might want to add guidance about that, so it's not confused with MUST (BUT WE KNOW YOU WON'T) as defined in https://tools.ietf.org/html/rfc6919#section-1. Is there another document that says things like Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv3 router or routing process. Reception of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPFv3 control plane. ? This doesn't seem very SR-specific, although I'm guessing. If there's a broader document, I don't object to including this guidance here, but adding a reference to a broader document might be useful. |
2018-12-04
|
20 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2018-12-04
|
20 | Spencer Dawkins | [Ballot comment] The Introduction would have been much clearer for me if these paragraphs were much closer to the top of the section - they're … [Ballot comment] The Introduction would have been much clearer for me if these paragraphs were much closer to the top of the section - they're at the bottom of the section now. This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are described in [RFC7855]. With that change, I'm not sure how much of the discussion in the Introduction would still be required, but do the right thing, of course. I'd make the same suggestion for the Abstract, Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. if it was more than two paragraphs long ... I am thinking that the reference There are additional segment types, e.g., Binding SID defined in [RFC8402]. would be more useful at the beginning of Section 3, because that's where you list the additional segment types, but the reference is back in the Introduction (with only one example of the segment types). I'm not thinking the SHOULD in this text Existing security extensions as described in [RFC5340] and [RFC8362] apply to these segment routing extensions. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. is not an RFC 2119 SHOULD that describes interworking, so something like In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] are needed. would be better, but if this IS a SHOULD, I'm curious why you wouldn't use stronger authentication mechanisms if they're needed. You might want to add guidance about that, so it's not confused with MUST (BUT WE KNOW YOU WON'T) as defined in https://tools.ietf.org/html/rfc6919#section-1. Is there another document that says things like Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv3 router or routing process. Reception of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPFv3 control plane. ? This doesn't seem very SR-specific, although I'm guessing. If there's a broader document, I don't object to including this guidance here, but adding a reference to a broader document might be useful. |
2018-12-04
|
20 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-12-04
|
20 | Martin Vigoureux | [Ballot comment] Hello, thank you for this document. I do have the usual IESG comment of suggesting to use RFC 8174 text for the requirement … [Ballot comment] Hello, thank you for this document. I do have the usual IESG comment of suggesting to use RFC 8174 text for the requirement language, and also have a suggestion: In section 7.2 you say: When the P-flag is not set, the Adj-SID MAY be persistent. When the P-flag is set, the Adj-SID MUST be persistent. Because we're in the LAN Adjacency section you may want to qualify the Adj-SID as being a LAN one. |
2018-12-04
|
20 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-12-03
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-12-03
|
20 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-20.txt |
2018-12-03
|
20 | (System) | New version approved |
2018-12-03
|
20 | (System) | Request for posting confirmation emailed to previous authors: lsr-chairs@ietf.org, Stefano Previdi , Peter Psenak |
2018-12-03
|
20 | Peter Psenak | Uploaded new revision |
2018-12-03
|
19 | Pete Resnick | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list. |
2018-12-03
|
19 | Mirja Kühlewind | [Ballot comment] Minor comments: 1) In intro: "...while an adjacency segment, in most cases, is a one-hop path." Is that true, that in _most_ … [Ballot comment] Minor comments: 1) In intro: "...while an adjacency segment, in most cases, is a one-hop path." Is that true, that in _most_ cases it is one hop? I though SR makes most sense in order to specify routers/hops that need to be visited, not matter how many hops are in between. 2) The contributor section has the following statement: "The following people gave a substantial contribution to the content of this document and should be considered as co-authors:" Should this section then not be called "Authors" instead? |
2018-12-03
|
19 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-11-20
|
19 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete Resnick |
2018-11-20
|
19 | Jean Mahoney | Request for Telechat review by GENART is assigned to Pete Resnick |
2018-11-20
|
19 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-11-20
|
19 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-19.txt |
2018-11-20
|
19 | (System) | New version approved |
2018-11-20
|
19 | (System) | Request for posting confirmation emailed to previous authors: lsr-chairs@ietf.org, Stefano Previdi , Peter Psenak |
2018-11-20
|
19 | Peter Psenak | Uploaded new revision |
2018-11-16
|
18 | Amy Vezza | Placed on agenda for telechat - 2018-12-06 |
2018-11-16
|
18 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-11-16
|
18 | Alvaro Retana | Ballot has been issued |
2018-11-16
|
18 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2018-11-16
|
18 | Alvaro Retana | Created "Approve" ballot |
2018-11-16
|
18 | Alvaro Retana | Ballot writeup was changed |
2018-11-16
|
18 | Pete Resnick | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list. |
2018-11-16
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-11-16
|
18 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-18.txt |
2018-11-16
|
18 | (System) | New version approved |
2018-11-16
|
18 | (System) | Request for posting confirmation emailed to previous authors: lsr-chairs@ietf.org, Stefano Previdi , Peter Psenak |
2018-11-16
|
18 | Peter Psenak | Uploaded new revision |
2018-11-16
|
17 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-11-14
|
17 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Tomonori Takeda. |
2018-11-13
|
17 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-11-13
|
17 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16. 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-ospf-ospfv3-segment-routing-extensions-16. If any part of this review is inaccurate, please let us know. NOTE/QUESTION: The first sentence in the IANA Considerations states that "This specification updates several existing OSPFv3 registries." However, the document appears to be updating only two registries. Should this sentence be changed, or was the intention for the document to make more updates? QUESTION: The registrations in this document capitalize the first letter in "Sub-TLV," but existing registrations in the "OSPFv3 Extended-LSA Sub-TLVs" do not. Should the "s" in "Sub-TLV" be lower-case? The IANA Functions Operator understands that upon approval of this document, there are two actions to complete. First, in the OSPFv3 Extended-LSA TLVs registry on the Open Shortest Path First v3 (OSPFv3) Parameters registry page at https://www.iana.org/assignments/ospfv3-parameters/ the existing, TEMPORARY registration for Value: 9 Description: OSPFv3 Extended Prefix Range TLV will be made permanent, with its reference updated to [ RFC-to-be ]. Second, in the OSPFv3 Extended-LSA Sub-TLVs registry also on the Open Shortest Path First v3 (OSPFv3) Parameters registry page at https://www.iana.org/assignments/ospfv3-parameters/ the four existing TEMPORARY registrations for: Value: 4 Description: Prefix SID Sub-TLV Value: 5 Description: Adj-SID Sub-TLV Value: 6 Description: LAN Adj-SID Sub-TLV Value: 7 Description: SID/Label Sub-TLV will each be made permanent, with references updated to [ RFC-to-be ]. The IANA Functions Operator understands that these are the only actions 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, Amanda Baber Lead IANA Services Specialist |
2018-11-05
|
17 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-17.txt |
2018-11-05
|
17 | (System) | New version approved |
2018-11-05
|
17 | (System) | Request for posting confirmation emailed to previous authors: lsr-chairs@ietf.org, Stefano Previdi , Peter Psenak |
2018-11-05
|
17 | Peter Psenak | Uploaded new revision |
2018-11-04
|
16 | Yaron Sheffer | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Yaron Sheffer. Sent review to list. |
2018-10-26
|
16 | Joe Clarke | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Joe Clarke. Sent review to list. |
2018-10-26
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2018-10-26
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2018-10-25
|
16 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tomonori Takeda |
2018-10-25
|
16 | Min Ye | Request for Last Call review by RTGDIR is assigned to Tomonori Takeda |
2018-10-25
|
16 | Alvaro Retana | Requested Last Call review by RTGDIR |
2018-10-25
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2018-10-25
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2018-10-25
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-10-25
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-10-23
|
16 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-10-23
|
16 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-11-16): From: The IESG To: IETF-Announce CC: draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org, aretana.ietf@gmail.com, lsr-chairs@ietf.org, Acee Lindem , … The following Last Call announcement was sent out (ends 2018-11-16): From: The IESG To: IETF-Announce CC: draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org, aretana.ietf@gmail.com, lsr-chairs@ietf.org, Acee Lindem , lsr@ietf.org, acee@cisco.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (OSPFv3 Extensions for Segment Routing) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPFv3 Extensions for Segment Routing' 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 ietf@ietf.org mailing lists by 2018-11-16. 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 Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2234/ https://datatracker.ietf.org/ipr/2812/ |
2018-10-23
|
16 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-10-23
|
16 | Alvaro Retana | Last call was requested |
2018-10-23
|
16 | Alvaro Retana | Ballot approval text was generated |
2018-10-23
|
16 | Alvaro Retana | Ballot writeup was generated |
2018-10-23
|
16 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-10-23
|
16 | Alvaro Retana | Last call announcement was changed |
2018-10-23
|
16 | Alvaro Retana | Last call announcement was generated |
2018-10-21
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-10-21
|
16 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-16.txt |
2018-10-21
|
16 | (System) | New version approved |
2018-10-21
|
16 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , … Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2018-10-21
|
16 | Peter Psenak | Uploaded new revision |
2018-10-16
|
15 | Alvaro Retana | === AD Review of draft-ietf-ospf-ospfv3-segment-routing-extensions-15 === Dear authors: I just finished reviewing this document. Interestingly, or maybe not, this document is pretty much the same … === AD Review of draft-ietf-ospf-ospfv3-segment-routing-extensions-15 === Dear authors: I just finished reviewing this document. Interestingly, or maybe not, this document is pretty much the same (almost word-by-word!) as draft-ietf-ospf-segment-routing-extensions. I have to wonder, why didn't we just publish one document instead of two? Too late now of course...just wondering. I just have a couple of significant comments (see details below), mostly resulting from the copy/paste/replace exercise. The major issues I call out below are: (1) number of authors (2) the IGP Algorithm Type Registry should be reused I will wait for these points to be addressed before starting the IETF LC. Thanks! Alvaro. [The line numbers are provided by idnits.] 2 Open Shortest Path First IGP P. Psenak, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: February 4, 2019 S. Previdi, Ed. 6 Individual 7 H. Gredler 8 RtBrick Inc. 9 R. Shakir 10 Google, Inc. 11 W. Henderickx 12 Nokia 13 J. Tantsura 14 Nuage Networks [major] There are 7 authors listed. I know that the same question came up when processing draft-ietf-ospf-segment-routing-extensions, but I couldn't find a specific justification to keep all 7 names in the front page. I note that there are details in the Shepherd's Writeup for draft-ietf-ospf-segment-routing-extensions, but nothing equivalent for this draft. It does however mention that "the document shepherd have [sic] provided more substantive comments and edits to the document than most of the authors." Given the above, I am inclined to ask for just the 2 editors to be listed in the front page...the rest can be listed in a Contributors section. ... 134 2.1. SID/Label Sub-TLV ... 155 SID/Label: If length is set to 3, then the 20 rightmost bits 156 represent a label. If length is set to 4, then the value 157 represents a 32-bit SID. 159 The receiving router MUST ignore the SID/Label Sub-TLV if the 160 length is other then 3 or 4. [major] What is a 32-bit SID in an MPLS-only implementation of Segment Routing? If I'm not missing anything, the only valid value in the OSPFv3-MPLS-only should be a Length of 3. ... 170 3.1. SR-Algorithm TLV ... 205 Algorithm: Single octet identifying the algorithm. The following 206 values are defined by this document: [major] Should these values be taken from IGP Algorithm Type Registry set up in draft-ietf-ospf-segment-routing-extensions, or will there be a new registry? I'm assuming the former... ... 473 4. OSPFv3 Extended Prefix Range TLV ... 483 The OSPFv3 Extended Prefix Range TLV is a top-level TLV of the 484 following LSAs defined in [RFC8362]: 486 E-Intra-Area-Prefix-LSA 488 E-Inter-Area-Prefix-LSA 490 E-AS-External-LSA 492 E-Type-7-LSA 494 Multiple OSPFv3 Extended Prefix Range TLVs MAY be advertised in each 495 LSA mentioned above. The OSPFv3 Extended Prefix Range TLV has the 496 following format: [minor] What if the OSPFv3 Extended Prefix Range TLVs are in fact advertised in multiple LSAs (not just multiple times in the same LSA, but multiple TLVs distributed among different LSAs)? If the same range is advertised on different LSAs, but with different attributes. Is this a possibility? ... 522 AF: Address family for the prefix. 524 AF: 0 - IPv4 unicast 526 AF: 1 - IPv6 unicast [nit] It's too bad that the AFs don't match IANA's AF registry [1]. No action needed. [1] https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml ... 1043 8. IANA Considerations 1045 This specification updates several existing OSPFv3 registries. 1047 8.1. OSPFv3 Extended-LSA TLV Registry 1049 Following values are allocated: 1051 o suggested value 9 - OSPFv3 Extended Prefix Range TLV [nit] This value is not suggested...but it has already been allocated by IANA. ... 1063 9. Security Considerations 1065 With the OSPFv3 segment routing extensions defined herein, OSPFv3 1066 will now program the MPLS data plane [RFC3031] in addition to the IP 1067 data plane. Previously, LDP [RFC5036] or another label distribution 1068 mechanism was required to advertise MPLS labels and program the MPLS 1069 data plane. [minor] The IP date plane is out of scope. |
2018-10-16
|
15 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-09-07
|
15 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2018-09-07
|
15 | Alvaro Retana | Notification list changed to Acee Lindem <acee@cisco.com>, aretana.ietf@gmail.com from Acee Lindem <acee@cisco.com> |
2018-08-03
|
15 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-15.txt |
2018-08-03
|
15 | (System) | New version approved |
2018-08-03
|
15 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , … Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2018-08-03
|
15 | Peter Psenak | Uploaded new revision |
2018-08-02
|
14 | Acee Lindem | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … (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? A Standards Track RFC is being requested and is indicated in the title page header. (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 the OSPFv3 extensions for segment routing including Prefix-SID, Adjacency-SID, and LAN-Adjacency-SID. The extensions are based on RFC 8362 and RFC 7770. Working Group Summary: The Working Group discussion has been dominated by the initial vendors that implemented the segment routing on OSPFv2 (Juniper, Cisco, Nokia, and Huawei). We were waiting for completion the OSPFv2 Segment Routing specifications and implementation of RFC 8362. Document Quality: The document has been implemented by Huawei and Nokia and is planned by other. The encoding changes have mirrored those in the OSPFv2 segment routing extensions. Personnel: Acee Lindem is the Document Shepherd. Alvaro Retana is the Responsible Area Director. (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. The document shepherd has reviewed each revision of the document and followed the discussion on the OSPF/LSR mailing lists. In fact, the document shepherd have provided more substantive comments and edits to the document than most of the authors. (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. None. (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. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes - there is an IPR disclosure on non-WG version and a second one on the WG version of the document. The terms are such that the patent will not be asserted unless the party asserts a patent against the holder (forget the term for this). https://datatracker.ietf.org/ipr/2233/ (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 consensus from the WG and others outside the WG that this document can progress. The OSPFv2 Segment Routing Extensions are on the RFC Editor's queue. (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. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits are all resolved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (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). The Segment Routing extensions required allocation of a number of code points from the registries created for RFC 8362. These code points were pre-allocated through IANA early allocation as described in RFC 7120. Additionally, code points allocated for OSPFv2 Segment Routing are reused for the OSPFv3 Router Information LSA. (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. 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. Not applicable. |
2018-08-02
|
14 | Acee Lindem | Responsible AD changed to Alvaro Retana |
2018-08-02
|
14 | Acee Lindem | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-08-02
|
14 | Acee Lindem | IESG state changed to Publication Requested |
2018-08-02
|
14 | Acee Lindem | IESG process started in state Publication Requested |
2018-08-02
|
14 | Acee Lindem | Changed document writeup |
2018-08-02
|
14 | Acee Lindem | Notification list changed to Acee Lindem <acee@cisco.com> |
2018-08-02
|
14 | Acee Lindem | Document shepherd changed to Acee Lindem |
2018-08-02
|
14 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-14.txt |
2018-08-02
|
14 | (System) | New version approved |
2018-08-02
|
14 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , … Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2018-08-02
|
14 | Peter Psenak | Uploaded new revision |
2018-05-23
|
13 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-13.txt |
2018-05-23
|
13 | (System) | New version approved |
2018-05-23
|
13 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , … Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2018-05-23
|
13 | Peter Psenak | Uploaded new revision |
2018-04-20
|
12 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-12.txt |
2018-04-20
|
12 | (System) | New version approved |
2018-04-20
|
12 | (System) | Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , … Request for posting confirmation emailed to previous authors: Wim Henderickx , lsr-chairs@ietf.org, Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Rob Shakir |
2018-04-20
|
12 | Peter Psenak | Uploaded new revision |
2018-03-20
|
11 | Christian Hopps | Added to session: IETF-101: lsr Wed-0930 |
2018-02-28
|
11 | Cindy Morgan | Notification list changed to none |
2018-02-28
|
11 | Cindy Morgan | Changed group to Link State Routing (LSR) from Open Shortest Path First IGP (OSPF) |
2018-01-26
|
11 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-11.txt |
2018-01-26
|
11 | (System) | New version approved |
2018-01-26
|
11 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , ospf-chairs@ietf.org, Rob Shakir |
2018-01-26
|
11 | Peter Psenak | Uploaded new revision |
2017-09-05
|
10 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-10.txt |
2017-09-05
|
10 | (System) | New version approved |
2017-09-05
|
10 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-09-05
|
10 | Peter Psenak | Uploaded new revision |
2017-03-08
|
09 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-09.txt |
2017-03-08
|
09 | (System) | New version approved |
2017-03-08
|
09 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-03-08
|
09 | Peter Psenak | Uploaded new revision |
2017-02-28
|
08 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-08.txt |
2017-02-28
|
08 | (System) | New version approved |
2017-02-28
|
08 | (System) | Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils … Request for posting confirmation emailed to previous authors: Stefano Previdi , Wim Henderickx , Peter Psenak , Hannes Gredler , Jeff Tantsura , Clarence Filsfils , Rob Shakir |
2017-02-28
|
08 | Peter Psenak | Uploaded new revision |
2016-10-28
|
07 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-07.txt |
2016-10-28
|
07 | (System) | New version approved |
2016-10-28
|
06 | (System) | Request for posting confirmation emailed to previous authors: "Jeff Tantsura" , "Rob Shakir" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Peter Psenak" … Request for posting confirmation emailed to previous authors: "Jeff Tantsura" , "Rob Shakir" , "Hannes Gredler" , "Clarence Filsfils" , "Stefano Previdi" , "Peter Psenak" , ospf-chairs@ietf.org, "Wim Henderickx" |
2016-10-28
|
06 | Peter Psenak | Uploaded new revision |
2016-07-06
|
06 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-06.txt |
2016-06-20
|
Maddy Conner | Posted related IPR disclosure: Cisco Systems, Inc.'s Statement about IPR related to draft-ietf-ospf-ospfv3-segment-routing-extensions | |
2016-06-17
|
05 | Acee Lindem | Changed consensus to Yes from Unknown |
2016-06-17
|
05 | Acee Lindem | Intended Status changed to Proposed Standard from None |
2016-03-21
|
05 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-05.txt |
2015-12-22
|
04 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-04.txt |
2015-11-09
|
03 | Acee Lindem | This document now replaces draft-psenak-ospf-segment-routing-ospfv3-extension instead of None |
2015-06-26
|
03 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-03.txt |
2015-02-18
|
02 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-02.txt |
2015-02-13
|
01 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-01.txt |
2014-08-19
|
00 | Peter Psenak | New version available: draft-ietf-ospf-ospfv3-segment-routing-extensions-00.txt |