Re: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID Propagation and L1L2 leaks ...

[Les Ginsberg (ginsberg)]

Waman –

OK – I thought you had some questions regarding how prefix-sid leaking works – 
but it seems that may not be the case. Your concern is about scale.
I am not going to try to address such a broad topic here – other than to say 
this is something which has been on our collective minds for many years. Some 
solutions have been defined, some have been implemented/deployed, some are 
still waiting for a compelling deployment case, and no doubt there are other 
solutions yet to be defined. It is part of the journey we are on. I encourage 
you to listen/participate as you feel appropriate.

As regards redistribution, the need for including the prefix-sid when 
redistributing a route is not significantly different than the need when 
leaking – just having the prefix-sid of the ABR sending the redistributed 
advertisement is not always enough.

   Les


From: Waman Nawathe 
Sent: Monday, August 8, 2022 6:53 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related 
PrefixSID Propagation and L1L2 leaks ...

Hello Les,

Thank you for the response ..  L1L2 route leaks are fine by me but not route 
redistribution on
non-ABR (for Prefix-SID subtlvs).

Your last comment is the one that I have issues with as it will reduce the LSP 
space by 40% of more
because of additional Prefix-SID sub-tlvs (10/18 bytes)...  and I mentioned it 
is not needed as
there is ISIS node reference associated to the route of origin which is 
remotely redistributed.

With ABR that ISIS node association to route path is lost and that I understand 
and important
to add Prefix-SID subTLV but NOT in flat L1 or only L2 network as it is an 
expensive operation i.e.
40% LSP space impact, when there is no need for it. I can get that prefix-SID 
from the route path
association.

Route Space in LSP is limited and important. Only 255 LSPs and most networks use
1500 bytes per lsp. Not all vendors support jumbo ethernet frames. So LSP space 
is
important.

thanks,

-Waman

>

As far as redistribution, while this is commonly configured (if at all) on 
ABRs, there is no restriction against doing so on any router. Clearly the 
inclusion of the prefix-sid for the redistributed route would have to be 
introduced on the router where IS-IS learns of the redistributed route. Whether 
that router is an ABR or not isn’t relevant.



On Mon, Aug 8, 2022 at 9:11 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Hi Waman!

Not sure I completely understand your concerns/questions, but let me make a few 
comments and see if that helps.

The language in RFC 8667 Section 2.1.2 is to say that if the prefix which is 
being leaked/redistributed has a prefix-SID associated with the source 
advertisement (be that L1 for L1->l2 leaking or L2 for L2->L1 leaking or some 
other protocol in the case of redistribution) then the prefix-SID must be 
included in the leaked/redistributed advertisement. It is NOT suggesting that 
in the absence of a SID one should be introduced when leaking/redistributing.

Also, please do not be confused by the referenced slides which highlight the 
“R” and “N” flags in the prefix-SID advertisement. At the time SR was first 
defined, the prefix attribute advertisement (RFC 7794) did not exist. However, 
we quickly realized that R/N flags have use cases beyond SR and so the prefix 
attributes sub-TLV was defined. The R/N flags in the prefix-SID sub-TLV have 
been retained to allow interoperation with early deployments of SR, but note 
the text in RFC 8667 Section 2.1.1.2:

“The Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag and 
R-Flag and with the same semantics of the equivalent flags defined in this 
document. Whenever the Prefix Attribute Flags sub-TLV is present for a given 
prefix, the values of the N-Flag and R-Flag advertised in that sub-TLV MUST be 
used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be 
ignored.

Unfortunately, the slides you reference do not emphasize this point.
So there is no reason to introduce a prefix-sid advertisement simply to 
advertise R-bit.

As far as redistribution, while this is commonly configured (if at all) on 
ABRs, there is no restriction against doing so on any router. Clearly the 
inclusion of the prefix-sid for the redistributed route would have to be 
introduced on the router where IS-IS learns of the redistributed route. Whether 
that router is an ABR or not isn’t relevant.

HTH

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Waman Nawathe
Sent: Monday, August 8, 2022 3:57 PM
To: lsr@ietf.org
Subject: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID 
Propagation and L1L2 leaks ...

Hello All,

New to this IETF list and posting ..

Regarding this section RFC-8667 2.1.1.2, It should ONLY apply to
ISIS L1L2 (or ABR) router and not L1 only or L2 only and here is my
reasoning 

