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

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

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:[e-mail]] 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, 

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

> -----Original Message-----
> 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
> Subject: RE: [Teas] Could you check if the latest OSPF extension draft 
> for availability address your comments?
> 
> 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,
> 
> 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
> 
> > -----Original Message-----
> > From: Teas [mailto:[e-mail]] 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 availability address your comments?
> >
> > 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%).
> > >
> > > 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.
> >
> > 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-avail
> > ab
> > 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,
> >
> > 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”.
> > >
> > > 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-availa
> > > > bi
> > > > li
> > > > ty-extension/,
> > >
> > > > and
> > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwi
> > > > dt
> > > > h-
> > 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)
> > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas