Re: [Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

HI! I am not aware on any IPR that may apply to this draft. Thanks! Alvaro. On April 25, 2022 at 9:50:54 AM, Christian Hopps (cho...@chopps.org) wrote: Hi Folks, This begins a 2 week WG Adoption Call for the following draft: https://datatracker.ietf.org/doc/draft-

Re: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00

Hi! I’m not aware of any IPR related to this work. Thanks! Alvaro. On June 5, 2022 at 6:14:02 AM, Christian Hopps (cho...@chopps.org) wrote: Given the simplicity of this document and having received no objections or edits prior to or during the adoption call we'll

Re: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00

On July 7, 2022 at 6:04:30 PM, Adrian Farrel wrote: Adrian: Hi! ... > I checked the mailing list and couldn't find any discussion of this point so: > is there any reason why the term "black hole" is also not being addressed? It > seems to fall under the NIST guidance ("Avoid terms that use ‘bl

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: (with DISCUSS)

On September 24, 2022 at 5:23:05 PM, Les Ginsberg wrote: Les: Hi! > I have given your comments regarding clearer guidance on what value to use > for router id more thought and tried to address this in V5 of the document > (recently posted). > > I introduced a new sub-section "Choosing the TE Ro

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: (with DISCUSS)

On September 26, 2022 at 5:17:12 PM, Les Ginsberg wrote: Les: The text you proposed is...ok.  Just one minor comment: the router ID doesn't have to be "globally unique", just unique within the IS-IS domain.  I'll clear my DISCUSS. I'm disappointed that the resulting recommendation is driven by

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-flex-algo-24: (with DISCUSS)

On October 5, 2022 at 12:02:30 PM, Peter Psenak wrote: Peter: Hi! ... > > (1) When is a router's participation in a particular Flex-Algorithm > > advertised? ... > > Presumably, the operator configures support for a specific Flex-Algorithm > > with a FAD in mind. IOW, there should be no surpri

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

On October 6, 2022 at 5:46:59 AM, Ketan Talaulikar wrote: Ketan: Hi! ... > > (1) The main behavior in this document (using the reverse metric) is > > covered in the following sentences: > > > > §6: > > A router receiving a Hello packet from its neighbor that contains the > > Reverse Metric TLV

Re: [Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

On October 6, 2022 at 5:44:57 AM, Ketan Talaulikar wrote: Ketan: Hi! ... > KT> Added text in the security considerations that cover this issue as well > as a proposed mitigation. Please let us know if that works. This is the text that you added:    A router that is misbehaving or misconfigur

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-flex-algo-24: (with DISCUSS)

On October 6, 2022 at 6:58:18 AM, Peter Psenak wrote: Peter: ... > > (1) The text above instructs implementations of [RFC8667] and > > [RFC8665] to stop advertising the specific Flex-Algorithm value, but > > those RFCs (if I remember correctly) don't say anything about *not* > > advertising the

Re: [Lsr] Alvaro Retana's Yes on draft-ietf-lsr-ospf-l2bundles-07: (with COMMENT)

cover this. Also marking "updates" RFC9085 based on your suggestion. We have posted an update that reflects this changes and look for your feedback on the same: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-08 Thanks, Ketan On Thu, Oct 6, 2022 at 7:06 AM Alvaro

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

On October 6, 2022 at 7:44:51 AM, Ketan Talaulikar wrote: Ketan: > > > > (1) The main behavior in this document (using the reverse metric) is > > > > covered in the following sentences: > > > > > > > > §6: > > > > A router receiving a Hello packet from its neighbor that contains the > > > > Rev

Re: [Lsr] [Last-Call] Last Call: (Update to OSPF Terminology) to Proposed Standard

Hi Adrian! Yes, I think that makes sense. Thanks! Alvaro. On April 19, 2023 at 5:47:49 PM, Adrian Farrel (adr...@olddog.co.uk) wrote: Hi, Just a quick comment in last call for this draft. Would it be a good idea to also give some steer to future documents? Some

Re: [Lsr] Jim Guichard's Discuss on draft-ietf-lsr-ospf-terminology-06: (with DISCUSS and COMMENT)

Jim: Hi! Thanks for your comments and review! We submitted -07 to address your concerns. Please take a look. Alvaro. On May 8, 2023 at 4:15:04 PM, Jim Guichard via Datatracker (nore...@ietf.org) wrote: Jim Guichard has entered the following ballot position for draf

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-ospf-terminology-07: (with COMMENT)

  On May 24, 2023 at 10:07:22 AM, Éric Vyncke wrote: Hi Éric! ... > I find interesting that this update to be more inclusive has non-inclusive > abstract and introduction... There are more than 200 countries (if not > mistaken) and readers can genuinely wonder which one is referred by "National >

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

Amanda; Hi! Yes, I approve. Thanks! Alvaro. On July 1, 2020 at 5:11:01 PM, Amanda Baber via RT (iana-prot-pa...@iana.org) wrote: Alvaro: can you approve the request for early registration of the B-bit in the LLS Type 1 Extended Options and Flags registry at https://www.iana.org/assignments/o

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

I approve… :-) On July 1, 2020 at 7:20:40 PM, Amanda Baber via RT (iana-prot-pa...@iana.org) wrote: Hi Alvaro, Sorry, I asked you to approve the wrong registration! Can you approve "Local Interface IPv4 Address TLV" (suggested value 21) in the Link Local Signalling TLV Identifiers (LLS Types) r

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

Acee: Can you please get positive confirmation from the authors of draft-ietf-lsr-dynamic-flooding? Thanks! Alvaro. On July 2, 2020 at 5:50:06 AM, Acee Lindem (acee) ( acee=40cisco@dmarc.ietf.org) wrote: Right - the in-progress dynamic flooding implementations are IS-IS rather than OSPF. I

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

That was easy! :-) Thanks! Alvaro. On July 2, 2020 at 10:24:20 AM, Peter Psenak (ppse...@cisco.com) wrote: Hi Alvaro, On 02/07/2020 16:04, Alvaro Retana wrote: > Acee: > > Can you please get positive confirmation from the authors of > draft-ietf-lsr-dynamic-flooding? I'm

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

[Contributor hat on.] Hi! I am not aware of any undeclared IPR for this document. Alvaro. On August 18, 2020 at 10:24:53 AM, Acee Lindem (acee) (acee=40cisco@dmarc.ietf.org) wrote: Authors, The IETF IPRs declarations submitted for draft-chen-isis-t

[Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

Dear authors: Thank you for working on this document.  I have some comments (below) that I would like to see addressed before starting the IETF Last Call. Thanks! Alvaro. [Line numbers from idnits.] ... 70 1.  Introduction ... 77   The identification of the originating router for a

[Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

Dear authors: Please find below my review of this document.  I appreciate you and the WG discussing the details, but there is more work needed to be done before starting the IETF LC (details inline). Just one high-level comment: It is not clear to me why all the behaviors from rfc8986 are not cov

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

On March 3, 2021 at 2:47:38 PM, Les Ginsberg wrote: > > From: Lsr On Behalf Of Dhruv Dhody Les: Hi! ... > > (1) Is it wise to use normative keywords MUST and SHOULD in the > > appendix? The text is from section 3.1 but can it be reworded in the > > appendix? Also wondering if other changes (IANA

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Les: The text is not the same: §3.1 reads: "The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV [RFC5305].” I’m sure you’ll do the right thing. Thanks! Alvaro. On March 3, 2021 at 3:54:42 PM, Les Ginsberg (ginsberg) (ginsb...@cisco.com) wrote: >

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

On March 3, 2021 at 6:29:28 PM, Les Ginsberg wrote: Les: Hi! ... > Now, can you respond to my comment regarding the lack of clarity in using > quotes? Sure. I guess you mean this comment: "But I have to say that for me as a reader the use of quotes as you suggest does not aid clarity." Dhr

Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

On March 8, 2021 at 12:35:52 PM, Ketan Talaulikar (ketant) wrote: Ketan: Hi! I have a couple of comments below, which I think can be handled with other last-call comments.  I'm starting the IETF LC. Thanks!! Alvaro. ... > 127 2. Protocol Extensions > > 129 This document defines the Prefix

Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

 Ketan: Hi! I’m ok with your responses — I think we’re good to go. Thanks! Alvaro. On March 9, 2021 at 12:42:21 PM, Ketan Talaulikar wrote: > I will wait for your responses on a few of the points before > posting the draft update. ___ Lsr mailing

Re: [Lsr] When is an IANA Registry Required

On February 27, 2021 at 12:57:12 PM, Les Ginsberg wrote: Les: Hi! Sorry for the delay... §4/rfc8126 presents some general arguments for creating registries. But let's talk about this specific case. I'm taking the liberty of summarizing your message this way: > Historically, we have created

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

On March 11, 2021 at 5:46:51 AM, Peter Psenak wrote: Peter: Hi! > thanks for the review, please see inline (##PP): It looks like you didn't get the whole review (Outlook bug).  Take a look at it here: https://mailarchive.ietf.org/arch/msg/lsr/a4a4I4fP73DyfKsdKnRw_tRuStQ/ ... > > Just one hi

Re: [Lsr] When is an IANA Registry Required

On March 16, 2021 at 6:24:22 PM, Les Ginsberg wrote: Les: Hi! > But one thing I find missing in your response is some info on what problem > YOU think needs to be addressed? I simply think that the specifications are not complete without guidance on how to use/assign the unused bits.  I rath

Re: [Lsr] When is an IANA Registry Required

On March 17, 2021 at 12:25:25 PM, Les Ginsberg wrote: > > In the extreme case anyone can make use of the bits, through the ISE > > or a different SDO -- ideally we will be paying attention, but may > > not. Sure, a registry doesn't stop implementations from squatting on > > codepoints either (even

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

On March 25, 2021 at 6:03:53 AM, Peter Psenak wrote: Peter: Hi! I have some comments (see below) -- nothing major.  I look forward to -12. Thanks! Alvaro. ... > >>> Just one high-level comment: It is not clear to me why all the > >>> behaviors from rfc8986 are not covered in this document

Re: [Lsr] When is an IANA Registry Required

Dear lsr-chairs: It looks like the conversation about this topic has died down. Can you please close the discussion and tell us if the WG reached a consensus and what that is? As you know, this topic started because of my comments related to draft-ietf-lsr-isis-srv6-extensions. The authors have p

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

Peter: Hi! I looked at -12. I have a couple of nits/minor comments below.  There's only one significant one related to the information that must be shared between the Prefix Reachability TLV and the SRv6 Locator TLV: it is currently phrased as an example. We're also waiting of the resolution of

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

Peter: I’m ok with the text below. Thanks! Alvaro. On April 9, 2021 at 4:12:43 AM, Peter Psenak (ppse...@cisco.com (mailto:ppse...@cisco.com)) wrote: > > 268 In cases where a locator advertisement is received in both a Prefix > > 269 Reachability TLV and an SRv6 Locator TLV - (e.g. prefix, pr

Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

On April 22, 2021 at 7:26:57 AM, Peter Psenak wrote: > I have posted an updated version of the draft that has the new > registries defined for all flags fields defined in it. Thanks Peter! I've started the IETF LC. Alvaro. ___ Lsr mailing list Lsr@ie

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote: > Technically I agree with you and if everybody agrees, I'm fine to > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV. So...what does everyone else think? We need to close on this point before the IESG evaluates the docu

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

Peter: Hi! As Xuesong suggested earlier, could you/we live with “SHOULD send”? The mitigating circumstance (recommend vs require) is precisely the lack of support.  I think your original reply to Gunter about how it could be hard to mandate the Flags TLV at this point is spot on. Thanks! Alvar

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

On May 13, 2021 at 11:44:44 AM, John Scudder wrote: John: Hi! Thanks for the review! Just replying to one of your comments: ... >    This documents updates RFC 7370 by modifying an existing registry. > > Also, this doesn’t seem to me like an update to RFC 7370. It’s normal for an > RFC to up

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[RFC5305][RFC7370] > > Again, RFC7370 is not marked as updating RFC 5305. > > I think it is sufficient to request that IANA add the new RFC to the > list of References for the modified registry. > > Les > > *From:* Lsr *On Behalf Of *John Scudder > *Sent:* Thursday, May 13

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

Les: Hi! In this case the name is being changed, a new column is added, and all the existing code points are updated in light of the new column. I realize this may not be enough for you.  Instead of all of us discussing this specific case, we should focus our energy on clearly defining what “Upd

Re: [Lsr] Francesca Palombini's Discuss on draft-ietf-lsr-isis-srv6-extensions-17: (with DISCUSS)

On October 19, 2021 at 9:54:20 AM, Francesca Palombini wrote: Francesca: Hi!  Thanks for the review! ... > > 7. - > > > > Section 11.1.1 > > > > FP: It sounds like a bad idea in general to have to rename the registry > > every time a TLV needs to be added to the registry... Maybe the wg and

Re: [Lsr] Issues with master/slave terminology in OSPF

On November 16, 2021 at 4:10:16 PM, Acee Lindem wrote: Hi! > The IETF is already applying these standards to new documents. The better reference to what the IETF is doing is this one: https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/ > At some point, I'd expect that some

Re: [Lsr] Issues with master/slave terminology in OSPF

On November 16, 2021 at 5:00:16 PM, Acee Lindem wrote: [A little detour from Mike's topic.] > ...but I didn't see it in the Knodel draft. Hopefully, this terminology is > acceptable. The terminology list (which is where the Knodel draft was being discussed) "expressed strong support for the sen

[Lsr] Update to OSPF Terminology (draft-fox-lsr-ospf-terminology)

Hi! Mike, Acee, and I just uploaded a (very) short draft to update the master/slave terminology from rfc2328/rfc5340.    https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/    As you all know, implementations use these terms as part of their CLI and debug output.  The intent is

Re: [Lsr] Update to OSPF Terminology (draft-fox-lsr-ospf-terminology)

On February 23, 2022 at 8:35:03 PM, Christian Hopps wrote: Chris: Hi! > I support these changes, and thanks for taking this up. :-) > I guess it makes sense to not go full-in and re-spin the base docs if there > literally are no other changes (although one wonders if it will actually > chan

[Lsr] OSPF Monitor Node (draft-retana-lsr-ospf-monitor-node)

Hi! Lin and I just published a draft that specifies mechanisms for an active OSPF monitor: one that can be authenticated into the network but does not affect the topology.  This mechanism contrasts to a passive monitor: listen-only node on a multiaccess link. The primary prompt for this work

[Lsr] Implementations of draft-ietf-ospf-link-overload

Dear lsr WG: draft-ietf-ospf-link-overload [1] defines a new BGP-LS Graceful-Link-Shutdown TLV. When an early allocation was requested, it was mistakenly requested from the "BGP-LS NLRI-Types" registry [2], not from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TL

Re: [Lsr] Rtgdir last call review of draft-ietf-ospf-xaf-te-02

[Speaking as an author.] Hi Ben! Thanks for the review. We will address these nits in a future revision of the draft. Alvaro. From: Ben Niven-Jenkins To: rtg-dirmailto:rtg-...@ietf.org>> Cc: lsrmailto:lsr@ietf.org>>;draft-ietf-ospf-xaf-te.allmailto:draft-ietf-ospf-xaf-te@ietf.org>>;rtg-ads

Re: [Lsr] Early Allocation Request for "IGP Flexible Algorithm"

Hi! This request is fine with me. Acee: yes, according to rfc7120, the AD has to approve early allocation requests for “IETF Review” registries. Alvaro. On May 17, 2018 at 4:15:48 PM, Acee Lindem (acee) (a...@cisco.com) wrote: The authors of the subject document have requested early assignme

[Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

Dear authors: I just finished reading this document. I have several comments and concerns that I included inline below. One item that I want to highlight here is the lack of specific procedures defined to handle the cases of multiple advertisements (in both §2 and §3). Please take a look at my

[Lsr] AD Review of draft-ietf-ospf-segment-routing-msd-15

Dear authors: I just finished reading this document. I have several comments and concerns that I included inline below. While I do have some significant concerns (see below), I don't think there are specific items that prevent the start of the IETF LC (they should not be hard to address), so I'm

Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

after that. Thanks! Alvaro. From: Alvaro Retana Sent: Wednesday, August 15, 2018 1:53 PM 191 If there exist multiple Node MSD advertisements for the same MSD-Type 192 originated by the same router, the procedures defined in [RFC7981] 193 apply. [major] Does this

Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

. I just have one outstanding comment (below). I think that this comment, along with the ones in my other message on this thread can be addressed while we move the document forward. I will start the IETF Last Call. Thanks!! Alvaro. From: Alvaro Retana Sent: Wednesday, August 15, 2018 1:53 PM

[Lsr] Late IPR Disclosures for draft-ietf-isis-segment-routing-msd and draft-ietf-ospf-segment-routing-msd

Dear lsr WG: As you may have noticed, IPR disclosures were filed on August 13 for these two documents — very late in the process, given that both documents had already been sent to the IESG for publication. Regardless of the timing, the statements don’t represent additional disclosures. Instead,

Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

Thanks! On August 29, 2018 at 7:49:53 PM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: Alvaro – I have posted V15 addressing your comments. Responses inline. *From:* Alvaro Retana *Sent:* Wednesday, August 29, 2018 9:54 AM *To:* Les Ginsberg (ginsberg) ; draft-ietf-isis-segment

[Lsr] AD Review of draft-ietf-isis-reverse-metric-11

Dear authors: I just finished reading this document. Thanks for the work on it! I have several concerns (please see detailed comments below), and think the draft still needs work. Among other things, my main concerns include: - the lack of an explicit definition of the reverse metric; examples

Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

Alvaro Retana Sent: Friday, August 31, 2018 12:27 PM To: draft-ietf-isis-reverse-met...@ietf.org Cc: lsr-cha...@ietf.org; Christian Hopps ; lsr@ietf.org Subject: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11 Note that I read -11, but -12 was published in the interim -- so I'm pu

[Lsr] AD Review of draft-ietf-ospf-lls-interface-id-05

Dear authors: I just finished reading this document. I have put some comments inline (below). The main issue that I have with this document is that it is not clear where the Interface ID comes from. I think it is important to clearly specify that to achieve consistent and interoperable implemen

Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

On September 24, 2018 at 9:35:06 PM, Naiming Shen (naiming) ( naim...@cisco.com) wrote: Naiming: Hi! Thank you for your detailed review on this draft, I’ll try to reply to the comments inline below, and the proposed document diff is attached at the end. Let me know if you would like to have othe

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

On September 26, 2018 at 5:46:18 PM, Benjamin Kaduk (ka...@mit.edu) wrote: Benjamin: Hi! I don’t see your updated ballot in my archive…hmmm..?? But I wanted to reply to the additional point. You wrote: === I'm not sure I followed correctly some discussion around the rtgdir review, specificall

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

On September 27, 2018 at 6:26:57 AM, Julien Meuric (julien.meu...@orange.com) wrote: Hi! It looks like the outstanding item is this one about the terminology used in §5. tl;dr: I think that the terminology can be slightly improved to be in line with other documents. See suggestion at the bottom

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

On September 27, 2018 at 2:44:34 PM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: Les: Sometimes less is more. ;-) My personal opinion is that, given the precedent from rfc4221, the additional considerations are implied. I’ll approve the publication either way once you and Julien agree.

Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

On September 27, 2018 at 6:36:29 PM, Naiming Shen (naiming) ( naim...@cisco.com) wrote: Naiming: Hi! Some answers below. Please take a look and publish an update. Thanks! Alvaro. Note that I read -11, but -12 was published in the interim -- so I'm putting this comment up here. The onl

Re: [Lsr] I-D Action: draft-ietf-isis-reverse-metric-13.txt

Thanks Naiming! I just requested the start of the IETF Last Call. Alvaro. On October 2, 2018 at 9:28:11 PM, Naiming Shen (naiming) (naim...@cisco.com) wrote: Thanks to Alvaro’s review, and Acee and Uma comments. The update version is uploaded. Please review.

Re: [Lsr] IPR Call for draft-ietf-ospf-xaf-te - "OSPF Routing with Cross-Address Family Traffic Engineering Tunnes"

I am not aware of any IPR related to this document. Alvaro. On October 30, 2018 at 1:26:55 PM, Acee Lindem (acee) (a...@cisco.com) wrote: In preparation for requesting publication, I’m making a second IPR call on the subject document. Are you aware of any IPR that appli

Re: [Lsr] draft-ietf-ospf-ospfv3-segment-routing-extensions - small change

Peter: Hi! -18 still has one reference to the IA-flag in §8.1. Please remove it. Thanks! Alvaro. On November 16, 2018 at 1:20:18 AM, Mahendra Singh Negi ( mahendrasi...@huawei.com) wrote: Hi Acee/Peter, This change doesn't impact our implementation. Thanks, Mahendra -Original Message-

Re: [Lsr] Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Took the ops-dir and the ietf@ietf lists off.] Hi! Joe makes a really good point below about the TLV types and RFC7770. It looks like we all missed it! :-( To quote Peter (from a message in this thread), "I don't think it is good to specify the behavior which is described somewhere else.” Loo

[Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06

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

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

etf-lsr-isis-rfc7810bis-02 On November 28, 2018 at 4:33:54 PM, John Scudder (j...@juniper.net) wrote: +lsr to the cc Hi Alvaro, On Nov 28, 2018, at 4:01 PM, Alvaro Retana wrote: [major] AFAICT, Available Bandwidth is the only definition that is different between rfc7810/draft-ietf-lsr-isis-rf

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

wrong and needs to be changed. - If 7810bis is correct, and John is wrong, then there needs to be an erratum against RFC 7471. I think that covers the universe of possibilities. I still don't know which is right, though. No additional charge, --John On Nov 28, 2018, at 5:15 PM, Alvaro R

[Lsr] AD Review of draft-ietf-lsr-isis-rfc7810bis-02

Dear authors: Thanks for taking on this work!! I have just a couple of comments. (1) There are too many authors in the front page. I know that the list was cut prior to rfc7810 being processed, and that Les was added to hold the pen on this revision, so I'll let this one proceed. Just one thin

Re: [Lsr] Available Bandwidth erratum 5486 [was: Re: AD Review of draft-ietf-idr-te-pm-bgp-14]

On November 28, 2018 at 5:46:08 PM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: Les: Hi! As lead author on rfc7810bis I am happy to modify the language to be consistent with RFC7471. That seems like the far easier pathway so long as we have your assurance (which it seems we do) that thi

Re: [Lsr] AD Review of draft-ietf-lsr-isis-rfc7810bis-02

On November 29, 2018 at 2:36:30 PM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: Les: (1) There are too many authors in the front page. I know that the list was cut prior to rfc7810 being processed, and that Les was added to hold the pen on this revision, so I'll let this one proceed. J

Re: [Lsr] IPR Disclosure Eric Kenneth Rescorla's Statement about IPR related to draft-ietf-isis-reverse-metric and draft-shen-isis-spine-leaf-ext belonging to Chemtron Research LLC

Dear lsr WG: The filing of this IRP disclosure against draft-ietf-isis-reverse-metric is the result of the IESG Evaluation of the document, where one of the reviewers decided he needed to make a third-party IPR disclosure (see details below). A third-party disclosure is one where the IPR "is not

Re: [Lsr] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

On December 5, 2018 at 7:52:00 PM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: Les: You are right in pointing out that the changes made to rfc7810 are the ones mentioned in the appendix. That was the motivation that originated this work. However, this document doesn’t just modify rfc78

Re: [Lsr] IPR Disclosure Eric Kenneth Rescorla's Statement about IPR related to draft-ietf-isis-reverse-metric and draft-shen-isis-spine-leaf-ext belonging to Chemtron Research LLC

On December 19, 2018 at 3:56:37 AM, Christian Hopps (cho...@chopps.org) wrote: The IPR disclosure referenced 2 drafts, reverse metric and spine leaf and a patent. Is there any more specific information on how this patent might have relevance to these drafts in particular? Nope…just what is in th

Re: [Lsr] Warren Kumari's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)

On December 19, 2018 at 6:09:55 PM, Warren Kumari (war...@kumari.net) wrote: Warren: Hi! 1: From the shepherd writeup: (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

Re: [Lsr] Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)

On December 20, 2018 at 5:38:51 AM, Acee Lindem (acee) (a...@cisco.com) wrote: We only know of one implementation that has the wrong encoding and we have fixed that one. I then see no harm in removing the “generosity” paragraph. As Suresh suggests, it will make the document even clearer. Thanks

Re: [Lsr] Eric Rescorla's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)

On December 20, 2018 at 9:03:18 AM, Eric Rescorla (e...@rtfm.com) wrote: Hi! Looking at S 14, I see the following "The following people contributed substantially to the content of this document and should be considered co-authors". Is this just an artifact of the 5 author limit? Perhaps we should

Re: [Lsr] Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)

On December 20, 2018 at 10:43:06 AM, Les Ginsberg (ginsberg) ( ginsb...@cisco.com) wrote: I think the document is better off as is – but if you folks insist I will remove the text – though clearly I disagree with this choice. Please do. Thanks! Alvaro. __

Re: [Lsr] [Technical Errata Reported] RFC2328 (5611)

[Took the RFC Editor off..and removed Abhay’s e-mail as it is out of date. I’m pretty sure John’s e-mail is also not accurate anymore, I moved that to bcc…. In short, everyone interested should be in the lsr list. :-)] Hi! I am marking this report as Rejected…both because of Acee’s explanation, b

Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06

eview. 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

[Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22

Dear authors: I just finished reviewing this document. Please take a look at the in-line comments below. In general, I think that some more work is needed. I will wait for that before starting the IETF Last Call. There is a significant issue that I want to highlight here (there are also relate

Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22

On March 20, 2019 at 7:37:42 PM, Les Ginsberg (ginsberg) (ginsb...@cisco.com) wrote: Les: Hi! In regards to the relationship with RFC 7794, there is a history here. Thanks for the history lesson! :-) To avoid more confusion (specially from other reviewers), I think that it would be a good idea

Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22

On March 29, 2019 at 1:55:17 AM, Les Ginsberg (ginsberg) (ginsb...@cisco.com) wrote: Les: Hi! Thanks for the update. I have a couple of comments on your replies — no showstoppers. However, it looks like my original comments were truncated; I added the remaining comments at the end. I am start

[Lsr] Fwd: Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensi

, Alvaro Retana via Datatracker ( nore...@ietf.org) wrote: -- DISCUSS: -- (1) This first point is a cross-document DISCUSS. In short, the assumptions in this document

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensio

On April 10, 2019 at 5:46:56 PM, Vigoureux, Martin (Nokia - FR/Paris-Saclay) (martin.vigour...@nokia.com) wrote: Martin: Hi! It looks to me that you don’t disagree with what is written in the draft but rather with the fact that the draft may suggest that IGPs should do things which are in fact n

[Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

Dear authors: Thank you for the work on this document!! I just (finally!) finished reading this model. I have several comments in-line below, including some that I consider major -- I would like those to be addressed before moving the document forward. Thanks! Alvaro. [Line numbers come from

[Lsr] AD Review for draft-ietf-ospf-yang-21

Dear authors: I just finished reading this document. I have some comments in-line, including a couple that I consider major -- I'll wait for whose to be addressed before moving forward. The datatracker reports 4 errors in the model, mostly related to ietf-bfd-types. Please take a look. Thanks!

Re: [Lsr] AD Review for draft-ietf-ospf-yang-21

On June 22, 2019 at 7:03:58 PM, Acee Lindem (acee) (a...@cisco.com) wrote: Acee: Hi! Thanks for the review - we will address your comments in the -22 version. See inline. I have a couple of replies. Please take a look at the bottom because it looks like you didn’t get (or missed) part of the r

Re: [Lsr] AD Review for draft-ietf-ospf-yang-21

On June 26, 2019 at 11:53:28 AM, Acee Lindem (acee) (a...@cisco.com) wrote: Acee: Hi! This may take a couple iterations. See inline. I only have one response. :-) 3936 leaf dead-timer { 3937 type uint32; 3938 units "seconds"; 3939 config false; 39

Re: [Lsr] AD Review for draft-ietf-ospf-yang-21

On June 26, 2019 at 9:31:05 PM, Acee Lindem (acee) (a...@cisco.com) wrote: 3936 leaf dead-timer { 3937 type uint32; 3938 units "seconds"; 3939 config false; 3940 description "This timer tracks the remaining time before 3941

Re: [Lsr] AD Review for draft-ietf-ospf-yang-21

On July 1, 2019 at 6:58:43 PM, Acee Lindem (acee) (a...@cisco.com) wrote: I believe version -23 addresses your comments. It does! I’m starting the IETF LC. Thanks! Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Early Allocation Request for "Dynamic Flooding on Dense Graphs" - draft-ietf-lsr-dynamic-flooding-03

Hi! This request is fine with me. As we discussed at the meeting, I agree that the conditions in rfc7120 have been met. Alvaro. On July 22, 2019 at 5:04:52 PM, Acee Lindem (acee) (a...@cisco.com) wrote: > The authors of the subject draft have requested early IANA allocation of > the IANA code

Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

On June 27, 2019 at 8:36:46 AM, stephane.litkow...@orange.com ( stephane.litkow...@orange.com) wrote: Stephane: Hi! Sorry it took me while to get to your reply. Thanks for your comments. We are working on updating the document accordingly. Please find some replies inline that may require more

Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-xaf-te-06: (with COMMENT)

On July 30, 2019 at 11:44:20 AM, Mirja Kühlewind via Datatracker (nore...@ietf.org) wrote: [Speaking as an author.] Mirja: Hi! -- COMMENT: -

[Lsr] AD Review of draft-ietf-lsr-isis-rfc5306bis-02

Dear authors: I just finished reading this document. Thank you for your work on it. Why was it decided to create a bis document and not just an Update to rfc5306? Either way works for me, I'm just curious. Knowing that the change in this document, with respect to rfc5306, is new functionality,

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-ospf-xaf-te-06: (with COMMENT)

On August 5, 2019 at 8:52:19 AM, Acee Lindem (acee) (a...@cisco.com) wrote: With https://datatracker.ietf.org/doc/rfc5838/, separate instances are required for IPv4 and IPv6 topologies. With this enhancement, you'd only need to advertise TE information in one of those instances. Right. I think t

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-ospf-xaf-te-06: (with DISCUSS)

On August 8, 2019 at 12:26:07 AM, Roman Danyliw via Datatracker (nore...@ietf.org) wrote: [Document author.] Roman: Sure…we’ll add something like that in the next revision. Thanks! Alvaro. -- DISCUSS

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-xaf-te-06: (with COMMENT)

On August 8, 2019 at 1:52:59 AM, Benjamin Kaduk via Datatracker (nore...@ietf.org) wrote: [Document author.] -- COMMENT: -- Section 4

  1   2   >