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] 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] [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] 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] 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-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] 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-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

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

Alvaro Retana has entered the following ballot position for draft-ietf-lsr-ospf-l2bundles-07: Yes 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

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

Alvaro Retana has entered the following ballot position for draft-ietf-lsr-ospf-reverse-metric-08: 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

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

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

Alvaro Retana has entered the following ballot position for draft-ietf-lsr-flex-algo-24: 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

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

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

Alvaro Retana has entered the following ballot position for draft-ietf-lsr-isis-rfc5316bis-04: 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

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] 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 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-

[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

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] 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

[Lsr] Alvaro Retana's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)

Alvaro Retana has entered the following ballot position for draft-ietf-lsr-yang-isis-reverse-metric-04: 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

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

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] 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] 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] 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)

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] 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] 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] 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] 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

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] 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

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

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] 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] 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 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-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] 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] [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] [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 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

[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

[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

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

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] [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

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

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] AD Review of draft-ietf-lsr-isis-invalid-tlv-01

On June 19, 2020 at 11:49:51 AM, Les Ginsberg wrote: Les: Hi! Just a couple of in-line answers. We should be ready to move forward once you submit the update. Thanks!! Alvaro. ... > > I'm writing all this here to have a record of this decision and to > > give anyone in the WG the opportuni

[Lsr] AD Review of draft-ietf-lsr-isis-invalid-tlv-01

Dear authors: First of all, thank you for taking on this work! I have some comments which I home will be easy to address -- please see in-line below.  I will wait for a revised ID before starting the IETF Last Call. Before getting into the specifics, idnits came up with this warning: =    

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)

Rob: Hi! I just replied to your review of the OSPF document…making the same suggestion. :-) Thanks! Alvaro. On June 10, 2020 at 11:37:36 AM, Robert Wilton via Datatracker ( nore...@ietf.org) wrote: Robert Wilton has entered the following ballot position for draft-ietf-isis-te-app-14: No Obje

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS)

On June 10, 2020 at 10:32:09 AM, Robert Wilton wrote: Rob: Hi! Thanks for the review. I’m replying for the authors as I think that your questions/suggestions should be easy to address.  Please see below. Thanks! Alvaro. > --

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

sponse to the previous Email on your suggested text. > > On 5/26/20, 4:26 AM, "Peter Psenak" wrote: > > Hi Alvaro, > > please see inline (##PP) > > On 22/05/2020 16:59, Alvaro Retana wrote: > > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: > >

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: Peter: Hi! > With respect to Alvaro's clarification, your answer for (1) makes sense; > thanks! I think Alvaro has offered to help work out what (if any) > additional text we might want to be sure that the answer to (2) is clear in > the doc

Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

On May 21, 2020 at 6:05:41 AM, Peter Psenak wrote: Peter: Hi! > > -- > > DISCUSS: > > -- > > > > As for other reviewers, many of my comments duplicate those f

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

On May 20, 2020 at 4:38:54 AM, Peter Psenak (ppse...@cisco.com) wrote: > Two editorial nits: > ** Section 3. Editorial. s/ When a router propagates a prefix between ISIS > levels ([RFC5302],/When a router propagates a prefix between ISIS levels > [RFC5302],/ I must be missing something, but wha

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi! Yes, we cannot specify something that routers unaware of this specification should or shouldn’t do. I believe that Elwyn’s point is this: *if a router supports this specification* then when would it not advertise the ELC? IOW, the specification only obviously applies to implementations that

[Lsr] Considerations for Extended TE Metrics (draft-ietf-isis-te-app)

Dear authors: When reviewing the updates to draft-ietf-ospf-te-link-attr-reuse-11, I noticed the following difference with respect to draft-ietf-isis-te-app-12: [] draft-ietf-isis-te-app-12: 437 4.2.3.  Considerations for Extended TE Metrics 439   [RFC8570] defines a number of dynami

Re: [Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10

On May 5, 2020 at 6:08:27 AM, Peter Psenak wrote: Peter: Hi! ... > I tried to address all of them, some have been resolved during ISIS > draft review, in which case I took the same resolution for this draf. > > Please see inline, look for ##PP There's only one outstanding comment that I don'

[Lsr] OSPFv3 Implementations of draft-ietf-ospf-mpls-elc

Dear lsr WG: If you’ve been following the progress of this document, you will have noticed that it is already in IESG Evaluation. IANA discovered a typo in the draft; the current text says "Bit 0x04 in the "OSPFv3 Prefix Options (8 bits) registry has been assigned to the E-Flag (ELC Flag)”. How

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

On May 6, 2020 at 1:12:42 AM, Barry Leiba wrote: Barry: Hi! > — Section 4 — > > The ERLD is advertised in a Node MSD sub-TLV [RFC8476] using the > ERLD-MSD type defined in [I-D.ietf-isis-mpls-elc]. > > Just checking: is the IS-IS draft the right reference here in this OSPF > document? Yes, it

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

Murray: Hi! Yes, I have. In this case, this document was the result of merging several other documents so it was decided to allow 6 authors (the rest became contributors). The same is true for the OSPF version. Thanks! Alvaro. On May 6, 2020 at 1:44:50 AM, Murray Kucherawy via Datatracker ( n

Re: [Lsr] AD Review of draft-ietf-ospf-mpls-elc-12

Thanks Peter! This document looks good to me. I’m a starting the IETF LC, along with the ISIS document. Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Peter: I just looked at this document once more time and found an error in §5: s/The ERLD-MSD...[I-D.ietf-idr-bgp-ls-segment-routing-ext]./The ERLD-MSD...[I-D.ietf-idr-bgp-ls-segment-routing-msd]. I am going to start the IETF LC, along with the OSPF document. No need to address this correctio

Re: [Lsr] On collaboration for abstraction

On April 2, 2020 at 6:08:12 PM, tony...@tony.li wrote: [Speaking as an individual.  Explicitly adding Martin.] Tony: Hi! > I’d like to comment on the process for moving forward for the abstraction  > proposals that we are discussing (TTZ, Area proxy, flooding reduction, …). >  > My understand

Re: [Lsr] AD Review of draft-ietf-isis-te-app-09

Les: Hi! Just to close this loop: I looked at -12 and we’re good. :-) I’ll now wait for draft-ietf-ospf-te-link-attr-reuse to catch up to process both documents together. Thanks!! Alvaro. On March 21, 2020 at 1:09:56 PM, Les Ginsberg (ginsberg) (ginsb...@cisco.com) wrote: Following some offl

Re: [Lsr] Agenda Posted Re: Link State Routing (lsr) WG Virtual Meeting: 2020-04-02

On March 24, 2020 at 1:42:29 PM, Yingzhen Qu wrote: [Speaking as a WG participant.] > Now we have two interim sessions scheduled, please find updated agenda here: > https://datatracker.ietf.org/meeting/interim-2020-lsr-01/materials/agenda-interim-2020-lsr-01-lsr-01.html >   > > If there

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

On March 24, 2020 at 6:44:50 AM, Peter Psenak wrote: > I posted a new version - draft-ietf-isis-mpls-elc-11. It should have all > your inputs incorporated. > > Please let me know if you are ok with it. Once it's approved from your > side, I will update the OSPF draft. Yes, it looks good to me.  

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Ok…let’s move forward. No need to add more text. Alvaro. On March 23, 2020 at 10:36:42 AM, Acee Lindem (acee) (a...@cisco.com) wrote: Hi Alvaro, On 3/23/20, 5:17 AM, "Peter Psenak" wrote: Hi Alavaro, On 20/03/2020 19:23, Alvaro Retana wrote: > On March 20, 2020 at 10:34

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

On March 20, 2020 at 10:34:59 AM, Peter Psenak wrote: Peter: > >>> I don't really see why one would affect the other. > >> > >> I agree. BMI-MSD is an egress capability and ERLD-MSD is an ingress > >> capability. While they may be related in the internal ASIC implementation, > >> they are indep

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

 On March 20, 2020 at 10:27:55 AM, Acee Lindem wrote: … > > I don't really see why one would affect the other. > > I agree. BMI-MSD is an egress capability and ERLD-MSD is an ingress > capability. While they may be related in the internal ASIC implementation, > they are independent from a capabili

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

On March 20, 2020 at 6:22:38 AM, Peter Psenak wrote: ... > > Besides the in-line comments, I want to point out here that this > > specification is incomplete. It needs to have (1) a formal description of > > the new MSD-Type (similar to §5/rfc8491), and (2) a discussion of the > > interaction wit

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

On March 20, 2020 at 6:04:41 AM, Peter Psenak wrote: > please see inline (##PP2): We're good to go. The only comment from the original review that you didn't reply to is this:    Besides the in-line comments, I want to point out here that this    specification is incomplete.  It needs to have

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

On March 16, 2020 at 7:52:18 AM, Peter Psenak wrote: Peter: Hi! > Let's first close the ISIS ELC draft before starting to work on OSPF > one, as many comments are common and will be applicable to both ISIS and > OSPF variants. Sure, that makes sense. > Please see inline (##PP): I replied to

Re: [Lsr] AD Review of draft-ietf-isis-te-app-09

On February 27, 2020 at 11:00:19 PM, Les Ginsberg wrote: Les: Hi!  How are you? Some of the responses, yours and mine, feel like we're not communicating well, like we are talking past each other.  I am probably not clearly asking the right questions...  I think it would be a good idea to talk

[Lsr] AD Review of draft-ietf-ospf-mpls-elc-12

Dear authors: This is my review of draft-ietf-ospf-mpls-elc-12.  I reviewed this document alongside draft-ietf-isis-mpls-elc-10, so many comments are the same/similar.  Thank you for the work in both of them! I will progress both documents together, so I will wait for both of them to address my c

[Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Dear authors: This is my review of draft-ietf-isis-mpls-elc-10.  I reviewed this document alongside draft-ietf-ospf-mpls-elc-12, so many comments are the same/similar.  Thank you for the work in both of them! Besides the in-line comments, I want to point out here that this specification is incomp

Re: [Lsr] AD Review of draft-ietf-isis-te-app-09

On February 7, 2020 at 1:50:58 AM, Les Ginsberg wrote: Les: Hi! > We have published V10 of the draft addressing your comments. It looks like your copy of my review was truncated (not sure why). The archive has the complete version, and I pasted the remaining comments at the end of this message.

Re: [Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

FYI… Because I am one of the co-authors of draft-chen-isis-ttz, I am recusing myself from this discussion. Martin will be the responsible AD for it, should one be needed. Alvaro. On January 27, 2020 at 1:27:13 PM, Acee Lindem (acee) (a...@cisco.com) wrote: Speaking as WG Co-chair: At IETF 1

Re: [Lsr] AD Review of draft-ietf-isis-te-app-09

On January 15, 2020 at 3:48:31 PM, Les Ginsberg wrote: Les: Hi! ... > 5. Deployment Considerations > 6. Attribute Advertisements and Enablement > 7. Interoperability, Backwards Compatibility and Migration > Concerns > > Of these I think 5 and 7 could logically be combined and fall under the > he

Re: [Lsr] AD Review of draft-ietf-isis-te-app-09

On January 10, 2020 at 10:53:40 AM, Les Ginsberg wrote: Les: Hi! > We are working on addressing your comments - but it will take us a bit of > time to complete that - please be patient. You have all been very patient with me already -- I can only return the favor. :-) > One question. In sever

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

On January 9, 2020 at 7:53:17 PM, Marcelo Bustani wrote: Marcelo: Olá! > My intention was to mitigate a possible misunderstanding or a multiple > different interpretations, that I guess it is happening with Cisco and > Juniper; both are not wrong depending from the section they are based on.

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

On January 9, 2020 at 3:51:51 PM, Marcelo Bustani wrote: [Trimming the distribution.] Marcelo: Hi! > I believe this is interesting to make this consistent, because I`m facing > different usage for this situation. For example, Cisco uses cost 1 for this > type of interface and Juniper cost 0. >

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

On January 9, 2020 at 11:13:26 AM, Acee Lindem wrote: [Trimming the distribution list.] Hi! I agree with Acee, but for different reasons. > I don't agree this change is required. The non-normative appendix C text > clearly states that this is the "cost of sending a packet on the interface". > T

[Lsr] AD Review of draft-ietf-isis-te-app-09

Dear Authors: Happy New Year! I have finished reading this document, reviewing the e-mail archive and all the various reviews and comments.  Quoting one of the authors, "it is essential that the two IGPs provide equivalent functionality" [1] -- so I have considered draft-ietf-ospf-te-link-attr-re

[Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10

 Dear Authors: Happy New Year! I have finished reading this document, reviewing the e-mail archive and all the various reviews and comments.  Quoting one of the authors, "it is essential that the two IGPs provide equivalent functionality" [1] -- so I have considered draft-ietf-isis-te-app-09 in p

Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)

On December 2, 2019 at 10:40:05 AM, Mirja Kühlewind wrote: Mirja: Hi! ... > 1) This sentence in section 3: > "An OSPFv2 router advertising a router-LSA with the H-bit > set indicates that it MUST NOT be used as a transit router (see > Section 4) by other OSPFv2 routers in the area supporting the

Re: [Lsr] Éric Vyncke's Discuss on draft-ietf-ospf-ospfv2-hbit-11: (with DISCUSS and COMMENT)

On November 30, 2019 at 11:21:01 AM, Éric Vyncke wrote: Eric: Hi! > == DISCUSS == > > -- Section 5 -- > The risk of having inconsistent view of the topology with H-bit aware and > unaware routers seems possible to me (albeit perhaps only transient). Has > this feature been tested / simulated in

Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote: Padma: Hi! See below... > On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote: > > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote: > > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker > > > wrote: >

Re: [Lsr] I-D Action: draft-ietf-ospf-ospfv2-hbit-10.txt

On October 24, 2019 at 3:47:44 PM, Padma Pillay-Esnault (padma.i...@gmail.com) wrote: Padma: Hi! > The latest version posted includes all review comments discussed previously > on the list. I’m starting the IETF LC. Thanks!! Alvaro. ___ Lsr mailin

Re: [Lsr] Barry Leiba's No Objection on draft-ietf-isis-yang-isis-cfg-37: (with COMMENT)

On September 26, 2019 at 1:37:47 AM, Barry Leiba via Datatracker ( nore...@ietf.org) wrote: Acee: Hi! — Section 2.3 — In the last two paragraphs of the section, one uses “should” advertise and the other uses “SHOULD” advertise. They should either both be BCP 14 key words, or both not. In this

Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt

On September 23, 2019 at 3:29:55 PM, Padma Pillay-Esnault ( padma.i...@gmail.com) wrote: Padma: Hi! (1) §3 (last paragraph) introduces different behavior for permanently vs > temporarily acting as a host. From the point of view of the H-bit, what is > the difference? It seems to me that in bot

Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt

On September 14, 2019 at 1:12:51 AM, Padma Pillay-Esnault ( padma.i...@gmail.com) wrote: FYI the draft is posted. Padma: Hi! Thanks for the revision! I went through the changes and have some mostly-editorial nits/minor comments (see below, based on -09). There are a couple of major items, i

Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt

[Simply adding the WG to keep everyone in the loop.] On September 14, 2019 at 1:12:51 AM, Padma Pillay-Esnault ( padma.i...@gmail.com) wrote: Hi Alvaro FYI the draft is posted. Sending in attachment here - the diffs between -06 version and -09 version for your convenience. - while you asked m

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

On September 9, 2019 at 5:19:09 PM, Acee Lindem (acee) (a...@cisco.com) wrote: Acee: I see you started the WG last call. I’ll update this tonight - although I believe this isn’t the only down-ref. Thanks for the update! The other DownRef is in

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

Hi! I just found that rfc2966 is in the DownRef registry already, so I’m starting the IETF LC now. We will still need to update the reference, but that can be done with any other LC comments. Thanks! Alvaro. On September 9, 2019 at 4:43:30 PM, Alvaro Retana (aretana.i...@gmail.com) wrote: On

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

On September 5, 2019 at 3:09:44 PM, Acee Lindem (acee) (a...@cisco.com) wrote: Hi! Stephane and I have some more updates in -36 version. I’m ready to start the IETF LC, but there’s one small thing I need you to fix before: rfc2966 was Obsoleted by rfc5302; please update the reference. It’s im

  1   2   >