Subject: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

From: Alia Atlas <[email-masked]>
Date: Tue, 22 Sep 2015 18:00:57 -0400

As is customary, I have done my AD review
of draft-ietf-ospf-rfc4970bis-02.  First, let me thank Acee for his work on
this draft.

I have two major concerns before asking for an IETF Last Call.  I would
like to have them
resolved by this Thursday so that the draft can make the Oct 15 IESG
telechat.

First, from a process concern, I do not see any active discussion on the
OSPF mailing list - even to simply say "yes - go forward".  I don't see
anything about this draft or discussion in minutes for IETF 92 or IETF 93.
  I'd prefer some indication besides silence and lack of opposition.  I do
realize that there are some process or protocol-tidying drafts where there
isn't
much interest.  However, I am particularly concerned because this is
changing RFC4970 is a way that should be backwards compatible but might
trigger issues.   I would encourage WG participants to PLEASE RESPOND!

Second, I can see the intent that by creating an Opaque ID and creating a
special meaning for 0, the draft is making efforts to preserve backwards
compatibility.  Please add a paragraph or subsection that articulates how
and why backwards compatibility isn't an issue.  For extra credit, what
happens if the same TLV information is advertised in multiple RI LSAs (as
part of moving it from one RI LSA to another)?

Are there any implementations of this draft?  Has backwards compatibility
been verified at all?

My minor issue is around the IANA considerations; I have detailed comments
below.

Here are additional comments.

1) In Sec 2: "The first Opaque ID, i.e., 0, should always contain the Router
   Informational Capabilities TLV and, if advertised, the Router
   Functional Capabilities TLV."  and Sec 2.2 "The first instance ID, i.e.,
0,
   should always contain the Router Informational Capabilities TLV and,
   if advertised, the Router Functional Capabilities TLV."

   Since I assume this is important for backwards compatibility, should
those
   be SHOULD instead of should?

2) In Sec 2.3: "The first defined TLV in the body of an RI LSA is the Router
   Informational Capabilities TLV."

   Surely that is only for the first Opaque ID=0?  Does each subsequent RI
LSA
   also need to contain a Router Informational Capabilities TLV??

3) In Sec 4 IANA Considerations:  This section is defining the different
IANA policies;
when RFC4970 was written, RFC5226 didn't exist.  But since you're doing a
bis,
perhaps you can align to the policies in RFC5226 and remove the unnecessary
text??

4) In Sec 4 IANA Considerations:  The registry for OSPFv3 LSA Function
Codes can
be found at
http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-3
and what is in the draft doesn't match up.  I'd settle for defining the
ranges, and value 12 - but it's up to you and IANA on the preferences.
Would it make sense to change the policy from Standards Action to IETF
Review here also?

Same thing applies to the OSPF RI TLVS (
http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-9
)   Also here, I think there
was agreement among the 4 of us who commented on the WG mailing list to
change this
from Standards Action to IETF Review.

5) In Sec 4 IANA Considerations: "All Router Functional Capability TLV
       additions are to be assigned through standards action."   Given the
discussion
about IETF Review vs. Standards Action for other registries, are you sure
you want
Standards Action?

I'm sure that we'll get this moving along quickly.

Thanks again!
Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 22 Sep 2015 18:10:58 -0400

Minor correction:

> trigger issues.   I would encourage WG participants to PLEASE RESPOND!

In IETF 91 minutes, I see a presentation and question from Shraddha about
making it MT capable.  There was no
answer except take it to the list and no follow-up discussion.

Am I missing anything?

Regards,
Alia

>    Functional Capabilities TLV."  and Sec 2.2 "The first instance ID,
> i.e., 0,
> perhaps you can align to the policies in RFC5226 and remove the
> unnecessary text??
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 22 Sep 2015 22:30:53 +0000

Hi Alia, Shraddha,

From: OSPF <[email-masked]<mailto:[email-masked]>> on behalf of Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 22, 2015 at 6:10 PM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Minor correction:

On Tue, Sep 22, 2015 at 6:00 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
As is customary, I have done my AD review of draft-ietf-ospf-rfc4970bis-02.  First, let me thank Acee for his work on this draft.

I have two major concerns before asking for an IETF Last Call.  I would like to have them
resolved by this Thursday so that the draft can make the Oct 15 IESG telechat.

First, from a process concern, I do not see any active discussion on the OSPF mailing list - even to simply say "yes - go forward".  I don't see anything about this draft or discussion in minutes for IETF 92 or IETF 93.   I'd prefer some indication besides silence and lack of opposition.  I do realize that there are some process or protocol-tidying drafts where there isn't
much interest.  However, I am particularly concerned because this is changing RFC4970 is a way that should be backwards compatible but might trigger issues.   I would encourage WG participants to PLEASE RESPOND!

