Subject: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 May 2017 18:45:52 +0000

This draft was presented in Chicago and there was acknowledgment that a solution was needed. The authors have asked for WG adoption and we are now doing a WG adoption poll. Please indicate your support or objection by May 20th, 2017.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 May 2017 20:27:27 +0000

Speaking as a WG member:

I believe we should move forward with this simple mechanism for OSPFv2 neighbors to learn each other’s interface ID. Both IS-IS and, more importantly, OSPFv3 learn the interface ID via their respective hello mechanisms. Just because one implementation has repurposed the Generalized MPL (GMPL) extensions described in RFC 4302 for interface ID learning is not a reason to preclude using the more generally accepted IGP Hello packet learning. Additionally, there is the undesirable side effect of TE LSAs resulting in inclusion in the TE topology for multiple implementations.

Finally, when the right technical direction is clear and there is rough consensus, the OSPF WG MUST NOT be obstructed.

Thanks,
Acee

From: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 4, 2017 at 2:45 PM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 May 2017 21:07:14 +0000

A strong +1  here.

Acee has captured very well the compelling(sic) reasons for defining these extensions.

Use of RFC 4302 extensions are only a workaround for functionality which is missing in the protocol. We need to close that gap.

   Les

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 04, 2017 1:27 PM
To: OSPF WG List
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Speaking as a WG member:

Thanks,
Acee

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 4 May 2017 17:20:29 -0400

Support.

On May 4, 2017 11:52 AM, "Acee Lindem (acee)" <[email-masked]> wrote:

>
> This draft was presented in Chicago and there was acknowledgment that a
> solution was needed. The authors have asked for WG adoption and we are now
> doing a WG adoption poll. Please indicate your support or objection by May
> 20th, 2017.
>
> Thanks,
> Acee
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>
>

---

From: Yingzhen Qu <[email-masked]>
Date: Thu, 4 May 2017 22:18:41 +0000

Strong support +1 here.

The draft provides a generic way for the missing info and it’s needed.

Thanks,
Yingzhen

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 04, 2017 1:27 PM
To: OSPF WG List <[email-masked]>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Speaking as a WG member:

Thanks,
Acee

Thanks,
Acee

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 4 May 2017 23:21:31 +0000

I read through the draft and support its adoption.

Best Regards,
Huaimo
From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 04, 2017 4:27 PM
To: OSPF WG List
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Speaking as a WG member:

Thanks,
Acee

Thanks,
Acee

---

From: Veerendranatha Reddy Vallem <[email-masked]>
Date: Fri, 5 May 2017 05:07:54 +0000

I support. Very useful extension for OSPFv2.

Regards,
Veerendranath

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: 05 May 2017 00:16
To: OSPF WG List <[email-masked]>
Subject: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 5 May 2017 06:05:09 +0000

Acee,

>Additionally, there is the undesirable side effect of TE LSAs resulting in inclusion in the TE topology for multiple >implementations

The testing results on 3 implementation shows that local/remote interface ID in TE Opaque LSA does not result into links getting included in TE topology. Pls refer introduction section of draft draft-hegde-isis-advertising-te-protocols-02.

RFC 4203 defines Link local scope TE-Opaque LSA to carry the interface-id and a remote ingress node would not be adding links to TE-Topology based on these link local LSAs simply because they would never see them.

Rgds
Shraddha

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Friday, May 5, 2017 1:57 AM
To: OSPF WG List <[email-masked]>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Speaking as a WG member:

Thanks,
Acee

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Fri, 05 May 2017 09:29:51 +0200

Support as coauthor.

Peter

On 04/05/17 20:45 , Acee Lindem (acee) wrote:
> solution was needed. The authors have asked for WG adoption and we are
> now doing a WG adoption poll. Please indicate your support or objection
> by May 20th, 2017.
>
> Thanks,
> Acee
>
>

---

From: Dirk Goethals <[email-masked]>
Date: Fri, 5 May 2017 09:53:51 +0200

support
+1

Very useful extension for OSPFv2.

Regards,

Dirk

Op 4/05/2017 om 20:45 schreef Acee
Lindem (acee):

This draft was presented in Chicago and there was
acknowledgment that a solution was needed. The authors have
asked for WG adoption and we are now doing a WG adoption poll.
Please indicate your support or objection by May 20th, 2017.

Thanks,

Acee

---

From: "Ketan Talaulikar Talaulikar (ketant)" <[email-masked]>
Date: Fri, 5 May 2017 14:45:55 +0000

Support as co-author

Thanks,
Ketan

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 May 2017 15:09:19 +0000

Hi Shraddha,

From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 5, 2017 at 2:05 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Acee,

This is an IS-IS draft. I don’t see the relevance.

This is probably the case for link-local scoped TE LSAs. I wouldn’t expect any other implementation to have used the link-local scoped TE LSAs for any purpose.

Thanks,
Acee

Rgds
Shraddha

Speaking as a WG member:

Thanks,
Acee

Thanks,
Acee

---

From: prz <[email-masked]>
Date: Fri, 05 May 2017 08:09:27 -0700

Not sure it made it from my other address so rtx to the list ...  

A
conditional against here ...  

I am fine with adoption if I see a
version that spells the detailed behavior and especially interactions
between RFC4302 and this draft in a detailed section, i.e. both on,
RFC4302 gets configured/unconfigured, are the LLS extensions advertised
on every hello or just until a specific state (like ISIS padding
thingies) and so on ...  