Re: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID Propagation and L1L2 leaks ...

[Waman Nawathe]

Hello Les,

Thank you for the response ..  L1L2 route leaks are fine by me but not
route redistribution on
non-ABR (for Prefix-SID subtlvs).

Your last comment is the one that I have issues with as it will reduce the
LSP space by 40% of more
because of additional Prefix-SID sub-tlvs (10/18 bytes)...  and I mentioned
it is not needed as
there is ISIS node reference associated to the route of origin which is
remotely redistributed.

With ABR that ISIS node association to route path is *lost *and that I
understand and important
to add Prefix-SID subTLV but NOT in flat L1 or only L2 network as it is an
expensive operation i.e.
40% LSP space impact, when there is no need for it. I can get that
prefix-SID from the route path
association.

Route Space in LSP is limited and important. Only 255 LSPs and most
networks use
1500 bytes per lsp. Not all vendors support jumbo ethernet frames. So LSP
space is
important.

thanks,

-Waman

>

As far as redistribution, while this is commonly configured (if at all) on
ABRs, there is no restriction against doing so on any router. Clearly the
inclusion of the prefix-sid for the redistributed route would have to be
introduced on the router where IS-IS learns of the redistributed route. Whether
that router is an ABR or not isn’t relevant.



On Mon, Aug 8, 2022 at 9:11 PM Les Ginsberg (ginsberg) 
wrote:

> Hi Waman!
>
>
>
> Not sure I completely understand your concerns/questions, but let me make
> a few comments and see if that helps.
>
>
>
> The language in RFC 8667 Section 2.1.2 is to say that if the prefix which
> is being leaked/redistributed has a prefix-SID associated with the source
> advertisement (be that L1 for L1->l2 leaking or L2 for L2->L1 leaking or
> some other protocol in the case of redistribution) then the prefix-SID must
> be included in the leaked/redistributed advertisement. It is NOT suggesting
> that in the absence of a SID one should be introduced when
> leaking/redistributing.
>
>
>
> Also, please do not be confused by the referenced slides which highlight
> the “R” and “N” flags in the prefix-SID advertisement. At the time SR was
> first defined, the prefix attribute advertisement (RFC 7794) did not exist.
> However, we quickly realized that R/N flags have use cases beyond SR and so
> the prefix attributes sub-TLV was defined. The R/N flags in the prefix-SID
> sub-TLV have been retained to allow interoperation with early deployments
> of SR, but note the text in RFC 8667 Section 2.1.1.2:
>
>
>
> *“The Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag and
> R-Flag and with the same semantics of the equivalent flags defined in this
> document. Whenever the Prefix Attribute Flags sub-TLV is present for a
> given prefix, the values of the N-Flag and R-Flag advertised in that
> sub-TLV MUST be used, and the values in a corresponding Prefix-SID sub-TLV
> (if present) MUST be ignored.*
>
>
>
> Unfortunately, the slides you reference do not emphasize this point.
>
> So there is no reason to introduce a prefix-sid advertisement simply to
> advertise R-bit.
>
>
>
> As far as redistribution, while this is commonly configured (if at all) on
> ABRs, there is no restriction against doing so on any router. Clearly the
> inclusion of the prefix-sid for the redistributed route would have to be
> introduced on the router where IS-IS learns of the redistributed route.
> Whether that router is an ABR or not isn’t relevant.
>
>
>
> HTH
>
>
>
>Les
>
>
>
> *From:* Lsr  *On Behalf Of * Waman Nawathe
> *Sent:* Monday, August 8, 2022 3:57 PM
> *To:* lsr@ietf.org
> *Subject:* [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related
> PrefixSID Propagation and L1L2 leaks ...
>
>
>
> Hello All,
>
>
>
> New to this IETF list and posting ..
>
>
>
> Regarding this section RFC-8667 2.1.1.2, It should ONLY apply to
>
> ISIS L1L2 (or ABR) router and not L1 only or L2 only and here is my
>
> reasoning 
>
>
>
>
> -
> Reference Diagram (A):
> ---
>
>L1L2 (ABR)
>
> Grunt-54 (L1) -- (L1) Grunt-104 (L2) - (L2) Grunt
> 106
>
>   L1 --> L2 Route Leaks or
>   L1 <-- L2
>
>
>
> ---
> Reference Diagram (B):  Showing Flat L1 or Flat L2 not using any ABRs:
> ---
>
>
>
> Grunt-54 --- G100 --- G101 --- G103   Grunt-104 Grunt-106 
> G200  G201 - G201
>
> L1   L1   L1   L1L1L2  L2
>   L2L2 L2
>
> *NOT* Connected
>   to L1 OR L2
>
>
>
>   Please refer to RFC-8667 Section 2.1.1.2 Page 7 and Section 2.1.2 Page 8
> wrt ISIS
>   ISIS route/prefix leaks. It mentioned 3 types:
>
>   (a) L1L2
>   (b) L2L1 and
>   

Re: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID Propagation and L1L2 leaks ...

[Les Ginsberg (ginsberg)]

Hi Waman!

Not sure I completely understand your concerns/questions, but let me make a few 
comments and see if that helps.

The language in RFC 8667 Section 2.1.2 is to say that if the prefix which is 
being leaked/redistributed has a prefix-SID associated with the source 
advertisement (be that L1 for L1->l2 leaking or L2 for L2->L1 leaking or some 
other protocol in the case of redistribution) then the prefix-SID must be 
included in the leaked/redistributed advertisement. It is NOT suggesting that 
in the absence of a SID one should be introduced when leaking/redistributing.

Also, please do not be confused by the referenced slides which highlight the 
“R” and “N” flags in the prefix-SID advertisement. At the time SR was first 
defined, the prefix attribute advertisement (RFC 7794) did not exist. However, 
we quickly realized that R/N flags have use cases beyond SR and so the prefix 
attributes sub-TLV was defined. The R/N flags in the prefix-SID sub-TLV have 
been retained to allow interoperation with early deployments of SR, but note 
the text in RFC 8667 Section 2.1.1.2:

“The Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag and 
R-Flag and with the same semantics of the equivalent flags defined in this 
document. Whenever the Prefix Attribute Flags sub-TLV is present for a given 
prefix, the values of the N-Flag and R-Flag advertised in that sub-TLV MUST be 
used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be 
ignored.

Unfortunately, the slides you reference do not emphasize this point.
So there is no reason to introduce a prefix-sid advertisement simply to 
advertise R-bit.

As far as redistribution, while this is commonly configured (if at all) on 
ABRs, there is no restriction against doing so on any router. Clearly the 
inclusion of the prefix-sid for the redistributed route would have to be 
introduced on the router where IS-IS learns of the redistributed route. Whether 
that router is an ABR or not isn’t relevant.

HTH

   Les

From: Lsr  On Behalf Of Waman Nawathe
Sent: Monday, August 8, 2022 3:57 PM
To: lsr@ietf.org
Subject: [Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID 
Propagation and L1L2 leaks ...

Hello All,

New to this IETF list and posting ..

Regarding this section RFC-8667 2.1.1.2, It should ONLY apply to
ISIS L1L2 (or ABR) router and not L1 only or L2 only and here is my
reasoning 

-
Reference Diagram (A):
---

   L1L2 (ABR)

Grunt-54 (L1) -- (L1) Grunt-104 (L2) - (L2) Grunt 106

  L1 --> L2 Route Leaks or
  L1 <-- L2



---
Reference Diagram (B):  Showing Flat L1 or Flat L2 not using any ABRs:
---



Grunt-54 --- G100 --- G101 --- G103   Grunt-104 Grunt-106  G200 
 G201 - G201

L1   L1   L1   L1L1L2  L2   L2  
  L2 L2

*NOT* Connected
  to L1 OR L2



  Please refer to RFC-8667 Section 2.1.1.2 Page 7 and Section 2.1.2 Page 8 wrt 
ISIS
  ISIS route/prefix leaks. It mentioned 3 types:

  (a) L1L2
  (b) L2L1 and
  (c) redistribution from another protocol.

   Cases (a) and (b) are fine wrt to my understanding ... but (c) is NOT clear.

   NOTE: each prefix space (tlv-135) in LSP is approx 10 bytes (prefix length 
based)
 and this Prefix-SID TLV is an additional 8 bytes. So if we do this for 
ALL
 Leaked routes then we reduce the total route capacity in
 LSP by 40-50% which is "not" needed really as these routes are 
associated
 with Prefix-SID from the same ISIS node.

   1) I can understand if this adding of prefix-sid "sub-tlv" is is done "only" 
at
  the L1L2 (ABR). as that would maintain correct Prefix-SID association with
  the route accross ABR when it could have been lost.

  I do understand this is not for local routes ie static/connected BUT
  only for ospf/bgp into ISIS, no issues with that - on the L1L2 (ABR).
  This part is fine by me.


   2) Consider reference diagram (B) where L1 or L2 are flat networks with no
  L1L2 (ABR) but have redistributed ospf/bgp under router isis, so why
  should each leaked route be EXPLICITLY associated with Prefix-SID sub-tlv
  when there is ISIS node based Prefix-SID association which is available
  for all Flat network members ?

  The only advantage to this is to reset Prefix-SID flags but we would 
reduce LSP
  space by 40% wrt leaked routes., which is not clear why such an expensive
  penalty for leaked redistributed routes.


   4) I could not see ANY good examples of leaks on the web to clarify this 
issue.

  This is the ONLY 

[Lsr] Question on RFC-8667 section 2.1.1.2 and 2.1.2 related PrefixSID Propagation and L1L2 leaks ...

[Waman Nawathe]

Hello All,

New to this IETF list and posting ..

Regarding this section RFC-8667 2.1.1.2, It should ONLY apply to
ISIS L1L2 (or ABR) router and not L1 only or L2 only and here is my
reasoning 

---
--
Reference Diagram (A):
---

   L1L2 (ABR)

Grunt-54 (L1) -- (L1) Grunt-104 (L2) - (L2) Grunt
106

  L1 --> L2 Route Leaks or
  L1 <-- L2



---
Reference Diagram (B):  Showing Flat L1 or Flat L2 not using any ABRs:
---



Grunt-54 --- G100 --- G101 --- G103   Grunt-104 Grunt-106 
G200  G201 - G201

L1   L1   L1   L1L1L2  L2
L2L2 L2

*NOT* Connected
  to L1 OR L2



  Please refer to RFC-8667 Section 2.1.1.2 Page 7 and Section 2.1.2 Page 8
wrt ISIS
  ISIS route/prefix leaks. It mentioned 3 types:

  (a) L1L2
  (b) L2L1 and
  (c) redistribution from another protocol.

   Cases (a) and (b) are fine wrt to my understanding ... but (c) is NOT
clear.

   NOTE: each prefix space (tlv-135) in LSP is approx 10 bytes (prefix
length based)
 and this Prefix-SID TLV is an additional 8 bytes. So if we do this
for ALL
 Leaked routes then we reduce the total route capacity in
 LSP by 40-50% which is "not" needed really as these routes are
associated
 with Prefix-SID from the same ISIS node.

   1) I can understand if this adding of prefix-sid "sub-tlv" is is done
"only" at
  the L1L2 (ABR). as that would maintain correct Prefix-SID association
with
  the route accross ABR when it could have been lost.

  I do understand this is not for local routes ie static/connected BUT
  only for ospf/bgp into ISIS, no issues with that - on the L1L2 (ABR).
  This part is fine by me.


   2) Consider reference diagram (B) where L1 or L2 are flat networks with
no
  L1L2 (ABR) but have redistributed ospf/bgp under router isis, so why
  should each leaked route be EXPLICITLY associated with Prefix-SID
sub-tlv
  when there is ISIS node based Prefix-SID association which is
available
  for all Flat network members ?

  The only advantage to this is to reset Prefix-SID flags but we would
reduce LSP
  space by 40% wrt leaked routes., which is not clear why such an
expensive
  penalty for leaked redistributed routes.


   4) I could not see ANY good examples of leaks on the web to clarify this
issue.

  This is the ONLY reference I could see ...

  check Slide #14


https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKRST-3009.pdf

  Side #64


https://www.segment-routing.net/tutorials/2016-09-27-segment-routing-igp-control-plane/

Comments and feedback welcome,
Thanks,

-Waman Nawathe
Boston Area, SR Learner


--
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Les Ginsberg (ginsberg)]

I support progressing this draft.
IGP support for SRv6 is clearly needed. We already have IS-IS extensions 
defined and WG work on that draft is already complete.
Having the equivalent functionality defined for OSPFv3 closes an obvious gap.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, July 29, 2022 10:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Yingzhen Qu]

