Re: [OSPF] draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

[Les Ginsberg (ginsberg)]

Mahendra -

What is advertised depends on what is configured (right or wrong). We do not 
"overwrite" config based on detected conflicts - the misconfiguration has to be 
addressed by the network operator.

   Les


From: Mahendra Singh Negi [mailto:mahendrasi...@huawei.com]
Sent: Friday, February 23, 2018 1:03 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: draft-ietf-spring-conflict-resolution 
<draft-ietf-spring-conflict-resolut...@ietf.org>; 
draft-ietf-ospf-segment-routing-extensions 
<draft-ietf-ospf-segment-routing-extensi...@ietf.org>; ospf <ospf@ietf.org>
Subject: Re: RE: 
draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions:
 If you please provide your inputs on the issue.

Dear Les,

Abrs RT1 and RT2 advertise SID 1 in area a1 10.10.10.10 SID:1 inter-area.

Now in RT1 change the configuration to SID:4.

RT1 assumes that SID:1 being originated by RT2 as SID:1 (inter-area is not yet 
deleted), hence Prefix conflict resolution is triggerred and SID:1 wins.

RT1 advertise 10.10.10.10 SID:1 in area a1 and 10.10.10.10 SID:4 in area a0.
In general I understand it like this : each node resolves the conflict, 
downloads wining SID for forwarding but advertises locally configured SID. I 
think advertisement should not depend on conflict-resolution, If you please 
clarify on this basic point.
Agreed, issue will not persist, its a transient one.

Regards,
Mahendra
From:Les Ginsberg (ginsberg)
To:Mahendra Singh 
Negi,draft-ietf-spring-conflict-resolut...@ietf.org,draft-ietf-ospf-segment-routing-extensi...@ietf.org
Cc:ospf@ietf.org
Date:2018-02-23 23:08:17
Subject:RE: 
draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions:
 If you please provide your inputs on the issue.

Mahendra -

Similar to Peter, I don't fully understand your scenario.

You claim:

10.10.10.10/SID 1 is originated by RT1
10.10.10.10/SID 3 os originated by RT3

Now you change SID config on RT1 so it advertises:
10.10.10.10/SID 4

In a short period of time RT2 should also reflect this update.

So the statement "SID:1 is forever in LSDB" makes no sense to me.

Certainly there is a transient period during which databases may have different 
combinations of (1,3) or (4,3) or even (1,3,4) but this will not persist.

   Les


From: Mahendra Singh Negi [mailto:mahendrasi...@huawei.com]
Sent: Thursday, February 22, 2018 8:49 PM
To: 
draft-ietf-spring-conflict-resolut...@ietf.org<mailto:draft-ietf-spring-conflict-resolut...@ietf.org>;
 
draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>
Subject: RE: 
draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions:
 If you please provide your inputs on the issue.

Dear Authors,

Amidst implementing conflict resolution for OSPF SR ( 
https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05) we came 
across this issue.


Topology:
[cid:image001.png@01D3ACA7.574A2830]

Issue:



1.   Prefix conflict occurs at RT1 and RT2.

2.   Both RT1 and RT2 resolve the conflict and download corresponding Label 
for SID:1 (SID:1 wins conflict resolution).

3.   Both RT1 and RT2 advertise inter-area Extended Prefix Opaque LSA for 
prefix 10.10.10.10 in area a1 with SID:1.

Reference: 
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-7.2

&

https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-5

  (If an OSPF router advertises multiple Prefix-SIDs for the same prefix, 
topology and algorithm, all of them MUST be ignored.)



4.   Now at RT1, user changes the  SID configuration value to 4, and still 
SID 1 wins the conflict resolution as in area a1 RT2 has not flushed or updated 
SID:1, and SID:1 is forever in LSDB.

How to fix the issue?

a)   think ABRs should advertise all the SIDs to leaking areas and MUST 
condition mentioned highlighted in yellow above be relaxed (i.e. update 
inter-area segment routing section accordingly) and let each node run 
conflict-resolution.

b)   On SID configuration change, RT1 Flushes the SID:1 and waits for SID:1 
flushing out from the LSDB and then originates with new SID:4.(How long to wait 
is decided locally).


I prefer (a), if you please provide your opinion on this. We are under 
development, highly appreciate prompt  responses.



Regards,
Mahendra

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

[Les Ginsberg (ginsberg)]

Mahendra -

Similar to Peter, I don't fully understand your scenario.

You claim:

10.10.10.10/SID 1 is originated by RT1
10.10.10.10/SID 3 os originated by RT3

Now you change SID config on RT1 so it advertises:
10.10.10.10/SID 4

In a short period of time RT2 should also reflect this update.

So the statement "SID:1 is forever in LSDB" makes no sense to me.

Certainly there is a transient period during which databases may have different 
combinations of (1,3) or (4,3) or even (1,3,4) but this will not persist.

   Les


From: Mahendra Singh Negi [mailto:mahendrasi...@huawei.com]
Sent: Thursday, February 22, 2018 8:49 PM
To: draft-ietf-spring-conflict-resolut...@ietf.org; 
draft-ietf-ospf-segment-routing-extensi...@ietf.org
Cc: ospf@ietf.org
Subject: RE: 
draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions:
 If you please provide your inputs on the issue.

Dear Authors,

Amidst implementing conflict resolution for OSPF SR ( 
https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05) we came 
across this issue.


Topology:
[cid:image001.png@01D3AC89.CC75DE10]

Issue:



1.   Prefix conflict occurs at RT1 and RT2.

2.   Both RT1 and RT2 resolve the conflict and download corresponding Label 
for SID:1 (SID:1 wins conflict resolution).

3.   Both RT1 and RT2 advertise inter-area Extended Prefix Opaque LSA for 
prefix 10.10.10.10 in area a1 with SID:1.

Reference: 
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-7.2

&

https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-5

  (If an OSPF router advertises multiple Prefix-SIDs for the same prefix, 
topology and algorithm, all of them MUST be ignored.)



4.   Now at RT1, user changes the  SID configuration value to 4, and still 
SID 1 wins the conflict resolution as in area a1 RT2 has not flushed or updated 
SID:1, and SID:1 is forever in LSDB.

How to fix the issue?

a)   think ABRs should advertise all the SIDs to leaking areas and MUST 
condition mentioned highlighted in yellow above be relaxed (i.e. update 
inter-area segment routing section accordingly) and let each node run 
conflict-resolution.

b)   On SID configuration change, RT1 Flushes the SID:1 and waits for SID:1 
flushing out from the LSDB and then originates with new SID:4.(How long to wait 
is decided locally).


I prefer (a), if you please provide your opinion on this. We are under 
development, highly appreciate prompt  responses.



Regards,
Mahendra

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [Isis-wg] Link-State Routing WG charter

[Les Ginsberg (ginsberg)]

Stewart –

Supporting BGP-LS is a feature implementation issue – not a protocol issue 
i.e., we do not define extensions to the IGPs specifically so that BGP-LS can 
be supported.
If your focus is only on how IGP advertisements get mapped into BGP-LS 
advertisements we can end this thread and simply say that your choice of words 
was confusing.

But as you are suggesting there is something that needs to go into the charter 
about this, there is a clear implication that you think there is IGP protocol 
extension work here. If so, I am raising a red flag and saying I don’t want 
such a statement in the charter.

   Les


From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, January 25, 2018 11:25 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Alia Atlas <akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org>; isis...@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter




On 25/01/2018 18:59, Les Ginsberg (ginsberg) wrote:
Stewart -

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, January 25, 2018 4:32 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com><mailto:ginsb...@cisco.com>; 
Acee Lindem (acee) <a...@cisco.com><mailto:a...@cisco.com>; Alia Atlas 
<akat...@gmail.com><mailto:akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org><mailto:ospf@ietf.org>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter




Les

I agree wrt L2

Isn't another focus collecting the information to feed into an SDN controller 
via BGP-LS? That is really network layer  state collection rather than routing 
in the traditional sense.



[Les:] Please do not propose such language. This raises the old discussion 
about using the IGPs as a transport for “just about anything”.

We long ago agreed that TE related information was “routing information” – if 
for no other reason than it was grandfathered in. But this does not alter the 
IGP’s focus on routing.

I know we “stretch” the definition with things like MSD and S-BFD 
discriminators, but I see these as carefully considered choices – and ones w 
modest impact.

Institutionalizing the IGPs as an “SDN Distribution Protocol” is not something 
I want in the charter.

   Les



Hi Les,

I don't see it quite like that.

I don't think we flood a lot of the SDN specific information do we? We just use 
the LSP data structures as a convenient encoding, and supplement the 
information we flood with additional information.

If we were flooding it I would share your concern, but I don't see the reuse of 
the syntax which is what BGP-LS does as quite such a problem.

Am I missing something here?

- Stewart




- Stewart

On 24/01/2018 23:09, Les Ginsberg (ginsberg) wrote:
It occurred to me after sending this that perhaps a better statement as regards 
IS-IS would be:

“LSR’s work is focused on IP/IPv6 and Layer 2 routing…”

though admittedly there isn’t much going on as regards Layer2 and IS-IS at the 
moment.

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 24, 2018 2:33 PM
To: Stewart Bryant <stewart.bry...@gmail.com><mailto:stewart.bry...@gmail.com>; 
Acee Lindem (acee) <a...@cisco.com><mailto:a...@cisco.com>; Alia Atlas 
<akat...@gmail.com><mailto:akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org><mailto:ospf@ietf.org>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Since a charter only provides a general definition of the work that falls 
within the purview of the WG it requires some adjunct to keep track of the 
current priorities.
That could be the list of milestones (which OSPF has regularly maintained – but 
IS-IS has not) – or it could simply be the list of active WG documents.
I just don’t see that we should expect the charter to express “work in 
progress” now – or in the future.

Alia – do you think the statement about IS-IS:

“LSR’s work is focused on IP routing…”

Could be improved by saying

“LSR’s work is focused on IP/IPv6 routing…”

???

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 24, 2018 10:01 AM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: OSPF List <ospf@ietf.org<mailto:ospf@ietf.org>>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter


Yes that fixes that.

How about:

s/The following topics are expected to be an initial focus:/ In addition to 
ongoing maintenance, the following topics are expected to be an initial focus:/

I am just concerned that we need not to loose focus on work in progress.

- Stewart

On 24/01/2018 17:54, Acee Lindem (acee) wrote:
How abo

Re: [OSPF] [Isis-wg] Link-State Routing WG charter

[Les Ginsberg (ginsberg)]

Stewart -

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, January 25, 2018 4:32 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Alia Atlas <akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org>; isis...@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter




Les

I agree wrt L2

Isn't another focus collecting the information to feed into an SDN controller 
via BGP-LS? That is really network layer  state collection rather than routing 
in the traditional sense.



[Les:] Please do not propose such language. This raises the old discussion 
about using the IGPs as a transport for “just about anything”.

We long ago agreed that TE related information was “routing information” – if 
for no other reason than it was grandfathered in. But this does not alter the 
IGP’s focus on routing.

I know we “stretch” the definition with things like MSD and S-BFD 
discriminators, but I see these as carefully considered choices – and ones w 
modest impact.

Institutionalizing the IGPs as an “SDN Distribution Protocol” is not something 
I want in the charter.

   Les



- Stewart

On 24/01/2018 23:09, Les Ginsberg (ginsberg) wrote:
It occurred to me after sending this that perhaps a better statement as regards 
IS-IS would be:

“LSR’s work is focused on IP/IPv6 and Layer 2 routing…”

though admittedly there isn’t much going on as regards Layer2 and IS-IS at the 
moment.

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 24, 2018 2:33 PM
To: Stewart Bryant <stewart.bry...@gmail.com><mailto:stewart.bry...@gmail.com>; 
Acee Lindem (acee) <a...@cisco.com><mailto:a...@cisco.com>; Alia Atlas 
<akat...@gmail.com><mailto:akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org><mailto:ospf@ietf.org>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Since a charter only provides a general definition of the work that falls 
within the purview of the WG it requires some adjunct to keep track of the 
current priorities.
That could be the list of milestones (which OSPF has regularly maintained – but 
IS-IS has not) – or it could simply be the list of active WG documents.
I just don’t see that we should expect the charter to express “work in 
progress” now – or in the future.

Alia – do you think the statement about IS-IS:

“LSR’s work is focused on IP routing…”

Could be improved by saying

“LSR’s work is focused on IP/IPv6 routing…”

???

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 24, 2018 10:01 AM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: OSPF List <ospf@ietf.org<mailto:ospf@ietf.org>>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter


Yes that fixes that.

How about:

s/The following topics are expected to be an initial focus:/ In addition to 
ongoing maintenance, the following topics are expected to be an initial focus:/

I am just concerned that we need not to loose focus on work in progress.

- Stewart

On 24/01/2018 17:54, Acee Lindem (acee) wrote:
How about:

LSR will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as
applicable to LSV protocol operation and scale.

Thanks,
Acee

From: Isis-wg <isis-wg-boun...@ietf.org><mailto:isis-wg-boun...@ietf.org> on 
behalf of Alia Atlas <akat...@gmail.com><mailto:akat...@gmail.com>
Date: Wednesday, January 24, 2018 at 12:42 PM
To: Stewart Bryant <stewart.bry...@gmail.com><mailto:stewart.bry...@gmail.com>
Cc: OSPF WG List <ospf@ietf.org><mailto:ospf@ietf.org>, 
"isis...@ietf.org"<mailto:isis...@ietf.org> 
<isis...@ietf.org><mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Stewart,

Thanks for the quick feedback.  Feel free to provide suggestions for text 
changes if you have them.
You've certainly written enough charters :-)

Regards,
Alia

On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant 
<stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> wrote:

Alia,
I think that this merger is long overdue, and hopefully it will help new 
features to be written in an aligned way.

I think the remit to perform general maintenance should slightly clarified 
since the way the charter is written they look like they are at a lower 
priority than the enumerated list.

I would have thought that "LSR can coordinate with CCAMP and BIER on their 
extensions " should have been more directive.

- Stewart

On 24/01/2018 17:18, Alia Atlas wrote:
Here is the proposed charter for the LSR working group
that will be created from the SPF and ISIS working groups.

This is sc

Re: [OSPF] [Isis-wg] Link-State Routing WG charter

[Les Ginsberg (ginsberg)]

Alia –

Looks fine to me – thanx. I like the fact that the charter now more clearly 
allows work which we have yet to anticipate.
If the staunch IPv6 advocates don’t give you grief for overloading “IP” to mean 
“IP/IPv6” you won’t get any from me. ☺

   Les


From: Alia Atlas [mailto:akat...@gmail.com]
Sent: Wednesday, January 24, 2018 4:13 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Stewart Bryant <stewart.bry...@gmail.com>; Acee Lindem (acee) 
<a...@cisco.com>; OSPF List <ospf@ietf.org>; isis...@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Les,

Thanks for the suggestions!  I've modified the paragraph about IS-IS to read:

"IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and 
additional RFC standards with extensions to support IP that has been deployed 
in the Internet for decades.  For the IS-IS protocol, LSR-WG’s work is focused 
on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. 
The LSR-WG will interact with other standards bodies that have responsible for 
standardizing IS-IS. LSR-WG will continue to support Layer 2 routing (for 
example TRILL work) as needed."

and updated to "In addition to ongoing maintenance, the following topics are 
expected to be among the work-items at the time of chartering." to clarify that 
the list isn't constrictive.

I didn't go for IP/IPv6 since IP should cover both IPv4 & IPv6.

The updated version (with Stewart's comments addressed as well) can be found as 
charter-ietf-lsf-00-04 at:

https://datatracker.ietf.org/doc/charter-ietf-lsr/

Regards,
Alia

On Wed, Jan 24, 2018 at 6:09 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
It occurred to me after sending this that perhaps a better statement as regards 
IS-IS would be:

“LSR’s work is focused on IP/IPv6 and Layer 2 routing…”

though admittedly there isn’t much going on as regards Layer2 and IS-IS at the 
moment.

   Les


From: Isis-wg 
[mailto:isis-wg-boun...@ietf.org<mailto:isis-wg-boun...@ietf.org>] On Behalf Of 
Les Ginsberg (ginsberg)
Sent: Wednesday, January 24, 2018 2:33 PM
To: Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>; 
Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>

Cc: OSPF List <ospf@ietf.org<mailto:ospf@ietf.org>>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Since a charter only provides a general definition of the work that falls 
within the purview of the WG it requires some adjunct to keep track of the 
current priorities.
That could be the list of milestones (which OSPF has regularly maintained – but 
IS-IS has not) – or it could simply be the list of active WG documents.
I just don’t see that we should expect the charter to express “work in 
progress” now – or in the future.

Alia – do you think the statement about IS-IS:

“LSR’s work is focused on IP routing…”

Could be improved by saying

“LSR’s work is focused on IP/IPv6 routing…”

???

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 24, 2018 10:01 AM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: OSPF List <ospf@ietf.org<mailto:ospf@ietf.org>>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter


Yes that fixes that.

How about:

s/The following topics are expected to be an initial focus:/ In addition to 
ongoing maintenance, the following topics are expected to be an initial focus:/

I am just concerned that we need not to loose focus on work in progress.

- Stewart

On 24/01/2018 17:54, Acee Lindem (acee) wrote:
How about:

LSR will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as
applicable to LSV protocol operation and scale.

Thanks,
Acee

From: Isis-wg <isis-wg-boun...@ietf.org><mailto:isis-wg-boun...@ietf.org> on 
behalf of Alia Atlas <akat...@gmail.com><mailto:akat...@gmail.com>
Date: Wednesday, January 24, 2018 at 12:42 PM
To: Stewart Bryant <stewart.bry...@gmail.com><mailto:stewart.bry...@gmail.com>
Cc: OSPF WG List <ospf@ietf.org><mailto:ospf@ietf.org>, 
"isis...@ietf.org"<mailto:isis...@ietf.org> 
<isis...@ietf.org><mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Stewart,

Thanks for the quick feedback.  Feel free to provide suggestions for text 
changes if you have them.
You've certainly written enough charters :-)

Regards,
Alia

On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant 
<stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> wrote:

Alia,
I think that t

Re: [OSPF] [Isis-wg] Link-State Routing WG charter

[Les Ginsberg (ginsberg)]

It occurred to me after sending this that perhaps a better statement as regards 
IS-IS would be:

“LSR’s work is focused on IP/IPv6 and Layer 2 routing…”

though admittedly there isn’t much going on as regards Layer2 and IS-IS at the 
moment.

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 24, 2018 2:33 PM
To: Stewart Bryant <stewart.bry...@gmail.com>; Acee Lindem (acee) 
<a...@cisco.com>; Alia Atlas <akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org>; isis...@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter

Since a charter only provides a general definition of the work that falls 
within the purview of the WG it requires some adjunct to keep track of the 
current priorities.
That could be the list of milestones (which OSPF has regularly maintained – but 
IS-IS has not) – or it could simply be the list of active WG documents.
I just don’t see that we should expect the charter to express “work in 
progress” now – or in the future.

Alia – do you think the statement about IS-IS:

“LSR’s work is focused on IP routing…”

Could be improved by saying

“LSR’s work is focused on IP/IPv6 routing…”

???

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 24, 2018 10:01 AM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: OSPF List <ospf@ietf.org<mailto:ospf@ietf.org>>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter


Yes that fixes that.

How about:

s/The following topics are expected to be an initial focus:/ In addition to 
ongoing maintenance, the following topics are expected to be an initial focus:/

I am just concerned that we need not to loose focus on work in progress.

- Stewart

On 24/01/2018 17:54, Acee Lindem (acee) wrote:
How about:

LSR will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as
applicable to LSV protocol operation and scale.

Thanks,
Acee

From: Isis-wg <isis-wg-boun...@ietf.org><mailto:isis-wg-boun...@ietf.org> on 
behalf of Alia Atlas <akat...@gmail.com><mailto:akat...@gmail.com>
Date: Wednesday, January 24, 2018 at 12:42 PM
To: Stewart Bryant <stewart.bry...@gmail.com><mailto:stewart.bry...@gmail.com>
Cc: OSPF WG List <ospf@ietf.org><mailto:ospf@ietf.org>, 
"isis...@ietf.org"<mailto:isis...@ietf.org> 
<isis...@ietf.org><mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Stewart,

Thanks for the quick feedback.  Feel free to provide suggestions for text 
changes if you have them.
You've certainly written enough charters :-)

Regards,
Alia

On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant 
<stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> wrote:

Alia,
I think that this merger is long overdue, and hopefully it will help new 
features to be written in an aligned way.

I think the remit to perform general maintenance should slightly clarified 
since the way the charter is written they look like they are at a lower 
priority than the enumerated list.

I would have thought that "LSR can coordinate with CCAMP and BIER on their 
extensions " should have been more directive.

- Stewart

On 24/01/2018 17:18, Alia Atlas wrote:
Here is the proposed charter for the LSR working group
that will be created from the SPF and ISIS working groups.

This is scheduled for internal review for the IESG telechat on February 8.

https://datatracker.ietf.org/doc/charter-ietf-lsr/

The Link-State Routing (LSR) Working Group is chartered to document current 
protocol implementation practices and improvements, protocol usage scenarios, 
maintenance and extensions of link-state routing interior gateway protocols 
(IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3.  The LSR Working Group is 
formed by merging the isis and ospf WGs and will take on all their existing 
adopted work at the time of chartering.

IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and 
additional RFC standards with extensions to support IP that has been deployed 
in the Internet for decades.  For the IS-IS protocol, LSR’s work is focused on 
IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The 
LSR WG will interact with other standards bodies that have responsible for 
standardizing IS-IS.

OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the 
Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 
and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949].

The LSR Working Group will generally manage its specific work items by 
milestones agreed with the responsible Area Director.

The following topics are expected to be an initial focus:

1) Improvin

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Les Ginsberg (ginsberg)]

I think the point here is that the link is not necessarily going to be shutdown 
in all cases.

For example, the operator needs to do some testing of the link. They set 
max-metric to divert traffic, then keep the link up so they can send OAM 
traffic over the link and try to determine what problems may exist.

It is a mistake to assume that this mechanism is always intended to be used as 
a precursor to link shutdown.

   Les


From: Acee Lindem (acee)
Sent: Friday, January 05, 2018 8:47 AM
To: Shraddha Hegde <shrad...@juniper.net>; Les Ginsberg (ginsberg) 
<ginsb...@cisco.com>; Ketan Talaulikar (ketant) <ket...@cisco.com>; Joel 
Halpern <j...@joelhalpern.com>; gen-...@ietf.org
Cc: ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

Works for me.
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Friday, January 5, 2018 at 11:15 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg 
(ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "Ketan Talaulikar 
(ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

How about “graceful-link-shutdown” ?

Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel 
Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload....@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Joel Halpern 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload....@ietf.org>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mai

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Les Ginsberg (ginsberg)]

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <a...@cisco.com>; Les Ginsberg (ginsberg) 
<ginsb...@cisco.com>; Joel Halpern <j...@joelhalpern.com>; gen-...@ietf.org
Cc: ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 05 January 2018 08:14
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11


> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.

That is not the use case - you are going to take the link down. It is not going 
to be the "link of last resort”, it is the currently the “link of last resort” 
and will imminently be taken down.




The suggestion from Shraddha that this term was borrowed from IS-IS isn't 
accurate. "overload" in IS-IS has a very different meaning - it indicates a 
node either has an incomplete LSDB or (a la RFC 
3277<https://datatracker.ietf.org/doc/rfc3277/> )an incomplete forwarding plane.



The only use of "link overload" in IS-IS occurs in 
https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and 
this was added recently to support the (very useful) TE use case which was 
defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When 
this was done the term "link-overload" was cut and pasted from the OSPF draft. 
I think this should also be changed in the IS-IS draft.

Agreed.

Thanks,
Acee



   Les



> Thanks,

> Acee

> >

> >

> >

>

> ___

> OSPF mailing list

> OSPF@ietf.org<mailto:OSPF@ietf.org>

> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Les Ginsberg (ginsberg)]

Acee -

From: Acee Lindem (acee)
Sent: Thursday, January 04, 2018 6:44 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Joel Halpern 
<j...@joelhalpern.com>; gen-...@ietf.org
Cc: ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11


> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.

That is not the use case - you are going to take the link down. It is not going 
to be the "link of last resort”, it is the currently the “link of last resort” 
and will imminently be taken down.
[Les:] https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11#section-2


2.  Motivation

…
   4.  Allow the link to be used as last resort link to prevent traffic
   disruption when alternate paths are not available.


This is the real value of the protocol extension. If the intention was to take 
the link out of service the extension would not be worth much as the behavioral 
difference between (normal metric->max metric->down) vs (normal metric->down) 
is very small.
This is also consistent with my recollection of the service providers 
motivation when the early versions of isis-reverse-metric were presented. The 
question was asked “why don’t you simply take the link down?” and the response 
was “We don’t want to take the link down – we want it to be the link of last 
resort so that if all else fails we can still use the link to get to the node.”

(As an aside, if the idea was to more gracefully redirect traffic away from the 
link in preparation for taking the link down you would need to use a metric 
offset as the isis-reverse-metric draft does. Then you could direct traffic 
away from the link in incremental steps. I don’t mean to suggest this will be a 
common use case of reverse-metric – but it would at least be useful if the 
intent was to take the link down in a short while).

   Les




The suggestion from Shraddha that this term was borrowed from IS-IS isn't 
accurate. "overload" in IS-IS has a very different meaning - it indicates a 
node either has an incomplete LSDB or (a la RFC 
3277<https://datatracker.ietf.org/doc/rfc3277/> )an incomplete forwarding plane.



The only use of "link overload" in IS-IS occurs in 
https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and 
this was added recently to support the (very useful) TE use case which was 
defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When 
this was done the term "link-overload" was cut and pasted from the OSPF draft. 
I think this should also be changed in the IS-IS draft.

Agreed.

Thanks,
Acee



   Les



> Thanks,

> Acee

> >

> >

> >

>

> ___

> OSPF mailing list

> OSPF@ietf.org<mailto:OSPF@ietf.org>

> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Les Ginsberg (ginsberg)]

> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.



The suggestion from Shraddha that this term was borrowed from IS-IS isn't 
accurate. "overload" in IS-IS has a very different meaning - it indicates a 
node either has an incomplete LSDB or (a la RFC 
3277 )an incomplete forwarding plane.



The only use of "link overload" in IS-IS occurs in 
https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and 
this was added recently to support the (very useful) TE use case which was 
defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When 
this was done the term "link-overload" was cut and pasted from the OSPF draft. 
I think this should also be changed in the IS-IS draft.



   Les



> Thanks,

> Acee

> >

> >

> >

>

> ___

> OSPF mailing list

> OSPF@ietf.org

> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [Isis-wg] Comments on draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-app-01.txt

[Les Ginsberg (ginsberg)]

Olivier –

I think we are going in a circle a bit i.e., you seem to be asking the same 
questions that I have already tried to answer – so not sure how successful my 
second attempt will be – but I will give it a try.

As an aside, I think it would probably be helpful to provide some examples of 
how to use the extensions defined in the draft. Section 7 of the draft 
discusses this – but it may well be helpful to provide some more detailed 
examples.  We will work on adding that to the next revision.

As background context, the draft supports sharing a single set of link 
attribute advertisements among many applications and it supports having 
multiple sets of link attribute advertisements for a given link, each set 
associated with one or more applications. Which mode you use depends on the use 
cases you have in your network. Please keep in mind that this is a choice – not 
a mandate to move to multiple set of link attribute advertisements.

As regards different attribute values for different applications on a given 
link, we do understand that this increases complexity. If you do not have a use 
case for doing this in your network then you should advertise one and only one 
value for a given attribute on a link. However, there are networks where the 
operator wants to manage bandwidth on a per application basis. We did not 
invent this use case – it has been requested. In such a case the requirement is 
to be able to advertise per application values. Clearly, when doing so, the 
management task becomes more complex. But this is a choice the operator makes 
based on the use case.

As regards the two “special parameters”, we have tried to be explicit in the 
draft as to the reasons for special treatment.

Section 4.2.1: “Maximum link bandwidth is an application independent attribute 
of the  link.”
This attribute simply advertises the physical capacity of the link – which does 
not change based on the number/type of applications which may be using that 
link. We have therefore specified that only one value may be advertised/link. 
As an aid to transition cases, the same value MAY be advertised in multiple 
sub-TLVs for a given link, but the values MUST be identical.

Section 4.2.2: “Unreserved bandwidth is an attribute specific to RSVP.”
It is therefore illegal to advertise that parameter associated with an 
application other than RSVP-TE.
This can be accomplished by using a legacy advertisement or by using the new 
sub-TLV. In the latter case only the RSVP-TE bit can be set.

   Les



From: olivier.dug...@orange.com [mailto:olivier.dug...@orange.com]
Sent: Wednesday, November 29, 2017 10:28 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] [OSPF] Comments on 
draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-app-01.txt


Hello Les,

Thanks to take into account our use cases.

I carefully read the new version of the draft. If now it is clear that Maximum 
and Unreserved Bandwidth Link parameters are announced as unique value (which 
solve partially the issue I raised), it is unclear for me in which Sub-TLVs 
group there are announced: standard TE TLVs or the new proposed TLV's ? If 
there are not announced in the same TLVs set, these will drastically increase 
the complexity for a router that runs both SR-TE and RSVP-TE. If there are 
announced in the same TLVs set, I don't understand the objective of the draft.

But, looking again carefully to the draft, now, I don't understand why these 
two specifics Bandwidth Link parameters have a special treatment while other 
Bandwidth parameters not. I means, all extended bandwidth metrics must be also 
uniquely announce to avoid any mis-interpretation during bandwidth reservation. 
In particular for these extended metrics which come from measurement, why 
duplicate them, one per application ? Same for the Maximum Reservable Bandwidth.

Finally, I still do not understand why these new parameters are announced per 
Application. All these parameters are belonging to the Link Attributes, not to 
a particular application. Looking to the argument of the draft, I agree that TE 
link parameters where design specifically for RSVP-TE and enhance time after 
time which, at the end, give a non-optimal, perhaps not coherent global 
picture, especially for OSPF. So, if the goal is to re-order and clean Link 
Attributes, I think that the way to go is not correctly expose in the draft. I 
would prefer a new encoding schema within the new OSPF Opaque LSA Extended Link 
Attributes and a clear migration scenario to help operators move from the old 
encoding schema to the new one. For ISIS, it is safer as Link Attributes are 
convey into a more coherent TLVs and don't need to be change.

Regards

Olivier

Le 14/11/2017 à 18:16, Les Ginsberg (ginsberg) a écrit :

Olivier -



https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-03 was published a 
sho

Re: [OSPF] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

[Les Ginsberg (ginsberg)]

In regards to

> > 4. Section 3.3:
> >
> > 'The originating router MUST NOT advertise overlapping ranges.'
> >
> > How are conflicts resolved at receiver?
> 
> SRLB sub-TLV is not used by routers running ISIS. The advertisement is only
> there for the benefit of external entities such as controllers so they can
> determine what labels are available for assignment. We do not define
> controllers behavior in our drafts.
> 
> >
[Les:] SRLB usage is not the same as SRGB usage.

SRLB is a local space for each node to allocate node private labels. There is 
no notion of conflicting usage e.g. Node A can use 1000 as an adj-sid for one 
of its links and Node B can use SID 1000 as an adj-sid for one of its links and 
this is not a conflict. In other words the scope of the SIDs is local to the 
advertising node.

Further, nodes are NOT required to validate that a private SID (such as an 
adj-sid) is allocated from the SRLB of the advertising node - it is legal to 
assign a SID from outside of this space - so - as Peter has indicated - other 
routers do not make use of SRLB advertisements. IT is there for the convenience 
of external entities only.

It should be obvious that advertising overlapping ranges makes the 
advertisement ambiguous. Not sure what else needs to be said.

???

Les



___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] draft-ietf-ospf-ospfv3-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Acee -

OSPF draft currently says:

"The G-Flag: Group Flag.  When set, the G-Flag indicates that
 the Adj-SID refers to a group of adjacencies (and therefore MAY
 be assigned to other adjacencies as well)."

IS-IS draft currently says:

"S-Flag.  Set flag.  When set, the S-Flag indicates that the
 Adj-SID refers to a set of adjacencies (and therefore MAY be
 assigned to other adjacencies as well)."

I do not see the terms "link-group" or "link-set" in either draft and I don’t 
see how they would apply to "adjacencies".
So exactly what is the issue and what is the proposed change?

If the concern is about the name "G-flag" vs "S-flag"  - I find this much ado 
about very little. (Sorry...)

Les


> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
> (acee)
> Sent: Monday, October 02, 2017 11:46 AM
> To: Goethals, Dirk (Nokia - BE/Antwerp) 
> Cc: OSPF WG List 
> Subject: Re: [OSPF] draft-ietf-ospf-ospfv3-segment-routing-extensions
> 
> Hi Dirk,
> 
> I agree we should use the same term but we have finished WG last call and
> AD review for the OSPFv2 Segment Routing extensions. Additionally,
> everyone is familiar with the term link-group. A link-set would be new
> terminology. Let’s fix the IS-IS draft.
> 
> Thanks,
> Acee
> >
> >
> >
> > Original Message 
> >Subject: draft-ietf-ospf-ospfv3-segment-routing-extensions
> >Resent-Date: Wed, 13 Sep 2017 06:26:45 -0700
> >Resent-From: 
> >Resent-To:   , ,
> >, , ,
> >, 
> >Date:Wed, 13 Sep 2017 15:26:47 +0200
> >From:Dirk Goethals 
> >To:  ,
> >,
> >"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
> >
> >
> >
> >
> >Hi authors,
> >
> >OSPF's G-flag and ISIS's S-flag are both representing adjacency sets,
> >see snip below, can we align these definitions and simply call it
> >S-Flag in both IGPs.
> >
> >Thx,
> >Dirk
> >
> >OSPFv2 and OSPFv3:
> >
> >   The G-Flag.  Group Flag.  When set, the G-Flag indicates that
> >   the Adj-SID refers to a set of adjacencies (and therefore MAY
> >   be assigned to other adjacencies as well).
> >
> >
> >
> >ISIS:
> >
> >   S-Flag.  Set flag.  When set, the S-Flag indicates that the
> >   Adj-SID refers to a set of adjacencies (and therefore MAY be
> >   assigned to other adjacencies as well).
> >
> >.
> >
> >
> 
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

[Les Ginsberg (ginsberg)]

Support as co-author.

   Les

> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Abhay Roy (akr)
> Sent: Monday, July 03, 2017 11:37 AM
> To: ospf@ietf.org
> Subject: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse
> 
> We would like to kick-off a poll for WG adoption of the following document
> (per Authors request):
> 
> https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse
> 
> Please let us know if you support or have concerns with OSPF WG adopting
> this work.
> 
> Regards,
> -Abhay
> 
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Les Ginsberg (ginsberg)]

Jeff -

Inline.

> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, June 20, 2017 7:17 AM
> To: Mahesh Jethanandani
> Cc: Jeffrey Haas; Reshad Rahman (rrahman); OSPF WG List; draft-ietf-ospf-
> y...@ietf.org; rtg-...@ietf.org; draft-ietf-bfd-y...@ietf.org; Acee Lindem
> (acee)
> Subject: Re: IETF OSPF YANG and BFD Configuration
> 
> Mahesh,
> 
> On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote:
> > > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas  wrote:
> > > Where we run into some issues are the cases highlighted: when the
> > > sessions don't share common properties, how should the protocol pick
> > > what BFD session to use?
> >
> > The issue that I hear most is the timer granularity. Is there something 
> > else?
> 
> Potentially mode (async vs. echo) and authentication.  However, I believe
> timer granularity is the biggest one.
> 
> > > The current BFD yang model only permits a single IP single-hop
> > > session to be configured.  (Key is interface/dst-ip)  This means
> > > that if different parameters *were* desired, the BFD model won't
> > > permit it today.  However, BFD sessions for many protocols tend not
> > > to be configured, but may spring forth from protocol state, such as
> > > IGP adjacencies.  Thus, it's not "configured" - it's solely
> > > operational state.  However, the BFD yang model doesn't really make
> good provision for that as an "on”.
> >
> > The idea is that a BFD session is configured a priori and before a IGP 
> > session
> is configured with the most aggressive timer. IGP sessions then refer to the
> BGP session configured. If a IGP session is added that requires a more
> aggressive timer, we would have to renegotiate the more aggressive timer
> value.
> 
> Consider a broadcast network segment such as Ethernet.
> Consider a few dozen routers on such a segment.
> 
> Is it your expectation that an IGP would require each of those routers to be
> manually configured in the Yang module a priori?  That is, after all, much of
> the point of an IGP: automatic discovery.
> 
> > > Where all endpoint state is known a priori, config state makes better
> sense.
> > >
> > > To pick the example of Juniper's configuration, if OSPF and eBGP
> > > were using BFD, both can choose differing timers.  This represents
> > > two pieces of configuration state for the same endpoints.
> > > Additionally, only one BFD session is formed using the most aggressive
> timers.
> >
> > That is what we are suggesting also.
> 
> The distinguishing point is configuration vs. operational state.  The current
> model doesn't permit more than one set of parameters to be provisioned
> even if the implementation may choose to instantiate exactly one session.
> 
> > > I partially point out the situation of multiple timers since there
> > > have been prior list discussions on the situation where clients have
> > > different timing requirements.  I don't think we handle this
> > > operationally in the BFD protocol in the cleanest fashion right now
> > > - the session will go to Down when the aggressive timers fail and
> > > there's no clean way to renegotiate to the less aggressive timers.
> >
> > A BFD session would fail more likely because there is a real network failure
> than because the timer was more aggressive than what IGP had requested.
> 
> Please note that I raise this point mostly because of prior discussion.  I'm 
> well
> aware of the headaches this currently causes:
> 
> Different protocols have different survivability requirements.  An IGP may
> very well want sub-second timers, potentially for repair behaviors.  BGP may
> want fast failover, but may be fine with second level granularity.  This is
> particularly true since the cost of too aggressively flapping BGP is of
> significantly greater impact to the network and the router.
> 
[Les:] The real issues here are false failures and proper use of dampening. No 
protocol - not even an IGP - wants to flap unnecessarily. If timers are set so 
aggressively that false failures are reported this is BAD.
Even worse is failure to dampen so that we get multiple false failures in a 
short period of time.

Arguing that the right way to solve this problem is to increase the number of 
sessions using different timer granularity seems likely to make any problems 
worse as you have now increased the number of BFD sessions with the associated 
costs.

   Les

> But moving to what *is* rather than what should be, if there are two
> different timing setups for the same endpoint: If you deprovision the more
> aggressive timer, the session should likely renegotiate to the less aggressive
> one rather than drop.
> 
> -- Jeff

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] Fwd: Last Call: (Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

[Les Ginsberg (ginsberg)]

Acee –

Did you look at the Appendix – which has ASCII art for some example encodings?

   Les


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 11, 2017 11:58 AM
To: Alia Atlas; OSPF List; rt...@ietf.org; idr@ietf. org
Subject: Re: [OSPF] Fwd: Last Call:  
(Advertising L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Hi Alia,
I have reviewed the document and had several conversations with the authors. I 
believe the encodings are adaptable to the OSPF Segment Routing extensions. Of 
course, we’ll use a different identifier than System ID (Used to identify 
LAN-Adj-SID neighors). One comment I have is that it would be nice to have 
ASCII art graphically depicting the format of the new Sub-TLVs.

Thanks,
Acee

From: OSPF > on behalf of 
Alia Atlas >
Date: Wednesday, May 3, 2017 at 2:30 PM
To: OSPF WG List >, Routing WG 
>, IDR List 
>
Subject: [OSPF] Fwd: Last Call:  (Advertising 
L2 Bundle Member Link Attributes in IS-IS) to Proposed Standard

Dear RTGWG, OSPF WG & IDR WG,

I'd like to bring this IETF Last Call to your attention.  The method for 
advertising
L2 bundle information via IS-IS described in this draft may be of interest for 
other
protocols (OSPF,  BGP-LS) that may use it as precedent for how to advertise
such information if there is need in the future and consistency is desired at 
that point.

Regards,
Alia


-- Forwarded message --
From: The IESG >
Date: Wed, May 3, 2017 at 1:52 PM
Subject: Last Call:  (Advertising L2 Bundle 
Member Link Attributes in IS-IS) to Proposed Standard
To: IETF-Announce >
Cc: han...@gredler.at, 
isis-cha...@ietf.org, 
isis...@ietf.org, 
draft-ietf-isis-l2bund...@ietf.org, 
akat...@gmail.com



The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'Advertising L2 Bundle Member Link Attributes 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 comments to the
i...@ietf.org mailing lists by 2017-05-17. Exceptionally, 
comments may be
sent to i...@ietf.org instead. In either case, please 
retain the
beginning of the Subject line to allow automated sorting.

Abstract


   There are deployments where the Layer 3 interface on which IS-IS
   operates is a Layer 2 interface bundle.  Existing IS-IS
   advertisements only support advertising link attributes of the Layer
   3 interface.  If entities external to IS-IS wish to control traffic
   flows on the individual physical links which comprise the Layer 2
   interface bundle link attribute information about the bundle members
   is required.

   This document introduces the ability for IS-IS to advertise the link
   attributes of layer 2 (L2) bundle members.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2793/





___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

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

[Les Ginsberg (ginsberg)]

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:ospf-boun...@ietf.org] 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:

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 >
Date: Thursday, May 4, 2017 at 2:45 PM
To: OSPF WG List >
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
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

[Les Ginsberg (ginsberg)]

Acee -

From: Acee Lindem (acee)
Sent: Thursday, May 04, 2017 8:20 AM
To: Les Ginsberg (ginsberg); Alexander Vainshtein
Cc: alex.zi...@alcatel-lucent.com; isis...@ietf.org; db3...@att.com; 
cho...@chopps.org; RFC Errata System; OSPF WG List
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, May 4, 2017 at 11:07 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Cc: "alex.zi...@alcatel-lucent.com<mailto:alex.zi...@alcatel-lucent.com>" 
<alex.zi...@alcatel-lucent.com<mailto:alex.zi...@alcatel-lucent.com>>, 
"isis...@ietf.org<mailto:isis...@ietf.org>" 
<isis...@ietf.org<mailto:isis...@ietf.org>>, Deborah Brungard 
<db3...@att.com<mailto:db3...@att.com>>, Christian Hopps 
<cho...@chopps.org<mailto:cho...@chopps.org>>, RFC Errata System 
<rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Acee –

Any ARP issues which might occur for numbered interfaces where neighbors do not 
have matching subnets will occur independent of P2P mode. I therefore see no 
reason why RFC 5309 should address this issue.

You may not be aware that subnet checking on numbered P2P links (which is 
enforced by many router implementations) is not standard. In fact, BSD 
implementations (which were very popular in the pre-Linux era), model a P2P 
link as simply a connection between two endpoints as opposed to a subnet.

[Les:] I am well aware. I am also aware that even on LANs some implementations 
enforce matching subnet checking and some don’t. Please read the previously 
mention RFC 3787 Section 10.


If you feel this needs to be addressed (I don’t – but YMMV) then I think errata 
should be against RFC 2328.

This statement in RFC 5309 is respect to ARP – not OSPF. After several decades, 
we’re certainly not going to change OSPF to enforce subnet checking on P2P 
links.

[Les:] I never suggested that (and I don’t think Sasha did either). The errata  
is suggesting the following new text:

“For the ARP implementation (which checks that the subnet of the source address 
of the ARP request matches the local interface address), this check needs to be 
relaxed for the p2p-over-lan circuits (both numbered and unnumbered).”

I am pointing out that this issue is not specific to P2P operation on a LAN.
Naiming has also pointed out that in P2P mode you are less likely to have 
problems because ARP will always respond to requests for the local address. If 
there is going to be a problem it is more likely to occur in multi-access mode 
when an ARP request for a non-local address might be received.

   Les




Note that in the case of IS-IS we have RFC 3787 Section 10 – which concludes by 
saying:

“…The  network administrator should ensure that there is a common IP subnet
   assigned to links with numbered interfaces, and that all routers on
   each link have a IP Interface Addresses belonging to the assigned
   subnet.”

OSPF supports both models of P2P link. OSPF has been widely deployed on hosts 
as well as routers. See this excerpt from RFC 2328 and note Option 1:


12.4.1.1.  Describing point-to-point interfaces



For point-to-point interfaces, one or more link

descriptions are added to the router-LSA as follows:



o   If the neighboring router is fully adjacent, add a

Type 1 link (point-to-point). The Link ID should be

set to the Router ID of the neighboring router. For

numbered point-to-point networks, the Link Data

should specify the IP interface address. For

unnumbered point-to-point networks, the Link Data

field should specify the interface's MIB-II [Ref8]

ifIndex value. The cost should be set to the output

cost of the point-to-point interface.



o   In addition, as long as the state of the interface

is "Point-to-Point" (and regardless of the

neighboring router state), a Type 3 link (stub

network) should be added. There are two forms that

this stub link can take:



Option 1

Assuming that the neighboring router's IP

address is known, set the Link ID of the Type 3

link to the neighbor's IP address, the Link Data

to the mask 0x (indicating a host

route

Re: [OSPF] [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

[Les Ginsberg (ginsberg)]

Acee –

Any ARP issues which might occur for numbered interfaces where neighbors do not 
have matching subnets will occur independent of P2P mode. I therefore see no 
reason why RFC 5309 should address this issue.

If you feel this needs to be addressed (I don’t – but YMMV) then I think errata 
should be against RFC 2328.

Note that in the case of IS-IS we have RFC 3787 Section 10 – which concludes by 
saying:

“…The  network administrator should ensure that there is a common IP subnet
   assigned to links with numbered interfaces, and that all routers on
   each link have a IP Interface Addresses belonging to the assigned
   subnet.”

   Les


From: Acee Lindem (acee)
Sent: Thursday, May 04, 2017 7:20 AM
To: Alexander Vainshtein; Les Ginsberg (ginsberg)
Cc: alex.zi...@alcatel-lucent.com; isis...@ietf.org; db3...@att.com; 
cho...@chopps.org; RFC Errata System; OSPF WG List
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

+ospf-wg list

While very implementation specific, P2P over LAN isn’t described anywhere other 
than RFC 5309. The point Sasha is making is that OSPF doesn’t enforce subnet 
match checking on P2P links (which is true) and the ARP must do the same. 
Hence, I would agree with the errata.

Original Text
-
For the ARP implementation (which checks that the subnet of the source address 
of the ARP request matches the local interface address), this check needs to be 
relaxed for the unnumbered p2p-over-lan circuits.

Corrected Text
--
For the ARP implementation (which checks that the subnet of the source address 
of the ARP request matches the local interface address), this check needs to be 
relaxed for the p2p-over-lan circuits (both numbered and unnumbered).

Let’s go forward with this and not spend any more time debating it.

Thanks,
Acee



From: Isis-wg <isis-wg-boun...@ietf.org<mailto:isis-wg-boun...@ietf.org>> on 
behalf of Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Date: Thursday, May 4, 2017 at 6:03 AM
To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: "alex.zi...@alcatel-lucent.com<mailto:alex.zi...@alcatel-lucent.com>" 
<alex.zi...@alcatel-lucent.com<mailto:alex.zi...@alcatel-lucent.com>>, 
"isis...@ietf.org<mailto:isis...@ietf.org>" 
<isis...@ietf.org<mailto:isis...@ietf.org>>, Deborah Brungard 
<db3...@att.com<mailto:db3...@att.com>>, Christian Hopps 
<cho...@chopps.org<mailto:cho...@chopps.org>>, RFC Errata System 
<rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>>
Subject: Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,
Lots of thanks for a detailed response. It seems that we are now in sync 
regarding the problem.

Doing nothing with this problem is of course one of the possible options☺.
I wonder how should we reach consensus regarding its handling.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, May 01, 2017 6:04 PM
To: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Cc: isis...@ietf.org<mailto:isis...@ietf.org>; RFC Errata System 
<rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>>; Naiming Shen 
(naiming) <naim...@cisco.com<mailto:naim...@cisco.com>>; 
alex.zi...@alcatel-lucent.com<mailto:alex.zi...@alcatel-lucent.com>; 
akat...@gmail.com<mailto:akat...@gmail.com>; 
db3...@att.com<mailto:db3...@att.com>; Alvaro Retana (aretana) 
<aret...@cisco.com<mailto:aret...@cisco.com>>; 
cho...@chopps.org<mailto:cho...@chopps.org>; 
han...@gredler.at<mailto:han...@gredler.at>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Sasha -

From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Monday, May 01, 2017 12:50 AM
To: Les Ginsberg (ginsberg)
Cc: isis...@ietf.org<mailto:isis...@ietf.org>; RFC Errata System; Naiming Shen 
(naiming); alex.zi...@alcatel-lucent.com<mailto:alex.zi...@alcatel-lucent.com>; 
akat...@gmail.com<mailto:akat...@gmail.com>; 
db3...@att.com<mailto:db3...@att.com>; Alvaro Retana (aretana); 
cho...@chopps.org<mailto:cho...@chopps.org>; 
han...@gredler.at<mailto:han...@gredler.at>
Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)

Les,
Lots of thanks for the clarification.
I fully agree with you that configuring a pair of interfaces across a P2P link 
with IP addresses from different subnets should not be encouraged even if these 
interfaces operate as P2P from the POV of the routing protocol.

[Les:] This is not what I said. I said:

“allowing an adjacency to be formed on 

[OSPF] FW: New Version Notification for draft-ginsberg-isis-te-app-00.txt

[Les Ginsberg (ginsberg)]

(resending due to some problems posting the message to IS-IS list - apologies 
for any redundancy)

Folks -

This new draft is the IS-IS functional equivalent of the OSPF Draft 
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/

The two drafts  represent what we believe is a better alternative to the 
solution proposed in:

https://datatracker.ietf.org/doc/draft-hegde-ospf-advertising-te-protocols/
https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-protocols/

I have included a previously sent but slightly updated slide which compares the 
two sets of solutions.

   Les


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, February 27, 2017 8:23 AM
To: Stefano Previdi (sprevidi); Wim Henderickx; Peter Psenak (ppsenak); Les 
Ginsberg (ginsberg)
Subject: New Version Notification for draft-ginsberg-isis-te-app-00.txt


A new version of I-D, draft-ginsberg-isis-te-app-00.txt has been successfully 
submitted by Les Ginsberg and posted to the IETF repository.

Name:   draft-ginsberg-isis-te-app
Revision:   00
Title:  IS-IS TE Attributes per application
Document date:  2017-02-27
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/internet-drafts/draft-ginsberg-isis-te-app-00.txt
Status: https://datatracker.ietf.org/doc/draft-ginsberg-isis-te-app/
Htmlized:   https://tools.ietf.org/html/draft-ginsberg-isis-te-app-00


Abstract:
   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  In cases
   where multiple applications wish to make use of these link attributes
   the current advertisements do not support application specific values
   for a given attribute nor do they support indication of which
   applications are using the advertised value for a given link.

   This draft introduces new link attribute advertisements which address
   both of these shortcomings.  It also discusses backwards
   compatibility issues and how to minimize duplicate advertisements in
   the presence of routers which do not support the extensions defined
   in this document.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



te_app.pptx
Description: te_app.pptx
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt

[Les Ginsberg (ginsberg)]

Alia -

From: Alia Atlas [mailto:akat...@gmail.com]
Sent: Wednesday, March 01, 2017 8:33 AM
To: Les Ginsberg (ginsberg)
Cc: OSPF List; isis...@ietf.org; rtgwg-cha...@ietf.org; rt...@ietf.org
Subject: RE: [Isis-wg] New Version Notification for 
draft-bryant-rtgwg-param-sync-01.txt


On Feb 28, 2017 10:55 PM, "Les Ginsberg (ginsberg)" 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Alia –

Thanx for reminding about the MRT drafts (and so quickly ☺). Both seem to have 
expired.

:-)   The base MRT drafts have been published as RFCs.  The MRT LDP extensions 
is past WGLC now.
The ISIS and OSPF MRT drafts have been waiting for the outcome of this 
discussion.

I don’t see the connection between extending the use cases for a convergence 
time advertisement beyond MRT and the need for encapsulating other unrelated 
parameters into a single container.

Right - it's not clear to me whether there is going to be a finding/use issue 
with the convergence time advertisement if published as part of the MRT drafts. 
 I am interested to see if there are additional parameters that would make 
sense to be in the single container.

[Les:] In the IANA registry there is ALWAYS a link to the defining 
specification for every codepoint.


http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242

There is no reason why we need worry about how to find the source for a 
definition.
However, if the convergence advertisement is seen as having more widespread 
use, then perhaps it is better to have a standalone draft for it.
Note that I have concerns about the convergence advertisement – but I would 
rather discuss that in a separate thread. Here we are discussing 
draft-bryant-rtgwg-param-sync-01 and the need for a generic "routing parameter 
synchronization protocol". Like to see us reach conclusion on that issue in 
this thread.

   Les

Regards,
Alia


   Les

From: Isis-wg 
[mailto:isis-wg-boun...@ietf.org<mailto:isis-wg-boun...@ietf.org>] On Behalf Of 
Alia Atlas
Sent: Tuesday, February 28, 2017 7:43 PM
To: Les Ginsberg (ginsberg)
Cc: isis...@ietf.org<mailto:isis...@ietf.org>; 
rtgwg-cha...@ietf.org<mailto:rtgwg-cha...@ietf.org>; 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>; 
ospf@ietf.org<mailto:ospf@ietf.org>; rt...@ietf.org<mailto:rt...@ietf.org>
Subject: Re: [Isis-wg] New Version Notification for 
draft-bryant-rtgwg-param-sync-01.txt

Hi Les,

I will note that the MRT ISIS and OSPF drafts include the extension for 
convergence time.
I believe this draft was motivated by a concern that those extensions would not 
be seen and
realized to be generally useful.

Regards,
Alia

On Tue, Feb 28, 2017 at 10:35 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Stewart -

This draft discusses two things:

1)You propose to advertise "convergence time" so that routers utilizing a form 
of FRR can determine when it is safe to start utilizing the post convergence 
path. All this requires is advertisement of a value and definition of how 
routers in the network should make use of this value - specifically use the 
maximum advertised value as the lower bound for how long a repair path should 
continue to be used.

This proposal deserves to be discussed on its own merits - something I will NOT 
do in this email.

2)Rather than simply define the new advertisement as (for example) a new 
sub-TLV in IS-IS Router Capability TLV, you have decided that there is "general 
class of problem" that needs to be addressed and so you have invented a 
"routing parameter synchronization protocol". This proposes to "encapsulate" 
the above parameter and some yet to be defined set of future parameters in a 
common container- suggesting we will have a large number of such parameters in 
the future and that they have some logical relationship.

I find this proposal unnecessary and undesirable. I do not see any value add to 
encapsulating multiple parameters which are otherwise unrelated in a common 
container simply because there may be some algorithm (unique to each parameter) 
which needs to be applied when making use of each parameter.

If your concern is consumption of sub-TLV codepoints in IS-IS, it is worth 
reviewing the current status. RFC 4971 which originally defined the Router 
Capability TLV was published in 2007. Over the nearly 10 years in which this 
has been available there have been 21 codepoints assigned. There are two or 
three more that I am aware of that are in the works, so in 10 years we will 
have consumed less than 10% of the available codepoints. I am quite comfortable 
with this rate of consumption.

If you believe there is about to be an explosion of code point requests I wish 
you would be more forthcoming as to what you expect as it would then be 
appropriate to consider whether this set of candidates is an

Re: [OSPF] [Isis-wg] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt

[Les Ginsberg (ginsberg)]

Alia –

Thanx for reminding about the MRT drafts (and so quickly ☺). Both seem to have 
expired.

I don’t see the connection between extending the use cases for a convergence 
time advertisement beyond MRT and the need for encapsulating other unrelated 
parameters into a single container.

   Les

From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Alia Atlas
Sent: Tuesday, February 28, 2017 7:43 PM
To: Les Ginsberg (ginsberg)
Cc: isis...@ietf.org; rtgwg-cha...@ietf.org; internet-dra...@ietf.org; 
ospf@ietf.org; rt...@ietf.org
Subject: Re: [Isis-wg] New Version Notification for 
draft-bryant-rtgwg-param-sync-01.txt

Hi Les,

I will note that the MRT ISIS and OSPF drafts include the extension for 
convergence time.
I believe this draft was motivated by a concern that those extensions would not 
be seen and
realized to be generally useful.

Regards,
Alia

On Tue, Feb 28, 2017 at 10:35 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Stewart -

This draft discusses two things:

1)You propose to advertise "convergence time" so that routers utilizing a form 
of FRR can determine when it is safe to start utilizing the post convergence 
path. All this requires is advertisement of a value and definition of how 
routers in the network should make use of this value - specifically use the 
maximum advertised value as the lower bound for how long a repair path should 
continue to be used.

This proposal deserves to be discussed on its own merits - something I will NOT 
do in this email.

2)Rather than simply define the new advertisement as (for example) a new 
sub-TLV in IS-IS Router Capability TLV, you have decided that there is "general 
class of problem" that needs to be addressed and so you have invented a 
"routing parameter synchronization protocol". This proposes to "encapsulate" 
the above parameter and some yet to be defined set of future parameters in a 
common container- suggesting we will have a large number of such parameters in 
the future and that they have some logical relationship.

I find this proposal unnecessary and undesirable. I do not see any value add to 
encapsulating multiple parameters which are otherwise unrelated in a common 
container simply because there may be some algorithm (unique to each parameter) 
which needs to be applied when making use of each parameter.

If your concern is consumption of sub-TLV codepoints in IS-IS, it is worth 
reviewing the current status. RFC 4971 which originally defined the Router 
Capability TLV was published in 2007. Over the nearly 10 years in which this 
has been available there have been 21 codepoints assigned. There are two or 
three more that I am aware of that are in the works, so in 10 years we will 
have consumed less than 10% of the available codepoints. I am quite comfortable 
with this rate of consumption.

If you believe there is about to be an explosion of code point requests I wish 
you would be more forthcoming as to what you expect as it would then be 
appropriate to consider whether this set of candidates is an appropriate use of 
the routing protocol and the Router Capability TLV.

My recommendation is to write a draft confined to the definition of the new 
convergence time parameter you wish to advertise and let us review that on its 
own merits.

   Les

> -Original Message-
> From: rtgwg [mailto:rtgwg-boun...@ietf.org<mailto:rtgwg-boun...@ietf.org>] On 
> Behalf Of Stewart Bryant
> Sent: Monday, February 27, 2017 9:23 AM
> To: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>; Chris Bowers; 
> Alia Atlas; rt...@ietf.org<mailto:rt...@ietf.org>; rtgwg-
> cha...@ietf.org<mailto:cha...@ietf.org>; 
> isis...@ietf.org<mailto:isis...@ietf.org>; ospf@ietf.org<mailto:ospf@ietf.org>
> Subject: Re: New Version Notification for draft-bryant-rtgwg-param-sync-
> 01.txt
>
> Resend with correct ISIS WG email address
>
> Following discussion at the last IETF, I have made a number of changes to the
> text to emphasis that this protocols is only to be used for the 
> synchronization
> of parameters needs by the routing system.
>
> As agreed at the RTGWG meeting I am notifying RTGWG, ISIS and OSPF WGs.
>
> The draft can be found here:
>
> URL:
> https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-sync-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/
> Htmlized:   https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bryant-rtgwg-param-sync-01
>
> The following is a summary of the changed:
>
> I have changed the title to:
>
> Synchronisation of Routing Parameters
>
> =
>
> I have added in the introduction:
>
> Note that this protocol is only intended to be used for th

Re: [OSPF] New Version Notification for draft-bryant-rtgwg-param-sync-01.txt

[Les Ginsberg (ginsberg)]

Stewart -

This draft discusses two things:

1)You propose to advertise "convergence time" so that routers utilizing a form 
of FRR can determine when it is safe to start utilizing the post convergence 
path. All this requires is advertisement of a value and definition of how 
routers in the network should make use of this value - specifically use the 
maximum advertised value as the lower bound for how long a repair path should 
continue to be used.

This proposal deserves to be discussed on its own merits - something I will NOT 
do in this email.

2)Rather than simply define the new advertisement as (for example) a new 
sub-TLV in IS-IS Router Capability TLV, you have decided that there is "general 
class of problem" that needs to be addressed and so you have invented a 
"routing parameter synchronization protocol". This proposes to "encapsulate" 
the above parameter and some yet to be defined set of future parameters in a 
common container- suggesting we will have a large number of such parameters in 
the future and that they have some logical relationship.

I find this proposal unnecessary and undesirable. I do not see any value add to 
encapsulating multiple parameters which are otherwise unrelated in a common 
container simply because there may be some algorithm (unique to each parameter) 
which needs to be applied when making use of each parameter. 

If your concern is consumption of sub-TLV codepoints in IS-IS, it is worth 
reviewing the current status. RFC 4971 which originally defined the Router 
Capability TLV was published in 2007. Over the nearly 10 years in which this 
has been available there have been 21 codepoints assigned. There are two or 
three more that I am aware of that are in the works, so in 10 years we will 
have consumed less than 10% of the available codepoints. I am quite comfortable 
with this rate of consumption.

If you believe there is about to be an explosion of code point requests I wish 
you would be more forthcoming as to what you expect as it would then be 
appropriate to consider whether this set of candidates is an appropriate use of 
the routing protocol and the Router Capability TLV.

My recommendation is to write a draft confined to the definition of the new 
convergence time parameter you wish to advertise and let us review that on its 
own merits. 

   Les

> -Original Message-
> From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Stewart Bryant
> Sent: Monday, February 27, 2017 9:23 AM
> To: internet-dra...@ietf.org; Chris Bowers; Alia Atlas; rt...@ietf.org; rtgwg-
> cha...@ietf.org; isis...@ietf.org; ospf@ietf.org
> Subject: Re: New Version Notification for draft-bryant-rtgwg-param-sync-
> 01.txt
> 
> Resend with correct ISIS WG email address
> 
> Following discussion at the last IETF, I have made a number of changes to the
> text to emphasis that this protocols is only to be used for the 
> synchronization
> of parameters needs by the routing system.
> 
> As agreed at the RTGWG meeting I am notifying RTGWG, ISIS and OSPF WGs.
> 
> The draft can be found here:
> 
> URL:
> https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-sync-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/
> Htmlized:   https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bryant-rtgwg-param-sync-01
> 
> The following is a summary of the changed:
> 
> I have changed the title to:
> 
> Synchronisation of Routing Parameters
> 
> =
> 
> I have added in the introduction:
> 
> Note that this protocol is only intended to be used for the propagation of
> parameters needed to support the operation of the routing system. It MUST
> NOT be used as a general purpose parameter exchange protocol, and in
> particular it MUST NOT be used as a parameter negotiation protocol, since
> such use may degrade the ability of the underlying link-state routing protocol
> to carry our its essential purpose.
> 
> 
> 
> I have changed the IANA text to say:
> 
> Synchronisation of Routing Parameters
> 
> 
> 
> I have added to the security section:
> 
> In specifying a new parameter, consideration must be given to the impact of
> the additional parameter, and in particular the rate of change of that
> parameter, on the dynamics of the link-state routing protocol in use. In the
> specific case of the Convergence Timer, the amount of data being carried and
> the rate of change of the parameter value will have a negligible impact on the
> link-state routing protocol in use.
> 
> =
> 
> Incorporated a number of review suggestions by Mohamed Boucadair (Mod)
> 
> Added
> 
> Such consistency may be ensured by deploying automated means such as
> enforcing the new value by invoking the management interface of all
> involved routers. For example, a central management entity may be
> responsible for communicating the new configuration value by means of
> vendor-specific CLI, NETCONF, 

[OSPF] FW: New Version Notification for draft-ginsberg-isis-te-app-00.txt

[Les Ginsberg (ginsberg)]

Folks -

This new draft is the IS-IS functional equivalent of the OSPF Draft 
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/

The two drafts  represent what we believe is a better alternative to the 
solution proposed in:

https://datatracker.ietf.org/doc/draft-hegde-ospf-advertising-te-protocols/
https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-protocols/

I have included a previously sent but slightly updated slide which compares the 
two sets of solutions.

   Les


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, February 27, 2017 8:23 AM
To: Stefano Previdi (sprevidi); Wim Henderickx; Peter Psenak (ppsenak); Les 
Ginsberg (ginsberg)
Subject: New Version Notification for draft-ginsberg-isis-te-app-00.txt


A new version of I-D, draft-ginsberg-isis-te-app-00.txt has been successfully 
submitted by Les Ginsberg and posted to the IETF repository.

Name:   draft-ginsberg-isis-te-app
Revision:   00
Title:  IS-IS TE Attributes per application
Document date:  2017-02-27
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/internet-drafts/draft-ginsberg-isis-te-app-00.txt
Status: https://datatracker.ietf.org/doc/draft-ginsberg-isis-te-app/
Htmlized:   https://tools.ietf.org/html/draft-ginsberg-isis-te-app-00


Abstract:
   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  In cases
   where multiple applications wish to make use of these link attributes
   the current advertisements do not support application specific values
   for a given attribute nor do they support indication of which
   applications are using the advertised value for a given link.

   This draft introduces new link attribute advertisements which address
   both of these shortcomings.  It also discusses backwards
   compatibility issues and how to minimize duplicate advertisements in
   the presence of routers which do not support the extensions defined
   in this document.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



te_app.pptx
Description: te_app.pptx
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [mpls] Working group last call on draft-ietf-mpls-residence-time

[Les Ginsberg (ginsberg)]

Greg –

This looks fine to me.
Thanx for all the quick revisions.

   Les


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Tuesday, January 31, 2017 7:19 PM
To: Uma Chunduri
Cc: Les Ginsberg (ginsberg); m...@ietf.org; isis-cha...@ietf.org; Isis-wg; 
draft-ietf-mpls-residence-t...@tools.ietf.org; TEAS WG Chairs; 
mpls-cha...@ietf.org; TEAS WG; ospf@ietf.org; ospf-cha...@ietf.org
Subject: Re: [mpls] [OSPF] Working group last call on 
draft-ietf-mpls-residence-time

Hi Uma, Acee, Les, et. al,
attached please find diff and the updated version. I think I've got it right by 
now.
Greatly appreciate your comments.

Regards,
Greg

On Tue, Jan 31, 2017 at 10:22 AM, Uma Chunduri 
<uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>> wrote:
Had a quick look at this diff.

This is about unifying the encoding parts in IGP to have a consistent view for 
BGP-LS encoding or keeping these separate and yet having a correct 
representation in BGP-LS for both IGPs.

==
With variable length bit field for Section 4.5 and fixed 4 byte value (as 
indicated as MUST  for length) in section 4.3  - I saw a discrepancy  in 
section 4.6 (BGP-LS) which is referencing section 4.3.

You have multiple options to fix this:


1.   Change section 4.3 to match section 4.5 (I am not sure why we have to 
have variable length for this bit field to start with in this case like rfc 
7794…but I won’t say much now)

2.   Change Section 4.6 to represent differences in encoding section 4.5 
and 4.3 correctly.
“Length, RTM, and Reserved fields as defined in Section 4.3.”
   3. Lastly unify section 4.5 to 4.3  i.e., 4 byte value with 3 bits defined 
and 29 bits reserved.
--
Uma C.

From: mpls [mailto:mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>] On 
Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, January 31, 2017 8:22 AM
To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: m...@ietf.org<mailto:m...@ietf.org>; 
isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; Isis-wg 
<isis-wg-boun...@ietf.org<mailto:isis-wg-boun...@ietf.org>>; 
draft-ietf-mpls-residence-t...@tools.ietf.org<mailto:draft-ietf-mpls-residence-t...@tools.ietf.org>;
 TEAS WG Chairs <teas-cha...@ietf.org<mailto:teas-cha...@ietf.org>>; 
mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>; TEAS WG 
<t...@ietf.org<mailto:t...@ietf.org>>; ospf@ietf.org<mailto:ospf@ietf.org>; 
ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>
Subject: Re: [mpls] [OSPF] Working group last call on 
draft-ietf-mpls-residence-time

Greg –

Looks good.

   Les

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Tuesday, January 31, 2017 8:06 AM
To: Les Ginsberg (ginsberg)
Cc: Loa Andersson; m...@ietf.org<mailto:m...@ietf.org>; TEAS WG; 
ospf@ietf.org<mailto:ospf@ietf.org>; Isis-wg; 
ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>; 
draft-ietf-mpls-residence-t...@tools.ietf.org<mailto:draft-ietf-mpls-residence-t...@tools.ietf.org>;
 TEAS WG Chairs; isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; 
mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>
Subject: Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

Hi Les,
thank you for your patience and apologies for missing it.
Diff and the update been attached.

Regards,
Greg

On Tue, Jan 31, 2017 at 5:07 AM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Greg –

Almost…

Please change the title of Section 7.5 to “IS-IS RTM Capability sub-TLV”.

Please change the title of Table 5 to “IS-IS RTM Capability sub-TLV Registry 
Description”.

The common point being since this is not exclusively for TLV 22 we do not want 
to say “for TLV 22”.
Thanx.

Les


From: Greg Mirsky [mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>]
Sent: Monday, January 30, 2017 11:43 PM

To: Les Ginsberg (ginsberg)
Cc: Loa Andersson; m...@ietf.org<mailto:m...@ietf.org>; TEAS WG; 
ospf@ietf.org<mailto:ospf@ietf.org>; Isis-wg; 
ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>; 
draft-ietf-mpls-residence-t...@tools.ietf.org<mailto:draft-ietf-mpls-residence-t...@tools.ietf.org>;
 TEAS WG Chairs; isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; 
mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>
Subject: Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

Hi Les,
many thanks for your the most detailed suggestions. Hope I've it right.

Regards,
Greg

On Mon, Jan 30, 2017 at 11:04 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Greg –

Thanx for the quick turnaround.

Section 4.5 (revised text)

   The capability to support RTM on a particular link (interface) is
   advertised in a new sub-TLV which may be included in TLVs advertising
   Intemediate System (IS) Reachability on a specific link (TL

Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

[Les Ginsberg (ginsberg)]

Greg –

Looks good.

   Les

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Tuesday, January 31, 2017 8:06 AM
To: Les Ginsberg (ginsberg)
Cc: Loa Andersson; m...@ietf.org; TEAS WG; ospf@ietf.org; Isis-wg; 
ospf-cha...@ietf.org; draft-ietf-mpls-residence-t...@tools.ietf.org; TEAS WG 
Chairs; isis-cha...@ietf.org; mpls-cha...@ietf.org
Subject: Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

Hi Les,
thank you for your patience and apologies for missing it.
Diff and the update been attached.

Regards,
Greg

On Tue, Jan 31, 2017 at 5:07 AM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Greg –

Almost…

Please change the title of Section 7.5 to “IS-IS RTM Capability sub-TLV”.

Please change the title of Table 5 to “IS-IS RTM Capability sub-TLV Registry 
Description”.

The common point being since this is not exclusively for TLV 22 we do not want 
to say “for TLV 22”.
Thanx.

Les


From: Greg Mirsky [mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>]
Sent: Monday, January 30, 2017 11:43 PM

To: Les Ginsberg (ginsberg)
Cc: Loa Andersson; m...@ietf.org<mailto:m...@ietf.org>; TEAS WG; 
ospf@ietf.org<mailto:ospf@ietf.org>; Isis-wg; 
ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>; 
draft-ietf-mpls-residence-t...@tools.ietf.org<mailto:draft-ietf-mpls-residence-t...@tools.ietf.org>;
 TEAS WG Chairs; isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; 
mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>
Subject: Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

Hi Les,
many thanks for your the most detailed suggestions. Hope I've it right.

Regards,
Greg

On Mon, Jan 30, 2017 at 11:04 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Greg –

Thanx for the quick turnaround.

Section 4.5 (revised text)

   The capability to support RTM on a particular link (interface) is
   advertised in a new sub-TLV which may be included in TLVs advertising
   Intemediate System (IS) Reachability on a specific link (TLVs 22, 23, 222, 
and 223).

   The format for the RTM Capabilities sub-TLV is presented in Figure 5

 0   1   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|  Type | Length| RTM |  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Figure 5: RTM Capability sub-TLV

… (Remainder unchanged)

Section 7.5 (revised text)

7.5.  IS-IS RTM Capability sub-TLV

   IANA is requested to assign a new Type for RTM capability sub-TLV
   from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as
   follows:

+--+-+++-+-+-+---+
| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+--+-+++-+-+-+---+
| TBA3 | RTM  | y  | y  | n   | y   | y   | This document |
|   | Capability |  | |  |   |  |   
 |
+--+-+++-+-+-+---+

 Table 5: IS-IS RTM Capability sub-TLV Registry Description


Thanx.

Les

From: Greg Mirsky [mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>]
Sent: Monday, January 30, 2017 10:36 PM
To: Les Ginsberg (ginsberg)
Cc: Loa Andersson; m...@ietf.org<mailto:m...@ietf.org>; TEAS WG; 
ospf@ietf.org<mailto:ospf@ietf.org>; Isis-wg; 
ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>; 
draft-ietf-mpls-residence-t...@tools.ietf.org<mailto:draft-ietf-mpls-residence-t...@tools.ietf.org>;
 TEAS WG Chairs; isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; 
mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>
Subject: Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

Hi Les,
attached are diff and the updated version -14. Would be much obliged to hear 
from you if the updates are according to your suggestions and address your 
comments.

Kind regards,
Greg


On Mon, Jan 30, 2017 at 1:11 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:

Loa -



The change for IS-IS encoding to utilize a sub-TLV of TLV 22 et al to advertise 
RTM capability is a better solution than the previous proposal and this has my 
support.

However, there are some details as regards the proposed sub-TLV that should be 
revised.



1)Rather than use a fixed 16 bit field for the flags I suggest you utilize the 
encoding style introduced in RFC 7794 (see Section 2.1) which allows for a 
variable length flags field. This addresses two issues:



   o You need never worry that the size of the flags field will be too small 
for future extensions

   o It minimizes the number of bytes required to be sent



The latter point is something 

Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

[Les Ginsberg (ginsberg)]

Greg –

Almost…

Please change the title of Section 7.5 to “IS-IS RTM Capability sub-TLV”.

Please change the title of Table 5 to “IS-IS RTM Capability sub-TLV Registry 
Description”.

The common point being since this is not exclusively for TLV 22 we do not want 
to say “for TLV 22”.
Thanx.

Les


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, January 30, 2017 11:43 PM
To: Les Ginsberg (ginsberg)
Cc: Loa Andersson; m...@ietf.org; TEAS WG; ospf@ietf.org; Isis-wg; 
ospf-cha...@ietf.org; draft-ietf-mpls-residence-t...@tools.ietf.org; TEAS WG 
Chairs; isis-cha...@ietf.org; mpls-cha...@ietf.org
Subject: Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

Hi Les,
many thanks for your the most detailed suggestions. Hope I've it right.

Regards,
Greg

On Mon, Jan 30, 2017 at 11:04 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Greg –

Thanx for the quick turnaround.

Section 4.5 (revised text)

   The capability to support RTM on a particular link (interface) is
   advertised in a new sub-TLV which may be included in TLVs advertising
   Intemediate System (IS) Reachability on a specific link (TLVs 22, 23, 222, 
and 223).

   The format for the RTM Capabilities sub-TLV is presented in Figure 5

 0   1   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|  Type | Length| RTM |  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Figure 5: RTM Capability sub-TLV

… (Remainder unchanged)

Section 7.5 (revised text)

7.5.  IS-IS RTM Capability sub-TLV

   IANA is requested to assign a new Type for RTM capability sub-TLV
   from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as
   follows:

+--+-+++-+-+-+---+
| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+--+-+++-+-+-+---+
| TBA3 | RTM  | y  | y  | n   | y   | y   | This document |
|   | Capability |  | |  |   |  |   
 |
+--+-+++-+-+-+---+

 Table 5: IS-IS RTM Capability sub-TLV Registry Description


Thanx.

Les

From: Greg Mirsky [mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>]
Sent: Monday, January 30, 2017 10:36 PM
To: Les Ginsberg (ginsberg)
Cc: Loa Andersson; m...@ietf.org<mailto:m...@ietf.org>; TEAS WG; 
ospf@ietf.org<mailto:ospf@ietf.org>; Isis-wg; 
ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>; 
draft-ietf-mpls-residence-t...@tools.ietf.org<mailto:draft-ietf-mpls-residence-t...@tools.ietf.org>;
 TEAS WG Chairs; isis-cha...@ietf.org<mailto:isis-cha...@ietf.org>; 
mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>
Subject: Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

Hi Les,
attached are diff and the updated version -14. Would be much obliged to hear 
from you if the updates are according to your suggestions and address your 
comments.

Kind regards,
Greg


On Mon, Jan 30, 2017 at 1:11 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:

Loa -



The change for IS-IS encoding to utilize a sub-TLV of TLV 22 et al to advertise 
RTM capability is a better solution than the previous proposal and this has my 
support.

However, there are some details as regards the proposed sub-TLV that should be 
revised.



1)Rather than use a fixed 16 bit field for the flags I suggest you utilize the 
encoding style introduced in RFC 7794 (see Section 2.1) which allows for a 
variable length flags field. This addresses two issues:



   o You need never worry that the size of the flags field will be too small 
for future extensions

   o It minimizes the number of bytes required to be sent



The latter point is something IS-IS has always been more conservative about 
than OSPF because of the fixed size of an LSP set which can be advertised by a 
single router.



2)In the IANA considerations you have limited the sub-TLV to being used in TLV 
22 only, but there is no reason to do so. This does not allow MT to be 
supported and it needlessly prevents use of the sub-TLV by the RFC 5311 
extensions (however unpopular those may be). I can understand why the sub-TLV 
may not be useful in TLV 141, therefore I suggest the table in Section 7.5 be 
revised to be:





| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |

   +--+-+++-+-+-+---+

  | TBA3 |RTM   | y  | y  | n   | y   | y   | This document |

+--+-+++-+-+-+---+



i.e. "y" for all but TLV 141 (in case the ASCII art doesn't translate well in 
you

Re: [OSPF] Working group last call on draft-ietf-mpls-residence-time

[Les Ginsberg (ginsberg)]

Loa -



The change for IS-IS encoding to utilize a sub-TLV of TLV 22 et al to advertise 
RTM capability is a better solution than the previous proposal and this has my 
support.

However, there are some details as regards the proposed sub-TLV that should be 
revised.



1)Rather than use a fixed 16 bit field for the flags I suggest you utilize the 
encoding style introduced in RFC 7794 (see Section 2.1) which allows for a 
variable length flags field. This addresses two issues:



   o You need never worry that the size of the flags field will be too small 
for future extensions

   o It minimizes the number of bytes required to be sent



The latter point is something IS-IS has always been more conservative about 
than OSPF because of the fixed size of an LSP set which can be advertised by a 
single router.



2)In the IANA considerations you have limited the sub-TLV to being used in TLV 
22 only, but there is no reason to do so. This does not allow MT to be 
supported and it needlessly prevents use of the sub-TLV by the RFC 5311 
extensions (however unpopular those may be). I can understand why the sub-TLV 
may not be useful in TLV 141, therefore I suggest the table in Section 7.5 be 
revised to be:





| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |

   +--+-+++-+-+-+---+

  | TBA3 |RTM   | y  | y  | n   | y   | y   | This document |

+--+-+++-+-+-+---+



i.e. "y" for all but TLV 141 (in case the ASCII art doesn't translate well in 
your mailer).


You should also remove the reference to RFC 5305 in Section 4.5 as it is too 
limiting. Simply referencing the IANA registry 
http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-141-222-223
 should be sufficient. All necessary references can be found there.



3)An editorial correction:



Introduction 3rd paragraph:



s/ Althugh/ Although



   Les



> -Original Message-

> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Loa Andersson

> Sent: Monday, January 30, 2017 8:02 AM

> To: m...@ietf.org; TEAS WG; ospf@ietf.org; Isis-wg

> Cc: isis-cha...@ietf.org; draft-ietf-mpls-residence-t...@tools.ietf.org; TEAS

> WG Chairs; mpls-cha...@ietf.org; ospf-cha...@ietf.org

> Subject: [OSPF] Working group last call on draft-ietf-mpls-residence-time

>

> Working Groups,

>

> This is to initiate a two week working group last call in four working groups 
> on

> draft-ietf-mpls-residence-time-13.

>

> The MPLS working group has done an earlier working group last call and a

> request for publication has been made.

>

> The changes to the document were such that we decided to do a new

> working group last call and extend it to MPLS, TEAS, OSPF and IS-IS.

>

> There are three major changes between the version of the document for

> which publication was requested are:

>

> (1) that section 7 " One-step Clock and Two-step Clock Modes" has been

>  moved up to become section 2.1.

> (2) that a sub-TLV for TLV 22 instead of TLV 251 is used to RTM

>  Capability when IS-IS used advertise RTM capabilities

> (3) BGP-LS has been added as a RTM capability advertisement method

>

> A side-by-side diff between version -12 and -13 is available at:

> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-13

>

> Please send your comments to the mpls wg mailing list 
> (m...@ietf.org), if

> you are not subscribed to the mpls wg list, send to "your own"

> working group mailing list, and we'll make sure they are posted to the MPLS

> wg list.

>

> There were one IPR disclosure against this document.

>

> All the authors and contributors have stated on the working group mailing list

> that they are not aware of any other IPRs that relates to this document.

>

> This working group last call ends February 13, 2017.

>

>

> /Loa

> MPLS wg co-chairs

> --

>

>

> Loa Anderssonemail: 
> l...@mail01.huawei.com

> Senior MPLS Expert  l...@pi.nu

> Huawei Technologies (consultant) phone: +46 739 81 21 64

>

> ___

> OSPF mailing list

> OSPF@ietf.org

> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03

[Les Ginsberg (ginsberg)]

Stephane -

> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of
> stephane.litkow...@orange.com
> Sent: Wednesday, November 16, 2016 10:53 PM
> To: Peter Psenak (ppsenak); DECRAENE Bruno IMT/OLN
> Cc: OSPF WG List; draft-ppsenak-ospf-te-link-attr-re...@tools.ietf.org
> Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03
> 
> Hi,
> 
> We agreed during the OSPF meeting that a use case/requirement draft
> should be written before progressing with any solution.

[Les:] Both as minute-taker and WG member, I think you have not accurately 
reflected what happened at the meeting.
It is true that there was discussion about writing a use case document - and 
multiple people (myself included) believe that writing a use case document 
would be a good idea.

It is inaccurate however to say that the WG decided to do this - and it is 
particularly inaccurate to say that the WG decided that progress on the 
solution drafts should be halted until the use case document is written.

Please see another post I sent to the list a few minutes ago reflecting how I 
think the  WG should move forward. I do think writing a use case document is a 
good idea, but I also think we already understand use cases and requirements 
well enough to know what extensions to the protocol are required. 

   Les
 
> I propose to take the point to initiate the work and I will first try to list 
> the
> possible situations and then we can really agree on the use cases that are
> relevant. We have some in Orange but there may be additional as well.
> 
> Brgds,
> 
> Stephane
> 
> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Tuesday, November 08, 2016 18:26
> To: DECRAENE Bruno IMT/OLN
> Cc: OSPF WG List; draft-ppsenak-ospf-te-link-attr-re...@tools.ietf.org
> Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03
> 
> Hi Bruno,
> 
> please see inline (##PP):
> 
> On 07/11/16 15:35 , bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Many thanks for your replies.
> > Please see inline [Bruno]
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]  > Sent: Monday,
> >> November 07, 2016 1:23 PM
> >>
> >   > Hi Bruno,
> >   >
> >   > thanks for your comments, please see responses inline.
> >   >
> >   > We can work on details as we progress the draft in the WG.
> >
> > [Bruno] Sure. We can also work on these details independently of the
> > WG adoption (question). This was purpose of this thread (even though
> > it was at the same time of the WG adoption thread)
> >
> >   > What I would like to hear from you at this point is whether you support
> >   > the idea described in the draft.
> >
> > [Bruno]
> > - I support the problem statement and the need for a solution.
> > - Regarding the encoding (type of LSA/TLV), if the question is specific to 
> > the
> OSPF WG, and the IS-IS WG will be free to make a fully independent
> decision/solution, I'd rather leave this choice to OSPF
> users/implementers/experts (rather than adding noise on the mailing list). If
> the OSPF choice is likely to influence the IS-IS choice, I'd prefer waiting 
> for
> the IS-IS document to express my comments/support.
> 
> ##PP
> encoding is one thing, what I would like to hear from you is whether you
> support the idea of per application link-attribute values.
> 
> >
> >
> >
> >   > On 04/11/16 16:50 , bruno.decra...@orange.com wrote:
> >   > > Hi authors,
> >   > >
> >   > > Although I'm more familiar with IS-IS (nobody's perfect ;-) ), please
> find below some
> >   > proposed comments
> >   > >
> >   > > 1) meaning of "TE"
> >   > > As already expressed in a meeting, I'd like the document to clarify 
> > the
> meaning of "TE".
> >   > I suspect that in this document it is used to mean "RSVP-TE" while some
> readers could
> >   > understand it as "Traffic Engineering application". IOW, is SR-TE part 
> > of
> "TE" or not?
> >   >
> >   > TE in the context of the draft means RSVP based TE.
> >
> > [Bruno] Thanks for the crystal clear clarification. Looks good to me.
> >
> >   > >
> >   > > In particular, this needs to be crystal clear in the recommended
> approach. Current text
> >   > is:
> >   > > "3.3.  Selected Approach
> >   > > It is RECOMMENDED to use the Extended Link Opaque LSA
> ([RFC7684] to advertise
> >   > any link attributes used for non-TE purposes in OSPFv2"
> >   >
> >   > sure, we can make that clarification.
> >   >
> >   > >
> >   > > IMHO, I would interpret this text as SR-TE must not use the Extended
> Link Opaque LSA
> >   > ([RFC7684], hence presumably must use the TE Opaque TSA.
> >   > > But I suspect that this is not the intent of the authors.
> >   >
> >   > In a long run, we would like the SRTE to use the Extended Link Opaque
> >   > LSA ([RFC7684].
> >   >
> >   > >
> >   > > 2) As a minor comment, I'm not that convinced with (or don't
> understand well) the
> >   > argument 2 in section 3.2
> >   > > "The TE Opaque LSA remains truly 

[OSPF] Moving Forward with link attribute advertisement extensions

[Les Ginsberg (ginsberg)]

There is general agreement that protocol extensions are required to address new 
requirements related to the use of link attributes historically associated only 
with RSVP-TE. That is why we have two drafts in OSPF on the subject:



https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/ and



https://datatracker.ietf.org/doc/draft-hegde-ospf-advertising-te-protocols/



In the recent WG meeting there was a rather "exciting" debate about the 
merits/demerits of the two proposals- but I think if we filter out the emotions 
and focus on the things we know to be true then it should be straightforward to 
decide which of the approaches should be pursued.



Evolution of use cases for link attributes can be expected to continue - so any 
discussion of existing use cases is limited to requirements which are known at 
the time of this writing. However, in order to determine the functionality 
required beyond what already exists in the protocol, it is only necessary to 
discuss a single use case.



rfc7855 discusses use 
cases/requirements for SR. Included among these use cases is SR-TE. If both 
RSVP-TE and SR-TE are deployed in a network, links can be used by one or both 
of these applications. As there is no requirement for the topology supported 
for SR-TE to be congruent to the topology supported for RSVP-TE there is a 
clear requirement to indicate independently which applications are associated 
with a given link. If both RSVP-TE and SR-TE are enabled on the same link it is 
also possible that an attribute such as Maximum Bandwidth to be utilized by 
SR-TE may be different than/disjoint from the Maximum Bandwidth to be utilized 
by RSVP-TE.



This leads to two clear requirements:



1)Support for indicating which applications are using the link attribute 
advertisements on a link

2)Support for advertising application specific values for the same attribute on 
a link



Only draft-ppsenak-ospf-te-link-attr-reuse meets both of these requirements. 
draft-hegde-ospf-advertising-te-protocols only supports the first requirement.



Another topic debated at the recent WG meeting was the issue of backwards 
compatibility. It is a given that routers supporting the protocol extensions 
will have to co-exist with legacy routers, so backwards compatibility is 
important. Here again there is a clear advantage for 
draft-ppsenak-ospf-te-link-attr-reuse as it fully supports backwards 
compatibility (i.e. no impact to legacy routers) by advertising duplicate 
advertisements when necessary. draft-hegde-ospf-advertising-te-protocols cannot 
support backwards compatibility in cases where SR-TE is enabled on some links 
and RSVP-TE is enabled on other links as it uses legacy advertisements of the 
attribute in both cases. draft-hegde-ospf-advertising-te-protocols does offer a 
partial deployment strategy - but this requires introducing new configuration 
(affinity) on legacy routers.


There was also discussion that writing a use case/requirements document would 
be desirable - to which I agree. However, the major benefit of  a use case 
document will be to define which of the many link attributes are candidates for 
per application advertisements. This will not discover the requirement for 
application specific advertisements - we already have at least one such case - 
though it will potentially discover additional cases. The framework required 
for the protocol extensions will not change as a result of the writing of the 
use case document - so the best way forward is to work on the use case document 
and the protocol extensions in parallel.



I therefore strongly believe the WG should adopt 
draft-ppsenak-ospf-te-link-attr-reuse without further delay. WG adoption call 
was already started and has to date received support from multiple people (NOT 
counting the co-authors). The only dissenting opinions have come from the 
authors of draft-hegde-ospf-advertising-te-protocols.



I also believe that the suggested use case document should go forward as well 
to help define the use cases to which the new protocol extensions apply - but 
we can and should do this work in parallel with the protocol extensions.



I have attached a slide summarizing the capabilities of the two competing 
drafts as an aid to understanding the differences between the two proposals.



Les




te_app.pptx
Description: te_app.pptx
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

[Les Ginsberg (ginsberg)]

Folks –

I am adding the IS-IS WG to this thread because the issues discussed below 
apply equally to IS-IS.

There is currently one draft in IS-IS: 
https://www.ietf.org/id/draft-hegde-isis-advertising-te-protocols-01.txt which 
has the same shortcomings as its OSPF counterpart:  
https://www.ietf.org/id/draft-hegde-ospf-advertising-te-protocols-00.txt

It is essential that the two IGPs provide equivalent functionality. We 
therefore need a draft in IS-IS that defines functionality equivalent to that 
defined in https://www.ietf.org/id/draft-ppsenak-ospf-te-link-attr-reuse-03.txt.

It is my intention to help write such a draft.

   Les


From: Rob Shakir [mailto:r...@rob.sh]
Sent: Thursday, November 03, 2016 11:47 AM
To: Jeff Tantsura; Peter Psenak (ppsenak); Chris Bowers; ospf@ietf.org
Cc: draft-ppsenak-ospf-te-link-attr-re...@tools.ietf.org
Subject: Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Hi OSPF chairs, Peter, Chris,

To add my opinion to this thread. The issue of having multiple places in which 
one might advertise TE related information is one that I think there can be 
multiple takes on. Particularly, whilst I can see that there is an argument 
that duplication of such attributes might result in ambiguity in which is used, 
we must also consider what happens when the TE information for one protocol 
does not apply for others that are running within the same network. This is 
particularly important during the period where there is coexistence of multiple 
protocols on the device. In order to explicitly allow the operator to choose 
how resources might be partitioned on the network, then to me it seems like we 
need more than simply "is this link eligible to carry TE paths that are 
signalled via protocol X".

As well as resource partitioning (e.g., subsets of bandwidth being available 
per application for example), there appear to me to be potential use cases 
where the administrative groups across the protocols may differ, when a subset 
of links are eligible for a particular protocol's paths and not another's. Not 
being able to do this scoping makes the difficult problem of coexistence even 
more difficult, so having the flexibility to tag particular attributes for 
links based on application seems (generically) to be more useful than the 
simple ability of partitioning the network link-by-link that is proposed in 
draft-hegde-ospf-advertising-te-protocols-00.

Operationally - yes - if one specifies metrics in multiple places this might 
have some ambiguity, however, we have many years of experience of such a 
scenario - where TE metric might make RSVP-TE act differently in terms of path 
selection than the base IGP metric. Those networks that do not derive benefit 
from the additional attributes will simply not set them, or make their value 
exactly mirrored between the different protocols that they run. Those that do 
have benefit will have the flexibility to utilise them, but have to deal with 
the additional operational overhead that comes with it.

I would prefer that we adopt the more flexible approach (this draft), and then 
work out the implementation and operational complexities that might be 
introduced, than to adopt an approach which leaves us with few extensibility 
options going forward.

Cheers,
r.





On Thu, Nov 3, 2016 at 10:48 AM Jeff Tantsura 
> wrote:
Hi,

Some history to add on top of Peter’s, IMO absolutely correct comments.
The issue is well known, we have had first discussions on the topic during the 
time rLFA was going thru standardization and implementation.
Back then however there was no clean and painless way to so.

draft-ppsenak-ospf-te-link-attr-reuse addresses exactly the issue we have seen 
starting from the time TE seized to be the only application, however now, with 
the new extensions (7684) we have got much better and cleaner way.

Cheers,
Jeff


On 11/3/16, 6:53 AM, "Peter Psenak (ppsenak)" 
> wrote:

>Chris,
>
>draft-hegde-ospf-advertising-te-protocols has following limitations:
>
>1. only solves the problem of RSVP and Segment Routing TE. It does not
>address any other non-TE applications - e.g. LFA, SPF based on the delay
>or bandwidth, or anything that may come in the future.
>
>2. it took the approach of "indicating the protocols enabled on the
>link". While this may be good for RSVP, it does not work for other
>applications. For example the fact that the LFA is enabled on a remote
>link is orthogonal to the fact whether the SRLG value on such link is
>going to be used by LFA calculation on other nodes in a network.
>
>3. does not support per application values. You questioned the use case
>of SRLG. Well, we have a real use case, where operator runs RSVP TE and
>SRTE in parallel and wants to know bandwidth available for each.
>
>You mentioned 

Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

[Les Ginsberg (ginsberg)]

Support adoption as co-author.

I am not aware of any relevant IPR.

   Les


> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Abhay Roy (akr)
> Sent: Tuesday, October 25, 2016 10:28 PM
> To: ospf@ietf.org; draft-ppsenak-ospf-te-link-attr-re...@tools.ietf.org
> Subject: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse
> 
> Dear WG,
> 
> Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the WG
> for adoption of this document as a WG Draft. Please send your opinions /
> concerns.
> 
> This begins the two week WG adoption poll which will conclude on Nov 9th
> 2016.
> 
> Authors, we need your explicit response on this thread to capture your
> answer on if you are aware of any IPR related to this draft.
> 
> Regards,
> -Abhay
> 
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] WG Adoption Poll for "Signaling MSD (Maximum SID Depth) using OSPF"

[Les Ginsberg (ginsberg)]

I have read the draft and believe the simple protocol extension advertises 
information which is useful.
I support WG adoption.

Les


From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, October 11, 2016 11:57 AM
To: OSPF WG List
Subject: [OSPF] WG Adoption Poll for "Signaling MSD (Maximum SID Depth) using 
OSPF"

Please indicate your support or objection to OSPF WG Adoption for "Signaling 
MSD (Maximum SID Depth) using OSPF” before 10/26/2016.

For your convenience, here is a URL: 
https://www.ietf.org/id/draft-tantsura-ospf-segment-routing-msd-01.txt

Thanks,
Acee and Abhay
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] OSPFv2 SR draft

[Les Ginsberg (ginsberg)]

Chris/Peter -

> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
> (ppsenak)
> Sent: Thursday, August 25, 2016 1:45 AM
> To: Chris Bowers; OSPF List
> Subject: Re: [OSPF] OSPFv2 SR draft
> 
> Hi Chris,
> 
> On 24/08/16 20:31 , Chris Bowers wrote:
> > Peter,
> >
> > The text that you propose corresponds to part of the text that I proposed,
> and it seems good to me.
> >
> > However, the last sentence of the text that I proposed in not addressed.
> > --
> > If router B does not advertise the
> > SR-Algorithm TLV for algorithm X, then other routers should not
> > forward traffic destined for a prefix-SID for algorithm X advertised
> > by some router D using a path that would require router B to forward
> > traffic using algorithm X.
> > --
> > Is this an oversight?
> 
> not that I disagree with the statement that you want to add.
> 
> The question is whether that belongs to the IGP SR draft, or whether that
> should be specified in a different draft.
> 
> There is already some text regarding the forwarding for a SR algorithm in
> draft-ietf-spring-segment-routing section 3.2.1., which may not be aligned
> with what you have in mind:
> 
>"The ingress node of an SR domain validates that the path to a prefix,
> advertised with a given algorithm, includes nodes all supporting the
> advertised algorithm.  In other words, when computing paths for a
> given algorithm, the transit nodes MUST compute the algorithm X on
> the IGP topology, regardless of the support of the algorithm X by the
> nodes in that topology.  As a consequence, if a node on the path does
> not support algorithm X, the IGP-Prefix segment will be interrupted
> and will drop packet on that node.  It's the responsibility of the
> ingress node using a segment to check that all downstream nodes
> support the algorithm of the segment."
> 
> Maybe we should add/modify the text in draft-ietf-spring-segment-routing
> section 3.2.1, rather then adding anything to the OSPF/ISIS SR drafts.
> 
[Les:] I strongly agree with this approach. If one wants to understand how the 
MPLS dataplane works with SR then the following documents are relevant:

https://www.ietf.org/id/draft-ietf-spring-segment-routing-09.txt
https://www.ietf.org/id/draft-ietf-spring-segment-routing-mpls-05.txt
https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-04.txt

References to these documents can be included in the IGP drafts - but we should 
not try to repurpose the IGP drafts to cover material which is covered far more 
completely in the above drafts. 

If you feel there is something which needs to be added/revised to any of the 
above drafts to more accurately explain algorithm specific forwarding please 
make the comment in the context of one of those drafts.

   Les

> thanks,
> Peter
> 
> >
> > Thanks,
> > Chris
> >
> >
> > -Original Message-
> > From: Peter Psenak [mailto:ppse...@cisco.com]
> > Sent: Monday, August 22, 2016 2:32 AM
> > To: Chris Bowers ; OSPF List 
> > Subject: Re: [OSPF] OSPFv2 SR draft
> >
> > Chris,
> >
> > what about this to be added in the Section 3.1:
> >
> >
> > "A router receiving a Prefix-SID (defined in section 5) from a remote node
> and with an SR algorithm value that such remote node has not advertised in
> the SR-Algorithm sub-TLV MUST ignore the Prefix-SID sub-TLV."
> >
> > thanks,
> > Peter
> >
> >
> > On 19/08/16 23:33 , Chris Bowers wrote:
> >> Peter,
> >>
> >> Please share the updated text that you plan to use with the WG, since this
> is a reasonably significant clarification.
> >>
> >> Thanks,
> >> Chris
> >>
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Tuesday, August 16, 2016 10:02 AM
> >> To: Chris Bowers ; OSPF List 
> >> Subject: Re: [OSPF] OSPFv2 SR draft
> >>
> >> Hi Chris,
> >>
> >> I'll update the draft along those lines.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >> On 16/08/16 16:02 , Chris Bowers wrote:
> >>> Peter,
> >>>
> >>> I suggest changing the paragraph to read as below to make this clearer.
> >>>
> >>> =
> >>>   The SR-Algorithm Sub-TLV is optional.  It MAY only be advertised 
> >>> once
> >>>   in the Router Information Opaque LSA.  If the SID/Label Range TLV, 
> >>> as
> >>>   defined in Section 3.2, is advertised, then the SR-Algorithm TLV 
> >>> MUST
> >>>   also be advertised.  If a router C advertises a Prefix-SID sub-TLV 
> >>> for
> algorithm X
> >>>   but does not advertise the SR-Algorithm Sub-TLV with algorithm X,
> then
> >>>   a router receiving that advertisement MUST ignore the Prefix-SID
> >>>   advertisement from router C.  If router B does not advertise the
> >>>   SR-Algorithm TLV for algorithm X, then other routers should not
> >>>   forward traffic destined for a prefix-SID for algorithm X 
> >>> advertised by
> >>>   

Re: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

[Les Ginsberg (ginsberg)]

Jie -

My opinion is:

Problem statement draft should NOT move forward. There is no problem which we 
intend to solve.

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Wednesday, August 17, 2016 2:45 AM
To: Les Ginsberg (ginsberg); ospf@ietf.org
Cc: Zhangxudong (zhangxudong, VRP); lizhenqi...@chinamobile.com
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

I'm a little confused here. Do you mean the problem statement should not be 
moved forward, because the discussion on the potential solutions has not 
converged yet?

We will prepare some material to describe a candidate solution for impact 
mitigation, and we can discuss further base on that . But IMO the progress of 
the solution does not impact the value of the problem statement, what do you 
think?

Best regards,
Jie

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, August 17, 2016 7:05 AM
To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; 
ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP) 
<zhangxud...@huawei.com<mailto:zhangxud...@huawei.com>>; 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

I agree that the discussion has been useful. But my position - considering all 
the points made during this discussion - is that no protocol changes are 
advisable.
I therefore think the draft should not be moved forward.

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Tuesday, August 16, 2016 6:16 AM
To: Les Ginsberg (ginsberg); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

It seems that after these days discussion, now we are clear with the problem, 
this is a good progress for the problem statement draft. Next step I think we 
can focus on the discussion of the solutions.

If the Maxage flush problem happens in production network, without protocol 
change, it will have severe impact to the network, which I believe is not 
acceptable. At least some mechanism to mitigate the impact is needed. The 
mechanism you proposed can be part of the mitigation solution, while some 
optimization needs to be considered to avoid unexpected behaviors, e.g. in some 
cases the LSA may stay for quite a long time and cannot get aged properly.

As for RFC 6232, sorry for not making it clear in the beginning. RFC 6232 can 
be useful to track the originator of the purge message when an invalid purge 
(e.g. remain lifetime corruption) is detected by some other means.

Best regards,
Jie

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, August 12, 2016 1:29 AM
To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; 
ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP) 
<zhangxud...@huawei.com<mailto:zhangxud...@huawei.com>>; 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

Having the discussion has certainly been a good thing, but if the consensus of 
the WG is that there is no protocol change required then there is no need for 
any draft - which is my current position.

The other point is that you seem to be confusing the IS-IS Purge origination 
TLV (RFC 6232) with detecting invalid purges/remaining lifetime corruption. 
This is not the case. RFC 6232 simply allows us to detect which router 
originated a purge - it is not able to detect whether a purge is valid/invalid 
- and was not motivated by concerns about remaining lifetime corruption.

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Wednesday, August 10, 2016 9:24 PM
To: Les Ginsberg (ginsberg); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

The current draft is about problem statement, so IMO what the WG needs to 
consider is whether this is a vulnerability of OSPF protocol, and whether it 
can have negative impact to the network. If the problem is acknowledged, IMO it 
is worth to be documented.

The "ROI" as you mentioned is for the evaluation of the proposed solutions. I 
totally agree that for the timer bug case, recognizing and ignoring the 
received abnormal Maxage LSAs cannot stop the misbehaved router from generating 
further Maxage LSA, as it is a systematic problem, which can only be fixed 
after the operator identifies that router. This is also similar to the 
systematic corruption of

Re: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

[Les Ginsberg (ginsberg)]

Jie -

I agree that the discussion has been useful. But my position - considering all 
the points made during this discussion - is that no protocol changes are 
advisable.
I therefore think the draft should not be moved forward.

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Tuesday, August 16, 2016 6:16 AM
To: Les Ginsberg (ginsberg); ospf@ietf.org
Cc: Zhangxudong (zhangxudong, VRP); lizhenqi...@chinamobile.com
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

It seems that after these days discussion, now we are clear with the problem, 
this is a good progress for the problem statement draft. Next step I think we 
can focus on the discussion of the solutions.

If the Maxage flush problem happens in production network, without protocol 
change, it will have severe impact to the network, which I believe is not 
acceptable. At least some mechanism to mitigate the impact is needed. The 
mechanism you proposed can be part of the mitigation solution, while some 
optimization needs to be considered to avoid unexpected behaviors, e.g. in some 
cases the LSA may stay for quite a long time and cannot get aged properly.

As for RFC 6232, sorry for not making it clear in the beginning. RFC 6232 can 
be useful to track the originator of the purge message when an invalid purge 
(e.g. remain lifetime corruption) is detected by some other means.

Best regards,
Jie

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, August 12, 2016 1:29 AM
To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; 
ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP) 
<zhangxud...@huawei.com<mailto:zhangxud...@huawei.com>>; 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

Having the discussion has certainly been a good thing, but if the consensus of 
the WG is that there is no protocol change required then there is no need for 
any draft - which is my current position.

The other point is that you seem to be confusing the IS-IS Purge origination 
TLV (RFC 6232) with detecting invalid purges/remaining lifetime corruption. 
This is not the case. RFC 6232 simply allows us to detect which router 
originated a purge - it is not able to detect whether a purge is valid/invalid 
- and was not motivated by concerns about remaining lifetime corruption.

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Wednesday, August 10, 2016 9:24 PM
To: Les Ginsberg (ginsberg); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

The current draft is about problem statement, so IMO what the WG needs to 
consider is whether this is a vulnerability of OSPF protocol, and whether it 
can have negative impact to the network. If the problem is acknowledged, IMO it 
is worth to be documented.

The "ROI" as you mentioned is for the evaluation of the proposed solutions. I 
totally agree that for the timer bug case, recognizing and ignoring the 
received abnormal Maxage LSAs cannot stop the misbehaved router from generating 
further Maxage LSA, as it is a systematic problem, which can only be fixed 
after the operator identifies that router. This is also similar to the 
systematic corruption of IS-IS remain time.  And this is why this draft 
mentions two kinds of potential solutions, the mitigation mechanism can avoid 
the network being severely impacted by the problem, while for systematic 
problems, problem localization is needed to identify the misbehaved router and 
then solve the problem.

Best regards,
Jie

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, August 08, 2016 2:14 AM
To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; 
ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP) 
<zhangxud...@huawei.com<mailto:zhangxud...@huawei.com>>; 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: Re: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

Thinking about the following some more:


What remains is the possibility that an implementation has some bug and 
unintentionally modifies the age to something other than what it should be due 
to the actual elapsed time since LSA generation. I suppose a mechanism 
equivalent to what the IS-IS draft defined i.e. setting the age to "new" (0 in 
OSPF case) when first receiving a non-self-generated LSA could be useful to 
prevent negative impacts of such an implementation bug. Is this what you intend?

[Jie]: More specifically, the problem could be caused b

Re: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

[Les Ginsberg (ginsberg)]

Jie -

Having the discussion has certainly been a good thing, but if the consensus of 
the WG is that there is no protocol change required then there is no need for 
any draft - which is my current position.

The other point is that you seem to be confusing the IS-IS Purge origination 
TLV (RFC 6232) with detecting invalid purges/remaining lifetime corruption. 
This is not the case. RFC 6232 simply allows us to detect which router 
originated a purge - it is not able to detect whether a purge is valid/invalid 
- and was not motivated by concerns about remaining lifetime corruption.

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Wednesday, August 10, 2016 9:24 PM
To: Les Ginsberg (ginsberg); ospf@ietf.org
Cc: Zhangxudong (zhangxudong, VRP); lizhenqi...@chinamobile.com
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

The current draft is about problem statement, so IMO what the WG needs to 
consider is whether this is a vulnerability of OSPF protocol, and whether it 
can have negative impact to the network. If the problem is acknowledged, IMO it 
is worth to be documented.

The "ROI" as you mentioned is for the evaluation of the proposed solutions. I 
totally agree that for the timer bug case, recognizing and ignoring the 
received abnormal Maxage LSAs cannot stop the misbehaved router from generating 
further Maxage LSA, as it is a systematic problem, which can only be fixed 
after the operator identifies that router. This is also similar to the 
systematic corruption of IS-IS remain time.  And this is why this draft 
mentions two kinds of potential solutions, the mitigation mechanism can avoid 
the network being severely impacted by the problem, while for systematic 
problems, problem localization is needed to identify the misbehaved router and 
then solve the problem.

Best regards,
Jie

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, August 08, 2016 2:14 AM
To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; 
ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP) 
<zhangxud...@huawei.com<mailto:zhangxud...@huawei.com>>; 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: Re: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

Thinking about the following some more:


What remains is the possibility that an implementation has some bug and 
unintentionally modifies the age to something other than what it should be due 
to the actual elapsed time since LSA generation. I suppose a mechanism 
equivalent to what the IS-IS draft defined i.e. setting the age to "new" (0 in 
OSPF case) when first receiving a non-self-generated LSA could be useful to 
prevent negative impacts of such an implementation bug. Is this what you intend?

[Jie]: More specifically, the problem could be caused by either "setting the LS 
age field incorrectly due to implementation bug" or "system timer runs so fast 
that the LS age reaches MaxAge much earlier than other routers". Another less 
likely case is that the LS age field is corrupted before the LSA is assembled 
into OSPF packet.


The benefits are extremely limited. If a router prematurely ages an LSA due to 
a timer bug, ignoring the received LSA age on reception isn't going to prevent 
premature purging by the router which has the bug. So the effect of ignoring 
the received LSA age prior to reaching MAXAGE will be short lived. You are then 
left with the possibility that an implementation corrupts the LSA age BEFORE 
calculating checksum/crypto authentication - but its local timeout logic is 
unaffected. This has very limited value. Whether the WG considers this worth 
pursuing is something you need to ask. For myself, I don't see much ROI here.

  Les



From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Monday, August 01, 2016 9:43 PM
To: Les Ginsberg (ginsberg); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

Please see my replies with [Jie2]:

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 01, 2016 9:57 PM
To: Dongjie (Jimmy); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Monday, August 01, 2016 1:44 AM
To: Les Ginsberg (ginsberg); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit

Re: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

[Les Ginsberg (ginsberg)]

Jie -

Thinking about the following some more:


What remains is the possibility that an implementation has some bug and 
unintentionally modifies the age to something other than what it should be due 
to the actual elapsed time since LSA generation. I suppose a mechanism 
equivalent to what the IS-IS draft defined i.e. setting the age to "new" (0 in 
OSPF case) when first receiving a non-self-generated LSA could be useful to 
prevent negative impacts of such an implementation bug. Is this what you intend?

[Jie]: More specifically, the problem could be caused by either "setting the LS 
age field incorrectly due to implementation bug" or "system timer runs so fast 
that the LS age reaches MaxAge much earlier than other routers". Another less 
likely case is that the LS age field is corrupted before the LSA is assembled 
into OSPF packet.


The benefits are extremely limited. If a router prematurely ages an LSA due to 
a timer bug, ignoring the received LSA age on reception isn't going to prevent 
premature purging by the router which has the bug. So the effect of ignoring 
the received LSA age prior to reaching MAXAGE will be short lived. You are then 
left with the possibility that an implementation corrupts the LSA age BEFORE 
calculating checksum/crypto authentication - but its local timeout logic is 
unaffected. This has very limited value. Whether the WG considers this worth 
pursuing is something you need to ask. For myself, I don't see much ROI here.

  Les



From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Monday, August 01, 2016 9:43 PM
To: Les Ginsberg (ginsberg); ospf@ietf.org
Cc: Zhangxudong (zhangxudong, VRP); lizhenqi...@chinamobile.com
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

Please see my replies with [Jie2]:

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 01, 2016 9:57 PM
To: Dongjie (Jimmy); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Monday, August 01, 2016 1:44 AM
To: Les Ginsberg (ginsberg); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

Please see inline with [Jie]:

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 01, 2016 3:09 PM
To: Dongjie (Jimmy); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

Fully agree that IS-IS and OSPF differ in this regard.

https://www.ietf.org/id/draft-ietf-isis-remaining-lifetime-01.txt addresses 
problems where corruption of the remaining lifetime occurs either during 
transmission/reception or due to some DOS attack. This isn't a concern w OSPF 
(hope you agree).

[Jie]: Yes, for OSPF the corruption during packet transmission can be detected.

What remains is the possibility that an implementation has some bug and 
unintentionally modifies the age to something other than what it should be due 
to the actual elapsed time since LSA generation. I suppose a mechanism 
equivalent to what the IS-IS draft defined i.e. setting the age to "new" (0 in 
OSPF case) when first receiving a non-self-generated LSA could be useful to 
prevent negative impacts of such an implementation bug. Is this what you intend?

[Jie]: More specifically, the problem could be caused by either "setting the LS 
age field incorrectly due to implementation bug" or "system timer runs so fast 
that the LS age reaches MaxAge much earlier than other routers". Another less 
likely case is that the LS age field is corrupted before the LSA is assembled 
into OSPF packet.

[Jie]: Regarding the solutions space, IMO we need to consider both cases: "LS 
age reaches MaxAge" and "LS age close to MaxAge". For IS-IS, RFC 6232 and RFC 
6233 provide solutions for the detection and identification of corrupted IS-IS 
purge, while OSPF does not have similar mechanisms.

[Les:] It is incorrect to say that RFC 6232 makes it possible to detect a 
corrupt purge. What it does do is to provide an indication as to which IS 
initiated a purge. I don't know how OSPF would address this issue, but for 
OSPFv2 at least any solution would likely not be backwards compatible. For this 
reason I suggest that you not try to address this issue in the same draft.

[Jie2]: Agreed, RFC 6232 provide the mechanism to track the misbehaved routers 
so that operator can fix the 

Re: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

[Les Ginsberg (ginsberg)]

Jie -

From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Monday, August 01, 2016 1:44 AM
To: Les Ginsberg (ginsberg); ospf@ietf.org
Cc: Zhangxudong (zhangxudong, VRP); lizhenqi...@chinamobile.com
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

Please see inline with [Jie]:

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 01, 2016 3:09 PM
To: Dongjie (Jimmy); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

Fully agree that IS-IS and OSPF differ in this regard.

https://www.ietf.org/id/draft-ietf-isis-remaining-lifetime-01.txt addresses 
problems where corruption of the remaining lifetime occurs either during 
transmission/reception or due to some DOS attack. This isn't a concern w OSPF 
(hope you agree).

[Jie]: Yes, for OSPF the corruption during packet transmission can be detected.

What remains is the possibility that an implementation has some bug and 
unintentionally modifies the age to something other than what it should be due 
to the actual elapsed time since LSA generation. I suppose a mechanism 
equivalent to what the IS-IS draft defined i.e. setting the age to "new" (0 in 
OSPF case) when first receiving a non-self-generated LSA could be useful to 
prevent negative impacts of such an implementation bug. Is this what you intend?

[Jie]: More specifically, the problem could be caused by either "setting the LS 
age field incorrectly due to implementation bug" or "system timer runs so fast 
that the LS age reaches MaxAge much earlier than other routers". Another less 
likely case is that the LS age field is corrupted before the LSA is assembled 
into OSPF packet.

[Jie]: Regarding the solutions space, IMO we need to consider both cases: "LS 
age reaches MaxAge" and "LS age close to MaxAge". For IS-IS, RFC 6232 and RFC 
6233 provide solutions for the detection and identification of corrupted IS-IS 
purge, while OSPF does not have similar mechanisms.

[Les:] It is incorrect to say that RFC 6232 makes it possible to detect a 
corrupt purge. What it does do is to provide an indication as to which IS 
initiated a purge. I don't know how OSPF would address this issue, but for 
OSPFv2 at least any solution would likely not be backwards compatible. For this 
reason I suggest that you not try to address this issue in the same draft.

Solutions to LS age  corruption can be done in a backwards compatible way, but 
they  MUST NOT result in discarding purges which pass authentication- doing so 
places you at risk for having inconsistent LSDBs in the network.

As written, the draft makes claims that are at least misleading - and I believe 
actually incorrect. In Section 6 you say:

"The LS age field may be altered as a result of
   packet corruption, such modification cannot be detected by LSA
   checksum nor OSPF packet cryptographic authentication."

This isn't correct.

[Jie] Thanks for pointing out this. This sentence need to be revised to mention 
"LSA corruption" rather than "packet corruption".

What would be helpful - at least to me - is to move from a generic problem 
statement to the specific problem you want to solve and the proposed solution. 
This also requires you to more clearly state the cases where there is an actual 
vulnerability. It would be a lot easier to support the draft if this were done.

[Jie] Thanks for your suggestion. Yes we can update this draft with more 
specific problem statements as I mentioned above.