I'd rather have this now than a LC discussion
...  

The idea is deceptively simple but it is a redundant mechanism
and those always end causing inter-op problems unless cleanly spelled
out ...  

--- tony   

On Thu, 4 May 2017 20:27:27 +0000, "Acee Lindem
(acee)"  wrote:  

Speaking as a WG member:  

I believe we should move
forward with this simple mechanism for OSPFv2 neighbors to learn each
other's interface ID. Both IS-IS and, more importantly, OSPFv3 learn the
interface ID via their respective hello mechanisms. Just because one
implementation has repurposed the Generalized MPL (GMPL) extensions
described in RFC 4302 for interface ID learning is not a reason to
preclude using the more generally accepted IGP Hello packet learning.
Additionally, there is the undesirable side effect of TE LSAs resulting
in inclusion in the TE topology for multiple implementations.  

Finally, when the right technical direction is clear and there is rough
consensus, the OSPF WG MUST NOT be obstructed. 

Thanks, 
Acee  

From:
Acee Lindem 

Subject: WG Adoption Poll for "OSPF LLS Extensions for Local Interface
ID Advertisement" 

This draft was presented in Chicago and there was
acknowledgment that a solution was needed. The authors have asked for WG
adoption and we are now doing a WG adoption poll. Please indicate your
support or objection by May 20th, 2017.  

Thanks, 
Acee      

Links:
------
[1] mailto:[email-masked]
[2] mailto:[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 May 2017 15:14:30 +0000

Hi Tony,

The authors will cover this in the next revision. Based on discussions, the usage of link-scoped TE LSAs is limited to unnumbered point-to-point links. If this is the case, the backward compatibility is much simpler than the other discussions we’ve been having.

Thanks,
Acee

From: prz <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 5, 2017 at 11:09 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

A conditional against here ...

I am fine with adoption if I see a version that spells the detailed behavior and especially interactions between RFC4302 and this draft in a detailed section, i.e. both on, RFC4302 gets configured/unconfigured, are the LLS extensions advertised on every hello or just until a specific state (like ISIS padding thingies) and so on ...
I'd rather have this now than a LC discussion ...
The idea is deceptively simple but it is a redundant mechanism and those always end causing inter-op problems unless cleanly spelled out ...
--- tony

On Thu, 4 May 2017 20:27:27 +0000, "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as a WG member:

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 5 May 2017 21:14:40 +0000

Support.

--
Uma C.

On May 4, 2017 11:52 AM, "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Acee

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Sat, 6 May 2017 03:46:44 +0000

Support as co-author.

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 04, 2017 11:46 AM
To: OSPF WG List
Subject: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Thanks,
Acee

---

From: "Russ White" <[email-masked]>
Date: Sat, 6 May 2017 09:20:03 -0400

> Acee has captured very well the compelling(sic) reasons for defining these

Agreed -- support the adoption of this draft as a WG doc.

😊 /r

---

From: prz <[email-masked]>
Date: Sat, 06 May 2017 09:58:16 -0700

Hey Acee,  

1. looking fwd to read the revision with backwards
compatibility section and definition which Hello FSM states the
extension applies to 

2. I try to read what you say carefully but
please clarify: there's nothing in rfc5613 that prevents LLC on any link
so do you mean, you suggest to use this TLV on unnumbered links _only_?
Or do you suggest that RFC3630 implies somehow that LS TE LSAs are used
on unnumbered links _only_? If so, I don't see anything in the RFC to
this effect ...  

--- tony  

On Fri, 5 May 2017 15:14:30 +0000, "Acee
Lindem (acee)"  wrote:  
Hi Tony,  

The authors will cover this in the
next revision. Based on discussions, the usage of link-scoped TE LSAs is
limited to unnumbered point-to-point links. If this is the case, the
backward compatibility is much simpler than the other discussions we've
been having.  

Thanks, 
Acee  

From: prz 
Date: Friday, May 5, 2017 at
11:09 AM
To: Acee Lindem 
Cc: OSPF WG List 
Subject: Re: [OSPF] WG
Adoption Poll for "OSPF LLS Extensions for Local Interface ID
Advertisement" 

Not sure it made it from my other address so rtx to the
list ...  

A conditional against here ...  
I am fine with adoption if
I see a version that spells the detailed behavior and especially
interactions between RFC4302 and this draft in a detailed section, i.e.
both on, RFC4302 gets configured/unconfigured, are the LLS extensions
advertised on every hello or just until a specific state (like ISIS
padding thingies) and so on ...  
I'd rather have this now than a LC
discussion ...  
The idea is deceptively simple but it is a redundant
mechanism and those always end causing inter-op problems unless cleanly
spelled out ...  
--- tony  

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]
[3] mailto:[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 6 May 2017 17:03:59 +0000

Hi Tony,

I’ll have to discuss with the authors - but my impression is that this would not be limited to unnumbered links.  My understanding is that the repurposing of link–local OSPF TE LSAs is only done on unnumbered links so that would be the main focus of the backward compatibility discussion.

Thanks,
Acee

Date: Saturday, May 6, 2017 at 12:58 PM

Hey Acee,

1. looking fwd to read the revision with backwards compatibility section and definition which Hello FSM states the extension applies to

2. I try to read what you say carefully but please clarify: there's nothing in rfc5613 that prevents LLC on any link so do you mean, you suggest  to use this TLV on unnumbered links _only_?  Or do you suggest that RFC3630 implies somehow that LS TE LSAs are used on unnumbered links _only_? If so, I don't see anything in the RFC to this effect ...

--- tony

On Fri, 5 May 2017 15:14:30 +0000, "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tony,

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 6 May 2017 18:15:21 +0000

Tony –

It is known that link identifiers are useful even in cases of numbered links e.g. some telemetry applications prefer to use link identifiers to identify all links (numbered and unnumbered).
So I share Acee’s expectations.

   Les

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, May 06, 2017 10:04 AM
To: prz
Cc: OSPF WG List
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Hi Tony,

Thanks,
Acee

Hey Acee,

--- tony

---

From: Anton Smirnov <[email-masked]>
Date: Sun, 7 May 2017 19:18:44 +0200

Hello,
    I support this draft to become WG document.

---
Anton

---

From: prz <[email-masked]>
Date: Sun, 07 May 2017 12:47:59 -0700

I try to parse that and am still not clear what you both are saying

1. It seems you both saying that RFC3630 is expected now to be used on
unnumbered only (for which I find no indication) or are you claiming
it's only used that way? Based on which implementation or document? What
is "repurposing"? RFC3630 is a published Standards track RFC and I don't
know what "re-purposing" standards RFCs means?  

2. Or are you saying
that the new draft will be restricted to unnumbered only? In which case
I expect a new version of draft to discuss further and agree taht the
backwards compat section colllapses to "unnumbered link" considerations
only ...  

? 

--- tony  

On Sat, 6 May 2017 18:15:21 +0000, "Les
Ginsberg (ginsberg)"  wrote:  

Tony - 

It is known that link
identifiers are useful even in cases of numbered links e.g. some
telemetry applications prefer to use link identifiers to identify all
links (numbered and unnumbered). 

So I share Acee's expectations. 

Les 

FROM: OSPF [mailto:[email-masked]] ON BEHALF OF Acee Lindem
(acee)
SENT: Saturday, May 06, 2017 10:04 AM
TO: prz
CC: OSPF WG
List
SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for
Local Interface ID Advertisement"   

Hi Tony,   

I'll have to discuss
with the authors - but my impression is that this would not be limited
to unnumbered links. My understanding is that the repurposing of
link-local OSPF TE LSAs is only done on unnumbered links so that would
be the main focus of the backward compatibility discussion.   

Thanks, 

Acee  

FROM: prz 
DATE: Saturday, May 6, 2017 at 12:58 PM
TO: Acee
Lindem 
CC: OSPF WG List 
SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF
LLS Extensions for Local Interface ID Advertisement"  

Hey Acee,  

1.
looking fwd to read the revision with backwards compatibility section
and definition which Hello FSM states the extension applies to 

2. I
try to read what you say carefully but please clarify: there's nothing
in rfc5613 that prevents LLC on any link so do you mean, you suggest to
use this TLV on unnumbered links _only_? Or do you suggest that RFC3630
implies somehow that LS TE LSAs are used on unnumbered links _only_? If
so, I don't see anything in the RFC to this effect ...  

--- tony  

On
Fri, 5 May 2017 15:14:30 +0000, "Acee Lindem (acee)"  wrote:  

Hi Tony,

The authors will cover this in the next revision. Based on
discussions, the usage of link-scoped TE LSAs is limited to unnumbered
point-to-point links. If this is the case, the backward compatibility is
much simpler than the other discussions we've been having.   

Thanks, 

Acee   

FROM: prz 
DATE: Friday, May 5, 2017 at 11:09 AM
TO: Acee
Lindem 
CC: OSPF WG List 
SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF
LLS Extensions for Local Interface ID Advertisement"   

Not sure it
made it from my other address so rtx to the list ...  

A conditional
against here ...  

I am fine with adoption if I see a version that
spells the detailed behavior and especially interactions between RFC4302
and this draft in a detailed section, i.e. both on, RFC4302 gets
configured/unconfigured, are the LLS extensions advertised on every
hello or just until a specific state (like ISIS padding thingies) and so
on ...   

The
idea is deceptively simple but it is a redundant mechanism and those
always end causing inter-op problems unless cleanly spelled out ...  

--- tony   

Links:
------
[1] mailto:[email-masked]
[2]
mailto:[email-masked]
[3] mailto:[email-masked]
[4]
mailto:[email-masked]
[5] mailto:[email-masked]
[6]
mailto:[email-masked]
[7] mailto:[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 May 2017 00:13:21 +0000

From: prz <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 7, 2017 at 3:47 PM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

1. It seems you both saying that RFC3630 is expected now to be used on unnumbered only (for which I find no indication) or are you claiming it's only used that way? Based on which implementation or document? What is "repurposing"? RFC3630 is a published Standards track RFC and I don't know what "re-purposing" standards RFCs means?

RFC 3630 is specific to OSPF TE Opaque LSAs and what I’m saying is that for this specific usage for interface ID discovery, the repurposing the TE LSAs is limited to unnumbered interfaces. For the second time, can you confirm???

2. Or are you saying that the new draft will be restricted to unnumbered only? In which case I expect a new version of draft to discuss further and agree taht the backwards compat section colllapses to "unnumbered link" considerations only  ...

Absolutely not – the draft that is under WG consideration is for general purpose discovery of interface IDs. I believe this point is clear if you read the draft.

Thanks,
Acee

?

--- tony

On Sat, 6 May 2017 18:15:21 +0000, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>> wrote:
Tony –

   Les

Hi Tony,

Thanks,
Acee

Hey Acee,

--- tony

---

From: prz <[email-masked]>
Date: Sun, 07 May 2017 21:01:33 -0700

OK, intention clear.  

What baffles me: can you specify where the
idea of "repurposing" existing, implemented and deployed standards RFC
comes from? And what does that look like in practice? You intend to
publish an errata? And how will we deal with deployed gear that uses
RFC3630 on all interfaces? And how will traffic engineering metrics be
obtained on interfaces if RFC3630 is "repurposed" to some type of
interfaces only? 

Or do you expect RFC3630 being advertised without the
sub-TLV 2 now on some kind of interfaces while still using all the
others sub-TLVs after being "repurposed" and all the tooling rewritten
to look for the suggested draft while being backwards compatible without
having an indication what is actually implemented on the combination of
both routers on both sides of an interface?  

Any hack works for a
super special deployment case but that seems to be suggest an
orthogonal, clean standard. Really?  

--- tony  

On Mon, 8 May 2017
00:13:21 +0000, "Acee Lindem (acee)"  wrote:  

From: prz 
Date: Sunday,
May 7, 2017 at 3:47 PM
To: "Les Ginsberg (ginsberg)" 
Cc: Acee Lindem ,
OSPF WG List 
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS
Extensions for Local Interface ID Advertisement" 

I try to parse that
and am still not clear what you both are saying 

1. It seems you both
saying that RFC3630 is expected now to be used on unnumbered only (for
which I find no indication) or are you claiming it's only used that way?
Based on which implementation or document? What is "repurposing"?
RFC3630 is a published Standards track RFC and I don't know what
"re-purposing" standards RFCs means?      
RFC 3630 is specific to OSPF
TE Opaque LSAs and what I'm saying is that for this specific usage for
interface ID discovery, the repurposing the TE LSAs is limited to
unnumbered interfaces. For the second time, can you confirm???  

2. Or
are you saying that the new draft will be restricted to unnumbered only?
In which case I expect a new version of draft to discuss further and
agree taht the backwards compat section colllapses to "unnumbered link"
considerations only ...      
Absolutely not - the draft that is under
WG consideration is for general purpose discovery of interface IDs. I
believe this point is clear if you read the draft.  

Thanks, 
Acee  

?

--- tony  

On Sat, 6 May 2017 18:15:21 +0000, "Les Ginsberg
(ginsberg)"  wrote:  

Tony - 

It is known that link identifiers are
useful even in cases of numbered links e.g. some telemetry applications
prefer to use link identifiers to identify all links (numbered and
unnumbered). 

 Les 

FROM: OSPF
[mailto:[email-masked] [6]] ON BEHALF OF Acee Lindem (acee)
SENT:
Saturday, May 06, 2017 10:04 AM
TO: prz
CC: OSPF WG List
SUBJECT: Re:
[OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID
Advertisement"   

Hi Tony,   

I'll have to discuss with the authors -
but my impression is that this would not be limited to unnumbered links.
My understanding is that the repurposing of link-local OSPF TE LSAs is
only done on unnumbered links so that would be the main focus of the
backward compatibility discussion.   

Thanks,  

Acee  

FROM: prz

TO: Acee Lindem 

Hey Acee,  

1. looking fwd to read
the revision with backwards compatibility section and definition which
Hello FSM states the extension applies to 

2. I try to read what you
say carefully but please clarify: there's nothing in rfc5613 that
prevents LLC on any link so do you mean, you suggest to use this TLV on
unnumbered links _only_? Or do you suggest that RFC3630 implies somehow
that LS TE LSAs are used on unnumbered links _only_? If so, I don't see
anything in the RFC to this effect ...  

--- tony  

On Fri, 5 May 2017
15:14:30 +0000, "Acee Lindem (acee)"  wrote:  

Hi Tony,   

The authors
will cover this in the next revision. Based on discussions, the usage of
link-scoped TE LSAs is limited to unnumbered point-to-point links. If
this is the case, the backward compatibility is much simpler than the
other discussions we've been having.   

Thanks,  

Acee   

FROM: prz

TO: Acee Lindem 
CC: OSPF WG List

SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local
Interface ID Advertisement"   

Not sure it made it from my other
address so rtx to the list ...  

I am
fine with adoption if I see a version that spells the detailed behavior
and especially interactions between RFC4302 and this draft in a detailed
section, i.e. both on, RFC4302 gets configured/unconfigured, are the LLS
extensions advertised on every hello or just until a specific state
(like ISIS padding thingies) and so on ...   

I'd rather have this now
than a LC discussion ...   

The idea is deceptively simple but it is a
redundant mechanism and those always end causing inter-op problems
unless cleanly spelled out ...   

--- tony   

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]
[3]
mailto:[email-masked]
[4] mailto:[email-masked]
[5]
mailto:[email-masked]
[6] mailto:[email-masked]
[7]
mailto:[email-masked]
[8] mailto:[email-masked]
[9]
mailto:[email-masked]
[10] mailto:[email-masked]
[11]
mailto:[email-masked]
[12] mailto:[email-masked]
[13]
mailto:[email-masked]

---

From: prz <[email-masked]>
Date: Sun, 07 May 2017 21:16:50 -0700

Having thought a bit about it a possible idea is to think whether the
suggested TLV 18 would try to take precedence over sub-TLV 2 in TLV on
RFC3630.  

That has another interesting problem. 3630 does not talk
about scope of the opaque in normative language (Shraddha suggested it's
link local but it looks like she was talking about 4203 in fact) but
3630 allures in Introduction that it's type 10 (area scope) talking
about "flooding rules" which would make the "preference" idea null and
void.  

So IMO we have a really interesting backwards section here with
deployed 4203 and 3630 backwards compatibility considerations.  

---
tony 

On Sun, 07 May 2017 21:01:33 -0700, prz  wrote:  

OK, intention
clear.  

What baffles me: can you specify where the idea of
"repurposing" existing, implemented and deployed standards RFC comes
from? And what does that look like in practice? You intend to publish an
errata? And how will we deal with deployed gear that uses RFC3630 on all
interfaces? And how will traffic engineering metrics be obtained on
interfaces if RFC3630 is "repurposed" to some type of interfaces only?

Or do you expect RFC3630 being advertised without the sub-TLV 2 now on
some kind of interfaces while still using all the others sub-TLVs after
being "repurposed" and all the tooling rewritten to look for the
suggested draft while being backwards compatible without having an
indication what is actually implemented on the combination of both
routers on both sides of an interface?  

Any hack works for a super
special deployment case but that seems to be suggest an orthogonal,
clean standard. Really?  

--- tony  

On Mon, 8 May 2017 00:13:21
+0000, "Acee Lindem (acee)" wrote:  
From: prz 
Date: Sunday, May 7,
2017 at 3:47 PM
To: "Les Ginsberg (ginsberg)" 
Cc: Acee Lindem , OSPF WG
List 
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for
Local Interface ID Advertisement"  

I try to parse that and am still
not clear what you both are saying 

1. It seems you both saying that
RFC3630 is expected now to be used on unnumbered only (for which I find
no indication) or are you claiming it's only used that way? Based on
which implementation or document? What is "repurposing"? RFC3630 is a
published Standards track RFC and I don't know what "re-purposing"
standards RFCs means?      
RFC 3630 is specific to OSPF TE Opaque LSAs
and what I'm saying is that for this specific usage for interface ID
discovery, the repurposing the TE LSAs is limited to unnumbered
interfaces. For the second time, can you confirm???    

2. Or are you
saying that the new draft will be restricted to unnumbered only? In
which case I expect a new version of draft to discuss further and agree
taht the backwards compat section colllapses to "unnumbered link"
considerations only ...      
Absolutely not - the draft that is under
WG consideration is for general purpose discovery of interface IDs. I
believe this point is clear if you read the draft.  
Thanks, 
Acee   

? 

--- tony  

Tony - 

 Les 

FROM: OSPF

Hi Tony,   

Thanks,  

Acee  

FROM: prz

Hey Acee,  

1. looking fwd to read

--- tony  

On Fri, 5 May 2017

Hi Tony,   

The authors

Thanks,  

Acee   

FROM: prz

I am

I'd rather have this now
than a LC discussion ...   

--- tony   

Links:
------
[1]
mailto:[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 May 2017 14:19:06 +0000

From: prz <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 8, 2017 at 12:16 AM
To: prz <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Having thought a bit about it a possible idea is to think whether the suggested TLV 18 would try to take precedence over sub-TLV 2 in TLV on RFC3630.

That has another interesting problem. 3630 does not talk about scope of the opaque in normative language (Shraddha suggested it's link local but it looks like she was talking about 4203 in fact) but 3630 allures in Introduction that it's type 10 (area scope) talking about "flooding rules" which would make the "preference" idea null and void.

So IMO we have a really interesting backwards section here with deployed 4203 and 3630 backwards compatibility considerations.

The application we are talking about here is neighbor interface ID discovery and what Shraddha has, in fact, suggested is link-local flooding scope. Many see usage of TE Opaque LSAs for non-TE purposes as repurposing while one implementation sees it as a deployed standard. I think we have discussed to the point of impasse and further discussion is circular and would only impede WG progress. The OSPF LLS Interface ID draft will address backward compatibility.

Thanks,
Acee

--- tony

On Sun, 07 May 2017 21:01:33 -0700, prz <[email-masked]<mailto:[email-masked]>> wrote:

OK, intention clear.

What baffles me: can you specify where the idea of "repurposing" existing, implemented and deployed standards RFC comes from? And what does that look like in practice? You intend to publish an errata? And how will we deal with deployed gear that uses RFC3630 on all interfaces? And how will traffic engineering metrics be obtained on interfaces if RFC3630 is "repurposed" to some type of interfaces only?

Or do you expect RFC3630 being advertised without the sub-TLV 2 now on some kind of interfaces while still using all the others sub-TLVs after being "repurposed" and all the tooling rewritten to look for the suggested draft while being backwards compatible without having an indication what is actually implemented on the combination of both routers on both sides of an interface?

Any hack works for a super special deployment case but that seems to be suggest an orthogonal, clean standard. Really?

--- tony

On Mon, 8 May 2017 00:13:21 +0000, "Acee Lindem (acee)" wrote:

?

--- tony

   Les

Hi Tony,

Thanks,
Acee

Hey Acee,

--- tony

---

From: prz <[email-masked]>
Date: Mon, 08 May 2017 07:57:15 -0700

Acee, ack. Looking forward to the backwards compatibility section &
document version.  

We have here NOT a "one implementation considers"
problem. We have a problem of standards track published documents that
are either unclear or have been deployed as intended and now suggestions
of more documents that have a good chance to contradict the published
standards or make impossible to adhere to all published standards. I
don't have to point out that the word "standard" looses any meaning in
such a case without proper consideration sections, errata or proper
"updates" or "obsoletes" track procedures ...  

thanks  

--- tony 

On Mon, 8 May 2017 14:19:06 +0000, "Acee Lindem (acee)"  wrote: 

From: prz 
Date: Monday, May 8, 2017 at 12:16 AM
To: prz 
Cc: Acee
Lindem , OSPF WG List 
Subject: Re: [OSPF] WG Adoption Poll for "OSPF
LLS Extensions for Local Interface ID Advertisement" 

Having thought a
bit about it a possible idea is to think whether the suggested TLV 18
would try to take precedence over sub-TLV 2 in TLV on RFC3630.  

That
has another interesting problem. 3630 does not talk about scope of the
opaque in normative language (Shraddha suggested it's link local but it
looks like she was talking about 4203 in fact) but 3630 allures in
Introduction that it's type 10 (area scope) talking about "flooding
rules" which would make the "preference" idea null and void.  

So IMO
we have a really interesting backwards section here with deployed 4203
and 3630 backwards compatibility considerations.      
The application
we are talking about here is neighbor interface ID discovery and what
Shraddha has, in fact, suggested is link-local flooding scope. Many see
usage of TE Opaque LSAs for non-TE purposes as repurposing while one
implementation sees it as a deployed standard. I think we have discussed
to the point of impasse and further discussion is circular and would
only impede WG progress. The OSPF LLS Interface ID draft will address
backward compatibility.  

Thanks, 
Acee 

--- tony 

On Sun, 07 May
2017 21:01:33 -0700, prz  wrote:  

OK, intention clear.  

What baffles
me: can you specify where the idea of "repurposing" existing,
implemented and deployed standards RFC comes from? And what does that
look like in practice? You intend to publish an errata? And how will we
deal with deployed gear that uses RFC3630 on all interfaces? And how
will traffic engineering metrics be obtained on interfaces if RFC3630 is
"repurposed" to some type of interfaces only? 

Or do you expect RFC3630
being advertised without the sub-TLV 2 now on some kind of interfaces
while still using all the others sub-TLVs after being "repurposed" and
all the tooling rewritten to look for the suggested draft while being
backwards compatible without having an indication what is actually
implemented on the combination of both routers on both sides of an
interface?  

Any hack works for a super special deployment case but
that seems to be suggest an orthogonal, clean standard. Really?  

---
tony  

From: prz 
Date: Sunday, May 7, 2017 at 3:47 PM
To: "Les Ginsberg
(ginsberg)" 
Cc: Acee Lindem , OSPF WG List 
Subject: Re: [OSPF] WG
Adoption Poll for "OSPF LLS Extensions for Local Interface ID
Advertisement"  

I try to parse that and am still not clear what you
both are saying 

1. It seems you both saying that RFC3630 is expected
now to be used on unnumbered only (for which I find no indication) or
are you claiming it's only used that way? Based on which implementation
or document? What is "repurposing"? RFC3630 is a published Standards
track RFC and I don't know what "re-purposing" standards RFCs means?    

RFC 3630 is specific to OSPF TE Opaque LSAs and what I'm saying is
that for this specific usage for interface ID discovery, the repurposing
the TE LSAs is limited to unnumbered interfaces. For the second time,
can you confirm???    

2. Or are you saying that the new draft will be
restricted to unnumbered only? In which case I expect a new version of
draft to discuss further and agree taht the backwards compat section
colllapses to "unnumbered link" considerations only ...      
Absolutely
not - the draft that is under WG consideration is for general purpose
discovery of interface IDs. I believe this point is clear if you read
the draft.  
Thanks, 
Acee    

? 

--- tony  

On Sat, 6 May 2017
18:15:21 +0000, "Les Ginsberg (ginsberg)"  wrote:  

Tony - 

It is
known that link identifiers are useful even in cases of numbered links
e.g. some telemetry applications prefer to use link identifiers to
identify all links (numbered and unnumbered). 

So I share Acee's
expectations. 

 Les 

FROM: OSPF [mailto:[email-masked] [11]] ON
BEHALF OF Acee Lindem (acee)
SENT: Saturday, May 06, 2017 10:04 AM
TO:
prz
CC: OSPF WG List
SUBJECT: Re: [OSPF] WG Adoption Poll for "OSPF LLS
Extensions for Local Interface ID Advertisement"   

Hi Tony,   

I'll
have to discuss with the authors - but my impression is that this would
not be limited to unnumbered links. My understanding is that the
repurposing of link-local OSPF TE LSAs is only done on unnumbered links
so that would be the main focus of the backward compatibility
discussion.   

Thanks,  

Acee  

FROM: prz 
DATE: Saturday, May 6,
2017 at 12:58 PM
TO: Acee Lindem 
CC: OSPF WG List 
SUBJECT: Re: [OSPF]
WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID
Advertisement"  

Hey Acee,  

1. looking fwd to read the revision with
backwards compatibility section and definition which Hello FSM states
the extension applies to 

--- tony  

Hi Tony,   

The authors will cover this in
the next revision. Based on discussions, the usage of link-scoped TE
LSAs is limited to unnumbered point-to-point links. If this is the case,
the backward compatibility is much simpler than the other discussions
we've been having.   

Thanks,  

Acee   

FROM: prz 
DATE: Friday, May
5, 2017 at 11:09 AM
TO: Acee Lindem 
CC: OSPF WG List 
SUBJECT: Re:

Not sure it made it from my other address so rtx to
the list ...  

I am fine with
adoption if I see a version that spells the detailed behavior and
especially interactions between RFC4302 and this draft in a detailed
section, i.e. both on, RFC4302 gets configured/unconfigured, are the LLS
extensions advertised on every hello or just until a specific state
(like ISIS padding thingies) and so on ...   

I'd rather have this now
than a LC discussion ...   

--- tony   

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]
[3]
mailto:[email-masked]
[4] mailto:[email-masked]
[5]
mailto:[email-masked]
[6] mailto:[email-masked]
[7]
mailto:[email-masked]
[8] mailto:[email-masked]
[9]
mailto:[email-masked]
[10] mailto:[email-masked]
[11]
mailto:[email-masked]
[12] mailto:[email-masked]
[13]
mailto:[email-masked]
[14] mailto:[email-masked]
[15]
mailto:[email-masked]
[16] mailto:[email-masked]
[17]
mailto:[email-masked]
[18] mailto:[email-masked]

---

From: Peter Psenak <[email-masked]>
Date: Tue, 09 May 2017 12:54:08 +0200

Hi Tony,

let me try to clarify.

1. This draft does not change, nor does it conflict with RFC3630 in any way.

2. This draft does not change anything in RFC4203 either. It provides an 
alternative and more generic way to exchange Link Local Identifier on 
the interface. Your are right that in our draft we need to specify the 
behavior in case the mechanism described in RFC4203 AND the new 
mechanism specified in our draft are both active at the same time. We 
will add a new section in a next version that covers this part. I don't 
believe it will be too difficult, given that the value of the Link Local 
Identifier is the same same in both cases, the only difference is the 
the mechanism how it is advertised.

Hopes this helps and moves us forward.

thanks,
Peter

On 08/05/17 06:01 , prz wrote:
> OK, intention clear.
>
> What baffles me: can you specify where the idea of "repurposing"
> existing, implemented and deployed standards RFC comes from? And what
> does that look like in practice? You intend to publish an errata? And
> how will we deal with deployed gear that uses RFC3630 on all interfaces?
> And how will traffic engineering metrics be obtained on interfaces if
> RFC3630 is "repurposed" to some type of interfaces only?
>
> Any hack works for a super special deployment case but that seems to be
> suggest an orthogonal, clean standard. Really?
>
> --- tony
>
> On Mon, 8 May 2017 00:13:21 +0000, "Acee Lindem (acee)" <[email-masked]>
> wrote:
>
>> From: prz <[email-masked] <mailto:[email-masked]>>
>> Cc: Acee Lindem <[email-masked] <mailto:[email-masked]>>, OSPF WG List
>> <[email-masked] <mailto:[email-masked]>>
>>     1. It seems you both saying that RFC3630 is expected now to be
>>     used on unnumbered only (for which I find no indication) or are
>>     you claiming it's only used that way? Based on which
>>     implementation or document? What is "repurposing"? RFC3630 is a
>> RFC 3630 is specific to OSPF TE Opaque LSAs and what I’m saying is
>> that for this specific usage for interface ID discovery, the
>> repurposing the TE LSAs is limited to unnumbered interfaces. For the
>> second time, can you confirm???
>>
>>     2. Or are you saying that the new draft will be restricted to
>>     unnumbered only? In which case I expect a new version of draft to
>>     discuss further and agree taht the backwards compat section
>> Absolutely not – the draft that is under WG consideration is for
>> general purpose discovery of interface IDs. I believe this point is
>> clear if you read the draft.
>> Thanks,
>> Acee
>>
>>     ?
>>
>>     --- tony
>>
>>     On Sat, 6 May 2017 18:15:21 +0000, "Les Ginsberg (ginsberg)"
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Tony –
>>
>>         It is known that link identifiers are useful even in cases of
>>         numbered links e.g. some telemetry applications prefer to use
>>         link identifiers to identify all links (numbered and unnumbered).
>>
>>         *From:*OSPF [mailto:[email-masked]] *On Behalf Of *Acee
>>         Lindem (acee)
>>         *Sent:* Saturday, May 06, 2017 10:04 AM
>>         *To:* prz
>>         *Cc:* OSPF WG List
>>         *Subject:* Re: [OSPF] WG Adoption Poll for "OSPF LLS
>>         I’ll have to discuss with the authors - but my impression is
>>         that this would not be limited to unnumbered links.  My
>>         understanding is that the repurposing of link–local OSPF TE
>>         LSAs is only done on unnumbered links so that would be the
>>         main focus of the backward compatibility discussion.
>>
>>         Thanks,
>>
>>         Acee
>>
>>         *From: *prz <[email-masked] <mailto:[email-masked]>>
>>         *Date: *Saturday, May 6, 2017 at 12:58 PM
>>         *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>
>>         *Cc: *OSPF WG List <[email-masked] <mailto:[email-masked]>>
>>         *Subject: *Re: [OSPF] WG Adoption Poll for "OSPF LLS
>>             compatibility section and definition which Hello FSM
>>             states the extension applies to
>>
>>             2. I try to read what you say carefully but please
>>             clarify: there's nothing in rfc5613 that prevents LLC on
>>             any link so do you mean, you suggest  to use this TLV on
>>             unnumbered links _only_?  Or do you suggest that RFC3630
>>             implies somehow that LS TE LSAs are used on unnumbered
>>             links _only_? If so, I don't see anything in the RFC to
>>             this effect ...
>>
>>             --- tony
>>
>>             On Fri, 5 May 2017 15:14:30 +0000, "Acee Lindem (acee)"
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 Hi Tony,
>>
>>                 The authors will cover this in the next revision.
>>                 Based on discussions, the usage of link-scoped TE LSAs
>>                 is limited to unnumbered point-to-point links. If this
>>                 is the case, the backward compatibility is much
>>                 simpler than the other discussions we’ve been having.
>>
>>                 Thanks,
>>
>>                 Acee
>>
>>                 *From: *prz <[email-masked] <mailto:[email-masked]>>
>>                 *Date: *Friday, May 5, 2017 at 11:09 AM
>>                 *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>
>>                 *Cc: *OSPF WG List <[email-masked] <mailto:[email-masked]>>
>>                 *Subject: *Re: [OSPF] WG Adoption Poll for "OSPF LLS
>>                     spells the detailed behavior and especially
>>                     interactions between RFC4302 and this draft in a
>>                     detailed section, i.e. both on, RFC4302 gets
>>                     configured/unconfigured, are the LLS extensions
>>                     advertised on every hello or just until a specific
>>                     state (like ISIS padding thingies) and so on ...
>>
>>                     redundant mechanism and those always end causing
>>                     inter-op problems unless cleanly spelled out ...
>>
>>                     --- tony
>>
>
>

---

From: prz <[email-masked]>
Date: Wed, 10 May 2017 08:57:09 -0700

> 1. This draft does not change, nor does it conflict with RFC3630 in 

 Peter, my bad, I got confused forgetting that the Link ID in 3630 is a
 different beast from the 4203 link ID. Thanks for pointing that out.

>
> 2. This draft does not change anything in RFC4203 either. It provides
> an alternative and more generic way to exchange Link Local Identifier
> on the interface. Your are right that in our draft we need to specify
> the behavior in case the mechanism described in RFC4203 AND the new
> will add a new section in a next version that covers this part. I
> don't believe it will be too difficult, given that the value of the
> Link Local Identifier is the same same in both cases, the only
> difference is the the mechanism how it is advertised.
>

 Discussion ongoing ... Your question about 4203 deployment is valid and
 needs answers and yes, we need a backward compatibility section 
 explaining

 a) @ which OSPF hello states the new signaling is supposed to be 
 present
 b) what happens if the value ever changes (tear down adjacency?) or 
 whether
    it's a violation
 c) what happens if flooded 4203 values (on LSAs) contradict signaling
    (e.g. you're holding to the flooded LSA with "old" value) while
    neighbor LLS'es a new value
 d) what happens if both signaling types show up on the link

 Per earlier mails, clarification WHEN the new signaling is supposed to 
 be used
 would be also helpful. 4203 Link ID signaling seems to be used only in
 case of unnumbered.

 So, overall I think we agree on scope of the problem that needs to be
 addressed so we get a coherent set of standards out

 thanks

 --- tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 May 2017 10:55:51 +0200

Hi Tony,

please see inline:

On 10/05/17 17:57 , prz wrote:
> On Tue, 09 May 2017 12:54:08 +0200, Peter Psenak <[email-masked]> wrote:
>> Hi Tony,
>>
>> let me try to clarify.
>>
> needs answers and yes, we need a backward compatibility section explaining
>
> a) @ which OSPF hello states the new signaling is supposed to be present

all hellos, will clarify that in the draft

> b) what happens if the value ever changes (tear down adjacency?) or whether
>     it's a violation

no need to tear down the adjacency. Just update anything that uses the 
link ID.

>     neighbor LLS'es a new value

we must set some preference, e.g. LLS value is always preferred.

> d) what happens if both signaling types show up on the link

if they are signaling the same value, there is no problem. If values are 
different, we prefer LLS.

> would be also helpful. 4203 Link ID signaling seems to be used only in

any link, will clarify that in the draft.

> addressed so we get a coherent set of standards out

so would you agree to make this a WG document?

thanks,
Peter

> .

---

From: prz <[email-masked]>
Date: Thu, 11 May 2017 09:37:18 -0700

<lots of "yes, needed and will be done" ... cut out :->

> so would you agree to make this a WG document?

 Hey Peter,

 yes, given the backward compat section addresses all the issues and the 
 signaling states/transitions are properly
 written down as you indicated I see how the idea has merit to be taken 
 on. I do see some holes in what you suggest
 as behavior but that can be discussed through/ironed out.

 And yes, from all I gathered so far there seems to be some unnumbered 
 4203 around and needs to be paid attention to.

 --- tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 11 May 2017 19:00:57 +0200

Hi Tony,

> as behavior but that can be discussed through/ironed out.

right.

> 4203 around and needs to be paid attention to.

agree.

thanks,
Peter