I support the adoption of this draft. These clarifications are needed.

Thanks,
Yingzhen

> On Aug 8, 2022, at 3:17 AM, Christian Hopps  wrote:
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Henderickx, Wim (Nokia - BE/Antwerp)]

Support, not aware of IPR related to this draft

From: Lsr  on behalf of Christian Hopps 

Date: Monday, 8 August 2022 at 12:22
To: lsr@ietf.org 
Cc: cho...@chopps.org , lsr-cha...@ietf.org 
, lsr-...@ietf.org 
Subject: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

  https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/

Please indicate your support or objections by August 22nd, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Jeff Tantsura]

Chris,

I’m not aware of any IPR that hasn’t been disclosed and support the progress 
(as co-author).

Cheers,
Jeff

> On Aug 8, 2022, at 05:57, John E Drake  
> wrote:
> 
> Support
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Christian Hopps
>> Sent: Monday, August 8, 2022 6:17 AM
>> To: lsr@ietf.org
>> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
>> Subject: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> Hi Folks,
>> 
>> This begins a 2 week WG Adoption Call for the following draft:
>> 
>>  https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
>> 
>> Please indicate your support or objections by August 22nd, 2022.
>> 
>> Authors, please respond to the list indicating whether you are aware 
>> of any IPR that applies to these drafts.
>> 
>> Thanks,
>> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Acee Lindem (acee)]

As a contributor, I'm not aware of any IPR related to the draft.

Thanks,
Acee

On 8/8/22, 9:55 AM, "Peter Psenak"  wrote:

Hi Chris,

I am not aware of any IPR related to this draft.

thanks,
Peter


On 08/08/2022 06:17, Christian Hopps wrote:
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of 
any IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Peter Psenak]

Hi Chris,

I am not aware of any IPR related to this draft.

thanks,
Peter

On 08/08/2022 06:17, Christian Hopps wrote:


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

   https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/

Please indicate your support or objections by August 22nd, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Peter Psenak]

Hi Chris,

I am not aware of any IPR related to this draft.

thanks,
Peter


On 08/08/2022 06:17, Christian Hopps wrote:


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

   https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/

Please indicate your support or objections by August 22nd, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Les Ginsberg (ginsberg)]

I am not aware of any IPR related to this draft.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, August 8, 2022 3:17 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Les Ginsberg (ginsberg)]

I am not aware of any IPR related to this draft.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, August 8, 2022 3:17 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[John E Drake]

Support

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, August 8, 2022 6:17 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware 
> of any IPR that applies to these drafts.
> 
> Thanks,
> Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[John E Drake]

Support

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Monday, August 8, 2022 6:17 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
> 
> Please indicate your support or objections by August 22nd, 2022.
> 
> Authors, please respond to the list indicating whether you are aware 
> of any IPR that applies to these drafts.
> 
> Thanks,
> Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Acee Lindem (acee)]

I support WG adoption. The clarifications in the BIS document were discussed in 
the course of the flex algorithm draft.
Thanks,
Acee

On 8/8/22, 6:21 AM, "Christian Hopps"  wrote:


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

  https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/

Please indicate your support or objections by August 22nd, 2022.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to these drafts.

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Acee Lindem (acee)]

I support WG adoption. The clarifications in the BIS document were discussed in 
the course of the flex algorithm draft.
Thanks,
Acee

On 8/8/22, 6:22 AM, "Christian Hopps"  wrote:


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

  https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/

Please indicate your support or objections by August 22nd, 2022.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to these drafts.

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] The LSR WG has placed draft-ppsenak-lsr-rfc8920bis in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The LSR WG has placed draft-ppsenak-lsr-rfc8920bis in state
Call For Adoption By WG Issued (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] The LSR WG has placed draft-ginsberg-lsr-rfc8919bis in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The LSR WG has placed draft-ginsberg-lsr-rfc8919bis in state
Call For Adoption By WG Issued (entered by Christian Hopps)

The document is available at
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Christian Hopps]

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

 https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/

Please indicate your support or objections by August 22nd, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.


signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Christian Hopps]

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

 https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/

Please indicate your support or objections by August 22nd, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to these drafts.

Thanks,
Chris.


signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr