Re: [CCAMP] Could you check if the latest OSPF extension draft for availability address your comments?

["Yemin (Amy)" <[e-mail]>]

Dear all,

Below is the offline discussion on “draft-ietf-ccamp-ospf-availability-extension-03” and “draft-ietf-ccamp-rsvp-te-bandwidth-availability-03”.
You are welcome to give comments.

BR,
Amy

From: Yemin (Amy)
Sent: Wednesday, January 13, 2016 3:35 PM
To: 'Lou Berger'
Cc: D'Alessandro Alessandro Gerardo; Shah, Himanshu; Gregory Mirsky; Longhao
Subject: RE: Could you check if the latest OSPF extension draft for availability address your comments?


Hi Lou,



Thanks for reply. Please see my reply starting with [Amy].



BR,

Amy



-----Original Message-----
From: Lou Berger [mailto:[e-mail]]
Sent: Saturday, January 09, 2016 12:12 AM
To: Yemin (Amy)
Cc: D'Alessandro Alessandro Gerardo; Shah, Himanshu; Gregory Mirsky; Longhao
Subject: Re: Could you check if the latest OSPF extension draft for availability address your comments?



Hi Amy,





On 12/29/2015 1:47 AM, Yemin (Amy) wrote:

>

> Hi Lou,

>

>

>

> Could you kindly check if the latest OSPF extension draft for

> availability address your comments?

>



Here are my original comments and their resolution:

> On 7/25/2015 12:20 PM, Lou Berger wrote:

> > Abstract: > - States applies to PSC >

fixed .



> > Sections 1 > - (general comment) informative sections such as Intro and Overview

> > shouldn't contain normative (RFC2119) language. See >

> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some >

> suggested guidelines. >

you still have a conformance statement in the abstract.  This is a nit

and can be fixed whenever you do the next rev.

[Amy] Thanks for pointing it out. Will fix it.



> > Section 2 > - You mention "by the PE node" (and in two other places in the >

> document). I have don't understand why "PE" is being introduced. >

> Perhaps you mean simply "a node"? >



done.



> > Section 3.1 > - You duplicate a format definition from RFC4203. I think this

> should > be replaced with a simple sentence stating that "The

> Interface Switching > Capacity Descriptor (ISCD) sub-TLV is defined in

> Section 1.4 of [RFC 4203]". >

done. as a nit comment you can get rid of section 3.1 and just move the

reference to the first time you refer to ISCD



> > - More significantly you are actually changing its format, and in > particular taking 8 bits from the existing reserved field: > > A

> new AI field is defined in this document. >

AI is gone, right?

[Amy] Yes, AI is removed.



> > - Taking bits from the reserved field is a major change and needs to be > justified. The purpose *and the use* of this new field,

> Availability > Index, is unclear in the document. It needs to be, or

> better yet, drop it. > > Section 3.2: > - Why limit Availability

> information to PSC and LSC? >



This limitation remains.   I thought you agreed to dropping this in your

mail back in August.

[Amy] Sorry, I missed this point. Will fix it.



> > Section 6.1 > - A number of references listed as Normative are not required to >

> implement the mechanisms in the document and therefore should be >

> identified as Informative.



I think this needs some change, but this can be resolved independently

of LC.

[Amy] OK.



> The attached is the mail discussion in July and Aug.We believe that

> the latest drafts addressed the comments in these mails, please check.

>

> The latest drafts links

> arehttps://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/,

> and

> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/.

>



My original comments were:

> On 7/25/2015 12:20 PM, Lou Berger wrote:

> > Hi, > I reviewed this document from the perspective of how generalized it

> > is in its current form. > > I think this document's scope in it's

> current form is limited to > RFC6003. I think it sould retitle the

> draft to something like "Ethernet > Traffic Parameters With

> Availability Information" to align with RFC6003.

Done.



> >  The document could also use RFC6003 as a 'design pattern' for some > reediting of its sections/text.



So I guess this wasn't a sufficiently detailed comment.  I see several

issues with section 3. In order of least to most significant:

1) Editorial nits:

    There is no section 3.1

There are grammar and spelling  errors in the section

[Amy] Will fix it.



2) Formatting problems in sections 3.1.x

    Type and length are included, when they aren't in RFC6003 Section 4.1

    Type isn't identified as needing to be assigned

    Most fields lack definition

    AF is defined as a redefinition of the Profile field rather than

simply a definition

        of a new bit in the field.  It should simply be an assignment of

a new flag, i.e.:

         Flag 3 (bit 1): Availability Flag (AF)

    I also don't see the value of the flag as the rfc6003 already

accommodates optional tlv inclusion and no explicit indication of

subsequent TLVs is required.



3) Approach

    Given that there is really no difference between 3.1.1. and RFC6003

Section 4.1, I suggest dropping the Extended Ethernet Bandwidth Profile

TLV (section 3.1.1) and just adding the Availability sub-tlv as a a new

Ethernet SENDER_TSPEC object TLV type.  This also helps backwards

compatibility.

[Amy] I will reply 2) and 3) together. The availability comes with bandwidth together, for example, the request is (bandwidth = 200Mbps, availability = 99.99%).

That’s why the Availability sub-tlv is defined as a sub-tlv under Ethernet Bandwidth Profile TLV.

As the Ethernet Bandwidth Profile TLV defined in RFC6003 is not capable to carry sub-tlv, a new Extended Ethernet Bandwidth Profile TLV is defined. This was presented and discussed in IETF90.



4) Section 3.2

This isn't needed, i.e., the section should be dropped,  as this is

already provided for in RF6003 Section 5.

[Amy] Ok.



5) Section 3.3



This section should refer back to RFC6003 section 7 and  be modified to

talk about the additional processing related to the Availability TLV

(which shouldn't be a big change).



You can drop the last paragraph as it is sufficiently covered in 6003,

but you do need to mention what is expected to happen, as informative

text, on a  node that doesn't support the new tlv.

[Amy] Will update it.



6) The IANA section will need to be updated accordingly





> > > I also suggest reviewing >

> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some >

> suggested guidelines.





> If the drafts addressed all the comments, could it be moved forward?

> Or if you have any other comments, just let us know.

>



So I think we're left with a minor comment + nits on the OSPF document

and some more substantive work on the RSVP draft.





>

>

> BTW, take this chance to wish a happy new year!

>



To you as well!



Cheers,

Lou

>

>

>

> BR,

>

> Amy(on behalf of the co-authors)

>