[Jie] As for the proposed solutions, the current draft specifies the 
requirements on the potential solutions, from which we envision that different 
solutions maybe needed for "Impact Mitigation" and "Problem Localization". 
Impact mitigation can be the easier one, for which we can start to discuss the 
potential solution. While the solution for "problem localization" may need more 
considerations.

[Les:] A discussion of the requirements is useful and necessary, but IMO until 
you propose a solution there isn't enough substance for the document to become 
a WG document.

Les

Best regards,
Jie

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Sunday, July 31, 2016 11:48 PM
To: Les Ginsberg (ginsberg); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

Thanks for your comments.

OSPF packet level checksum and authentication can only protect the assembled 
LSU packet one hop on the wire, while cannot detect any change to LSA made by 
the routers. This is because the OSPF packet

Re: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

[Les Ginsberg (ginsberg)]

Jie -

Fully agree that IS-IS and OSPF differ in this regard.

https://www.ietf.org/id/draft-ietf-isis-remaining-lifetime-01.txt addresses 
problems where corruption of the remaining lifetime occurs either during 
transmission/reception or due to some DOS attack. This isn't a concern w OSPF 
(hope you agree).

What remains is the possibility that an implementation has some bug and 
unintentionally modifies the age to something other than what it should be due 
to the actual elapsed time since LSA generation. I suppose a mechanism 
equivalent to what the IS-IS draft defined i.e. setting the age to "new" (0 in 
OSPF case) when first receiving a non-self-generated LSA could be useful to 
prevent negative impacts of such an implementation bug. Is this what you intend?

As written, the draft makes claims that are at least misleading - and I believe 
actually incorrect. In Section 6 you say:

"The LS age field may be altered as a result of
   packet corruption, such modification cannot be detected by LSA
   checksum nor OSPF packet cryptographic authentication."

This isn't correct.

What would be helpful - at least to me - is to move from a generic problem 
statement to the specific problem you want to solve and the proposed solution. 
This also requires you to more clearly state the cases where there is an actual 
vulnerability. It would be a lot easier to support the draft if this were done.

   Les


From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Sunday, July 31, 2016 11:48 PM
To: Les Ginsberg (ginsberg); ospf@ietf.org
Cc: Zhangxudong (zhangxudong, VRP); lizhenqi...@chinamobile.com
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi Les,

Thanks for your comments.

OSPF packet level checksum and authentication can only protect the assembled 
LSU packet one hop on the wire, while cannot detect any change to LSA made by 
the routers. This is because the OSPF packets are re-assembled on each hop, 
which is slightly different from IS-IS. So the problem for OSPF is mainly due 
to the problems inside the router, for example protocol implementations, system 
timers, or some hardware problem. Actually this problem has been seen in 
several production networks.

We can improve the description in the draft to make this clear.

Best regards,
Jie

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 01, 2016 1:30 PM
To: Dongjie (Jimmy); ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: RE: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Jie -

The draft says (Section 2):

"Since cryptographic authentication is executed at the OSPF packet
   level, it can only protect the assembled LSU packet for one hop and
   does not provide any additional protection for the corruption of LS
   age field."

But as authentication is calculated at the OSPF packet level, any change to the 
LS age field for an individual LSA contained within the OSPF packet (e.g. by 
some packet corruption in transmission) would cause authentication to fail when 
the packet is received. So the statement you make is not correct. I therefore 
am struggling to understand what problem you believe is not addressed by 
existing authentication techniques.

   Les



From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Sunday, July 31, 2016 8:15 PM
To: ospf@ietf.org<mailto:ospf@ietf.org>
Cc: Zhangxudong (zhangxudong, VRP); 
lizhenqi...@chinamobile.com<mailto:lizhenqi...@chinamobile.com>
Subject: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi all,

draft-dong-ospf-maxage-flush-problem-statement describes the problems caused by 
the corruption of the LS Age field, and summarizes the requirements on 
potential solutions. This draft received good comments during the presentation 
on the IETF meeting in B.A.

The authors would like to solicit further feedbacks from the mailing list, on 
both the problem statement and the solution requirements. Based on the 
feedbacks, we will update the problem statement draft, and work together to 
build suitable solutions.

The URL of the draft is:
https://tools.ietf.org/html/draft-dong-ospf-maxage-flush-problem-statement-00

Comments & feedbacks are welcome.

Best regards,
Jie

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

[Les Ginsberg (ginsberg)]

Jie -

The draft says (Section 2):

"Since cryptographic authentication is executed at the OSPF packet
   level, it can only protect the assembled LSU packet for one hop and
   does not provide any additional protection for the corruption of LS
   age field."

But as authentication is calculated at the OSPF packet level, any change to the 
LS age field for an individual LSA contained within the OSPF packet (e.g. by 
some packet corruption in transmission) would cause authentication to fail when 
the packet is received. So the statement you make is not correct. I therefore 
am struggling to understand what problem you believe is not addressed by 
existing authentication techniques.

   Les



From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Sunday, July 31, 2016 8:15 PM
To: ospf@ietf.org
Cc: Zhangxudong (zhangxudong, VRP); lizhenqi...@chinamobile.com
Subject: [OSPF] Solicit feedbacks on 
draft-dong-ospf-maxage-flush-problem-statement

Hi all,

draft-dong-ospf-maxage-flush-problem-statement describes the problems caused by 
the corruption of the LS Age field, and summarizes the requirements on 
potential solutions. This draft received good comments during the presentation 
on the IETF meeting in B.A.

The authors would like to solicit further feedbacks from the mailing list, on 
both the problem statement and the solution requirements. Based on the 
feedbacks, we will update the problem statement draft, and work together to 
build suitable solutions.

The URL of the draft is:
https://tools.ietf.org/html/draft-dong-ospf-maxage-flush-problem-statement-00

Comments & feedbacks are welcome.

Best regards,
Jie

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt

[Les Ginsberg (ginsberg)]

Adrian –

As an interested bystander (given I am co-author on the companion IS-IS S-BFD 
draft) I share the concerns expressed by Carlos and Manav.

Churning S-BFD discriminator assignments is about as likely as churning IP/IPv6 
address assignments on a node – it is simply not something that any deployment 
would be likely to do.
IGP drafts pay close attention to churn for advertisements of information which 
is expected to be dynamic - 
https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions/ is a 
good example of this. But there is no reason to expect a similar issue with 
S-BFD discriminators. Therefore, for the same reasons that base protocol 
specifications do not discuss the impact of churn in advertising prefix 
reachability we saw no reason to discuss it in the context of advertising S-BFD 
discriminators.

It would be helpful if you provided some context as to  why you have raised 
this point.
Thanx.

   Les

From: rtg-dir [mailto:rtg-dir-boun...@ietf.org] On Behalf Of Manav Bhatia
Sent: Wednesday, April 27, 2016 10:32 PM
To: Adrian Farrel
Cc: ; rtg-...@ietf.org; 
draft-ietf-ospf-sbfd-discriminator@ietf.org; OSPF WG List
Subject: Re: [RTG-DIR] Rtg Dir review of 
draft-ietf-ospf-sbfd-discriminator-04.txt

Hi Adrian,

Thanks for the extensive review. I have a minor comment on a minor issue that 
you raised.


Minor Issues:

I should like to see some small amount of text on the scaling impact on
OSPF. 1. How much additional information will implementations have to
store per node/link in the network? 2. What is the expected churn in
LSAs introduced by this mechanism (especially when the Reflector is
turned on and off)?

Isnt this implementation specific? This is what will differentiate one vendor 
implementation from the other.

I am not sure how we can quantify this -- any ideas?

This is akin to saying that IS-IS, in contrast to OSPFv2, is more attuned for 
partial SPF runs because the node information is cleanly separated from the 
reachability information. However, this isnt entirely true. While i concede 
that node information is mixed with prefix information in OSPFv2, there still 
are ways in which clever implementations could separate the two and do exactly 
what IS-IS does.

I took this rather circuitous approach to drive home the point that 
scalability, churn, overheads on the system are in many cases dependent on the 
protocol implementation and by that token outside the scope of the IETF drafts.


You *do* have...
   A change in information in the S-BFD Discriminator TLV MUST NOT
   trigger any SPF computation at a receiving router.
...which is a help.

I would be alarmed if an implementation in an absence of this pedantic note 
triggered SPF runs each time an S-BFD disc changed ! I mean if you understand 
the idea being discussed then you also understand that a change in this TLV has 
no bearing on the reachability anywhere. And that knowledge should be enough to 
prevent SPF runs in most cases !

I know that we have added this note but if we need to explicitly spell such 
things out in all standards then we clearly have bigger problems ! :-)

Cheers, Manav



___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

[Les Ginsberg (ginsberg)]

Uma -

> -Original Message-
> From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
> Sent: Thursday, April 07, 2016 8:03 PM
> To: Les Ginsberg (ginsberg); Acee Lindem (acee); OSPF WG List
> Subject: RE: WG Adoption Poll for "Using Operator-defined TLVs for Agile
> Service Deployment"
> 
> Les,
> 
> In-line [Uma]:
> 
> --
> Uma C.
> 
> 
> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Wednesday, March 16, 2016 9:41 PM
> To: Acee Lindem (acee); OSPF WG List
> Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for
> Agile Service Deployment"
> 
> My opinion of the draft has not changed.
> It is defining a way to utilize OSPF to send application information - which 
> is
> not something the protocol should be used to do.
> Further, it leaves definition of the new codepoints and formats of the
> information advertised completely unspecified - the latest draft revision
> states:
> 
> " The meaning of the operator-defined sub-TLV is totally opaque to OSPF
>and is defined by the network local policy and is controlled via
>configuration.  "
> 
> How interoperability is achieved is not addressed at all.
> 
> [Uma]: The whole point of the draft is,  not to define the format for the sub-
> TLVs so that it can be used  as per the sub-tlv type as set by the operator 
> (for
> example service attribute/Label).  Sub-TLV has set of attribute length and
> attribute value in NBO.
> 
[Les:] Yes - I know. :-)
And I think this is a "disaster waiting to happen".

On this point I think we currently have no common ground.

   Les

> IS-IS has taken a much more stringent approach to a similar request.
> 
> [Uma]: .. and hence unfortunately I see no body saw using it- in fact 
> including
> you. For example https://tools.ietf.org/html/draft-ietf-isis-sbfd-
> discriminator-02 could have used GENAPP but rather resorted to Router
> capabilities (Remember IETF90 discussion around this).
> 
> RFC 6823 (GENAPP) requires that information sent in the generic container
> TLV MUST be based on a public specification - and that an application specific
> ID for the application using this mechanism be assigned by IANA. This
> addresses the interoperability issue.
> GENAPP further specifies that such information SHOULD be advertised by a
> separate instance of the routing protocol (as specified in RFC 6822(MI)) so as
> to minimize the impact of the application information flooding on the
> performance of the routing protocol.
> 
> [Uma]: As I indicated earlier [I-D.ietf-ospf-transport-instance] can be
> definitely used if the information related to application need to be used
> there. If it is used for supporting routing one can use this TLV.
> 
> 
> 
> Without addressing both of these issues I cannot support the draft.
> 
>Les
> 
> 
> > -Original Message-
> > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
> > (acee)
> > Sent: Wednesday, March 16, 2016 7:09 PM
> > To: OSPF WG List
> > Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for
> > Agile Service Deployment"
> >
> > We’ve discussed this draft a number of times. In my opinion, it seems
> > like a useful mechanism if one envisions a generalized API between
> > OSPF and user and third-party applications to convey
> > application-specific information learned from other OSPF routers. In
> > many respects, this has already been envisioned for OSPF Node Tags.
> > Please indicate your opinion on this draft before March 31st, 2016.
> >
> > Thanks,
> > Acee
> >
> > ___
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

[Les Ginsberg (ginsberg)]

My opinion of the draft has not changed.

It is defining a way to utilize OSPF to send application information - which is 
not something the protocol should be used to do.
Further, it leaves definition of the new codepoints and formats of the 
information advertised completely unspecified - the latest draft revision 
states:

" The meaning of the operator-defined sub-TLV is totally opaque to OSPF
   and is defined by the network local policy and is controlled via
   configuration.  "

How interoperability is achieved is not addressed at all.

IS-IS has taken a much more stringent approach to a similar request.
RFC 6823 (GENAPP) requires that information sent in the generic container TLV 
MUST be based on a public specification - and that an application specific ID 
for the application using this mechanism be assigned by IANA. This addresses 
the interoperability issue.
GENAPP further specifies that such information SHOULD be advertised by a 
separate instance of the routing protocol (as specified in RFC 6822(MI)) so as 
to minimize the impact of the application information flooding on the 
performance of the routing protocol.

Without addressing both of these issues I cannot support the draft.

   Les


> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
> (acee)
> Sent: Wednesday, March 16, 2016 7:09 PM
> To: OSPF WG List
> Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile
> Service Deployment"
> 
> We’ve discussed this draft a number of times. In my opinion, it seems like a
> useful mechanism if one envisions a generalized API between OSPF and user
> and third-party applications to convey application-specific information
> learned from other OSPF routers. In many respects, this has already been
> envisioned for OSPF Node Tags. Please indicate your opinion on this draft
> before March 31st, 2016.
> 
> Thanks,
> Acee
> 
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] More Comments on OSPF S-BFD Discriminator

[Les Ginsberg (ginsberg)]

There is no discussion ongoing nor any action item for the authors that I am 
aware of.
I believe this state exists because we were waiting for discussion on the S-BFD 
base draft to be resolved.

If ADs require any additional updates they need to tell us – otherwise I think 
this draft should move forward as is.

   Les


From: Acee Lindem (acee)
Sent: Friday, February 05, 2016 7:52 AM
To: Les Ginsberg (ginsberg); Carlos Pignataro (cpignata); Manav Bhatia
Cc: draft-ietf-ospf-sbfd-discrimina...@ietf.org; OSPF WG List; isis...@ietf.org 
list; rtg-...@ietf.org
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

I see the DISCUSS on the IS-IS document is still open - are the authors 
discussing resolution?

https://datatracker.ietf.org/doc/draft-ietf-isis-sbfd-discriminator/ballot/

Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Friday, February 5, 2016 at 9:47 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Carlos Pignataro 
(cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, Manav Bhatia 
<manavbha...@gmail.com<mailto:manavbha...@gmail.com>>
Cc: 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"isis...@ietf.org<mailto:isis...@ietf.org> list" 
<isis...@ietf.org<mailto:isis...@ietf.org>>, 
"rtg-...@ietf.org<mailto:rtg-...@ietf.org>" 
<rtg-...@ietf.org<mailto:rtg-...@ietf.org>>
Subject: RE: [OSPF] More Comments on OSPF S-BFD Discriminator

All of this is fine and as it should be – but the ADs need to tell us if the 
discussion of this point as regards draft-ietf-bfd-seamless-base is concluded 
and the IGP drafts may proceed.
As draft-ietf-bfd-seamless-base has been submitted to IESG for publication I 
assume this should be resolved but the IS-IS Draft still has this state:

“Has a DISCUSS. Has enough positions to pass once DISCUSS positions are 
resolved.”

???

   Les


From: Acee Lindem (acee)
Sent: Friday, February 05, 2016 5:00 AM
To: Carlos Pignataro (cpignata); Manav Bhatia
Cc: Les Ginsberg (ginsberg); 
draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>;
 OSPF WG List
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Carlos, Manav,
 I remember now as well - this is the text I was referring to after the 
discussion including Les.
Thanks,
Acee

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 10:33 PM
To: Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg 
(ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Thank you Manav! I remember now :-)

Done :-)

https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-03

Thanks,

— Carlos.

On Feb 4, 2016, at 9:53 PM, Manav Bhatia 
<manavbha...@gmail.com<mailto:manavbha...@gmail.com>> wrote:

Hi Carlos,

I think we need to add the following in the current version:

“When multiple S-BFD discriminators are advertised how a given discriminator is 
mapped to a specific use case is out of scope for this document.”

I dont have the xml with me that i can update. Can you do it if you have one 
with you?

Cheers, Manav

On Fri, Feb 5, 2016 at 1:17 AM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Hi, Acee,

On Feb 4, 2016, at 2:24 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Hi Carlos,

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 2:16 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: 

Re: [OSPF] More Comments on OSPF S-BFD Discriminator

[Les Ginsberg (ginsberg)]

All of this is fine and as it should be – but the ADs need to tell us if the 
discussion of this point as regards draft-ietf-bfd-seamless-base is concluded 
and the IGP drafts may proceed.
As draft-ietf-bfd-seamless-base has been submitted to IESG for publication I 
assume this should be resolved but the IS-IS Draft still has this state:

“Has a DISCUSS. Has enough positions to pass once DISCUSS positions are 
resolved.”

???

   Les


From: Acee Lindem (acee)
Sent: Friday, February 05, 2016 5:00 AM
To: Carlos Pignataro (cpignata); Manav Bhatia
Cc: Les Ginsberg (ginsberg); draft-ietf-ospf-sbfd-discrimina...@ietf.org; OSPF 
WG List
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Carlos, Manav,
 I remember now as well - this is the text I was referring to after the 
discussion including Les.
Thanks,
Acee

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 10:33 PM
To: Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg 
(ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Thank you Manav! I remember now :-)

Done :-)

https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-03

Thanks,

— Carlos.

On Feb 4, 2016, at 9:53 PM, Manav Bhatia 
<manavbha...@gmail.com<mailto:manavbha...@gmail.com>> wrote:

Hi Carlos,

I think we need to add the following in the current version:

“When multiple S-BFD discriminators are advertised how a given discriminator is 
mapped to a specific use case is out of scope for this document.”

I dont have the xml with me that i can update. Can you do it if you have one 
with you?

Cheers, Manav

On Fri, Feb 5, 2016 at 1:17 AM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Hi, Acee,

On Feb 4, 2016, at 2:24 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Hi Carlos,

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 2:16 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Hi, Acee,

Following up on your note below regarding draft-ietf-ospf-sbfd-discriminator, 
could you request publication and send this document to the IESG?

Has the document been updated with the proposed text? It hasn’t been modified 
since Sept 24, 2015.


Yes. The only text modification proposed and to be implemented was done here:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-02.txt

I do not believe there was anything else pending. Do you mean something else?

Thanks!

Carlos.


Thanks,
Acee


[BTW, its sibling document on ISIS is already in IESG ballot.]

Thanks!

— Carlos.

On Nov 11, 2015, at 4:16 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

I was more concerned about the consumer of the information than the IGPs. I did 
look at base S-BFD draft and I agree this unspecified. Let’s go forward than 
with the proposed text and I will request publication.

Thanks,
Acee






___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] More Comments on OSPF S-BFD Discriminator

[Les Ginsberg (ginsberg)]

Acee –

While I can understand your struggle as to how to select one S-BFD 
discriminator from multiple advertised by a given node, I do not understand why 
you believe the IGPs have a responsibility to address this issue.

At the time both the OSPF and IS-IS S-BFD drafts were first being written this 
question was raised – and the response was that this was outside the scope of 
the IGP drafts. We included the ability to advertise multiple discriminators 
because it was easy to do and future proofed us against unanticipated 
requirements.  But this does not obligate the IGPs to address the mapping 
issue. I think Manav’s proposed text is both appropriate and adequate. (Of 
course I could be biased since the IS-IS draft says the same thing. ☺ )

Please explain what it is that you believe is required and why it should be 
addressed by the  IGP drafts.

   Les


From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, November 09, 2015 2:24 PM
To: Manav Bhatia
Cc: draft-ietf-ospf-sbfd-discrimina...@ietf.org; OSPF WG List
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Hi Manav,

From: Manav Bhatia >
Date: Friday, November 6, 2015 at 11:35 AM
To: Acee Lindem >
Cc: 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org"
 
>,
 "Alvaro Retana (aretana)" >, OSPF 
WG List >
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Hi Acee,

Sorry for the late response.

We will add the following text in the next update

“When multiple S-BFD discriminators are advertised how a given discriminator is 
mapped to a specific use case is out of scope for this document.”

I’m still struggling with the utility of automatic discovery of multiple S-BFD 
discriminators if one has no way to map them to an endpoint or the 
corresponding service.

Thanks,
Acee





Will address the other minor comments in the next rev.

Cheers, Manav

On Mon, Oct 26, 2015 at 5:37 AM, Acee Lindem (acee) 
> wrote:
I have one major comments and I’ve copied Alvaro since he is reviewing the
base S-BFD drafts.

  If an OSPF router advertises multiple BFD discriminators, how do the
other OSPF routers in the OSPF routing domain map the S-BFD discriminators
to the OSPF router IP endpoints and services?

I also have some minor comments:

  1) This draft should reference the RFC 4970BIS draft as this is in RFC
EDIT state.
  2) Section 2.1 - The base RFC 4970BIS draft states that unrecognized
TLVs are ignored (as stated in section 3). This is not specific to this
TLV.
  3) Section 2.2 - This says the Opaque ID must be 0. Note that an OSPF
router can now originate multiple OSPF RI LSAs instances. I think this TLV
should be allowed in an OSPF RI LSA subsequent to the first.
  4) Section 2.2 - I don’t think we should advocate sending an empty OSPF
Router Information LSA. I’d remove this case.


Thanks,
Acee



___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)

[Les Ginsberg (ginsberg)]

Mohamed -

The data can certainly be opaque to OSPF since OSPF is merely acting as a 
transport. But it cannot be opaque to the application which is supposed to 
process this data. The draft currently says:

"There is no need for any specification to define any operator-defined
   sub-TLV.  "

This is what causes me to comment about the need for "clairvoyance". In order 
for interoperability to occur there MUST be a common understanding of the 
format of the data by the originator and the receiver. To say that this does 
not need to be specified anywhere makes this completely non-functional. The 
specification is certainly not an OSPF specification - but there clearly needs 
to be one.

   Les


> -Original Message-
> From: mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> Sent: Tuesday, October 27, 2015 12:08 AM
> To: Les Ginsberg (ginsberg); Acee Lindem (acee); OSPF WG List
> Subject: RE: OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-
> chunduri-ospf-operator-defined-tlvs-01.txt)
> 
> Hi Les,
> 
> Thank you for raising these points, especially the one about abuse (misuse).
> 
> The data is sent as an opaque value. The data may be validated by a receiver
> but this is deployment-specific. Likewise, the specification does not assume
> an order of the TLVs as this is also left to the taste of the operator.
> 
> The draft is not frozen. The text will be worked out for better clarity and a
> discussion (including some recommendation to avoid misuse of the proposal)
> will be considered.
> 
> The issues you raised will be part of our list of issues to handle once the 
> draft
> is adopted as a WG document.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : OSPF [mailto:ospf-boun...@ietf.org] De la part de Les Ginsberg
> > (ginsberg)
> > Envoyé : jeudi 22 octobre 2015 22:04
> > À : Acee Lindem (acee); OSPF WG List
> > Objet : Re: [OSPF] OSPF Operator-Defined TLVs
> > (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.
> > txt)
> >
> > I have two major issues w the draft as it currently stands:
> >
> > 1)It seems to depend upon clairvoyance for interoperability since it
> > claims that no standardization of the format of the values associated
> > w an operator defined TLV is necessary.  Note that here I am NOT
> > talking about what specific code point is assigned to a particular use
> > case - I am talking about the format of the data sent.
> >
> > 2)As it opens the door to use/abuse of the protocol to send
> > information which is not used by the protocol it does not in any way
> > address the impact this could have on the operation of the protocol.
> > This is a major omission.
> >
> > As an example, IS-IS has provided similar  functionality in RFC 6823 -
> > but the document discusses restrictions  restrictions on the use of
> > this extension - notable in Section 7.
> >
> > Unless the authors are prepared to address these issues I cannot
> > support the document.
> >
> >Les
> >
> > > -Original Message-
> > > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
> > > (acee)
> > > Sent: Monday, October 19, 2015 1:29 PM
> > > To: OSPF WG List
> > > Subject: [OSPF] OSPF Operator-Defined TLVs
> > (https://www.ietf.org/id/draft-
> > > chunduri-ospf-operator-defined-tlvs-01.txt)
> > >
> > > This draft has been presented at two IETFs and while I don’t agree
> > > with
> > some
> > > of the proposed use cases as these applications reference should, if
> > fact, be
> > > standardized, I can see that the use case for local applications
> > > could
> > be
> > > compelling. This is the use where OSPF provides an API for local
> > applications
> > > to advertise application-specific information throughout the routing
> > domain
> > > and receive the same parameters from other routers running that
> > > application. Since this is to support local applications
> > > generically,
> > one could
> > > see the reason to allow non-standard parameters to be flooded
> > > opaquely (i.e., OSPF is used solely as a flooding mechanism).
> > >
> > > Please take a look at the draft and indicate whether or not you feel
> > > the
> > OSPF
> > > WG should work on such a solution. If there is enough interest, we
> > > will
> > adopt
> > > it as a WG document.
> > >
> > > Thanks,
> > > Acee
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > OSPF mailing list
> > > OSPF@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ospf
> > ___
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt)

[Les Ginsberg (ginsberg)]

I have two major issues w the draft as it currently stands:

1)It seems to depend upon clairvoyance for interoperability since it claims 
that no standardization of the format of the values associated w an operator 
defined TLV is necessary.  Note that here I am NOT talking about what specific 
code point is assigned to a particular use case - I am talking about the format 
of the data sent.

2)As it opens the door to use/abuse of the protocol to send information which 
is not used by the protocol it does not in any way address the impact this 
could have on the operation of the protocol. This is a major omission.

As an example, IS-IS has provided similar  functionality in RFC 6823 - but the 
document discusses restrictions  restrictions on the use of this extension - 
notable in Section 7.

Unless the authors are prepared to address these issues I cannot support the 
document.

   Les

> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
> (acee)
> Sent: Monday, October 19, 2015 1:29 PM
> To: OSPF WG List
> Subject: [OSPF] OSPF Operator-Defined TLVs (https://www.ietf.org/id/draft-
> chunduri-ospf-operator-defined-tlvs-01.txt)
> 
> This draft has been presented at two IETFs and while I don’t agree with some
> of the proposed use cases as these applications reference should, if fact, be
> standardized, I can see that the use case for local applications could be
> compelling. This is the use where OSPF provides an API for local applications
> to advertise application-specific information throughout the routing domain
> and receive the same parameters from other routers running that
> application. Since this is to support local applications generically, one 
> could
> see the reason to allow non-standard parameters to be flooded opaquely
> (i.e., OSPF is used solely as a flooding mechanism).
> 
> Please take a look at the draft and indicate whether or not you feel the OSPF
> WG should work on such a solution. If there is enough interest, we will adopt
> it as a WG document.
> 
> Thanks,
> Acee
> 
> 
> 
> 
> 
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] H-bit Support for OSPFv2 - draft-keyupate-ospf-ospfv2-hbit-01 WG Document Adoption Poll

[Les Ginsberg (ginsberg)]

Support - similar functionality has proven to be useful in both IS-IS and 
OSPFv3.

  Les

> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
> (acee)
> Sent: Saturday, September 26, 2015 12:05 PM
> To: OSPF WG List
> Subject: [OSPF] H-bit Support for OSPFv2 - draft-keyupate-ospf-ospfv2-hbit-
> 01 WG Document Adoption Poll
> 
> This draft was presented in Prague and there was consensus in the room that
> it was a valid use case. It provides protocol mechanisms to absolutely prevent
> transit traffic for OSPFv2 Routers (RFC 6987 only discourages transit 
> traffic).
> The draft also includes assurance of backward compatibility.
> 
> Please indicate your support (or concerns) for adopting this as a WG
> Document.
> 
> Thanks,
> Acee
> 
> 
> ___
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] OSPF GR and BFD operability

[Les Ginsberg (ginsberg)]

Anil –

IF BFD does NOT share fate w the Control plane then what you say is true.

If BFD shares fate w the control plane then the behavior depends on the 
neighbor knowing that a restart is in progress. If neighbor knows this then the 
BFD down event can be ignored w minimal risk – otherwise you need to treat it 
as a real failure.

   Les


From: Anil Raj [mailto:anilra...@gmail.com]
Sent: Tuesday, August 25, 2015 8:51 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee); OSPF WG List
Subject: Re: [OSPF] OSPF GR and BFD operability

Thanks Acess, Les.

So ideally it is recommended to tear down OSPF adjacency and signal topology 
change, and thus honor BFD notification in this case.

Regards,
Anil

On Tue, Aug 25, 2015 at 8:57 PM, Les Ginsberg (ginsberg) 
ginsb...@cisco.commailto:ginsb...@cisco.com wrote:
https://www.rfc-editor.org/rfc/rfc5882.txt Section 
4.3https://www.rfc-editor.org/rfc/rfc5882.txt%20Section%204.3 is relevant 
here.

   Les


From: OSPF [mailto:ospf-boun...@ietf.orgmailto:ospf-boun...@ietf.org] On 
Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 25, 2015 7:54 AM
To: Anil Raj; OSPF WG List
Subject: Re: [OSPF] OSPF GR and BFD operability

Hi Anil,

OSPF and OSPFv3 graceful restart pre-dated BFD so this wasn’t explicitly 
covered. However, given that the intension is that the data plane is preserved 
during restart, an implementation could interpret this as a topology change and 
terminate helper mode as documented in section 3.2 of RFC 3623.
Hope this helps,
Acee



From: OSPF ospf-boun...@ietf.orgmailto:ospf-boun...@ietf.org on behalf of 
Anil Raj anilra...@gmail.commailto:anilra...@gmail.com
Date: Tuesday, August 25, 2015 at 10:19 AM
To: OSPF WG List ospf@ietf.orgmailto:ospf@ietf.org
Subject: [OSPF] OSPF GR and BFD operability

Hi,

I need clarification on the behavior when BFD notifies remote inactivity for a 
OSPF session, when OSPF neighbor is undergoing Graceful restart? OSPF router in 
helper mode will ideally inactivate the restarting neighbor only after grace 
period, and if BFD notifies neighbor down to OSPF, should the adjacency be 
terminated? If not, will it cause a blackhole for the entire grace period if 
the neighbor is actually down?

Appreciate if you can help here.

Regards,
Anil

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] OSPF GR and BFD operability

[Les Ginsberg (ginsberg)]

https://www.rfc-editor.org/rfc/rfc5882.txt Section 
4.3https://www.rfc-editor.org/rfc/rfc5882.txt%20Section%204.3 is relevant 
here.

   Les


From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 25, 2015 7:54 AM
To: Anil Raj; OSPF WG List
Subject: Re: [OSPF] OSPF GR and BFD operability

Hi Anil,

OSPF and OSPFv3 graceful restart pre-dated BFD so this wasn’t explicitly 
covered. However, given that the intension is that the data plane is preserved 
during restart, an implementation could interpret this as a topology change and 
terminate helper mode as documented in section 3.2 of RFC 3623.
Hope this helps,
Acee



From: OSPF ospf-boun...@ietf.orgmailto:ospf-boun...@ietf.org on behalf of 
Anil Raj anilra...@gmail.commailto:anilra...@gmail.com
Date: Tuesday, August 25, 2015 at 10:19 AM
To: OSPF WG List ospf@ietf.orgmailto:ospf@ietf.org
Subject: [OSPF] OSPF GR and BFD operability

Hi,

I need clarification on the behavior when BFD notifies remote inactivity for a 
OSPF session, when OSPF neighbor is undergoing Graceful restart? OSPF router in 
helper mode will ideally inactivate the restarting neighbor only after grace 
period, and if BFD notifies neighbor down to OSPF, should the adjacency be 
terminated? If not, will it cause a blackhole for the entire grace period if 
the neighbor is actually down?

Appreciate if you can help here.

Regards,
Anil
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] How to handle multiple overlapping SRGB ranges

[Les Ginsberg (ginsberg)]

Bruno -

I am thinking that the behavior you prefer below requires further specification.

Consider an example. We receive the following set of SRGB ranges:

2-22000
21000-24000
26000-28000

In such a case no one would consider using any of the ranges because the first 
two overlap - and using the third range  (which does NOT overlap) is likely to 
be wrong because indices less than 4000 seem like they should be into one of 
the first two ranges - but we can't really be sure because we don't know which 
of the three ranges was misconfigured.

Now, here is a second case:

26000-28000
2-22000
21000-24000

Here, again, we don't know which of the three ranges is misconfigured - but 
because it is the first range which does not conflict you want us to assume 
that it must be correct. We actually have no more reason to believe it is 
correct than we did in the first case - but because it is the first range you 
propose that we trust it.

Now, the second case might be less ambiguous if we had some history - for 
example, suppose the same router had previously advertised:

26000-28000
2-22000

Then it advertised the third range (in conflict w second range) shown above. 
With this history we might feel more strongly that the misconfiguration was 
associated w adding the third range and so it is safe to use the first range. 
But in the absence of history we really don't know which of the ranges should 
be considered valid - we are just hoping that the config error (or 
implementation bug) is confined.

Now, if you want to bring history into the specification, things become less 
predictable because it is possible that a recently booted router won't have the 
history - and so now all routers won't agree on what should be used and what 
should not.

This is an example of how complex things can get when we try to define rules 
about how to deal with a set of information which is in error. This is why, 
though I appreciate your desire to try to preserve what you hope is usable, 
taking a simpler approach (ignore) is appealing. 

   Les

 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of
 bruno.decra...@orange.com
 Sent: Thursday, June 25, 2015 6:58 AM
 To: Stefano Previdi (sprevidi); isis...@ietf.org list
 Cc: ospf@ietf.org
 Subject: Re: [OSPF] How to handle multiple overlapping SRGB ranges
 
  From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stefano
  Previdi (sprevidi)
 
  All,
 
  there's an open question that requires the wg to agree
 
  The issue here is related to SRGB ranges advertised within the SR-Cap
 SubTLV.
 
  The question is: what a receiving router should do when receiving SRGB
  ranges that overlaps ?
 
 Presumably, the question is equally applicable to OSPF, so I'm adding the
 ospf WG in the discussion.
 
 
  Knowing that the spec mandates a single SR-Cap SubTLV, the overlap may
  happen only within the same SR-Cap subTLV and therefore it is clearly
  a local misconfiguration or an implementation bug in the router
  originating the SR- Cap.
 
  Personally, I would recommend to ignore the whole SRGB (not only the
  overlapping ranges) from the faulty router. Ignoring only the
  overlapping ranges would not work since the whole index space is affected
 anyway.
 
 Personally, I would recommend ignoring the overlapping SRGB Descriptor
 and the subsequent ones. But I'd rather keep the SRGB descriptors which are
 before (the overlaps) as they do not pose a problem. Keeping them preserve
 the forwarding of the global Segments using them. This seems inline with the
 IETF  Robustness Principle https://tools.ietf.org/html/rfc1122#section-1.2.2
 
   1.2.2  Robustness Principle
 
  At every layer of the protocols, there is a general rule whose
  application can lead to enormous benefits in robustness and
  interoperability [IP:1]:
 
 Be liberal in what you accept, and
  conservative in what you send
 
  Software should be written to deal with every conceivable
  error, no matter how unlikely; sooner or later a packet will
  come in with that particular combination of errors and
  attributes, and unless the software is prepared, chaos can
  ensue.
 [...]
 host software should be prepared, not
  just to survive other misbehaving hosts, but also to cooperate
  to limit the amount of disruption such hosts can cause to the
  shared communication facility.
 
 In particular cooperate to limit the amount of disruption
 
 Thanks
 /Bruno
 
  There are different opinions on how the receiving router should behave.
  Ideally, we should converge towards a single solution so feel free to
 comment.
 
  Thanks.
  s.
 
  ___
  Isis-wg mailing list
  isis...@ietf.org
  https://www.ietf.org/mailman/listinfo/isis-wg
 
 __
 

[OSPF] Comments on draft-ietf-ospf-node-admin-tag-00

[Les Ginsberg (ginsberg)]

I have some comments in this draft.

Introduction

I think the last sentence should be removed. It is providing an example of a 
use case - and as such is more appropriate for Section 5. 

Also, node-tags are a property of the node - not of the routing protocol used 
to advertise them - I would like to see this point explicitly stated. Perhaps 
something like:

Per-node administrative tags are used to advertise an attribute of the node. 
As such they are independent of the routing protocol used to advertise them. 


Section 2
---

This section seems redundant w Section 1. It should be removed.

Section 3 - Last Paragraph
--
What is the reason for restricting the # of tags in a single TLV to 64? As OSPF 
TLVs have a 16 bit length field this restriction seems arbitrary.

Figure 1
---
The format of the ASCII art above needs to be corrected to properly indicate 
the field lengths.

Section 5
-

I would like to see this section moved to an Appendix. Since this section is 
not normative that would more clearly separate the normative/non-normative 
parts.

   Les

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Shraddha -

As Jeff has already mentioned, the case you are concerned about can be handled 
using LFA selection strategies discussed in 
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ 
And it is a far better solution since it allows the traffic of interest to be 
protected = less traffic interruption.

   Les



-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net] 
Sent: Monday, January 05, 2015 12:49 AM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Les,

Pls consider a case when the post convergence path goes through a different 
node and is well provisioned.

 G---
| |
ABCD
|   |
  EF

When the link between B  C goes down, we don’t want to divert the traffic via 
B-E-E-F-C because it is not well provisioned for the service.
The post convergence path is A-G-D which is well provisioned.
In this case it makes sense to simply avoid protection for the service as the 
nature of the service is such that it can be disconnected and reconnected 
without impacting the end user of the service.


The post convergence paths need to be provisioned at least for one failure if 
that is not the case then the service will remain down Irrespective of the 
technology used.


Rgds
Shraddha

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, January 05, 2015 12:07 PM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Pushpasis -

Inline.

-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net]
Sent: Sunday, January 04, 2015 10:13 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,


On 1/5/15, 11:23 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Pushpasis -

The key point is that the proposal does not have any lasting impact on 
traffic flow. A simple topology should suffice to illustrate this.


ABCD
  |   |
  EF

(All links have the same cost)

Suppose we wish to have traffic entering at A flow along the path 
A-B-C-D
- but if the link B---C fails we do NOT want traffic to take the path 
B--E--F--C.

You propose to have C advertise an address with two node-sids - one 
which allows protection - call it C(P) - and one which does NOT allow 
protection - call it C(NP).
[Pushpasis] No. My proposal is for D to advertise two node sids, D1 with NP set 
to 0 and D2 with NP set to 1. Applications on that do not need B, or C to 
protect the A-B-C-D path will use D2. B and C will not install backup paths for 
D2. Other apps can use D1 as they are supposed to do otherwise. Wether to 
protect D1 or not is a local decision of B and C.
Hope I could clarify enough :)

[Les:] Whether we talk about C or D doesn’t matter. As you point out below the 
issue you are concerned with is the FIB update time on the intermediate nodes 
relative to the recomputation on the ingress node.


If the label stack specifies C(NP) - then while the link B--C is UP 
everything works as desired (primary path to C(NP) on Node B is via 
link B-C).
However, when the link B--C goes down, the network will reconverge and 
in a modest amount of time the new primary path to C(NP) on node B will 
be via link B-E.
[Pushpasis] Yes agreed. But only applications on A will be injecting traffic 
using D2. Once the B-C link-down event reaches router A will stop injecting 
traffic using D2. A path re-compute will be triggered on A. Yes I agree that if 
B converges D2 (not FRR) before A re-compute, there is still chance that some 
small amount of traffic is sent over A-B-E-F-C-D.

[Les:] Well yes - the key point is that you cannot guarantee the timing of when 
B (for example) will reconverge relative to when the ingress node A decides to 
reroute/drop the D2 traffic. Given that B is closer to the failure it is quite 
likely that B will respond more quickly than A - and of course there are many 
other variables which could affect the relative response time of A and B. So 
the sole benefit of what you propose seems to be that in some cases you MIGHT 
not send as much traffic to D2 via the undesired links.

At this point I think

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Pushpasis -

I don't agree.

The use of one node-sid vs another has nothing whatever to do with the request 
Shraddha has made i.e. should we introduce a flag indicating whether a 
particular prefix should be protected or not. A node-sid only dictates what 
(intermediate) node traffic should be sent to - not what link(s) are used to 
reach that node.

Adjacency-sids have a different semantic - they identify the link over which 
traffic is to be forwarded. Identifying an adjacency-sid as unprotected means 
traffic will NEVER flow over a different link. There is no equivalent behavior 
w a node-sid - which is what this discussion has been about.

   Les


-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net] 
Sent: Sunday, January 04, 2015 8:51 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,

I think the requirement Shraddha is referring is about the choice of exact 
node-sid to use while constructing the label-stack for a explicit-LSP on the 
ingress router, which will be typically done after running some CSPF on the 
SPRING topology. And not the IGP on ingress or transit routers.

Thanks
-Pushpasis

On 1/3/15, 3:10 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Shraddha -

IGPs today do NOT perform constraint based SPFs - so I don't know why 
you believe that the primary SPF will meet a set of constraints that an 
LFA calculation will not. In fact , it is the opposite which is true 
because implementations today do support preferences in choosing LFAs 
based on various configured policy - something which is NOT done for primary 
SPF.

If you want a certain class of traffic to avoid a subset of the links 
in the topology then you need to have a way of identifying the links 
(NOT the node addresses) and a way of calculating a path which only 
uses the links which meet the constraints of that class of service. 
Identifying a particular prefix as protected or unprotected won't achieve that.

   Les

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Friday, January 02, 2015 10:54 AM
To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions

Hi Les/Peter,

  When reconvergence happens, the primary path will be calculated 
based on all constriants.
This is not true with the protection path.Protection path is calculated 
locally (LFA/RLFA)  and does not consider the characteristics of the 
services running on that path.
It's easier for some services to pick the unprotected path when the 
nature of the service is that it can be restarted  when there is a 
disconnection.

Rgds
Shraddha
-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 02, 2015 10:06 PM
To: Peter Psenak (ppsenak); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions

Peter -

The requirement Shraddha specified was to not allow a particular class 
of service (heavy bandwidth services was the example provided) to use 
certain links in the topology. My point is that advertising a flag for 
a given prefix which says do not calculate a repair path for this prefix
does not help achieve this. Once the network reconverges following the 
failure of one of the links on which heavy bandwidth services is 
allowed/preferred it is quite likely that the new best path will be 
over a link on which heavy bandwidth services is NOT 
allowed/preferred. This will happen whether you have the new flag or 
not - so the flag will have no lasting effect. It would only affect 
traffic flow during the brief period during which the network is reconverging.

I think you and I are actually in agreement - I am simply sending a 
stronger negative message - not only do I think the flag is not useful 
- I think it does not achieve the goal Shraddha has in mind.

   Les


-Original Message-
From: Peter Psenak (ppsenak)
Sent: Friday, January 02, 2015 12:18 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions

Hi Les,

I believe the idea is not to exclude any particular link, it's actually 
much simpler - do not calculate backup

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Pushpasis -

Inline.

-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net] 
Sent: Sunday, January 04, 2015 10:13 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,


On 1/5/15, 11:23 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Pushpasis -

The key point is that the proposal does not have any lasting impact on 
traffic flow. A simple topology should suffice to illustrate this.


ABCD
  |   |
  EF

(All links have the same cost)

Suppose we wish to have traffic entering at A flow along the path 
A-B-C-D
- but if the link B---C fails we do NOT want traffic to take the path 
B--E--F--C.

You propose to have C advertise an address with two node-sids - one 
which allows protection - call it C(P) - and one which does NOT allow 
protection - call it C(NP).
[Pushpasis] No. My proposal is for D to advertise two node sids, D1 with NP set 
to 0 and D2 with NP set to 1. Applications on that do not need B, or C to 
protect the A-B-C-D path will use D2. B and C will not install backup paths for 
D2. Other apps can use D1 as they are supposed to do otherwise. Wether to 
protect D1 or not is a local decision of B and C.
Hope I could clarify enough :)

[Les:] Whether we talk about C or D doesn’t matter. As you point out below the 
issue you are concerned with is the FIB update time on the intermediate nodes 
relative to the recomputation on the ingress node.


If the label stack specifies C(NP) - then while the link B--C is UP 
everything works as desired (primary path to C(NP) on Node B is via 
link B-C).
However, when the link B--C goes down, the network will reconverge and 
in a modest amount of time the new primary path to C(NP) on node B will 
be via link B-E.
[Pushpasis] Yes agreed. But only applications on A will be injecting traffic 
using D2. Once the B-C link-down event reaches router A will stop injecting 
traffic using D2. A path re-compute will be triggered on A. Yes I agree that if 
B converges D2 (not FRR) before A re-compute, there is still chance that some 
small amount of traffic is sent over A-B-E-F-C-D.

[Les:] Well yes - the key point is that you cannot guarantee the timing of when 
B (for example) will reconverge relative to when the ingress node A decides to 
reroute/drop the D2 traffic. Given that B is closer to the failure it is quite 
likely that B will respond more quickly than A - and of course there are many 
other variables which could affect the relative response time of A and B. So 
the sole benefit of what you propose seems to be that in some cases you MIGHT 
not send as much traffic to D2 via the undesired links.

At this point I think you would do well to look at the existing solutions - as 
well as Jeff's post on this thread which provides an excellent framework for 
thinking about solutions. We do have ways of addressing this problem and doing 
so far more robustly than what you are proposing. The ROI for what you propose 
is quite low. For my part I don’t think what you propose is a good idea.

Les


The existence of C(NP) therefore only affects traffic flow during the 
reconvergence period i.e. if we assume B did NOT install a repair path 
for C(NP) traffic will be dropped only until a new primary path is 
calculated. I don’t see the value in this.

As a (somewhat dangerous) aside, the functionality you are looking for 
is more akin to not-via as defined in RFC 6981 - though I am quick to 
add that I am NOT proposing to pursue that. :-) But reading that RFC 
might give you more insight into why simply setting don't protect for 
a prefix isn't useful for the purpose you have in mind.

   Les



-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net]
Sent: Sunday, January 04, 2015 8:34 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes 
Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,

Please find comments inline..

Authors,

Here is my proposal. Please let me know if this sounds reasonable or not.

- A new ŒNo-Potection-Required¹ or ŒNP¹ flag be added to the Prefix-SID 
Sub-TLV/TLV. Setting this flag means none of the transit routers should 
try to protect this node-segment.
- Let nodes advertise two node-sid-index each (per address-family), one 
without and one with ŒNP¹ flag set. For node-sid advertised with ŒNP¹ 
flag 0, routers same behave the same way as today. But when they 
receive a node-sid with ŒNP¹ flag set, they avoid/skip finding a backup

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Pushpasis -

The key point is that the proposal does not have any lasting impact on traffic 
flow. A simple topology should suffice to illustrate this.


ABCD
  |   |
  EF

(All links have the same cost)

Suppose we wish to have traffic entering at A flow along the path A-B-C-D - but 
if the link B---C fails we do NOT want traffic to take the path B--E--F--C.

You propose to have C advertise an address with two node-sids - one which 
allows protection - call it C(P) - and one which does NOT allow protection - 
call it C(NP).

If the label stack specifies C(NP) - then while the link B--C is UP everything 
works as desired (primary path to C(NP) on Node B is via link B-C).
However, when the link B--C goes down, the network will reconverge and in a 
modest amount of time the new primary path to C(NP) on node B will be via link 
B-E.

The existence of C(NP) therefore only affects traffic flow during the 
reconvergence period i.e. if we assume B did NOT install a repair path for 
C(NP) traffic will be dropped only until a new primary path is calculated. I 
don’t see the value in this.

As a (somewhat dangerous) aside, the functionality you are looking for is more 
akin to not-via as defined in RFC 6981 - though I am quick to add that I am 
NOT proposing to pursue that. :-)
But reading that RFC might give you more insight into why simply setting don't 
protect for a prefix isn't useful for the purpose you have in mind.

   Les



-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net] 
Sent: Sunday, January 04, 2015 8:34 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org; Hannes Gredler
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,

Please find comments inline..

Authors, 

Here is my proposal. Please let me know if this sounds reasonable or not.

- A new ŒNo-Potection-Required¹ or ŒNP¹ flag be added to the Prefix-SID 
Sub-TLV/TLV. Setting this flag means none of the transit routers should try to 
protect this node-segment.
- Let nodes advertise two node-sid-index each (per address-family), one without 
and one with ŒNP¹ flag set. For node-sid advertised with ŒNP¹ flag 0, routers 
same behave the same way as today. But when they receive a node-sid with ŒNP¹ 
flag set, they avoid/skip finding a backup for that segment.
- Finally ingress servers or TE-applications may use these 'node-sids with 
NP-flag set¹ for use cases where it is better to drop traffic on topology 
outages rather than diverting it to some other paths. For such cases ingress 
router or TE-applications should look for node-sids with ŒNP¹ flag set and not 
the regular node-sids. For all other normal use cases(including L3VPN/6VPE etc) 
traffic should be carried using node-sid without ŒNP‹flag set.

Thanks and Regards,
-Pushpasis

On 1/5/15, 3:37 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Pushpasis -

I don't agree.

The use of one node-sid vs another has nothing whatever to do with the 
request Shraddha has made i.e. should we introduce a flag indicating 
whether a particular prefix should be protected or not. A node-sid only 
dictates what (intermediate) node traffic should be sent to - not what
link(s) are used to reach that node.
[Pushpasis] This is not about which links to take. It is about wether transit 
routers should try to protect the node-segment to the this node-sid or not. I 
think this opens up a lot many number of possibilities on the ingress router 
and TE controller-based applications.


Adjacency-sids have a different semantic - they identify the link over 
which traffic is to be forwarded. Identifying an adjacency-sid as 
unprotected means traffic will NEVER flow over a different link. There 
is no equivalent behavior w a node-sid - which is what this discussion 
has been about.
[Pushpasis] I am not trying to draw a parallel between this new flag and the 
ŒB¹ flag in Adj-Sid SubTlv. Like said before


   Les


-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net]
Sent: Sunday, January 04, 2015 8:51 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,

I think the requirement Shraddha is referring is about the choice of 
exact node-sid to use while constructing the label-stack for a 
explicit-LSP on the ingress router, which will be typically done after 
running some CSPF on the SPRING topology. And not the IGP on ingress or 
transit routers.

Thanks
-Pushpasis

On 1/3/15, 3:10 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Shraddha

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Shraddha -

Inline.

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net] 
Sent: Sunday, January 04, 2015 9:27 PM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Les,


I agree with the point you made that the requirement of not protecting certain 
services can be met today using the LFA-manageability draft. 

[Les:] I did not say that. :-)

Deploying the solution using LFA manageability requires that the 

1. Services be represented by different prefixes 2. Come up with a policy that 
makes sure no backup path is downloaded for the prefix 3. Configure  the policy 
in each node in the network.
4. Repeat the process whenever a new service with similar characteristic comes 
up


The advantage of having an unprotected path to each node is the ease of 
deployment.

[Les:] Please read my reply to Pushpasis. Having an unprotected path is no 
guarantee that traffic will not flow on what would have been the protectING 
path (if a node had installed one) after reconvergence. So your proposal only 
impacts traffic flow for a brief period.

   Les

LFA-manageability has its own advantage of fine tuning the backup paths and I 
am not denying that.
I am trying to say that for certain use-cases it is easy to have unprotected 
paths in the network for each node And use those path for services that need 
such paths.

If someone wants to simply have a unprotected path for certain node and use it 
for all the services Which don't need protection, that flexibility should be 
available in the protocol. 
That is the reason I am saying that we should have No protection flag in the 
prefix-SID.


Rgds
Shraddha

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, January 05, 2015 3:37 AM
To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Pushpasis -

I don't agree.

The use of one node-sid vs another has nothing whatever to do with the request 
Shraddha has made i.e. should we introduce a flag indicating whether a 
particular prefix should be protected or not. A node-sid only dictates what 
(intermediate) node traffic should be sent to - not what link(s) are used to 
reach that node.

Adjacency-sids have a different semantic - they identify the link over which 
traffic is to be forwarded. Identifying an adjacency-sid as unprotected means 
traffic will NEVER flow over a different link. There is no equivalent behavior 
w a node-sid - which is what this discussion has been about.

   Les


-Original Message-
From: Pushpasis Sarkar [mailto:psar...@juniper.net]
Sent: Sunday, January 04, 2015 8:51 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [OSPF] [Isis-wg] Mail regarding 
draft-ietf-ospf-segment-routing-extensions

Hi Les,

I think the requirement Shraddha is referring is about the choice of exact 
node-sid to use while constructing the label-stack for a explicit-LSP on the 
ingress router, which will be typically done after running some CSPF on the 
SPRING topology. And not the IGP on ingress or transit routers.

Thanks
-Pushpasis

On 1/3/15, 3:10 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote:

Shraddha -

IGPs today do NOT perform constraint based SPFs - so I don't know why 
you believe that the primary SPF will meet a set of constraints that an 
LFA calculation will not. In fact , it is the opposite which is true 
because implementations today do support preferences in choosing LFAs 
based on various configured policy - something which is NOT done for primary 
SPF.

If you want a certain class of traffic to avoid a subset of the links 
in the topology then you need to have a way of identifying the links 
(NOT the node addresses) and a way of calculating a path which only 
uses the links which meet the constraints of that class of service.
Identifying a particular prefix as protected or unprotected won't achieve that.

   Les

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Friday, January 02, 2015 10:54 AM
To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [Isis-wg] Mail regarding
draft-ietf-ospf-segment-routing-extensions

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Peter -

The requirement Shraddha specified was to not allow a particular class of 
service (heavy bandwidth services was the example provided) to use certain 
links in the topology. My point is that advertising a flag for a given prefix 
which says do not calculate a repair path for this prefix does not help 
achieve this. Once the network reconverges following the failure of one of the 
links on which heavy bandwidth services is allowed/preferred it is quite 
likely that the new best path will be over a link on which heavy bandwidth 
services is NOT allowed/preferred. This will happen whether you have the new 
flag or not - so the flag will have no lasting effect. It would only affect 
traffic flow during the brief period during which the network is reconverging.

I think you and I are actually in agreement - I am simply sending a stronger 
negative message - not only do I think the flag is not useful - I think it does 
not achieve the goal Shraddha has in mind.

   Les


-Original Message-
From: Peter Psenak (ppsenak) 
Sent: Friday, January 02, 2015 12:18 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

I believe the idea is not to exclude any particular link, it's actually much 
simpler - do not calculate backup for the prefix if the flag is set.

I'm still not quite sure how useful above is, but technically it is possible.

thanks,
Peter

On 12/30/14 17:22 , Les Ginsberg (ginsberg) wrote:
 Shraddha -

 When performing a best path calculation whether a given link is in the set of 
 best paths (to be protectedED) or not (could be used as a protectING path) is 
 a function of the topology - not the link.  If there is a topology change it 
 is quite likely that a given link will change from being a protectED link to 
 being a protectING link (or vice versa). So what you propose regarding 
 node-SIDs would not work.

 In the use case you mention below if you don't want a certain class of 
 traffic to flow on a given link it requires a link attribute which is 
 persistent across topology changes. There are ways to do that - using 
 Adj-SIDs is one of them. But using node-SIDs in the way you propose is NOT.

 Les

 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
 Sent: Monday, December 29, 2014 10:12 PM
 To: Peter Psenak (ppsenak); 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [OSPF] [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Peter,

 The requirement here is to get an un-protected path for services which do 
 not want to divert the traffic on protected path in any case.

 can you give an example of such a service and a reasoning why such service 
 would want to avoid local protection along the path?

 Heavy bandwidth services are potential candidates.  The network is well 
 planned and well provisioned for primary path but same is not true for backup 
 paths.
 Diverting heavy bandwidth services along protection path can disrupt the 
 other services on that path, they are better-off un-protected so that an 
 event in the network Would result in disconnection and a retry for such 
 services.

 Rgds
 Shraddha

 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 4:35 PM
 To: Shraddha Hegde; 
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Shraddha,

 On 12/29/14 10:06 , Shraddha Hegde wrote:
 Peter,

 The requirement here is to get an un-protected path for services which do 
 not want to divert the traffic on protected path in any case.

 can you give an example of such a service and a reasoning why such service 
 would want to avoid local protection along the path?

 thanks,
 Peter

 So when the originator of node-sid signals un-protected path requirement, 
 there is always an unprotected path.

 Regarding the protected path, it is the default behavior as it exists today. 
 You get protection if it's available otherwise you don't get protection.

 In fact, you can have the new flag to say NP flag meaning non-protected 
 flag which can be set for the unprotected path.
 By default it remains off and gives the behavior as it exists today.


 Rgds
 Shraddha

 -Original Message-
 From: Peter Psenak [mailto:ppse...@cisco.com]
 Sent: Monday, December 29, 2014 2:26 PM
 To: Shraddha Hegde;
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

[Les Ginsberg (ginsberg)]

Shraddha -

IGPs today do NOT perform constraint based SPFs - so I don't know why you 
believe that the primary SPF will meet a set of constraints that an LFA 
calculation will not. In fact , it is the opposite which is true because 
implementations today do support preferences in choosing LFAs based on various 
configured policy - something which is NOT done for primary SPF.

If you want a certain class of traffic to avoid a subset of the links in the 
topology then you need to have a way of identifying the links (NOT the node 
addresses) and a way of calculating a path which only uses the links which meet 
the constraints of that class of service. Identifying a particular prefix as 
protected or unprotected won't achieve that.

   Les

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net] 
Sent: Friday, January 02, 2015 10:54 AM
To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak); 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les/Peter,

  When reconvergence happens, the primary path will be calculated based on 
all constriants.
This is not true with the protection path.Protection path is calculated locally 
(LFA/RLFA)  and does not consider the characteristics of the services running 
on that path. 
It's easier for some services to pick the unprotected path when the nature of 
the service is that it can be restarted  when there is a disconnection.

Rgds
Shraddha
-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, January 02, 2015 10:06 PM
To: Peter Psenak (ppsenak); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: RE: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Peter -

The requirement Shraddha specified was to not allow a particular class of 
service (heavy bandwidth services was the example provided) to use certain 
links in the topology. My point is that advertising a flag for a given prefix 
which says do not calculate a repair path for this prefix does not help 
achieve this. Once the network reconverges following the failure of one of the 
links on which heavy bandwidth services is allowed/preferred it is quite 
likely that the new best path will be over a link on which heavy bandwidth 
services is NOT allowed/preferred. This will happen whether you have the new 
flag or not - so the flag will have no lasting effect. It would only affect 
traffic flow during the brief period during which the network is reconverging.

I think you and I are actually in agreement - I am simply sending a stronger 
negative message - not only do I think the flag is not useful - I think it does 
not achieve the goal Shraddha has in mind.

   Les


-Original Message-
From: Peter Psenak (ppsenak)
Sent: Friday, January 02, 2015 12:18 AM
To: Les Ginsberg (ginsberg); Shraddha Hegde; 
draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org; 
draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
Cc: ospf@ietf.org; isis...@ietf.org
Subject: Re: [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Hi Les,

I believe the idea is not to exclude any particular link, it's actually much 
simpler - do not calculate backup for the prefix if the flag is set.

I'm still not quite sure how useful above is, but technically it is possible.

thanks,
Peter

On 12/30/14 17:22 , Les Ginsberg (ginsberg) wrote:
 Shraddha -

 When performing a best path calculation whether a given link is in the set of 
 best paths (to be protectedED) or not (could be used as a protectING path) is 
 a function of the topology - not the link.  If there is a topology change it 
 is quite likely that a given link will change from being a protectED link to 
 being a protectING link (or vice versa). So what you propose regarding 
 node-SIDs would not work.

 In the use case you mention below if you don't want a certain class of 
 traffic to flow on a given link it requires a link attribute which is 
 persistent across topology changes. There are ways to do that - using 
 Adj-SIDs is one of them. But using node-SIDs in the way you propose is NOT.

 Les

 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
 Sent: Monday, December 29, 2014 10:12 PM
 To: Peter Psenak (ppsenak);
 draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org;
 draft-ietf-isis-segment-routing-extensi...@tools.ietf.org
 Cc: ospf@ietf.org; isis...@ietf.org
 Subject: Re: [OSPF] [Isis-wg] Mail regarding 
 draft-ietf-ospf-segment-routing-extensions

 Peter,

 The requirement here is to get an un-protected path for services which do 
 not want to divert the traffic on protected path in any case.

 can you

Re: [OSPF] OSPF WG Poll for adoption of Yang Data Model for OSPF Protocol (resent in plan text mode)

[Les Ginsberg (ginsberg)]

Support.

   Les

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, December 02, 2014 4:57 PM
To: OSPF WG List
Subject: [OSPF] OSPF WG Poll for adoption of Yang Data Model for OSPF 
Protocol (resent in plan text mode)

We¹ve been working on this for several IETFs now and the chairs believe it is 
time for WG adoption. Note that this document started in the NETMOD WG.
Please indicate your support of opposition of WG adoptions. Here is a URL for 
your convenience:

http://www.ietf.org/id/draft-yeung-netmod-ospf-02.txt

Thanks,
Acee and Abhay

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

[OSPF] WG Draft QA review of draft-ietf-ospf-routable-ip-address-00

[Les Ginsberg (ginsberg)]

Hello,



I have been selected as the Routing Directorate QA reviewer for 
draft-ietf-ospf-routable-ip-address-00.



The Routing Directorate QA reviews are intended to be a support to improve the 
quality of RTG Area documents as they pass through the IETF process. This is 
the QA review just after WG adoption.



Summary



This draft defines a useful extension to OSPF to allow routers in other areas 
to be able to associate reachable addresses with a router which supports a

particular capability. I do not foresee any major hurdles in this document 
progressing to become an RFC.



Comments



It would be beneficial to explain why the routable address information only 
needs to be flooded with domain-scope

(i.e. explain how routers in the area already have this information).



I suspect the security folks will likely point to the dangers of advertising 
local node addresses domain wide -

which may make it easier for a node in one area to be targeted from another 
area. The security section should

anticipate this by referencing the various OSPF authentication RFCs as the 
means to protect this information.



Major Issues



No major issues found.



Minor Issues



The IANA Comsiderations section should refer to the OSPF Router Information 
(RI) TLVs Registry defined by [RFC4970].



Nits



Abstract: Last sentence

   s/the OSPF/the term OSPF



Introduction: First paragraph

propagated to another area, those routers in the latter area need...



The sentence should end after area and a new sentence begin with Those.



Introduction: Last sentence

   s/the OSPF/the term OSPF



Section 3: penultimate sentence

The phrase



  within the body of the corresponding RI Opaque LSA



can be removed. It repeats the first sentence of the paragraph and does not 
match the equivalent text in Section 4.










___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

[Les Ginsberg (ginsberg)]

Adding the IS-IS WG since there is an equivalent draft for IS-IS submitted by 
the same authors.

IF this were something the respective WGs decide the protocol should support, 
then running a separate instance of the protocol so that the flowspec  
advertisements can be isolated from the primary function of the IGP (routing) 
would be the right way to implement it - and this is precisely what GENINFO/MI 
(RFC 6823/6822) were defined to address. OSPF Transport instance would be the 
analogous mechanism for OSPF.

But the first question is whether this is something the IGPs should support at 
all. As Acee has indicated this was proposed previously in OSPF and there was 
little interest. In the case of IS-IS there is even less reason to consider it 
since IS-IS is NOT deployed as a PE-CE protocol.

   Les


 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
 (acee)
 Sent: Wednesday, October 08, 2014 9:36 AM
 To: Peter Psenak (ppsenak)
 Cc: ospf@ietf.org
 Subject: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-
 extensions-01.txt
 
 Hi Peter, et al,
 I’ve also seen many OSPF PE-CE deployments as well. One question is
 whether the CE is under the administrative control of the provider or the
 customer?
 Note that this was proposed at least once before -
 http://www.ietf.org/archive/id/draft-shrivastava-ospf-flow-spec-01.txt bit
 it didn’t gain momentum.
 
 With respect to Hannes’ comment, Les Ginsberg said he sees this as a
 candidate for the ISIS Generic Information instance (RFC 6823). We could do
 the same and push it to the OSPF transport instance which has also lost
 momentum as a draft.
 
 We’ve heard from one provider (Eric) who doesn’t think this is useful - any
 other input?
 
 One thing I hope is that no sees this a generic flow-spec distribution
 mechanism for SDN. The reason being that you really need per peer
 granularity of advertisement and policy, e.g. BGP.
 
 Thanks,
 Acee
 
 On Oct 8, 2014, at 12:16 PM, Peter Psenak ppse...@cisco.com wrote:
 
  Hi Eric,
 
  there are definitely deployments using OSPF as PE-CE. It's typically used
 for enterprise customers, that use OSPF as their IGP and use L3 VPN service
 to interconnect their sites.
 
  thanks,
  Peter
 
  On 10/8/14 17:45 , Osborne, Eric wrote:
  I'm not sure this has much value.  The vast majority of dynamic PE-CE is
 done with BGP; the little bit that isn't BGP is, in my experience, RIP.  I 
 don't
 think I've seen many (any?) OSPF PE-CE deployments.
 
 
 
 
  eric
 
  -Original Message-
  From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Youjianjie
  Sent: Tuesday, October 07, 2014 10:11 PM
  To: ospf@ietf.org
  Subject: [OSPF] 转发: New Version Notification for draft-liang-ospf-
 flowspec-extensions-01.txt
 
  Hi all,
 
  This document discusses the use cases that OSPF is used to distribute
 FlowSpec routes. This document also defines a new OSPF FlowSpec Opaque
 Link State Advertisement (LSA) encoding format.
  Your comments are appreciated.
 
  Best Regards,
  Jianjie
 
  -邮件原件-
  发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
  发送时间: 2014年9月28日 10:32
  收件人: Youjianjie; Youjianjie; liuweihang; liuweihang
  主题: New Version Notification for draft-liang-ospf-flowspec-
 extensions-01.txt
 
 
  A new version of I-D, draft-liang-ospf-flowspec-extensions-01.txt
  has been successfully submitted by Jianjie You and posted to the IETF
 repository.
 
  Name:  draft-liang-ospf-flowspec-extensions
  Revision:  01
  Title: OSPF Extensions for Flow Specification
  Document date: 2014-09-27
  Group: Individual Submission
  Pages: 11
  URL:http://www.ietf.org/internet-drafts/draft-liang-ospf-
 flowspec-extensions-01.txt
  Status: https://datatracker.ietf.org/doc/draft-liang-ospf-flowspec-
 extensions/
  Htmlized:   http://tools.ietf.org/html/draft-liang-ospf-flowspec-
 extensions-01
  Diff:   http://www.ietf.org/rfcdiff?url2=draft-liang-ospf-flowspec-
 extensions-01
 
  Abstract:
 This document discusses the use cases why OSPF (Open Shortest Path
 First) distributing flow specification (FlowSpec) routes is
 necessary.  This document also defines a new OSPF FlowSpec Opaque
 Link State Advertisement (LSA) encoding format that can be used to
 distribute FlowSpec routes.
 
 For the network only deploying IGP (Interior Gateway Protocol) (e.g.
 OSPF), it is expected to extend IGP to distribute FlowSpec routes.
 One advantage is to mitigate the impacts of Denial-of-Service (DoS)
 attacks.
 
 
 
 
 
  Please note that it may take a couple of minutes from the time of
 submission until the htmlized version and diff are available at 
 tools.ietf.org.
 
  The IETF Secretariat
 
  ___
  OSPF mailing list
  OSPF@ietf.org
  https://www.ietf.org/mailman/listinfo/ospf
  

Re: [OSPF] Poll for WG adoption of draft-xu-ospf-routable-ip-address

[Les Ginsberg (ginsberg)]

Support.

Les

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Abhay Roy (akr)
Sent: Monday, August 25, 2014 12:09 PM
To: ospf@ietf.org
Subject: [OSPF] Poll for WG adoption of draft-xu-ospf-routable-ip-address

This is a simple document with a few strong drivers (ELC and S-BFD) requiring 
it..

Please share your support or objections in making it a WG document.

Regards,
-Abhay
On 8/25/14, 11:57 AM, Abhay Roy wrote:
[speaking as WG member]

Two comments..

1. Section 3 has this text - This TLV is only applicable to OSPFv2..
I believe, this should also be applicable to RFC5838, i.e. for IPv4 AF's

2. Section 3 and 4 describes the scope as SHOULD be domain-wide. I personally 
don't see any real use cause of any lessor scope (Area or Link) since we have 
mechanisms to generate routable IP address for those scopes already. So I would 
suggest we limit the scope of this document to be MUST be domain-wide. Any 
concerns with that?

Regards,
-Abhay




___

OSPF mailing list

OSPF@ietf.orgmailto:OSPF@ietf.org

https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

[Les Ginsberg (ginsberg)]

I support making this draft a WG item - but I do think a much more complete 
discussion regarding the tradeoffs between using node tags vs capability 
identifiers needs to be included - if for no other reason than if/when this 
draft were to become an RFC we would have two mechanisms and it  is not so 
clear when it is more appropriate to use one over another.

We don't have to come to a conclusion on that issue in this thread - nor should 
it preclude making this a WG item - but it is definitely an important issue to 
be discussed.

   Les


 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
 (ppsenak)
 Sent: Tuesday, August 26, 2014 9:40 AM
 To: Hannes Gredler
 Cc: ospf@ietf.org
 Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-
 tag
 
 Hi Hannes,
 
 On 8/26/14 17:59 , Hannes Gredler wrote:
  hi peter,
 
  understood - so what about simply reserving a certain range of the tag
 space
  for well-known applications (+IANA registry etc.) such that
  for 2) we can avoid distributing policies ?
 
 we have an existing mechanism for advertising capabilities - RFC4970,
 section 2.3 and 2.4. We can reserve a bit for each well-known application.
 
 thanks,
 Peter
 
 
  /hannes
 
  On Tue, Aug 26, 2014 at 05:43:48PM +0200, Peter Psenak wrote:
  | Hi Hannes,
  |
  | On 8/26/14 17:32 , Hannes Gredler wrote:
  | hi peter,
  | 
  | operators want to assign node-tags as per router function (ABR, PE,
 core) and then
  | the LFA-selection becomes much easier to specify. - e.g.
  | - only pick a LFA that does not cross another PE router.
  | 
  | similarily it is desirable for LFA tunnel termination
  | to put out a constraint which says
  | - only pick a PQ neighbor which has node tag 'X'
  |
  | my point is that with the above approach you have to:
  | 1. On candidate PQ nodes configure the tag X
  | 2. on all other nodes configure only pick a PQ neighbor which has node
 tag
  | 'X'
  |
  | It's (2) which makes me feel uncomfortable, as it's a config to be applied
  | to many nodes.
  |
  | If we instead define a capability bit which would mean PQ candidate,
 we
  | would avoid (2).
  |
  | 
  | i found it always strange that we for TE (as an example for
  | constraining paths) we have got ways to tag links, but
  | not way to tag nodes - that draft aims to fix that.
  |
  | I'm not against tagging nodes as such. What worries me if we end up
 using
  | node tags for signalling capabilities of node.
  |
  | thanks,
  | Peter
  |
  | 
  | HTH,
  | 
  | /hannes
  | 
  | On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote:
  | | Hi Acee,
  | |
  | | On 8/26/14 15:45 , Acee Lindem (acee) wrote:
  | | Hi Peter,
  | | This is a valid concern and one that we¹ve discussed previously with
  | | respect to routing behavior based on policies. I think that accepting
 this
  | | draft as a WG document should not preclude standardization of
 capabilities
  | | advertisement for popular applications.
  | |
  | | sure. Just that the draft mentions applications like Controlling
 Remote LFA
  | | tunnel termination, which I'm not sure the node tag is the best
 approach
  | | for.
  | |
  | | thanks,
  | | Peter
  | |
  | | Thanks,
  | | Acee
  | | 
  | | On 8/26/14, 4:05 AM, Peter Psenak (ppsenak)
 ppse...@cisco.com wrote:
  | | 
  | | On 8/25/14 23:18 , Acee Lindem (acee) wrote:
  | | There are situations where node level policy is required and an
 OSPF
  | | advertised admin tag simplifies this. For example, advertisement
 of
  | | remote-LFA eligibility.
  | | 
  | | my concern with the generic use of admin tags for signaling
 capability
  | | is that it's operationally unfriendly compared to explicit signaling 
  of
  | | the capability (e.g. using a bit or a TLV). The reason is that you 
  have
  | | to configure the tag meaning on all receiving routers.
  | | 
  | | thanks,
  | | Peter
  | | 
  | | 
  | | Please indicate your support or objections to adopting this draft as
 an
  | | OSPF WG document.
  | | 
  | | Thanks,
  | | Acee
  | | 
  | | 
  | | ___
  | | OSPF mailing list
  | | OSPF@ietf.org
  | | https://www.ietf.org/mailman/listinfo/ospf
  | | 
  | | 
  | | ___
  | | OSPF mailing list
  | | OSPF@ietf.org
  | | https://www.ietf.org/mailman/listinfo/ospf
  | | 
  | | .
  | | 
  | |
  | | ___
  | | OSPF mailing list
  | | OSPF@ietf.org
  | | https://www.ietf.org/mailman/listinfo/ospf
  | .
  | 
  |
  .
 
 
 ___
 OSPF mailing list
 OSPF@ietf.org
 https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-ospfv3-extension-02.txt

[Les Ginsberg (ginsberg)]

Support.

Les

 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
 Sent: Thursday, July 03, 2014 8:45 AM
 Cc: OSPF List
 Subject: Re: [OSPF] New Version Notification for draft-psenak-ospf-
 segment-routing-ospfv3-extension-02.txt
 
 Hi,
 
 I'd like to start a 2 week OSPF WG adoption poll of the subject draft. The
 encodings are very close to those in the OSPFv2 draft (which is a WG
 document) other than the fact that they take advantage of the OSPFv3 LSA
 extensions which simplifies things. However, it makes a lot of sense to
 advance these drafts separately since the OSPFv2 draft is not dependent on
 any other drafts and there are existing implementations.
 
 Thanks,
 Acee
 
 On Jul 2, 2014, at 1:48 PM, Acee Lindem acee.lin...@ericsson.com
 wrote:
 
  Hi Peter,
  I will review this version and start the adoption poll.
 
  Others - please read and comment.
 
  Thanks,
  Acee
  On Jul 2, 2014, at 8:46 AM, Peter Psenak ppse...@cisco.com wrote:
 
  Acee, WG,
 
  I have updated the OSPFv3 SR extension draft.
 
  Given that OSPFv2 SR extension draft has been accepted as a WG item, it
 would make a lot of sense to make the OSPFv3 SR draft WG document as
 well.
 
  thanks,
  Peter
 
 
   Original Message 
  Subject: New Version Notification for draft-psenak-ospf-segment-
 routing-ospfv3-extension-02.txt
  Date: Wed, 2 Jul 2014 04:47:17 -0700
  From: internet-dra...@ietf.org
  To: Stefano Previdi sprev...@cisco.com, Jeff Tantsura
 jeff.tants...@ericsson.com, Jeff Tantsura jeff.tants...@ericsson.com,
 Rob Shakir rob.sha...@bt.com, Hannes Gredler han...@juniper.net,
 Wim Henderickx wim.henderi...@alcatel-lucent.com, Clarence Filsfils
 cfils...@cisco.com, Wim Henderickx wim.henderickx@alcatel-
 lucent.com, Peter Psenak ppse...@cisco.com, Stefano Previdi
 sprev...@cisco.com, Clarence Filsfils cfils...@cisco.com, Peter Psenak
 ppse...@cisco.com, Rob Shakir rob.sha...@bt.com, Hannes Gredler
 han...@juniper.net
 
 
  A new version of I-D, draft-psenak-ospf-segment-routing-ospfv3-
 extension-02.txt
  has been successfully submitted by Peter Psenak and posted to the
  IETF repository.
 
  Name:  draft-psenak-ospf-segment-routing-ospfv3-
 extension
  Revision:  02
  Title: OSPFv3 Extensions for Segment Routing
  Document date: 2014-07-02
  Group: Individual Submission
  Pages: 29
  URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-
 routing-ospfv3-extension-02.txt
  Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-
 routing-ospfv3-extension/
  Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-
 ospfv3-extension-02
  Diff: http://www.ietf.org/rfcdiff?url2=draft-psenak-ospf-segment-
 routing-ospfv3-extension-02
 
  Abstract:
   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths within IGP topologies by encoding paths as sequences of
   topological sub-paths, called segments.  These segments are
   advertised by the link-state routing protocols (IS-IS and OSPF).
 
   This draft describes the necessary OSPFv3 extensions that need to be
   introduced for Segment Routing.
 
 
 
 
 
  Please note that it may take a couple of minutes from the time of
 submission
  until the htmlized version and diff are available at tools.ietf.org.
 
  The IETF Secretariat
 
  .
 
 
 
 
 
 ___
 OSPF mailing list
 OSPF@ietf.org
 https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll

[Les Ginsberg (ginsberg)]

Support

   Les

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Monday, June 09, 2014 12:40 PM
To: OSPF - OSPF WG List
Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll

Given the progress made in the SRING WG on problem statement and use caseWG 
document adoption, Abhay and I now feel we can start a 1 week poll on adoption 
of the corresponding OSPF document.

http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt

Please indicate your support or opposition to WG adoption.

Thanks,
Abhay and Acee
P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of the 
OSPFv3 draft.

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [sunset4] IPv6 router IDs

[Les Ginsberg (ginsberg)]

Xiaohu –

RFC 5316 already has defined this – see sub-TLVs 11 and 12.

If the concern is that these are defined as TE specific it would be better to 
make an explicit statement to allow these to be used for purposes other than TE 
as has been done in RFC 5305 and RFC 6119 than to define a duplicate sub-TLV.

   Les


From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Xuxiaohu
Sent: Sunday, May 04, 2014 1:29 AM
To: George, Wes
Cc: ospf@ietf.org; isis...@ietf.org; fanp...@chinamobile.com; suns...@ietf.org; 
lizhenqi...@chinamobile.com
Subject: Re: [OSPF] [sunset4] IPv6 router IDs

Hi Wes,

Thanks for pointing out these two drafts.

The motivation for these two drafts 
(http://tools.ietf.org/html/draft-xu-isis-ipv6-router-id-00 and 
http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00) is very simple: the 
IPv6 ISIS|OSPF capability TLV/RI-LSA which are used for advertising router 
capabilities can be flooded across areas, however, only a 4-octect router ID is 
carried in them. As a result, it’s hard for routers in one area to establish 
correlations between IPv6 addresses and capabilities of routers in another 
area. For example, assume IS-IS router A in one area has established a L3VPN 
session with IS-IS router B in another area over their own IPv6 addresses. When 
router A needs to send L3VPN traffic to router B via a MPLS-SR tunnel, router A 
wants to know whether router B has the ELC 
(http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) 
beforehttp://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)%20before 
inserting an EL into the MPLS-SR packet . However, the Capability TLV 
originated by router B doesn’t carried an IPv6 address of its own. As a result, 
it’s hard for router A to know the ELC of router B.

Best regards,
Xiaohu

发件人: George, Wes [mailto:wesley.geo...@twcable.com]
发送时间: 2014年5月2日 1:51
收件人: Xuxiaohu
抄送: suns...@ietf.orgmailto:suns...@ietf.org; 
fanp...@chinamobile.commailto:fanp...@chinamobile.com; 
lizhenqi...@chinamobile.commailto:lizhenqi...@chinamobile.com
主题: Re: [sunset4] IPv6 router IDs

I got a bounce-back on all 3 draft aliases, trying again with the authors’s 
email addresses directly.

From: George, George, Wes 
wesley.geo...@twcable.commailto:wesley.geo...@twcable.com
Date: Thursday, May 1, 2014 at 1:42 PM
To: 
draft-xu-isis-ipv6-router...@tools.ietf.orgmailto:draft-xu-isis-ipv6-router...@tools.ietf.org
 
draft-xu-isis-ipv6-router...@tools.ietf.orgmailto:draft-xu-isis-ipv6-router...@tools.ietf.org,
 
draft-xu-ospf-ipv6-router...@tools.ietf.orgmailto:draft-xu-ospf-ipv6-router...@tools.ietf.org
 
draft-xu-ospf-ipv6-router...@tools.ietf.orgmailto:draft-xu-ospf-ipv6-router...@tools.ietf.org
Cc: 
draft-fan-idr-ipv6-bgp...@tools.ietf.orgmailto:draft-fan-idr-ipv6-bgp...@tools.ietf.org
 
draft-fan-idr-ipv6-bgp...@tools.ietf.orgmailto:draft-fan-idr-ipv6-bgp...@tools.ietf.org,
 suns...@ietf.orgmailto:suns...@ietf.org 
suns...@ietf.orgmailto:suns...@ietf.org
Subject: [sunset4] IPv6 router IDs

I see that you have submitted two drafts for IPv6 router IDs in ISIS and OSPF, 
noting that the existing router ID is only 4 octets. This has also come up in 
IDR for BGP. The authors of that draft are copied. I’ll give you a similar set 
of feedback to what I gave them -

It is important to distinguish between places where a unique identifier is 
needed, and by convention an IPv4 address assigned to the device has been used 
to provide that unique ID, vs. places where the actual IP address has some sort 
of importance to the protocol (I.e. That information must be available to take 
action on).
In other words, is the protocol requirement that the ID be unique across some 
domain, but that the actual value does not matter, or is the protocol 
requirement that the value must correspond to something on the router? In many 
of the former cases, the fact that the value isn’t relevant has been used to 
make recommendations that are easier for humans to deal with (I.e. Tying the 
router ID to an IP address) but that value as a human-readable set of info does 
not necessarily justify  changes to the protocol to support that convention as 
we move to IPv6.
I would argue that the router ID used in routing protocols must merely be 
unique, but it doesn’t have to be an IP address at all. Thus it is not strictly 
necessary to create a new field to carry IPv6 addresses when operating without 
IPv4 addresses on a network. If you believe otherwise, the justification needs 
to be documented in the draft.

There are many places in IETF protocols where a 32 bit unique identifier is 
needed, and by convention an IPv4 address has been used. It would be far more 
useful to write a general draft identifying this problem and discussing several 
solutions, including simply generating unique IDs manually, systematically 
generating a random ID, etc.  the place for such a draft may be in Sunset4, 
either as a part of the existing gap analysis draft or as another standalone 
draft.

There was rather a long 

Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

[Les Ginsberg (ginsberg)]

Acee -

One thing I have repeatedly emphasized is the simplicity of what I am 
proposing. You mention below that the proposal requires having fingerprint info 
available before LSDB exchange would normally occur in order to handle 
router-id collisions between neighbors - and you are understandably concerned 
about the complexity that would introduce.

There is no such requirement!! I am NOT proposing this!!

This is simply a misunderstanding on your part.

Here is all that is necessary:

Router-id collision between neighbors
--

I receive a hello with a duplicate router-id. The hello includes an options bit 
(or LLS if you prefer) indicating whether the neighbor considers itself 
old/new. Because I cannot form a neighbor with myself I need to resolve the 
duplicate router-id. There is no need to have or wait to acquire the neighbor 
fingerprint information. The logic is solely based on the content of the 
received hello and my internal state (old/new). The logic is:

if ((I am old)  (neighbor is new)) {
  return; /* Neighbor will change its router-id */
} else if (I am new)  (neighbor is old)) {
   Change_my_router_id();
} else /* We are both old or both new */ 
  if (my link_local address  neighbor_link_local_address) {
change_my_router_id();
  }
}

That's it! No additional logic required.
Similarly...

Router-id collision between non-neighbors
--

In this case we have acquired the LSDB so we detect a duplicate router-id as 
described in the draft Section 6.2. But fingerprint info includes a bit which 
indicates whether the originator is old or new.
The logic is then:

if ((I am old)  (non-neighbor is new)) {
  return; /* Non-Neighbor will change its router-id */
} else if (I am new)  (non-neighbor is old)) {
   Change_my_router_id();
} else /* We are both old or both new */ 
  if (my fingerprint  non-neighbor fingerprint) {
change_my_router_id();
  }
}

Setting of old/new state is done simply on the basis of a minimum amount of 
uptime (e.g. 5 minutes). The rather complex logic that Curtis proposed in an 
earlier reply is not needed - I will address why in a follow up response to his 
post.

You may still not like the idea - but complexity is not a basis for rejection. 
Hopefully what I have provided makes that clear.

   Les

 -Original Message-
 From: Acee Lindem [mailto:a...@lindem.com]
 Sent: Monday, February 10, 2014 2:55 PM
 Cc: cur...@ipv6.occnc.com; Les Ginsberg (ginsberg); OSPF List
 Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
 autoconfig-05.txt
 
 One thing I neglected to mention is that a solution dependent having the
 other router's hardware fingerprint available will greatly complicate
 duplicate router-id detection for directly attached routers since the
 resolution must either be deferred until the router's AC-LSA is received from
 another router OR the hardware fingerprint must be signaled in the OSPFv3
 Hello LLS. IMO, this complexity adds to the motivation of not attempting to
 solve this problem.
 Thanks,
 Acee
 On Feb 10, 2014, at 5:17 PM, Acee Lindem acee.lin...@ericsson.com wrote:
 
  Hi Curtis,
 
  See inline.
 
  On 2/9/14 12:38 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote:
 
 
  Les,
 
  Perhaps you should read the abstract of the document you are
  commenting about:
 
   SPFv3 is a candidate for deployments in environments where auto-
   configuration is a requirement.  One such environment is the IPv6
   home network where users expect to simply plug in a router and have
   it automatically use OSPFv3 for intra-domain routing.  This
   document describes the necessary mechanisms for OSPFv3 to be
   self-configuring.
 
  Home network!
 
  Or the introductio:
 
   OSPFv3 [OSPFV3] is a candidate for deployments in environments
   where auto-configuration is a requirement.
 
   [...]
 
  1.2. Acknowledgments
 
  This specification was inspired by the work presented in the
  Homenet working group meeting in October 2011 in Philadelphia,
  Pennsylvania.
 
  The Homenet WG works on what?  Home networks!
 
  So please keep that in mind when commenting.
 
  Unless a provider were to be so stupid or lazy to use this on a SP
  network then most of the comments from both of us don't apply,
  *except* the few comments below about in a home network.
 
  Perhaps the draft should add text explicitly stating that the last
  router-id used successfully should be used on a reboot rather than a
  new random number.  I notice that only the Router-Hardware-Fingerprint
  TLV is persistent across reboots.  This is insufficient if we want to
  minimize disruption.
 
  The only case then (if router-id is remembered across reboots) would
  be a new router.  In that case your uptime rule would help.  So
  perhaps two things could be reocmmended:
 
  1.  In section 4, include a SHOULD remember the most recent
  successfully used router-id across reboots and reuse

Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

[Les Ginsberg (ginsberg)]

Curtis -

