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

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 14 Jan 2016 02:05:52 +0000

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:[email-masked]]
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)

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Jan 2016 16:17:10 -0500

Amy,
    I think we're left with one substantive discussion topic:

>> 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%).
>
> 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.

So we're discussing two options:

Option 1) new TLV with new optional sub-TLV(s) + Availability sub-TLV
- New TLV : Extended Ethernet Bandwidth Profile TLV
https://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-bandwidth-availability-03#section-3.1.1

- NEW TLV = RFC6003 Section 4.1 + option sub-TLV(s)
and  Availability sub-TLV carried in new TLV, carried  when using
availability,
 
Option 2) Availability TLV
-No change to RFC 6003 or Ethernet Bandwidth Profile TLV
- Optional new Availability TLV carried when using availability

It seems to me that the carried information and the semantics are
equivalent.  But option 1 defines a strictly redundant information
format, with both added implementation and interoperability overhead. So
why not just go with option 2, i.e., drop section 3.1.1. and define
3.1.2 as a tlv of the Ethernet SENDER_TSPEC object?

Lou

On 1/13/2016 9:05 PM, Yemin (Amy) wrote:
>
> Dear all,
>
>  
>
> Below is the offline discussion on
> “draft-ietf-ccamp-ospf-availability-extension-03” and
> “draft-ietf-ccamp-rsvp-te-bandwidth-availability-03”.
>
> *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
> > > - More significantly you are actually changing its format, and in >
> particular taking 8 bits from the existing reserved field: > > A
>
> > > - Taking bits from the reserved field is a major change and needs to be >
> justified. The purpose *and the use* of this new field,
>
> [Amy] I will reply 2) and 3) together. The availability comes with
> bandwidth together, for example, the request is (bandwidth = 200Mbps,
> availability = 99.99%).
>
> 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
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 18 Jan 2016 12:47:22 +0000

Lou, Amy,

Let me try to rephrase the 2 options:

Option 1) As actually proposed by the draft.

+     Ethernet Sender T-spec Object
	++  EXISTING  Ethernet bandwidth profile TLV (type 2)
	++  NEW Extended Ethernet bandwidth profile TLV (e.g. type 4 - used instead of type 2 when availability is needed)
		+++ NEW availability sub-TLV of the NEW Extended Ethernet bandwidth profile TLV

Option 2)

+     Ethernet Sender T-spec Object
	++  EXISTING  Ethernet bandwidth profile TLV (type 2)
	++ NEW availability TLV to be used in conjunction with the type2 TLV when needed.

Since the Ethernet Sender T-SPEC object allows for carrying multiple TLVs I tend to agree with Lou. When no availability is requested only the Ethernet BW profile TLV will be included, otherwise both it and the new availability one.

BR
Daniele

> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: venerdì 15 gennaio 2016 22:17
> To: Yemin (Amy); CCAMP
> Cc: Gregory Mirsky; Longhao; D'Alessandro Alessandro Gerardo; TEAS WG;
> Shah, Himanshu
> Subject: Re: [Teas] Could you check if the latest OSPF extension draft for
> - NEW TLV = RFC6003 Section 4.1 + option sub-TLV(s) and  Availability sub-TLV
> carried in new TLV, carried  when using availability,
> 
> equivalent.  But option 1 defines a strictly redundant information format,
> with both added implementation and interoperability overhead. So why not
> just go with option 2, i.e., drop section 3.1.1. and define
> > > > - More significantly you are actually changing its format, and in
> > > > >
> > > >  The document could also use RFC6003 as a 'design pattern' for
> > > > some >
> > reediting of its sections/text.
> >
> >
> >
> > RFC6003
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 26 Jan 2016 20:22:14 +0000

Dear Daniele, Lou, et. al,
apologies for prolonged silence in the discussion.
I agree that Option 2 offers more elegant solution but it would require change to Availability TLV for the case when Ethernet_TSPEC includes multiple Ethernet Bandwidth Profile TLVs. In such scenario, as I understand Section 4.1 of RFC 6003, each of the Ethernet Bandwidth Profile TLVs within the same Ethernet_TSPEC will have unique value in the Index field. If we add Index field to the Availability TLV, reference it to the Index field as described in the Section 4.1 and note that mapping between two types of TLVs established via the Index would that acceptable solution?

	Regards,
		Greg

-----Original Message-----
From: Daniele Ceccarelli 
Sent: Monday, January 18, 2016 4:47 AM
To: Lou Berger; Yemin (Amy); CCAMP
Cc: Gregory Mirsky; Longhao; D'Alessandro Alessandro Gerardo; TEAS WG; Shah, Himanshu
Subject: RE: [Teas] Could you check if the latest OSPF extension draft for availability address your comments?

Lou, Amy,

Option 2)

BR
Daniele

> Subject: Re: [Teas] Could you check if the latest OSPF extension draft 
> for availability address your comments?
> 
> Amy,
> https://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-bandwidth-availab
> ility-
> 03#section-3.1.1
> 
> - NEW TLV = RFC6003 Section 4.1 + option sub-TLV(s) and  Availability 
> sub-TLV carried in new TLV, carried  when using availability,
> 
> format, with both added implementation and interoperability overhead. 
> So why not just go with option 2, i.e., drop section 3.1.1. and define
> > *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,
> >
> >
> >
> > > http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some 
> > > >
> >
> > > suggested guidelines. >
> >
> > > arehttps://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availabi
> > > li
> > > ty-extension/,
> >
> > > and
> >
> > > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidt
> > > h-
> availability/.
> >
> > >
> >
> >
> >
> >     Type and length are included, when they aren't in RFC6003 
> > Section
> > 4.1
> >
> > > http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some 
> > > >
> >
> > > suggested guidelines.
> >
> >
> >
> >
> >

---

From: Lou Berger <[email-masked]>
Date: Tue, 26 Jan 2016 16:36:07 -0500

Seems reasonable and probably better than an ordering based solution...

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 27 Jan 2016 13:02:00 +0000

Hi Greg, 

I think that's acceptable, or if you prefer you might consider a positioning encoding, e.g.  the availability TLV MUST follow the Ethernet bandwidth profile TLV it refers to.

Which one is easier to implement? Maybe your proposal?

BR
Daniele

> From: Gregory Mirsky
> Sent: martedì 26 gennaio 2016 21:22
> To: Daniele Ceccarelli; Lou Berger; Yemin (Amy); CCAMP
> Cc: Longhao; D'Alessandro Alessandro Gerardo; TEAS WG; Shah, Himanshu
> I agree that Option 2 offers more elegant solution but it would require
> change to Availability TLV for the case when Ethernet_TSPEC includes
> multiple Ethernet Bandwidth Profile TLVs. In such scenario, as I understand
> Section 4.1 of RFC 6003, each of the Ethernet Bandwidth Profile TLVs within
> the same Ethernet_TSPEC will have unique value in the Index field. If we add
> Index field to the Availability TLV, reference it to the Index field as described
> in the Section 4.1 and note that mapping between two types of TLVs
> established via the Index would that acceptable solution?
> 
> 	Regards,
> 		Greg
> 
> 	++  NEW Extended Ethernet bandwidth profile TLV (e.g. type 4 - used
> instead of type 2 when availability is needed)
> Since the Ethernet Sender T-SPEC object allows for carrying multiple TLVs I
> tend to agree with Lou. When no availability is requested only the Ethernet
> BW profile TLV will be included, otherwise both it and the new availability
> one.
> 
> BR
> Daniele
>

---

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 28 Jan 2016 03:12:39 +0000

Dear all,

I will prefer the index proposal which seems having better backward compatibility.
If the node doesn't support availability TLV, it still could proceed with the multiple continual Ethernet bandwidth profile TLVs, and ignore availability TLVs.
And from the implementation consideration, the index proposal will be easier than the ordering. 

BR,
Amy
-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, January 27, 2016 9:02 PM
To: Gregory Mirsky; Lou Berger; Yemin (Amy); CCAMP
Cc: Longhao; D'Alessandro Alessandro Gerardo; Shah, Himanshu; TEAS WG
Subject: Re: [Teas] Could you check if the latest OSPF extension draft for availability address your comments?

Hi Greg, 

BR
Daniele

> I agree that Option 2 offers more elegant solution but it would 
> require change to Availability TLV for the case when Ethernet_TSPEC 
> includes multiple Ethernet Bandwidth Profile TLVs. In such scenario, 
> as I understand Section 4.1 of RFC 6003, each of the Ethernet 
> Bandwidth Profile TLVs within the same Ethernet_TSPEC will have unique 
> value in the Index field. If we add Index field to the Availability 
> TLV, reference it to the Index field as described in the Section 4.1 
> and note that mapping between two types of TLVs established via the Index would that acceptable solution?
> 
> 	Regards,
> 		Greg
> 
> Since the Ethernet Sender T-SPEC object allows for carrying multiple 
> TLVs I tend to agree with Lou. When no availability is requested only 
> the Ethernet BW profile TLV will be included, otherwise both it and 
> the new availability one.
> 
> BR
> Daniele
> 
> > Subject: Re: [Teas] Could you check if the latest OSPF extension 
> > draft for availability address your comments?
> >
> > Amy,
> > > Profile TLV is defined. This was presented and discussed in IETF90.
> >
> > - NEW TLV = RFC6003 Section 4.1 + option sub-TLV(s) and  
> > Availability sub-TLV carried in new TLV, carried  when using 
> > availability,
> >
> > > > document). I have don't understand why "PE" is being introduced. 
> > > > >
> > >
> > > > implement the mechanisms in the document and therefore should be 
> > > > >
> > >
> > > Profile TLV is defined. This was presented and discussed in IETF90.
> > >
> > >
> > >
> > > 4) Section 3.2
> > >