Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)
On Wed, Oct 31, 2018 at 01:21:14AM +, Acee Lindem (acee) wrote: > Hi Ben, > > On 10/30/18, 9:09 PM, "Benjamin Kaduk" wrote: > > On Tue, Oct 30, 2018 at 02:28:12PM +, Acee Lindem (acee) wrote: > > Hi Ben, > > > > On 10/30/18, 10:08 AM, "Benjamin Kaduk" wrote: > > > > Hi Acee, > > > > On Thu, Oct 25, 2018 at 01:51:42PM +, Acee Lindem (acee) wrote: > > > Hi Ben, > > > > > > On 10/25/18, 8:22 AM, "Benjamin Kaduk" wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-ospf-lls-interface-id-08: 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-ospf-lls-interface-id/ > > > > > > > > > > > > > -- > > > COMMENT: > > > > -- > > > > > > Sending a new type of information to the peer usually > involves a privacy > > > considerations analysis. I don't expect there to be anything > worrisome > > > here, but some text in the document indicating that the > analysis has been > > > done would be reassuring. > > > > > > Can you suggest some text? I was thinking: > > > > I'm not sure that I could -- I don't have confidence that I > understand the > > system well enough to frame something in a complete and correct way. > > > > >Since the scope of the interface ID is limited to the > advertising OSPF router > > >uniquely identifying links, there are no privacy concerns > associated with its > > >advertisement. > > > > I wonder if there is a step missing to link these together -- that > the > > links are generally fixed and immobile, or that the scope of > distribution > > is limited to a set of trusted peers, perhaps? > > > > The point I'm making is that since the interface ID is only unique for > the network device, it doesn't provide any clue as to the identity of the > device owner or traffic transiting the device. Hence, there are no privacy > considerations associated with extension. It is also true that routing peers > are trusted but that is a moot point for this extension In the context of > privacy. > > Ah, I see; thanks. How does "The interface ID is locally assigned by the > advertising OSPF router as a uniquifier and need not be unique in any > broader context; it is not expected to contain any information about the > device owner or traffic transiting the device, so there are no privacy > concerns associated with its advertisement." sound? > > Sure - that is clearer. In fact, I realized that it wasn't obvious after > explaining it in my last Email. I'd avoid "uniquifier" since it isn't in the > dictionary yielding: > > The interface ID is assigned by the advertising OSPF router as a locally > unique identifier and need not be unique in any broader context; it is > not expected to contain any information about the device owner or > traffic transiting the device, so there are no privacy concerns > associated with its advertisement. Ship it! :) Thanks, Benjamin ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
On Tue, Oct 30, 2018 at 03:33:21PM +, Acee Lindem (acee) wrote: > Hi Les, > > On 10/30/18, 11:15 AM, "Les Ginsberg (ginsberg)" wrote: > > Acee - > > > > Section 3.2 > > > > > > "When a router receives multiple overlapping ranges, it MUST > > >conform to the procedures defined in > > >[I-D.ietf-spring-segment-routing-mpls]." > > > > > > It would be useful to include a section pointer here. I think > your referring > > > to Section 2.3 where the router ignores the range? Is it likely > that will > > > change to something other than "ignore?" If not, maybe it's just > worth > > > mentioning that here. > > > > ##PP > > I don't think it is good to specify the behavior which is described > > somewhere else. Regarding the section, the > > ietf-spring-segment-routing-mpls is still being worked on and the > > section may changes. We used the same text in OSPFv2 and ISIS SR > drafts. > > I would like to be consistent here. > > > > Given that this is a normative reference, I don't think it would create > too > > much of a dependency to include the section in the reference. We've had > a > > protracted discussion (1-2 years) on the whole SID overlap topic in > SPRING > > and I believe we've finally come up with behavior and the specification > of > > such behavior with which everyone agree (or at least doesn't strongly > > disagree). > > > [Les:] I strongly agree with Peter (and disagree with you). > Why would we want to risk having an incorrect section reference to a > document which is still being revised? This needlessly introduces a > dependency such that if the section numbering changes in the SR-MPLS draft we > would then have to update the dependent document(s). > Note this has nothing to do with the SID overlap discussion itself. The > compelling reason to NOT discuss this in the IGP documents but simply refer > to the document that defines the solution is so that whatever the outcome in > SPRING the IGP documents do not also have to be changed. > > While I don't feel as strongly as either of you, this could improve the > readability. For example, if you read RFC 8362 you'll see that I have > referred extensively to sections in RFC 5340. I may be overoptimistic but I'm > hoping we are finally done with the SR-MPLS draft as it is blocking all our > LSR SR documents. I also agree that specific section references can (in general) aid readability. And there's always "[RFC Editor: please check with authors during AUTH48 that the section reference remains correct]"; we've done essentially that on a document I was shepherding in the past. -Benjamin ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] IPR Call for draft-ietf-ospf-xaf-te - "OSPF Routing with Cross-Address Family Traffic Engineering Tunnes"
In preparation for requesting publication, I’m making a second IPR call on the subject document. Are you aware of any IPR that applies to draft-ietf-ospf-xaf-te? 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 IPR disclosures against draft-ietf-ospf-xaf-te-04. 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] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Hi Les, On 10/30/18, 11:15 AM, "Les Ginsberg (ginsberg)" wrote: Acee - > > Section 3.2 > > > > "When a router receives multiple overlapping ranges, it MUST > >conform to the procedures defined in > >[I-D.ietf-spring-segment-routing-mpls]." > > > > It would be useful to include a section pointer here. I think your referring > > to Section 2.3 where the router ignores the range? Is it likely that will > > change to something other than "ignore?" If not, maybe it's just worth > > mentioning that here. > > ##PP > I don't think it is good to specify the behavior which is described > somewhere else. Regarding the section, the > ietf-spring-segment-routing-mpls is still being worked on and the > section may changes. We used the same text in OSPFv2 and ISIS SR drafts. > I would like to be consistent here. > > Given that this is a normative reference, I don't think it would create too > much of a dependency to include the section in the reference. We've had a > protracted discussion (1-2 years) on the whole SID overlap topic in SPRING > and I believe we've finally come up with behavior and the specification of > such behavior with which everyone agree (or at least doesn't strongly > disagree). > [Les:] I strongly agree with Peter (and disagree with you). Why would we want to risk having an incorrect section reference to a document which is still being revised? This needlessly introduces a dependency such that if the section numbering changes in the SR-MPLS draft we would then have to update the dependent document(s). Note this has nothing to do with the SID overlap discussion itself. The compelling reason to NOT discuss this in the IGP documents but simply refer to the document that defines the solution is so that whatever the outcome in SPRING the IGP documents do not also have to be changed. While I don't feel as strongly as either of you, this could improve the readability. For example, if you read RFC 8362 you'll see that I have referred extensively to sections in RFC 5340. I may be overoptimistic but I'm hoping we are finally done with the SR-MPLS draft as it is blocking all our LSR SR documents. Thanks, Acee Les ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Hi Peter, Joe, et al, On 10/30/18, 8:05 AM, "Peter Psenak (ppsenak)" wrote: Hi Joe, thanks for your review, please see inline (##PP): On 26/10/18 21:42 , Joe Clarke wrote: > Reviewer: Joe Clarke > Review result: Has Nits > > I have been assigned to review > draft-ietf-ospf-ospfv3-segment-routing-extensions on behalf of the ops > directorate. This document defines OSPFv3 extensions needed for segment > routing (SR). And therein lies my first nit. While the document begins to set > forth this overarching scope, a small paragraph in section 1 further limits it > to MPLS dataplanes only. I think perhaps the abstract should be updated to > clarify that. ##PP Done > Other items I found are listed below. > > Overall, there are a lot of terminology used like RSVP, LDP, LSP, SID, etc. I > think this document would benefit from a terminology section. ##PP added > > With respect to TLV types 8, 9, 14, and 15, they are defined in > draft-ietf-ospf-segment-routing-extensions, and it took me a while to figure > out where you were getting those values and why they weren't spelled out in the > IANA considerations. You have a normative reference to this, which is good, > but you only mention it with respect to the algorithm parameters. I think > another mention is required. > > I'm going to be pedantic here. According to RFC7770, when a new OSPF Router > Information LSA TLV is defined, the spec needs to explicitly state if it's > applicable to OSPFv2, v3, or both. While you reference the TLVs from > draft-ietf-ospf-segment-routing-extensions, I didn't see that either document > _explicitly_ states that they are applicable to both. ##PP added the following to each of the values: Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and aplicable to OSPFv3. > > === > > Section 2.1 > > s/length is other then 3 or 4/length is other than 3 or 4/ ##PP fixed > > === > > Section 3.2 > > s/If more then one SID/Label/If more than one SID/label/ ##PP fixed > > === > > Section 3.2 > > "When a router receives multiple overlapping ranges, it MUST >conform to the procedures defined in >[I-D.ietf-spring-segment-routing-mpls]." > > It would be useful to include a section pointer here. I think your referring > to Section 2.3 where the router ignores the range? Is it likely that will > change to something other than "ignore?" If not, maybe it's just worth > mentioning that here. ##PP I don't think it is good to specify the behavior which is described somewhere else. Regarding the section, the ietf-spring-segment-routing-mpls is still being worked on and the section may changes. We used the same text in OSPFv2 and ISIS SR drafts. I would like to be consistent here. Given that this is a normative reference, I don't think it would create too much of a dependency to include the section in the reference. We've had a protracted discussion (1-2 years) on the whole SID overlap topic in SPRING and I believe we've finally come up with behavior and the specification of such behavior with which everyone agree (or at least doesn't strongly disagree). > > === > > Section 3.3 > > s/If more then one SID/Label/If more than one SID/Label/ ##PP fixed. > > === > > Section 3.3 > > "The originating router MUST NOT advertise overlapping ranges." > > You specify what a router should do if it receives overlapping ranges above. I > think the same text should be used here, too. ##PP Here we say that the originating router MUST NOT advertise overlapping ranges. We can not specify what it should do when it breaks the MUST. We specify what other routers should do when they receive overlapping ranges and we refer it to spring-segment-routing-mpls draft. Again this is the same as we used in OSPFv3 and ISIS SR extensions. I would like to keep the consistency here. > > === > > Section 5 > > "Other bits: Reserved. These MUST be zero when sent and are > ignored when received." > > The normative language changes. In other places you say the bits SHOULD be 0. > I suggest: ##PP Whenever we refer to "other bits" in the flag fields we use the same language. > > Other bits: Reserved. These SHOULD be set to 0 when sent and MUST be ignored > when received. ##PP this refers to Reserved fields in the TLV (not the bits in a flag field) and again is used consistently across document. I agree. Use "These SHOULD be set to
Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)
Hi Acee, On Thu, Oct 25, 2018 at 01:51:42PM +, Acee Lindem (acee) wrote: > Hi Ben, > > On 10/25/18, 8:22 AM, "Benjamin Kaduk" wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ospf-lls-interface-id-08: 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-ospf-lls-interface-id/ > > > > -- > COMMENT: > -- > > Sending a new type of information to the peer usually involves a privacy > considerations analysis. I don't expect there to be anything worrisome > here, but some text in the document indicating that the analysis has been > done would be reassuring. > > Can you suggest some text? I was thinking: I'm not sure that I could -- I don't have confidence that I understand the system well enough to frame something in a complete and correct way. >Since the scope of the interface ID is limited to the advertising OSPF > router >uniquely identifying links, there are no privacy concerns associated with > its >advertisement. I wonder if there is a step missing to link these together -- that the links are generally fixed and immobile, or that the scope of distribution is limited to a set of trusted peers, perhaps? Sorry I can't be more helpful... -Benjamin ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Hi Joe, thanks for your review, please see inline (##PP): On 26/10/18 21:42 , Joe Clarke wrote: Reviewer: Joe Clarke Review result: Has Nits I have been assigned to review draft-ietf-ospf-ospfv3-segment-routing-extensions on behalf of the ops directorate. This document defines OSPFv3 extensions needed for segment routing (SR). And therein lies my first nit. While the document begins to set forth this overarching scope, a small paragraph in section 1 further limits it to MPLS dataplanes only. I think perhaps the abstract should be updated to clarify that. ##PP Done Other items I found are listed below. Overall, there are a lot of terminology used like RSVP, LDP, LSP, SID, etc. I think this document would benefit from a terminology section. ##PP added With respect to TLV types 8, 9, 14, and 15, they are defined in draft-ietf-ospf-segment-routing-extensions, and it took me a while to figure out where you were getting those values and why they weren't spelled out in the IANA considerations. You have a normative reference to this, which is good, but you only mention it with respect to the algorithm parameters. I think another mention is required. I'm going to be pedantic here. According to RFC7770, when a new OSPF Router Information LSA TLV is defined, the spec needs to explicitly state if it's applicable to OSPFv2, v3, or both. While you reference the TLVs from draft-ietf-ospf-segment-routing-extensions, I didn't see that either document _explicitly_ states that they are applicable to both. ##PP added the following to each of the values: Type: X as defined in [I-D.ietf-ospf-segment-routing-extensions] and aplicable to OSPFv3. === Section 2.1 s/length is other then 3 or 4/length is other than 3 or 4/ ##PP fixed === Section 3.2 s/If more then one SID/Label/If more than one SID/label/ ##PP fixed === Section 3.2 "When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]." It would be useful to include a section pointer here. I think your referring to Section 2.3 where the router ignores the range? Is it likely that will change to something other than "ignore?" If not, maybe it's just worth mentioning that here. ##PP I don't think it is good to specify the behavior which is described somewhere else. Regarding the section, the ietf-spring-segment-routing-mpls is still being worked on and the section may changes. We used the same text in OSPFv2 and ISIS SR drafts. I would like to be consistent here. === Section 3.3 s/If more then one SID/Label/If more than one SID/Label/ ##PP fixed. === Section 3.3 "The originating router MUST NOT advertise overlapping ranges." You specify what a router should do if it receives overlapping ranges above. I think the same text should be used here, too. ##PP Here we say that the originating router MUST NOT advertise overlapping ranges. We can not specify what it should do when it breaks the MUST. We specify what other routers should do when they receive overlapping ranges and we refer it to spring-segment-routing-mpls draft. Again this is the same as we used in OSPFv3 and ISIS SR extensions. I would like to keep the consistency here. === Section 5 "Other bits: Reserved. These MUST be zero when sent and are ignored when received." The normative language changes. In other places you say the bits SHOULD be 0. I suggest: ##PP Whenever we refer to "other bits" in the flag fields we use the same language. Other bits: Reserved. These SHOULD be set to 0 when sent and MUST be ignored when received. ##PP this refers to Reserved fields in the TLV (not the bits in a flag field) and again is used consistently across document. === Section 7.4.1 s/state lower then 2-Way/state lower than 2-Way/ ##PP fixed. thanks, Peter === . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