In IETF 91 minutes, I see a presentation and question from Shraddha about making it MT capable.  There was no
answer except take it to the list and no follow-up discussion.

My answer would be that not all capabilities are scoped at an MT level of granularity it is incumbent on the definition of those that are to include the MT ID in the definition.

Thanks,
Acee

Am I missing anything?

Regards,
Alia

Second, I can see the intent that by creating an Opaque ID and creating a special meaning for 0, the draft is making efforts to preserve backwards compatibility.  Please add a paragraph or subsection that articulates how and why backwards compatibility isn't an issue.  For extra credit, what happens if the same TLV information is advertised in multiple RI LSAs (as part of moving it from one RI LSA to another)?

Are there any implementations of this draft?  Has backwards compatibility been verified at all?

My minor issue is around the IANA considerations; I have detailed comments below.

   Functional Capabilities TLV."  and Sec 2.2 "The first instance ID, i.e., 0,

   Since I assume this is important for backwards compatibility, should those
   be SHOULD instead of should?

   Surely that is only for the first Opaque ID=0?  Does each subsequent RI LSA
   also need to contain a Router Informational Capabilities TLV??

3) In Sec 4 IANA Considerations:  This section is defining the different IANA policies;
when RFC4970 was written, RFC5226 didn't exist.  But since you're doing a bis,
perhaps you can align to the policies in RFC5226 and remove the unnecessary text??

4) In Sec 4 IANA Considerations:  The registry for OSPFv3 LSA Function Codes can
be found at http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-3 and what is in the draft doesn't match up.  I'd settle for defining the ranges, and value 12 - but it's up to you and IANA on the preferences.  Would it make sense to change the policy from Standards Action to IETF Review here also?

Same thing applies to the OSPF RI TLVS (http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-9 )   Also here, I think there
was agreement among the 4 of us who commented on the WG mailing list to change this
from Standards Action to IETF Review.

5) In Sec 4 IANA Considerations: "All Router Functional Capability TLV
       additions are to be assigned through standards action."   Given the discussion
about IETF Review vs. Standards Action for other registries, are you sure you want
Standards Action?

Thanks again!
Alia

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 23 Sep 2015 07:13:57 +0000

Acee,

I agree that the MT –ID granularity is not required for the informational capability TLV as it  “more of” indicates whether router supports the
Feature or not.

Functional capabilities TLV is newly added in 4970bis. My read is that this TLV can be used to indicate whether the router
Currently has enabled the feature or not and take protocol actions based on this information.
It makes sense to add one functional capability TLV per MT-ID in MT deployments.
When the new features need to use the functional capability  TLV to advertise just their capabilities
and do not have additional information, just a functional capability bit should suffice and no new sub TLV definitions would be needed.
This looks more elegant and is compact from protocol message length perspective.

Having said that, it may be worthwhile to discuss in WG whether we need to consider MT based deployments while
defining the new protocol extensions. In general, there seems to be less interest in deploying multi-topology.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Wednesday, September 23, 2015 4:01 AM
To: Alia Atlas <[email-masked]>; OSPF List <[email-masked]>; [email-masked]; Shraddha Hegde <[email-masked]>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Hi Alia, Shraddha,

Minor correction:

Thanks,
Acee

Am I missing anything?

Regards,
Alia

Thanks again!
Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Sep 2015 09:44:52 +0000

Hi Shraddha,

From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 23, 2015 at 3:13 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Acee,

This new TLV is scoped for the entire node and analogous the existing informational capabilities TLV. A new TLV could be added that is scoped by MT-ID for per-MT capabilities.

Right - I’m not sure I see a strong requirement for this - especially after WG last call.

Thanks,
Acee

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Wednesday, September 23, 2015 4:01 AM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>; OSPF List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Hi Alia, Shraddha,

Minor correction:

Thanks,
Acee

Am I missing anything?

Regards,
Alia

Thanks again!
Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Sep 2015 14:37:30 +0000

Hi Alia,

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 22, 2015 at 6:00 PM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AD review of draft-ietf-ospf-rfc4970bis-02

Second, I can see the intent that by creating an Opaque ID and creating a special meaning for 0, the draft is making efforts to preserve backwards compatibility.  Please add a paragraph or subsection that articulates how and why backwards compatibility isn't an issue.

I will add more on this.

  For extra credit, what happens if the same TLV information is advertised in multiple RI LSAs (as part of moving it from one RI LSA to another)?

This depends on the context of the TLV. In some cases the router information is additive and in others conflicts need to be resolved.

Many implementations of RFC 4970. I don’t know of any implementations that originate multiple RI LSAs. However, with all the proposed OSPF RI LSA usages, I can see them coming.

