Skip to main content

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