[Lsr] Last Call: (Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final

[Lsr] Last Call: (IS-IS Fast Flooding) to Experimental RFC

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Fast Flooding' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the

[Lsr] Last Call: (Dynamic Flooding on Dense Graphs) to Experimental RFC

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Dynamic Flooding on Dense Graphs' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

Hi Tom. > On Jan 16, 2024, at 10:26 AM, Acee Lindem wrote: > > Hi Tom, > >> On Jan 16, 2024, at 06:50, tom petch wrote: >> >> From: Acee Lindem >> Sent: 15 January 2024 20:30 >> >> Hi Tom, >> >> Since this YANG model describes the RFC 8362 encodings, those encodings >> should be the

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

Hi Acee, Sounds good! Regards,Reshad. On Tuesday, January 16, 2024, 12:45:40 PM EST, Acee Lindem wrote: Hi Reshad,  On Jan 16, 2024, at 11:41, Reshad Rahman wrote: Hi, Apologies if this has been discussed before but I didn't follow this document. - Should interface-id and

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

Hi Reshad, > On Jan 16, 2024, at 11:41, Reshad Rahman > wrote: > > Hi, > > Apologies if this has been discussed before but I didn't follow this document. > > - Should interface-id and neighbor-interface-id be of type if:if-index > instead of uint32? I took a look at RFC8362, still not

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

Hi, Apologies if this has been discussed before but I didn't follow this document. - Should interface-id and neighbor-interface-id be of type if:if-index instead of uint32? I took a look at RFC8362, still not clear to me.- Should leaf metric be of type ospf-metric or ospf-leaf-metric instead of

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

Hi Tom, > On Jan 16, 2024, at 06:50, tom petch wrote: > > From: Acee Lindem > Sent: 15 January 2024 20:30 > > Hi Tom, > > Since this YANG model describes the RFC 8362 encodings, those encodings > should be the primary reference all the leaves and identifies. > > > > Acee > > I think

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

From: Acee Lindem Sent: 15 January 2024 20:30 Hi Tom, Since this YANG model describes the RFC 8362 encodings, those encodings should be the primary reference all the leaves and identifies. Acee I think that you are wrong. The historian in me knows that given a choice or primary or

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

Hi Tom, Since this YANG model describes the RFC 8362 encodings, those encodings should be the primary reference all the leaves and identifies. > On Jan 13, 2024, at 07:42, tom petch wrote: > > From: Lsr on behalf of The IESG > > Sent: 11 January 2024 14:35 > > The IESG has received a

Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

From: Lsr on behalf of The IESG Sent: 11 January 2024 14:35 The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Model for OSPFv3 Extended LSAs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and

[Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Model for OSPFv3 Extended LSAs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive

[Lsr] Last Call: (Area Proxy for IS-IS) to Experimental RFC

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Area Proxy for IS-IS' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the

Re: [Lsr] [Last-Call] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12

> On Jun 1, 2023, at 5:58 PM, Nyagudi Musandu Nyagudi > wrote: > > Question - To ask is not folly: At the time of writing these documents > "Administrator" is not a protocol, could it become a protocol in the near > future? There are plenty of protocols to “administer” network devices

Re: [Lsr] [Last-Call] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12

On 01/06/2023 23:58, Nyagudi Musandu Nyagudi wrote: Question - To ask is not folly: At the time of writing these documents "Administrator" is not a protocol, could it become a protocol in the near future? no matter how it is set it's not something that changes often. Please understand that

Re: [Lsr] [Last-Call] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12

Question - To ask is not folly: At the time of writing these documents "Administrator" is not a protocol, could it become a protocol in the near future?  On Thursday, June 1, 2023 at 06:19:54 PM GMT+3, Acee Lindem wrote: On Jun 1, 2023, at 06:54, Peter Psenak wrote: Hi Antoine,

Re: [Lsr] [Last-Call] Genart last call review of draft-ietf-lsr-ospf-terminology-05

Gyan, thank you for your review. I have entered a No Objection ballot for this document. Lars > On Apr 28, 2023, at 01:00, Gyan Mishra via Datatracker > wrote: > > Reviewer: Gyan Mishra > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review

Re: [Lsr] Last Call Expired:

Hi Authors, WG, Looks like the IETF LC went fine, I’ve issued the ballot for this document. Note that the May 25 telechat agenda is already full so I anticipate this will be on the June 8 telechat. It looks like there were some editorial points raised in the genart review, please consider

[Lsr] Last Call: (IGP Flexible Algorithms (Flex-Algorithm) In IP Networks) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IGP Flexible Algorithms (Flex-Algorithm) In IP Networks' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.

[Lsr] Last Call: (OSPFv3 Extensions for SRv6) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPFv3 Extensions for SRv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

previous comment, I chose not to do this. Les > 7.5 > you got there before me but IANA starts the name with I S I S > which as above I think significant in this context. > > Tom Petch > > > >Les > > > -----Original Message- > > From: tom pet

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

John Scudder > > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Last Call: (IS-IS > Application- > Specific Link Attributes) to Proposed Standard > > From: Les Ginsberg (ginsberg) > Sent: 20

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

Thursday, April 20, 2023 9:05 AM > To: John Scudder > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Last Call: (IS-IS > Application- > Specific Link Attributes) to Proposed Standard > > From: John Scudder

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

I agree and believe the suggested text is fine. Acee > On Apr 21, 2023, at 6:59 AM, Alvaro Retana > wrote: > > 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

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?

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

hopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Last Call: (IS-IS > Application- > Specific Link Attributes) to Proposed Standard > > From: John Scudder > Sent: 20 April 2023 13:45 > To: tom petch > Cc: cho...@chopps

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

@ietf.org; lsr@ietf.org Subject: Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard Hi Tom, Thanks for catching this, sorry I missed it in my review. The registry is now named "IS-IS Sub-TLVs for Application-Specific SRLG TLV”, so, OLD: 7.5. Sub-TLVs

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

From: John Scudder Sent: 20 April 2023 13:45 To: tom petch Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard Hi Tom, Thanks for catching this, sorry I

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

Hi Les, > On Apr 20, 2023, at 10:43 AM, Les Ginsberg (ginsberg) > wrote: > > Also to John - if you have provided a review of the bis draft (as you suggest > below) I don’t seem to have seen it. > Did you send it to the list?? Or are you referring to your comments from last > year which

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

in the bis draft being created? Les > -Original Message- > From: John Scudder > Sent: Thursday, April 20, 2023 5:46 AM > To: tom petch > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Last Call:

[Lsr] Last Call: (OSPF Application-Specific Link Attributes) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Application-Specific Link Attributes' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

nce > Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; j...@juniper.net; > lsr-cha...@ietf.org; lsr@ietf.org > Subject: [Lsr] Last Call: (IS-IS > Application-Specific Link Attributes) to Proposed Standard > The IESG has received a request from the Link State Routing

Re: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

From: Lsr on behalf of The IESG Sent: 19 April 2023 21:01 To: IETF-Announce Cc: cho...@chopps.org; draft-ietf-lsr-rfc8919...@ietf.org; j...@juniper.net; lsr-cha...@ietf.org; lsr@ietf.org Subject: [Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard The IESG has

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

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? Something like "It is intended that all future OSPF documents use this revised terminology even when they reference the RFCs updated by this document." That could go in

[Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Application-Specific Link Attributes' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send

[Lsr] Last Call Request for draft-ietf-lsr-rfc8920bis

The authors of draft-ietf-lsr-rfc8920bis request WG last call. The changes in this bis draft are clarifications to the existing RFC which have been thoroughly discussed by the WG. The changes were originally discussed over a year

[Lsr] Last Call Request for draft-ietf-lsr-rfc8919bis

The authors of draft-ietf-lsr-rfc8919bis request WG last call. The changes in this bis draft are clarifications to the existing RFC which have been thoroughly discussed by the WG. The changes were originally discussed over a year

Re: [Lsr] [Last-Call] Genart last call review of draft-ietf-lsr-flex-algo-23

Dan, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2022-9-20, at 0:29, Dan Romascanu via Datatracker wrote: > > Reviewer: Dan Romascanu > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team

Re: [Lsr] Last Call: (IS-IS Flood Reflection) to Experimental RFC

Hi Tom, On 9/28/22, 5:41 AM, "tom petch" wrote: On 26/09/2022 18:02, The IESG wrote: > > The IESG has received a request from the Link State Routing WG (lsr) to > consider the following document: - 'IS-IS Flood Reflection' > as Experimental RFC > > The IESG

Re: [Lsr] Last Call: (IS-IS Flood Reflection) to Experimental RFC

On 26/09/2022 18:02, The IESG wrote: The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Flood Reflection' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.

[Lsr] Last Call: (IS-IS Flood Reflection) to Experimental RFC

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Flood Reflection' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the

[Lsr] Last Call Expired:

Please DO NOT reply to this email. I-D: Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. ___ Lsr mailing list

[Lsr] Last Call: (Advertising Layer 2 Bundle Member Link Attributes in OSPF) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Advertising Layer 2 Bundle Member Link Attributes in OSPF' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.

[Lsr] Last Call: (IGP Flexible Algorithm) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IGP Flexible Algorithm' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to

[Lsr] Last Call: (OSPF Reverse Metric) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Reverse Metric' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the

[Lsr] Last Call: (OSPF BFD Strict-Mode) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF BFD Strict-Mode' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the

[Lsr] Last Call: (IGP extension for PCEP security capability support in PCE discovery) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IGP extension for PCEP security capability support in PCE discovery' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this

[Lsr] Last Call:

Last Call Request has been submitted for https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Last Call: (IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering' as Proposed Standard The IESG plans to make a decision in the next few weeks, and

[Lsr] Last Call: (YANG Module for IS-IS Reverse Metric) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Module for IS-IS Reverse Metric' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive

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

etana Sent: Wednesday, May 12, 2021 7:17 AM To: Gengxuesong (Geng Xuesong) ; Peter Psenak (ppsenak) ; bruno.decra...@orange.com Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) ; draft-ietf-lsr-isis-srv6- extensi...@ietf.org; Les Ginsberg (ginsberg) ; Shraddha Hegde ; lsr@ietf.org; cho...@chopps.or

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

; ; draft-ietf-lsr-isis-srv6- > extensi...@ietf.org; Les Ginsberg (ginsberg) ; > Shraddha Hegde ; lsr@ietf.org; > cho...@chopps.org > Subject: Re: [Lsr] Last Call: > (IS-IS > Extension to Support Segment Routing over IPv6 Dataplane) to Proposed > Standard > > Peter: >

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

Velde, Gunter (Nokia - BE/Antwerp) Subject: RE: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard [External Email. Be cautious of content] Shraddha/ Xuesong - Since Prefix Attributes sub-TLV is required for correct operation when a Locator

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!

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

a - BE/Antwerp) *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Les, Prefix Attributes sub-TLV is necessary when locator is leaked. So we are not against Prefix Attribute sub-TLV implementation. We just propose to keep it opt

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

ards, > >>> > >>> --Bruno > >>> > >>> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gengxuesong > >>> (Geng Xuesong) > >>> *Sent:* Wednesday, May 12, 2021 9:16 AM > >>> *To:* Les Ginsberg (ginsberg) ; Shr

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

elde, Gunter (Nokia - BE/Antwerp) *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Les, Prefix Attributes sub-TLV is necessary when locator is leaked. So we are not against Prefix Attribute sub-TLV implementation. We

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

] *On Behalf Of *Gengxuesong > > (Geng Xuesong) > > *Sent:* Wednesday, May 12, 2021 9:16 AM > > *To:* Les Ginsberg (ginsberg) ; Shraddha Hegde > > ; Alvaro Retana > > ; Peter Psenak (ppsenak) > ; > > lsr@ietf.org > > *Cc:* cho...@chopps.org; draft-ietf-lsr-i

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

; Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org *Cc:* cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) *Subject:* Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Les

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

nsi...@ietf.org>; Van De Velde, Gunter (Nokia - BE/Antwerp) mailto:gunter.van_de_ve...@nokia.com>> Subject: RE: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Shraddha/ Xuesong - Since Prefix Attributes sub-TLV is required for cor

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

o:ginsb...@cisco.com] Sent: Wednesday, May 12, 2021 6:29 AM To: Shraddha Hegde ; Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org; Gengxuesong (Geng Xuesong) Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject:

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

To: Alvaro Retana ; Peter Psenak (ppsenak) ; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Juniper has

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

; lsr@ietf.org Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard [External Email. Be cautious of content] On May 3

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

: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard As has been mentioned in this thread, the need for the prefix-attributes sub-TLV to correctly process leaked advertisements is not unique to the Locator TLV. The reason prefix-attributes

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

gt; it is fine to go with MUST. > >    Les > > > From: Lsr On Behalf Of Ketan Talaulikar (ketant) > Sent: Friday, May 07, 2021 7:00 AM > To: Alvaro Retana ; Peter Psenak (ppsenak) > ; lsr@ietf.org > Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De >

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

-isis-srv6-extensi...@ietf.org" , Gunter Van de Velde Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard As has been mentioned in this thread, the need for the prefix-attributes sub-TLV to correctly process leake

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

-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) Subject: Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard Hi Peter, I agree that the support for the Prefix Attribute Flags TLV is required

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

De Velde, Gunter (Nokia - BE/Antwerp) Subject: 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 pr

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

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

sr-isis-srv6-extensi...@ietf.org; aretana.i...@gmail.com Subject: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extension to Sup

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

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extension to Support Segment Routing over IPv6 Dataplane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this

Re: [Lsr] [Last-Call] Genart last call review of draft-ietf-lsr-ospf-prefix-originator-09

Vijay, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-4-2, at 16:54, Vijay Gurbani via Datatracker wrote: > > Reviewer: Vijay Gurbani > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review

[Lsr] Last Call: (OSPF Prefix Originator Extensions) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Prefix Originator Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive

Re: [Lsr] [Last-Call] Yangdoctors last call review of draft-ietf-lsr-yang-isis-reverse-metric-01

> On Dec 16, 2020, at 7:12 AM, Ladislav Lhotka via Datatracker > wrote: > > Reviewer: Ladislav Lhotka > Review result: Ready with Issues > > General comments > > - YANG module "ietf-isis-reverse-metric" is in a good shape except for > one issue described below. > - I appreciate the

[Lsr] Last Call: (Invalid TLV Handling in IS-IS) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Invalid TLV Handling in IS-IS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

draft-ietf-isis-te-app-17 has been posted with this change. Les > -Original Message- > From: Scott O. Bradner > Sent: Wednesday, June 17, 2020 8:53 AM > To: Les Ginsberg (ginsberg) > Cc: Rob Wilton (rwilton) ; Peter Psenak > ; Benjamin Kaduk > ; lsr@ietf.org; ops-...@ietf.org;

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

just to be clear - the test I mean is "On top of advertising the link attributes for standardized applications, link attributes can be advertised for the purpose of applications that are not standardized. We call such an application a "User Defined Application" or "UDA". These applications

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

I'm fine if both documents have the text thanks Scott > On Jun 17, 2020, at 10:56 AM, Les Ginsberg (ginsberg) > wrote: > > Rob - > > IS-IS draft currently states: > > "User Defined Application Identifier Bits have no relationship to > Standard Application Identifier Bits and are not

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

Les, Thanks for being accommodating. Regards, Rob > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: 17 June 2020 15:57 > To: Rob Wilton (rwilton) ; Peter Psenak > ; Benjamin Kaduk > Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops- > d...@ietf.org;

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

Rob - IS-IS draft currently states: "User Defined Application Identifier Bits have no relationship to Standard Application Identifier Bits and are not managed by IANA or any other standards body." (OSPF has this text also.) I am happy enough to include an additional statement similar to

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

Hi Les, Would you be opposed to adding text similar to the OSPF paragraph below to the ISIS draft? I think that the OSPF draft does a better job of first introducing UDAs. Having just looked at the ISIS draft, it does seem to somewhat assume that the reader will just know what they are ...

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

that looks just fine to me - thanks Scott > On Jun 15, 2020, at 5:14 AM, Peter Psenak > wrote: > > Hi Scott. > > there is a following text in the OSPF draft: > > "On top of advertising the link attributes for standardized > applications, link attributes can be advertised for the purpose

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

Scott - I hear and respect your choice to end this thread. One point of clarification - no response is required or expected. The definition I mentioned ("to provide the opportunity for proprietary/experimental applications") is simply my POV. This was never discussed in the WG. While this

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

inline > On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg) > wrote: > > Scott - > > > > Inline. > > > > > -Original Message- > > > From: Scott O. Bradner > > > Sent: Sunday, June 14, 2020 3:16 PM > > > To: Les Ginsberg (ginsberg) > > > Cc: ops-...@ietf.org; Benjamin

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

Scott - Inline. > -Original Message- > From: Scott O. Bradner > Sent: Sunday, June 14, 2020 3:16 PM > To: Les Ginsberg (ginsberg) > Cc: ops-...@ietf.org; Benjamin Kaduk ; draft-ietf-ospf-te- > link-attr-reuse@ietf.org; last-c...@ietf.org; lsr@ietf.org > Subject: Re:

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

but why not spend the few bits to make it clear what its intended for - the pushback on that simple request puzzles me I do not understand the reluctance if it is so far outside of the area covered by the document why not simply remove it? Scott > On Jun 14, 2020, at 5:14 PM, Les Ginsberg

Re: [Lsr] [Last-Call] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

that works for me - thanks Scott > On Jun 1, 2020, at 12:01 PM, Peter Psenak > wrote: > > Hi Linda, > > > On 01/06/2020 17:30, Linda Dunbar wrote: >> Peter, >> You said: >> /“//the problem with existing advertisement is that RSVP-TE will use it, >> even if it was not intended to be used

Re: [Lsr] [Last-Call] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

Scott, please see inline (##PP3) On 01/06/2020 12:46, Scott O. Bradner wrote: inline On Jun 1, 2020, at 5:54 AM, Peter Psenak wrote: ##PP2 It's the ambiguity that causes the problem. Here's a real life example which triggered some of this work: A network has RSVP-TE enabled on one

Re: [Lsr] [Last-Call] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

inline > On Jun 1, 2020, at 5:54 AM, Peter Psenak wrote: > > > ##PP2 > > It's the ambiguity that causes the problem. Here's a real life example which > triggered some of this work: > > A network has RSVP-TE enabled on one subset of links, and SRTE on some other > subset. On a link where

Re: [Lsr] [Last-Call] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

Scott, please see inline (##PP2) On 30/05/2020 20:38, Scott O. Bradner wrote: thanks for the reply - see in line On May 28, 2020, at 10:09 AM, Peter Psenak wrote: Hi Scott, please see inline (##PP): On 27/05/2020 17:17, Scott Bradner via Datatracker wrote: Reviewer: Scott Bradner

Re: [Lsr] [Last-Call] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

thanks for the reply - see in line > On May 28, 2020, at 10:09 AM, Peter Psenak > wrote: > > Hi Scott, > > please see inline (##PP): > > On 27/05/2020 17:17, Scott Bradner via Datatracker wrote: >> Reviewer: Scott Bradner >> Review result: Not Ready >> This is an OPS-DIR review of OSPF Link

[Lsr] Last Call: (OSPF Link Traffic Engineering Attribute Reuse) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Link Traffic Engineering Attribute Reuse' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send

[Lsr] Last Call: (IS-IS TE Attributes per application) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS TE Attributes per application' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive

[Lsr] Last Call: (Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final

[Lsr] Last Call: (Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS) to Proposed Standard

The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final

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

Hi Alvaro, Acee Ack, I will spin a new version with the review comments and will add the new bullet. Thanks everyone for your valuable feedback and comments! Padma On Thu, Nov 7, 2019 at 9:06 AM Acee Lindem (acee) wrote: > Hi Alvaro, > > On 11/7/19, 11:58 AM, "Alvaro Retana" wrote: > >

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

Hi Alvaro, On 11/7/19, 11:58 AM, "Alvaro Retana" wrote: 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

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] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

Hi Ben On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote: > Hi Padma, > > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote: > > Hi Kyle > > > > Thank you for your review > > > > Please see below PPE > > > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker < >

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

Hi Padma, On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote: > Hi Kyle > > Thank you for your review > > Please see below PPE > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker > wrote: > > * I'm curious what happens if a router sets the H-bit when it is on the

  1   2   >