Yes.

No. Will clarify this.

Yes. I think of already done this.

Yes - I think this draft should change the policy for OSPFv3 LSA Functions codes since RFC 4970 initially created the registry. If were going to change the policy (and I think we want to do this), it makes sense to do it here from a continuity standpoint.

Yes.

No  - I will change this.

Great - will work on this today in preparation for the tomorrow’s telechat.

Thanks,
Acee

Thanks again!
Alia

---

From: t.petch <[email-masked]>
Date: Thu, 24 Sep 2015 11:02:32 +0100

Acee

Alia having alerted me to the IANA Considerations :-( two further
thoughts.

Jeff Haas has written an excellent I-D recommending that the first and
last points of a numeric registry should be reserved, which I agree
with. In that light, I suggest reserving 8191 in OSPFv3 LSA Function
Codes

Second, 5226bis proposes a cleaner terminology, replacing top-level
registry, registry, sub-registry, sub-sub registry etc with Registry
within Group.  (OSPF has eleven Groups, BGP but one).  I see that OSPFv3
LSA Function Codes is in the Open Shortest Path First v3 (OSPFv3)
Parameters Group.  I think that you are implying that IANA should update
some but not all the references for that Registry.  Thus the reference
for the Registry as a whole should be for this new I-D but the reference
for individual entries for the most part do not change except where they
are to RFC4970(?).

Likewise for OSPF RI TLVs  which is in the Open Shortest Path First v2
(OSPFv2) Parameters Group, some references will need updating, others
will not, and I think that that needs specifying in the I-D.

OSPF Router Informational Capability Bits I think is another Registry
within the same Group while OSPF Router Functional Capability Bits I
think is a new Registry; I don't know which Group it fits best with but
I think that that should be specified.

Tom Petch

----- Original Message -----
From: "Acee Lindem (acee)" <[email-masked]>
To: "Alia Atlas" <[email-masked]>; "OSPF List" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, September 23, 2015 3:37 PM
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

> To: OSPF WG List <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:draft-ietf-ospf-rfc4970bis@i
etf.org>"
<[email-masked]<mailto:draft-ietf-ospf-rfc4970bis@i
etf.org>>
> As is customary, I have done my AD review of
draft-ietf-ospf-rfc4970bis-02.  First, let me thank Acee for his work on
this draft.
telechat.
>
> First, from a process concern, I do not see any active discussion on
the OSPF mailing list - even to simply say "yes - go forward".  I don't
see anything about this draft or discussion in minutes for IETF 92 or
IETF 93.   I'd prefer some indication besides silence and lack of
opposition.  I do realize that there are some process or
protocol-tidying drafts where there isn't
>
> Second, I can see the intent that by creating an Opaque ID and
creating a special meaning for 0, the draft is making efforts to
preserve backwards compatibility.  Please add a paragraph or subsection
that articulates how and why backwards compatibility isn't an issue.
>
> I will add more on this.
>
>   For extra credit, what happens if the same TLV information is
advertised in multiple RI LSAs (as part of moving it from one RI LSA to
another)?
>
> This depends on the context of the TLV. In some cases the router
information is additive and in others conflicts need to be resolved.
> Many implementations of RFC 4970. I don’t know of any implementations
that originate multiple RI LSAs. However, with all the proposed OSPF RI
LSA usages, I can see them coming.
i.e., 0,
unnecessary text??
Codes can
> be found at
http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtm
l#ospfv3-parameters-3 and what is in the draft doesn't match up.  I'd
settle for defining the ranges, and value 12 - but it's up to you and
IANA on the preferences.  Would it make sense to change the policy from
Standards Action to IETF Review here also?
>
> Yes - I think this draft should change the policy for OSPFv3 LSA
Functions codes since RFC 4970 initially created the registry. If were
going to change the policy (and I think we want to do this), it makes
sense to do it here from a continuity standpoint.
>
>
>
> Same thing applies to the OSPF RI TLVS
(http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xht
ml#ospfv2-parameters-9 )   Also here, I think there
> Great - will work on this today in preparation for the tomorrow’s
telechat.

------------------------------------------------------------------------
--------

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 24 Sep 2015 11:31:16 +0000

Hi Tom, 

>with. In that light, I suggest reserving 8191 in OSPFv3 LSA Function

I must admit that I thought this whole discussion was much ado about
nothing but I’m certainly not opposed to reserving the last function code.
If we run into a situation where we use the whole OSPFv3 LSA Function Code
space, it will mean that OSPFv3 has been wildly successful!

>for individual entries for the most part do not change except where they

Yes - Are you suggesting I state the registry is unchanged from RFC 4970
other than the change to the reservation policy and the reservation of
8192? 

>will not, and I think that that needs specifying in the I-D.

Yes - are you suggesting any change of text?

>I think that that should be specified.

This new registry should go in the "Open Shortest Path First v2 (OSPFv2)
Parameters" group the same as the existing "OSPF Router Informational
Capability Bits”.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 24 Sep 2015 12:28:02 +0000

Hi Tom,

I believe the 04 update addresses your comments and will make IANA’s job a
lot easier. 

A new version of I-D, draft-ietf-ospf-rfc4970bis-04.txt
has been successfully submitted by Acee Lindem and posted to the
IETF repository.

Name:		draft-ietf-ospf-rfc4970bis
Revision:	04
Title:		Extensions to OSPF for Advertising Optional Router Capabilities
Document date:	2015-09-24
Group:		ospf
Pages:		15
URL:            
https://www.ietf.org/internet-drafts/draft-ietf-ospf-rfc4970bis-04.txt
Status:         
https://datatracker.ietf.org/doc/draft-ietf-ospf-rfc4970bis/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ospf-rfc4970bis-04
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-rfc4970bis-04

Abstract:
   It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
   know the capabilities of their neighbors and other routers in the
   routing domain.  This document proposes extensions to OSPFv2 and
   OSPFv3 for advertising optional router capabilities.  The Router
   Information (RI) Link State Advertisement (LSA) is defined for this
   purpose.  In OSPFv2, the RI LSA will be implemented with an opaque
   LSA type ID.  In OSPFv3, the RI LSA will be implemented with a unique
   LSA type function code.  In both protocols, the RI LSA can be
   advertised at any of the defined flooding scopes (link, area, or
   autonomous system (AS)).  This document obsoletes RFC 4970 by
   providing a revised specification including support for advertisement
   of multiple instances of the RI LSA and a TLV for functional
   capabilities.

Thanks,
Acee

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Sep 2015 14:53:42 -0400

Acee,

I just took a quick look at this version and the IANA section looks much
better.
I don't see an extra paragraph talking about backwards compatibility...

I'd like to get this out for IETF Last Call today, if you can spin a quick
version.

Thanks,
Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 24 Sep 2015 19:09:01 +0000

Hi Alia,

On Sep 24, 2015, at 2:53 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Acee,

I just took a quick look at this version and the IANA section looks much better.
I don't see an extra paragraph talking about backwards compatibility…

Maybe because it is very brief. I wanted to avoid discussion of specific existing TLVs.

3.  Backward Compatibility

   For backward compatibility, previously advertised Router Information
   TLVs SHOULD continue to be advertised in the first instance, i.e., 0,
   of the Router Information LSA.  If a Router Information TLV is
   advertised in multiple Router Information LSA instances and the
   multiple instance processing is not explicitly specified in the RFC
   defining that Router Information TLV, the Router Instance TLV in the
   Router Information LSA with the numerically smallest Instance ID will
   be used and subsequent instances will be ignored.

Thanks,
Acee

I'd like to get this out for IETF Last Call today, if you can spin a quick version.

Thanks,
Alia

On Thu, Sep 24, 2015 at 8:28 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

Abstract:

Thanks,
Acee

On 9/24/15, 7:31 AM, "OSPF on behalf of Acee Lindem (acee)"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>Hi Tom,
>
>On 9/24/15, 6:02 AM, "t.petch" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>Acee
>>
>>From: "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
>>To: "Alia Atlas" <[email-masked]<mailto:[email-masked]>>; "OSPF List" <[email-masked]<mailto:[email-masked]>>;
>><[email-masked]<mailto:[email-masked]>>
>>> From: Alia Atlas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>>> To: OSPF WG List <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
>>"[email-masked]<mailto:[email-masked]><mailto:draft-ietf-ospf-rfc4970bis@i<mailto:draft-ietf-ospf-rfc4970bis@i>
>>etf.org<http://etf.org/>>"
>><[email-masked]<mailto:[email-masked]><mailto:draft-ietf-ospf-rfc4970bis@i<mailto:draft-ietf-ospf-rfc4970bis@i>
>>etf.org<http://etf.org/>>>
>>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Sep 2015 15:12:06 -0400

Acee,

Sorry- I made the error of looking at the diff and you'd done two quick
versions in succession.

I'll put it in IETF Last Call - but I'd still be much happier hearing from
others in the WG
about support or interest in this draft.

Thanks,
Alia

On Thu, Sep 24, 2015 at 3:09 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Alia,
>
> On Sep 24, 2015, at 2:53 PM, Alia Atlas <[email-masked]> wrote:
>
> Acee,
>
>> >>(
>> http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xht