Inline...

 -Original Message-
 From: Curtis Villamizar [mailto:cur...@ipv6.occnc.com]
 Sent: Monday, February 10, 2014 12:03 PM
 To: Les Ginsberg (ginsberg)
 Cc: cur...@ipv6.occnc.com; Acee Lindem; OSPF List
 Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
 autoconfig-05.txt
 
 
 In message f3ade4747c9e124b89f0ed2180cc814f23c63...@xmb-aln-x02.cisco.com
 Les Ginsberg (ginsberg) writes:
 
  Curtis -
 
  I think we are converging.
 
  Some context from my side...
 
  I am fully aware that this draft is about Homenet environments, but
  there is a suspicion in the back of my mind that once the duplicate-id
  resolution mechanism is defined and deployed that folks may want to
  use it in other environments e.g. TRILL has targeted auto-config as a
  goal (just an example). You may remember a few years ago a proposal to
  automatically resolve system-id conflicts was discussed in IS-IS
  WG. The proposal had a lot of flaws and we shot it down - but it does
  suggest that some folks may want to use such a mechanism in other
  types of deployments someday. So I would like to define things such
  that it is robust enough to be used elsewhere. And since what I am
  proposing is quite simple I don't think it unduly burdens the Homenet
  environments.
 
 Providers tend to configure anything that is expected to be static.
 At least the smart ones do.
 
 But then maybe smart people don't run trill.  :-)
 
 I think the prior IS-IS autoconfig may have been motivated by IEEE use
 of IS-IS for bridging.  Again, not something providers use.
 
  As regards preserving router-id across reboots - sure - that is a good
  idea also. And what I am proposing is supportive of that because it
  guarantees that so long as an existing router's LSAs are in the LSDB
  (even if it is currently undergoing maintenance) any new router that
  comes up (or even another old router that reboots and is not so well
  behaved as to remember the router-id it previously used) will not take
  the router-id of any router seen in the LSDB (reachable or not). This
  is better than the existing logic which leaves the decision to chance.
 
 The router today that can't remember anything between reboots is
 likely to be a very low end home networking device with no
 non-volitile strorage at all.  Anything running OSPF or ISIS is likely
 to be at least keeping a code image in flash and could keep a
 router-id there too.

There are various reasons the router-id may not be remembered across reboot.

The router may be low end w/o NVRAM.
The router might have a bug in its implementation.
The NVRAM might have gotten corrupted.

But we need not care. The point is we can still minimize disruption to the 
network by using the old/new paradigm - and that is a good thing.

It is, of course, also a good thing for a router to retain its old identity 
following reboot - I fully support that - and the old/new paradigm is 
complementary to the retention of router-id across reboots.

 
  More inline.
 
   -Original Message-
   From: Curtis Villamizar [mailto:cur...@ipv6.occnc.com]
   Sent: Sunday, February 09, 2014 12:39 PM
   To: Les Ginsberg (ginsberg)
   Cc: cur...@ipv6.occnc.com; Acee Lindem; OSPF List
   Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
   autoconfig-05.txt
  
  
   Les,
  
   Perhaps you should read the abstract of the document you are
   commenting about:
  
  SPFv3 is a candidate for deployments in environments where auto-
  configuration is a requirement.  One such environment is the IPv6
  home network where users expect to simply plug in a router and have
  it automatically use OSPFv3 for intra-domain routing.  This
  document describes the necessary mechanisms for OSPFv3 to be
  self-configuring.
  
   Home network!
  
   Or the introductio:
  
  OSPFv3 [OSPFV3] is a candidate for deployments in environments
  where auto-configuration is a requirement.
  
  [...]
  
1.2. Acknowledgments
  
 This specification was inspired by the work presented in the
 Homenet working group meeting in October 2011 in Philadelphia,
 Pennsylvania.
  
   The Homenet WG works on what?  Home networks!
  
   So please keep that in mind when commenting.
  
   Unless a provider were to be so stupid or lazy to use this on a SP
   network then most of the comments from both of us don't apply,
   *except* the few comments below about in a home network.
  
   Perhaps the draft should add text explicitly stating that the last
   router-id used successfully should be used on a reboot rather than a
   new random number.  I notice that only the Router-Hardware-Fingerprint
   TLV is persistent across reboots.  This is insufficient if we want to
   minimize disruption.
  
   The only case then (if router-id is remembered across reboots) would
   be a new router.
 
  Also a router which fails to remember its old router-id across a reboot.
 
 See above

Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

[Les Ginsberg (ginsberg)]

Curtis -

 -Original Message-
 From: Curtis Villamizar [mailto:cur...@ipv6.occnc.com]
 Sent: Saturday, February 08, 2014 7:30 AM
 To: Les Ginsberg (ginsberg)
 Cc: cur...@ipv6.occnc.com; Acee Lindem; OSPF List
 Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
 autoconfig-05.txt
 
 
 In message f3ade4747c9e124b89f0ed2180cc814f23c62...@xmb-aln-x02.cisco.com
 Les Ginsberg (ginsberg) writes:
 
  Curtis -
 
  Your reply below is talking about things which I think do not directly
  bear on the value add of what I have proposed.
 
  You mention various ways to insure that a given device assigns the
  same router-id each time it starts up and ways to insure it picks the
  same sequence of second/third... choices in the event it has to change
  its router-id. All good suggestions, but what I am talking about is
  what we do in the event a conflict occurs despite our best efforts to
  avoid it. With the current draft content preference is based solely on
  a fixed identifier (fingerprint) without regard to which choice would
  minimize disruption to the network. When preference is given to the
  old router to retain its existing router-id this shortcoming is
  addressed.
 
 In the lifetime of a router it only gets added once.  In the lifetime
 of a router we would hope it only reboots zero time but experience so
 far has been that reboots over a router's lifetime tend to be  0 and
 in some cases  0.
 
 So you are optimizing for a 1 in 4 billion occurance that can happen
 only once in the lifetime of a router.

The entire duplicate router-id resolution logic is addressing the improbable 
case. My proposal adds - literally - one line of code to the logic used to 
decide whether I should change my router-id or whether you should change 
your router-id.

 
 We also need to look at the consequences of this very improbably
 occurance.  Today's routers accomplish IGP convergence in large
 networks in subsecond times, in some cases  1 second.
 
 Note that if flooding is completed (both withdraw old and install new)
 in less than the SPF delay which is commonly implemented (some delay
 after receiving the first flooded IGP change), then there is no impact
 on routing.

Your analysis does not apply to this scenario. The router which changes its 
router-id is effectively doing a cold start. All adjacencies will go down. All 
LSAs originated by this router become invalid. All routes will be removed from 
the forwarding plane. If you are running BGP all the BGP nexthops will be gone 
on the router which is changing its identity. Restoration of the adjacencies 
and reacquisition of the LSDB will take multiple seconds. The best you can hope 
for is several seconds of disruption - it could easily be much longer.

For the new node which has usurped the old node's identity it will have to 
purge/replace all of the LSAs generated by the old node. While normal operation 
of the update process will insure that this happens in a reliable way the 
amount of flooding network-wide required to bringup a new node has now been 
roughly doubled i.e. the old node must reissue all of its LSAs using a new 
identity and the new node must purge/replace the old node's LSAs with its own 
versions. This will result in multiple SPFs on all nodes in the network and 
likely cause loops/blackholes during the transition since some of the SPFs will 
be run on versions of the LSDB which are inaccurate (part old node's old LSAs 
and part new node's LSAs). Suggesting that this could be handled in the same 
way/time as we typically handle a single link failure isn't credible.

 
  Your statement that what I propose is only relevant when two routers
  go down does not match the scenarios I envision. If I want to add a
  new device to my network or if I need to replace an existing device in
  my network I am only affecting one device - but as I am introducing a
  device with a new fingerprint it is possible that it will introduce a
  conflict with an existing router-id.
 
 In provider networks routers are generally added during maintenance
 windows so should anything unexpected happen, impact is minimized.
 
 In home nets, the home user isn't going to notice the convergence time
 if there is any.  A 10 msec SPF delay is likely to be plenty.

As I stated above, disruption will be orders of magnitude longer than 10 ms. 

 
  In a subsequent reply you liked the idea of the new device delaying
  advertising reachability until it is has determined that its router-id
  choice is not in conflict. The old/new router paradigm supports this
  strategy by assuring that the old router will not consider changing
  its router-id until enough time has elapsed for the new router to
  transition to being an old router.
 
 If it wins the coin toss, the router would advertise at least one LSA
 to indicate its existance and could hold back on any additional
 advertisements until the other router has withdrawn routes.
 

This suggestion does not alter

Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

[Les Ginsberg (ginsberg)]

So, I am one person who raised this concern to Acee - but the proposal outlined 
by Acee is not what I had in mind. There is no need to use uptime or to 
invent some unusual exchange of LSAs prior to Exchange state.

Also, in regards to Curtis's comment - it is not DOS attacks that I am trying 
to mitigate here. As he says if an attacker is in your network and able to 
originate credible packets no strategy is safe.

The motivating use case is to minimize disruption of a stable network when a 
new router is added or an existing router is replaced/rebooted. In other words 
non-disruptive handling of the common maintenance/upgrade scenarios.

What I have in mind is this:

1)A router needs a way to advertise that it has been up and running for a 
minimum length of time - for the sake of discussion let's say 20 minutes. 
Routers then fall into two categories:

  o Old routers (up = minimum time)
  o New routers (up  minimum time)

2)When a duplicate router-id is detected, the first tie breaker is between old 
routers and new routers. The old router gets to keep its router-id and the new 
router picks a new router-id.
If both routers are new or both routers are old then we revert to the 
existing tie breakers defined in the document (link local address for directly 
connected routers and fingerprint info for non-neighbors).

3)Advertisement of the old/new state requires a single bit - but it has to be 
available both in hellos and the new AC-LSA. Adding it to the AC-LSA is easy to 
do. For hellos, there are two possibilities:

   o Use one of the Options Bits
   o Use LLS

Be interested in how folks feel about this.

   Les


 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
 Sent: Thursday, February 06, 2014 5:12 PM
 To: Curtis Villamizar
 Cc: OSPF List
 Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
 autoconfig-05.txt
 
 Hi Curtis,
 I agree and believe the significance of this use case where a new router is
 inserted into an auto-configured domain has been greater exaggerated.
 Thanks,
 Acee
 On Feb 5, 2014, at 3:58 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote:
 
 
  In message cf17dd4e.2696b%acee.lin...@ericsson.com
  Acee Lindem writes:
 
  The OSPFv3 autoconfiguration draft was cloned and presented in the
  ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In
  the ISIS WG, there was a concern that the resolution of a duplicate
  system ID did not include the amount of time the router was
  operational when determining which router would need to choose a new
  router ID. With additional complexity, we could incorporate router
  uptime into the resolution process. One way to do this would be to:
 
  1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include
 the uptime in seconds.
 
  2. Use the Router Uptime TLV as the primary determinant in
 deciding which router must choose a new OSPFv3 Router
 ID. Router uptimes less than 3600 (MaxAge) seconds apart are
 considered equal.
 
  3. When an OSPFv3 Hello is received with a different link-local
 source address but a different router-id, unicast the OSPFv3
 AC-LSA to the neighbor so that OSPFv3 duplicate router
 resolution can proceed as in the case where it is received
 through the normal flooding process. This is somewhat of a
 hack as the we'd also need to accept OSPF Link State Updates
 from a neighbor that is not in Exchange State or greater.
 
  An alternative to #3 would be to use Link-Local Signaling (LLS) for
  signaling the contents of the OSPFv3 AC-LSA. However, you'd only want
  to send the Router-Uptime and Router Hardware Fingerprint when a
  duplicate Router-ID is detected. This requires implementing the
  resolution two ways but may be preferable since it doesn't require
  violating the flooding rules.
 
  In any case, I'd like to get other opinions as to whether this problem
  is worth solving.
 
  Thanks,
  Acee
 
 
  Acee,
 
  If the basis for router-id on boot up results in a fixed value, and if
  a duplicate will occur on a give network, then which of two duplicate
  routers gets that value may change after one of them reboots.  If
  uptime is not considered, it will never change as long as one router
  stays up at any given time.
 
  We are talking about a very low probability event (a duplicate) except
  if this is a DoS attack and then either using or not using uptime
  won't matter since the attacker will claim an impossibly long uptime.
 
  Curtis
 
 ___
 OSPF mailing list
 OSPF@ietf.org
 https://www.ietf.org/mailman/listinfo/ospf
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

[Les Ginsberg (ginsberg)]

One other thing I forgot to mention.

Using the mechanisms I define below, a modestly clever implementation could 
implement a startup mode where it does not advertise any reachability until it 
has formed at least one neighbor and acquired the full LSA database. At this 
point it should know whether it has a duplicate router-id or not and if so it 
can assign itself a new router-id without affecting forwarding behavior at all.

   Les


 -Original Message-
 From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Les Ginsberg
 (ginsberg)
 Sent: Friday, February 07, 2014 12:31 AM
 To: Acee Lindem; Curtis Villamizar
 Cc: OSPF List
 Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
 autoconfig-05.txt
 
 So, I am one person who raised this concern to Acee - but the proposal
 outlined by Acee is not what I had in mind. There is no need to use uptime
 or to invent some unusual exchange of LSAs prior to Exchange state.
 
 Also, in regards to Curtis's comment - it is not DOS attacks that I am trying
 to mitigate here. As he says if an attacker is in your network and able to
 originate credible packets no strategy is safe.
 
 The motivating use case is to minimize disruption of a stable network when a
 new router is added or an existing router is replaced/rebooted. In other
 words non-disruptive handling of the common maintenance/upgrade scenarios.
 
 What I have in mind is this:
 
 1)A router needs a way to advertise that it has been up and running for a
 minimum length of time - for the sake of discussion let's say 20 minutes.
 Routers then fall into two categories:
 
   o Old routers (up = minimum time)
   o New routers (up  minimum time)
 
 2)When a duplicate router-id is detected, the first tie breaker is between
 old routers and new routers. The old router gets to keep its router-id and
 the new router picks a new router-id.
 If both routers are new or both routers are old then we revert to the
 existing tie breakers defined in the document (link local address for
 directly connected routers and fingerprint info for non-neighbors).
 
 3)Advertisement of the old/new state requires a single bit - but it has to
 be available both in hellos and the new AC-LSA. Adding it to the AC-LSA is
 easy to do. For hellos, there are two possibilities:
 
o Use one of the Options Bits
o Use LLS
 
 Be interested in how folks feel about this.
 
Les
 
 
  -Original Message-
  From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
  Sent: Thursday, February 06, 2014 5:12 PM
  To: Curtis Villamizar
  Cc: OSPF List
  Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
  autoconfig-05.txt
 
  Hi Curtis,
  I agree and believe the significance of this use case where a new router is
  inserted into an auto-configured domain has been greater exaggerated.
  Thanks,
  Acee
  On Feb 5, 2014, at 3:58 PM, Curtis Villamizar cur...@ipv6.occnc.com
 wrote:
 
  
   In message cf17dd4e.2696b%acee.lin...@ericsson.com
   Acee Lindem writes:
  
   The OSPFv3 autoconfiguration draft was cloned and presented in the
   ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In
   the ISIS WG, there was a concern that the resolution of a duplicate
   system ID did not include the amount of time the router was
   operational when determining which router would need to choose a new
   router ID. With additional complexity, we could incorporate router
   uptime into the resolution process. One way to do this would be to:
  
   1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include
  the uptime in seconds.
  
   2. Use the Router Uptime TLV as the primary determinant in
  deciding which router must choose a new OSPFv3 Router
  ID. Router uptimes less than 3600 (MaxAge) seconds apart are
  considered equal.
  
   3. When an OSPFv3 Hello is received with a different link-local
source address but a different router-id, unicast the OSPFv3
AC-LSA to the neighbor so that OSPFv3 duplicate router
resolution can proceed as in the case where it is received
through the normal flooding process. This is somewhat of a
hack as the we'd also need to accept OSPF Link State Updates
from a neighbor that is not in Exchange State or greater.
  
   An alternative to #3 would be to use Link-Local Signaling (LLS) for
   signaling the contents of the OSPFv3 AC-LSA. However, you'd only want
   to send the Router-Uptime and Router Hardware Fingerprint when a
   duplicate Router-ID is detected. This requires implementing the
   resolution two ways but may be preferable since it doesn't require
   violating the flooding rules.
  
   In any case, I'd like to get other opinions as to whether this problem
   is worth solving.
  
   Thanks,
   Acee
  
  
   Acee,
  
   If the basis for router-id on boot up results in a fixed value, and if
   a duplicate will occur on a give

Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

[Les Ginsberg (ginsberg)]

Curtis -

Your reply below is talking about things which I think do not directly bear on 
the value add of what I have proposed.

You mention various ways to insure that a given device assigns the same 
router-id each time it starts up and ways to insure it picks the same sequence 
of second/third... choices in the event it has to change its router-id. All 
good suggestions, but what I am talking about is what we do in the event a 
conflict occurs despite our best efforts to avoid it. With the current draft 
content preference is based solely on a fixed identifier (fingerprint) without 
regard to which choice would minimize disruption to the network. When 
preference is given to the old router to retain its existing router-id this 
shortcoming is addressed.

Your statement that what I propose is only relevant when two routers go down 
does not match the scenarios I envision. If I want to add a new device to my 
network or if I need to replace an existing device in my network I am only 
affecting one device - but as I am introducing a device with a new fingerprint 
it is possible that it will introduce a conflict with an existing router-id.

In a subsequent reply you liked the idea of the new device delaying advertising 
reachability until it is has determined that its router-id choice is not in 
conflict. The old/new router paradigm supports this strategy by assuring that 
the old router will not consider changing its router-id until enough time has 
elapsed for the new router to transition to being an old router.

Finally, what I propose is extremely simple to implement. I think it isn't much 
of an exaggeration to say that any one of us could have implemented the 
enhancement in the time it has taken to discuss its merits. So we aren't 
overengineering for a case which is admittedly very unlikely to occur - we are 
adding a modest extension to make our solution less disruptive.

   Les


 -Original Message-
 From: Curtis Villamizar [mailto:cur...@ipv6.occnc.com]
 Sent: Friday, February 07, 2014 9:22 AM
 To: Les Ginsberg (ginsberg)
 Cc: Acee Lindem; Curtis Villamizar; OSPF List
 Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
 autoconfig-05.txt
 
 
 In message f3ade4747c9e124b89f0ed2180cc814f23c61...@xmb-aln-x02.cisco.com
 Les Ginsberg (ginsberg) writes:
 
  So, I am one person who raised this concern to Acee - but the proposal
  outlined by Acee is not what I had in mind. There is no need to use
  uptime or to invent some unusual exchange of LSAs prior to Exchange
  state.
 
  Also, in regards to Curtis's comment - it is not DOS attacks that I am
  trying to mitigate here. As he says if an attacker is in your network
  and able to originate credible packets no strategy is safe.
 
  The motivating use case is to minimize disruption of a stable network
  when a new router is added or an existing router is
  replaced/rebooted. In other words non-disruptive handling of the
  common maintenance/upgrade scenarios.
 
  What I have in mind is this:
 
  1) A router needs a way to advertise that it has been up and running
 for a minimum length of time - for the sake of discussion let's say
 20 minutes. Routers then fall into two categories:
 
o Old routers (up = minimum time)
o New routers (up  minimum time)
 
  2) When a duplicate router-id is detected, the first tie breaker is
 between old routers and new routers. The old router gets to keep
 its router-id and the new router picks a new router-id.  If both
 routers are new or both routers are old then we revert to the
 existing tie breakers defined in the document (link local address
 for directly connected routers and fingerprint info for
 non-neighbors).
 
  3) Advertisement of the old/new state requires a single bit - but it
 has to be available both in hellos and the new AC-LSA. Adding it to
 the AC-LSA is easy to do. For hellos, there are two possibilities:
 
 o Use one of the Options Bits
 o Use LLS
 
  Be interested in how folks feel about this.
 
 Les
 
 
 Les,
 
 Excluding DoS attack, we are talking about a one in 4 billion case
 (for any two routers, so with 400 routers, still well under one in 1M)
 where two routers hash a MAC address or pick a one time random number
 from out of nowhere and end up with the same number.
 
 If that does happen (and one in 1M is certainly possible), then it
 would be nice if the routers always ended up with the same router-id.
 This could be accomplished by some fixed method such as hashing a
 constant with the first choice or router-id or using the router-id as
 a seed for the random number generator (which will pick the same
 sequence of random numbers each time).  If this is done, then a
 conflict would always produce the same set of next picks.  The set of
 routers in a given network would always end up with the same
 router-ids once they all came up and if only one went down at a time
 then it would always end up

Re: [OSPF] WG LC

[Les Ginsberg (ginsberg)]

Sujay -

I assume you wanted to copy the WG lists...have added them to the
thread.
Reply inline.

 -Original Message-
 From: sujay gupta [mailto:[EMAIL PROTECTED]
 Sent: Sunday, June 22, 2008 10:16 PM
 To: David Ward
 Cc: Les Ginsberg (ginsberg); Mike Shand (mshand); Stefano Previdi
 (sprevidi); Ross Callon
 Subject: Re: [OSPF] WG LC
 
 
 HI David,
 
 A few questions;
 
 
 
 
 No. of octets
   +---+
   | Flags | 1
   +---+
 
   | Application ID| 2
   +---+
   | Application   |
   | IP Address Info   | 0 to 20
   +---+
 
   | Additional Application| 0 to (252 -
   |  Specific Information | len of IP Address info)
   +---+
 
 
 
 
 Why do we need the Application IP address info, field , although you
 specify it could be a zero size element, I believe it is dependent on
the
 Application ID to utilize this space, as a IP address or anything
else.
 One  concern is it is wasting two bits from the flag.
 Could we not better give a note as to the figure is only one possible
 means of using the Gen_TLV. And split the flag into two parts one as
 mandatory and the other subject to interpretation from the Application
ID.
 
 This approach would address my second concern, if the App-data is
spread
 across TLV's I would prefer to have some sequence number, end of data
bit
 etc. for ease in processing.

The draft clearly indicates that the presence of IPv4/IPv6 address (or
both) is optional. But, if present it should be placed at the position
indicated. Why? Because, as indicated at the end of this section:

The Application ID in combination with the Application IPv4/IPv6
   Address Information uniquely identifies the GENINFO Application
   Context (GENINFO-CTX).

As for the use of application specific flag bits, that may be done in
the additional application specific information. The intent is to keep
the standard header free of application specific information.

  Les

 
 Thanks,
 -Sujay
 
 
 
 
 
 
 On Sat, Jun 21, 2008 at 7:26 PM, David Ward [EMAIL PROTECTED] wrote:
 
 
   All -
  We are starting a 2 week WG (isis) LC on this draft:
 

http://www.ietf.org/internet-drafts/draft-ietf-isis-genapp-01.txt
 
 
   I've also bcc'ed the OSPF WG for their comments as well. Please
have
 all comments to the list by 1700 PST 2008.07.03
 
   -DWard, CHopps
   ___
   OSPF mailing list
   OSPF@ietf.org
   https://www.ietf.org/mailman/listinfo/ospf
 
 

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

[OSPF] RE: [Isis-wg] Further short CCAMP WG Last Call ondraft-ietf-ccamp-te-node-cap-03.txt

[Les Ginsberg (ginsberg)]

1)The use of TLV and sub-TLV is not consistent throughout the document 
regarding IS-IS. For example, in the second and third paragraphs of Section 4.2:

   The IS-IS TE Node Capability Descriptor TLV is carried within an IS-
   IS CAPABILITY TLV which is defined in [OSPF-CAP].

   The format of the IS-IS TE Node Capability sub-TLV is the same as the 
   TLV format used by the Traffic Engineering Extensions to IS-IS 
   [RFC3784]. That is, the TLV is composed of 1 octet for the type, 1 
   octet specifying the TLV length and a value field.

TLV should be sub-TLV in all cases except when referring to the IS-IS 
CAPABILITY TLV.
Also [OSPF-CAP] should be [IS-IS-CAP]

Similar changes needed in Section 5.2 and some other places.

2)In Section 5.2:

   The TE Node Capability Descriptor TLV is OPTIONAL and MUST NOT appear 
   more than once in an ISIS Router Capability TLV. If a TE Node 
   Capability Descriptor TLV appears more than once in an ISIS 
   Capability TLV, only the first occurrence MUST be processed, other 
   occurrences MUST be ignored.

I would prefer that the second sentence be omitted - for reasons that have been 
discussed in the context of the PCE draft - I have repeated the relevant 
comments here:

snip
In cases where a TLV may move from one LSP fragment to another (for
example because of the addition of information which exceeds the
carrying capacity of the original LSP fragment) a router may have
multiple copies of the same TLV as a transient condition. It is
impossible to know which of the copies is newer and therefore impossible
to deterministically decide which is the first instance of a subTLV. So
it is better to leave the behavior in this case as undefined.
end snip

   Les


 -Original Message-
 From: Adrian Farrel [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 15, 2006 3:33 AM
 To: LE ROUX Jean-Louis RD-CORE-LAN; ccamp@ops.ietf.org
 Cc: ospf@ietf.org; isis-wg@ietf.org
 Subject: [Isis-wg] Further short CCAMP WG Last Call ondraft-ietf-ccamp-te-
 node-cap-03.txt
 
 Hi,
 
 Sorry, I fumbled this.
 
 Jean-Louis made some significant changes after we completed the working
 group last call. He took on board the comments from CCAMP, ISIS and OSPF
 and
 made the changes that he describes below.
 
 Since one of these changes is relatively substantial (the conflation of
 two
 bit-fields into one) I want to give everyone a chance to comment before we
 go forward to the ADs.
 
 So, there is a one week last call running on the CCAMP mailing list until
 noon GMT 22nd December 2006.
 
 Thanks,
 Adrian
 
 - Original Message -
 From: LE ROUX Jean-Louis RD-CORE-LAN [EMAIL PROTECTED]
 ftgroup.com
 To: ccamp@ops.ietf.org
 Sent: Wednesday, November 22, 2006 7:25 AM
 Subject: RE: I-D ACTION:draft-ietf-ccamp-te-node-cap-03.txt
 
 
 Hi all,
 
 This new version accounts for comments received during the CCAMP ISIS and
 OSPF WG last call.
 
 Here are the main changes:
 
 -The data plane and control plane cap sub-TLVs have been removed. The
 capabilities are now carried directly with the TE Node Capability
 Descriptor
 TLV, and there is a single registry for both control and data plane
 capabilities.
 
 -In section 5:
 other occurences MUST be discarded replaced by other occurrences MUST
 be
 ignored
 
 -In section 6:
 a router not supporting the TE Node Capability Descriptor TLV MUST just
 silently ignore the TLV
 Replaced by: a router not supporting the TE Node Capability Descriptor
 TLV
 will just silently ignore the TLV
 
 Regards,
 
 JL
 
  -Message d'origine-
  De : [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] De la part de
  [EMAIL PROTECTED]
  Envoyé : mardi 21 novembre 2006 21:50
  À : i-d-announce@ietf.org
  Cc : ccamp@ops.ietf.org
  Objet : I-D ACTION:draft-ietf-ccamp-te-node-cap-03.txt
 
  A New Internet-Draft is available from the on-line
  Internet-Drafts directories.
  This draft is a work item of the Common Control and
  Measurement Plane Working Group of the IETF.
 
  Title : IGP Routing Protocol Extensions for
  Discovery of Traffic Engineering  Node Capabilities
  Author(s) : J. Vasseur, et al.
  Filename : draft-ietf-ccamp-te-node-cap-03.txt
  Pages : 13
  Date : 2006-11-21
 
  It is highly desired in several cases, to take into account Traffic
 Engineering (TE) node capabilities during Multi Protocol Label
 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered
 Label Switched Path (TE-LSP)  selection, such as for instance the
 capability to act as a branch Label Switching Router (LSR) of a
 Point-To-MultiPoint (P2MP) LSP. This requires advertising these
 capabilities within the Interior Gateway Protocol (IGP). For that
 purpose, this document specifies Open Shortest Path First
  (OSPF) and
 Intermediate System-Intermediate System (IS-IS) traffic
  engineering
 extensions for the advertisement of control plane and data plane
 traffic engineering node capabilities.
 
  A URL for this Internet-Draft is:
  

[OSPF] RE: [Isis-wg] Re: [Fwd: [mpls] WG Last Call ondraft-ietf-mpls-number-0-bw-te-lsps-02.txt]

[Les Ginsberg (ginsberg)]

JP -

Sorry for the very belated comments - but I do have two minor, but still
important, concerns regarding IS-IS.

Both are in Section 3.1.

1)You have specified a 32 bit value for the number of unconstrained TE
LSPs. I would prefer that this be a 16 bit value. This still provides
ample range and given the 255 octet limit for a TLV, it is worthwhile to
be prudent in our use of encoding space. And, unlike OSPF, there is no
benefit in IS-IS to attempts to align fields on a natural boundary.
Whether you want to change OSPF encoding to match is not required and is
left up to you and OSPF folks to decide.

So
 Length (1 octet): 4

becomes

 Length (1 octet): 2

And

   Value (4 octets): number of unconstrained TE LSP(s) signalled across
   the link.

Becomes

   Value (2 octets): number of unconstrained TE LSP(s) signalled across
   the link.

2)Remove the following sentence from the first paragraph of Section 3.1:

If a second instance of the Number of
   0-bandwidth TE LSP(s) sub-TLV is present, the receiving system MUST
   only process the first instance of the sub-TLV.

In cases where a TLV may move from one LSP fragment to another (for
example because of the addition of information which exceeds the
carrying capacity of the original LSP fragment) a router may have
multiple copies of the same TLV as a transient condition. It is
impossible to know which of the copies is newer and therefore impossible
to deterministically decide which is the first instance of a subTLV. So
it is better to leave the behavior in this case as undefined.

Thanx - and once again my apologies for the very late review.

   Les

___
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf