Re: [Lsr] IPR Poll for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07
Sorry, someone reminded me that there is an IPR related to using the draft-shen-isis-spine-leaf-ext scheme, https://datatracker.ietf.org/ipr/2736/ thanks. - Naiming On Dec 17, 2018, at 3:22 PM, Naiming Shen (naiming) mailto:naim...@cisco.com>> wrote: Hi, I am not aware of any IPR applies to draft-shen-isis-spine-leaf-ext. thanks. - Naiming On Dec 17, 2018, at 5:47 AM, Acee Lindem (acee) mailto:a...@cisco.com>> wrote: Authors, Are you aware of any IPR that applies to draft-shen-isis-spine-leaf-ext? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There are currently no 3 IPR disclosures so everyone should be aware of these - https://datatracker.ietf.org/ipr/search/?submit=draft=draft-shen-isis-spine-leaf-ext If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IPR Poll for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07
Hi, I am not aware of any IPR applies to draft-shen-isis-spine-leaf-ext. thanks. - Naiming On Dec 17, 2018, at 5:47 AM, Acee Lindem (acee) mailto:a...@cisco.com>> wrote: Authors, Are you aware of any IPR that applies to draft-shen-isis-spine-leaf-ext? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There are currently no 3 IPR disclosures so everyone should be aware of these - https://datatracker.ietf.org/ipr/search/?submit=draft=draft-shen-isis-spine-leaf-ext If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Alissa Cooper's No Objection on draft-ietf-lsr-isis-rfc7810bis-03: (with COMMENT)
Alissa Cooper has entered the following ballot position for draft-ietf-lsr-isis-rfc7810bis-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ -- COMMENT: -- In section 13 it seems a little awkward to reference the "first version" and "second version" of the document since they will be published with different RFC numbers. Might be clearer to say RFC 7810 in the first instance and "this document" in the second instance. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] IPR Poll for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07
Authors, Are you aware of any IPR that applies to draft-shen-isis-spine-leaf-ext? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There are currently no 3 IPR disclosures so everyone should be aware of these - https://datatracker.ietf.org/ipr/search/?submit=draft=draft-shen-isis-spine-leaf-ext If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06
Hi Padma, Is the updated draft coming soon? Thanks, Acee On 11/28/18, 2:31 PM, "Padmadevi Pillay Esnault" wrote: Dear Alvaro Thank you for your review. We will go through the comments and work on them. Thanks Padma on behalf of my co-authors On 11/28/18, 7:53 AM, "Alvaro Retana" wrote: Dear authors: I just finished reading this document. Even though it is relatively short, I have significant concerns and I think it needs more work. Please take a look at the detailed comments in-line below -- I'm highlighting some of the issues here. (1) What is the Update to rfc2328? Please be specific in both the Abstract and the Introduction to indicate how rfc2328 is Updated. Also, see my question about rfc6987 in §6. (2) Operational/Deployment Considerations. There are several places (specially in §3) where the specification offers a choice (e.g. by using MAY). Some of those choices would be better informed if there was a discussion of the considerations behind them. Please take a look at rfc5706 (specially §2). Either a discussion close to where the behavior is specified or a separate section is ok. Please also keep migration in mind (see comments in §5). (3) Both the IANA and Security Considerations sections need more details. I will wait for them to be addressed before starting the IETF Last Call. Thanks! Alvaro. [The line numbers come from idnits.] ... 11H-bit Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-06 [nit] Please make the title more descriptive. "non-transit router", "host mode", etc. come to mind. 14 Abstract 16 OSPFv3 defines an option bit for router-LSAs known as the R-bit in 17 RFC5340. If the R-bit is clear, an OSPFv3 router can participate in 18 OSPF topology flooding, however it will not be used as a transit 19 router. In such cases, other routers in the OSPFv3 routing domain 20 only install routes to allow local traffic delivery. This document 21 defines the H-bit functionality to prevent other OSPFv2 routers from 22 using the router for transit traffic in OSPFv2 routing domains as 23 described in RFC 2328. This document updates RFC 2328. [minor] Describing the functionality in terms of OSPFv2 would have been nice. IOW, there's no need (in the Abstract) to force the reader to go figure out what OSPFv3 already did to decide if it's worth reading this document or not. [major] What is the Update to rfc2328? Please be specific, both here and in the Introduction: don't just mention the section updated, but (more important) what is the update about. "This document updates rfc2328 by assigning a bit...changing the SPF process...creating a registry..." All/none/something else? Note that the answer to "what is the update?" doesn't have to be all. I think that the registry creation is a must. But Updating because of the SPF changes means that you expect an rfc2328 implementation to consider the H-bit when running SPF. I think you really mean that implementations of this document (i.e. not all rfc2328 implementations) have to use the modified SPF. That is my guess...please consider the answer carefully. ... 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)
Hi Benjamin, please see inline (##PP): On 17/12/2018 06:53 , Benjamin Kaduk wrote: Sorry for the slow reply -- you caught me right as I was leaving for vacation. On Wed, Dec 05, 2018 at 09:53:20AM +0100, Peter Psenak wrote: Hi Benjamin, please see inline: On 05/12/18 04:44 , Benjamin Kaduk wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-ospf-ospfv3-segment-routing-extensions-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ -- 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.) I don't think OSPFv3 will ever support other then IPv6 or IPv4 AF. Also the text says: "Prefix encoding for other address families is beyond the scope of this specification." Perhaps it would be better encoded in a 1-bit field (rather than an 8-bit one), then? That would at least make the (lack of) semantics of the other 7 bits more clear, as the usual "MUST set to zero on transmit and ignore on receipt". ##PP it's too late now to change the encoding. This draft has several years of history and there are implementation shipping. Changing the encoding would cause the backward compatibility issues. 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. please see my comments below. Okay. -- 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? this document describes OSPFv3 extension for SR with the MPLS data plane, not IPv6 data plane. And rfc8402 is referenced. I understand the difference between OSPFv3 SR with MPLS vs. IPv6 data plane (well, at least that there is a difference). My point is that you say it "will be specified in a separate document". If there's an existing I-D that is the start of this work, listing it as an informative reference seems helpful to me. (If there's not, perhaps "at a later date" would work instead of "in a separate document".) But of course this is a non-blocking comment, so feel free to ignore -- I really don't mind. 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. "prefix being assigned multiple SIDs" - that is not what we are doing here. Hmm, I must have misspoke; sorry. My point remains, though, that if I go to I-D.ietf-spring-segment-routing-ldp-interop and search for "range", I will not find anything to help me know which part of that document you are talking about. I would encourage some additional text to clarify how the terminology used in this document relates to the terminology and work used in the referenced document. ##PP range is not defined in I-D.ietf-spring-segment-routing-ldp-interop, it's the SRMS functionality that is defined there. The range was defined for IGPs to optimize the encoding for SRMS advertisement - with thousands of prefixes the encoding would not scale if we advertise the individual SID for every prefix independently. What about the following updated text in the OSPFv3 draft: "In some cases it is useful to advertise attributes for a range of prefixes. The Segment Routing Mapping Server, which is described in , is an example of where SIDs for multiple prefixes can be advertised. To optimize such advertisement in case of multiple prefixes from a contiguous address range, OSPFv3 Extended Prefix Range TLV is defined." I'm
