Subject: Re: [CCAMP] Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 1 Aug 2016 08:40:25 +0000

Hi Jon,

Thanks a lot for the thorough review and raising a good point that I missed during my review.

I think we could address the compatibility issue like we did in RFC7138.

There we were defining a new Sub-TLV for the SCSI of the ISCD, but since the SCSI associated to the TDM Switching Capability was already defined, we introduces a new Switching Capability value (OTN-TDM).
This allowed us putting a new sub-TLV into the SCSI field and solve all the compatibility issues as the new switching capability would be treated as all the other not known Switching Capabilities.

Now the question, to the authors and the WG is: is it ok to have the Availability defined only against a single (newly defined) Switching capability or it is something that needs to be applicable to all the switching capabilities? If the former we can proceed ala RFC7138, otherwise we need to find an alternate solution.

Jon, does this address your concern?

Thanks
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: mercoledì 27 luglio 2016 13:02
To: Yemin (Amy) <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

Hi Amy

Thanks for the quick reply.

I am still concerned about the lack of backwards compatibility.  Where possible, we want our protocols to be able to be deployed into a mixed environment with some non-compliant nodes.  As things stand, in a mixed environment, non-compliant nodes will disregard the ISCDs and therefore will not be able to compute paths via the compliant nodes.  They are also quite likely to consider the whole LSA to be corrupted and not re-flood it.  My question (to the working group) is – are you SURE you want to publish a standard that would require a forklift upgrade of every node in order to be deployed in a running network?  Particularly as there are other options available that would not require that (such as, not making Availability a sub-TLV of ISCD).

Best regards
Jon

From: Yemin (Amy) [mailto:[email-masked]]
Sent: 27 July 2016 07:53
To: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

Hi Jon,

Thanks for the review comments. Please see my reply inline.

BR,

Amy

________________________________
发件人: Jonathan Hardwick [[email-masked]]
发送时间: 2016年7月27日 0:47
收件人: <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>); BRUNGARD, DEBORAH A; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Routing directorate review of draft-ietf-ccamp-ospf-availability-extension
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-ccamp-ospf-availability-extension
Reviewer: Jon Hardwick
Review Date: 26 July 2016
IETF LC End Date: Not started yet
Intended Status: Proposed standard

== Summary ==
I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

== Comments ==
This document addresses the situation where the maximum bandwidth of some links in the network can vary over time, for example due to radio interference.  Specifically, it addresses the path computation problem, where service placement must take these fluctuations into account.

OSPF is extended to flood the “availability” of such links, which is defined as a sequence of <bandwidth, percentage> tuples.  Each tuple tells the percentage of time at which the bandwidth of the link will be at least as much as <bandwidth>, for example <100Mbps, 99.99%>.  This information is added to the ISCD TLV, defined in RFC 4203.  When services are being planned, the planner specifies the service’s availability requirement (e.g. 4-nines) and the path is computed accordingly.

The document is written in good English and easy enough to understand, and is commendably brief, although probably too brief – see below.

== Major Issues ==

1) The specification of the protocol extensions appears incomplete.  Specifically, section 1 says:

The extension
   reuses the reserved field in the ISCD and also introduces an
   optional Availability sub-TLV.

However, no further mention is made of the ISCD’s reserved field.  How is it reused?
[Amy] AI was defined in the ISCD rsv field in the old version, but it was removed according to discussion.
The latest draft should not contain any text related with AI. Sorry for that,  I will go through the draft to remove the related text.

The following description of the Availability level is difficult to understand and leaves me with several questions:

           This field is a 32-bit IEEE floating point number which

           describes the decimal value of availability guarantee of the

           switching capacity in the ISCD object which has the AI value

           equal to Index of this sub-TLV.

- What is the “switching capacity” of the ISCD object?  Do you mean “switching capability” like PSC-1 etc.?
[Amy] yes, it should be "switching capablity".
- What is the AI value?  This term is not defined.
[Amy] will update the draft to remove the AI related text
- What do you mean by the index of this sub-TLV?  Do you mean the position of this sub-TLV in the list of ISCD sub-TLVs?  What if somebody defines a new ISCD sub-TLV in future – won’t that mess up the indexing?
[Amy] The text "which has the AI value equal to Index of this sub-TLV" will be removed.

2) The proposed extensions are not backwards compatible, so do not support incremental deployment.  In section 3.2 it says:

   A node that doesn't support ISCD Availability sub-TLV SHOULD ignore

   ISCD Availability sub-TLV.

However, it’s not possible for this document to specify the behaviour of nodes that do not support this document.  The issue is that the ISCD Availability TLV is defined as a sub-TLV of the ISCD TLV, but the ISCD TLV defined in RFC 4203 has no sub-TLVs.  Therefore, implementations of RFC 4203 that do not support this draft will reject the ISCD TLVs sent by implementations of this draft, because they will appear to have the wrong length.
[Amy] You're right. How about this text "A node that doesn't support ISCD Availability sub-TLV will reject ISCD Availability sub-TLV."
Or you perfer don't say anything?

== Minor Issues ==

There are a few cases I would like to see spelled out more clearly in the document.
- How should a node interpret the absence of any ISCD Availability TLVs?
[Amy] If a node who support ISCD Availability TLVs doesn't receive the TLV, it indicatess that the link is with fixed bandwidth, the availability can be interpreted as the highest availability value, e.g., five nines.
will update draft to address this case.
- How should a node interpret more than one ISCD Availability TLV for the same availability level?  Is that even legal to send?
[Amy] It's legal to send. will update draft to address this case.
- Let’s say a node advertises a link with 10Gbps capacity, and includes an ISCD Availability TLV saying that the link has a 99% availability level at 8Gbps .  What (if anything) are we to conclude about its availability at 10Gbps?  At 5Gbps?
[Amy] The availability at 10Gbps/5Gbps cannot be concluded from 8Gbps. The <bandwidth, percentage> tuples is usually decided by the modulation and the local condition.
In the appendix of the accompanied draft, "draft-ietf-ccamp-rsvp-te-bandwidth-availability" (https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/?include_text=1 ), there is a example to explain. But there's an error in the table of the appendix, sorry for that. The correct one should be:
Sub-bandwidth(Mbps)    Availability
------------------     ------------
400                    99.99%
200                    99.995%
100                    99.999%
Section 5 (IANA Considerations).  What allocation policy should IANA use for the new sub-registry?  See RFC 5226.
[Amy] The allocation policy should be Standards Action. I will make it clear in next version.

Best regards
Jon

---

From: "Yemin (Amy)" <[email-masked]>
Date: Fri, 5 Aug 2016 02:29:45 +0000

Hi Daniele,

I would prefer the idea to define a new Switching Capability(e.g., Discrete-BW ).
Even with a new SC, it’s also possible to applicable to other SCs.
According to RFC4202, a single interface could support multiple Switching Capabilities, see section 4 of RFC4202.

BR,
Amy

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Monday, August 01, 2016 4:40 PM
To: Jonathan Hardwick; Yemin (Amy); <[email-masked]> ([email-masked]); BRUNGARD, DEBORAH A; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

Hi Jon,

Thanks
Daniele

To: Yemin (Amy) <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Amy

Best regards
Jon

Hi Jon,

BR,

Amy

== Summary ==

== Comments ==

== Major Issues ==

The extension

== Minor Issues ==

Best regards
Jon

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 5 Aug 2016 06:41:22 +0000

Hi Daniele, Amy,

If defining a new SC is acceptable to the WG then it would also address my concern.

Cheers
Jon

Sent from my Xperia Z1 on O2

---- Yemin (Amy) wrote ----

Hi Daniele,

BR,
Amy

Hi Jon,

Thanks
Daniele

Hi Amy

Best regards
Jon

Hi Jon,

BR,

Amy

== Summary ==

== Comments ==

== Major Issues ==

The extension

== Minor Issues ==

Best regards
Jon

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 5 Aug 2016 13:29:06 +0000

Thanks a lot once again Jon,

Amy, please update the draft accordingly and including the other comments from Jon.

The change is pretty much a major one and I see the draft has been placed in “Expert Review” state. Fatai and I will discuss with Deborah if the Expert Review will be enough or we’ll need to go for a second working group last call.

Thanks
Daniele

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: venerdì 5 agosto 2016 08:41
To: Daniele Ceccarelli <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]; Yemin (Amy) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

Hi Daniele, Amy,

Cheers
Jon

---- Yemin (Amy) wrote ----
Hi Daniele,

BR,
Amy

To: Jonathan Hardwick; Yemin (Amy); <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>); BRUNGARD, DEBORAH A; [email-masked]<mailto:[email-masked]>

Hi Jon,

Thanks
Daniele

Hi Amy

Best regards
Jon

Hi Jon,

BR,

Amy

== Summary ==

== Comments ==

== Major Issues ==

The extension

== Minor Issues ==

Best regards
Jon

---

From: Lou Berger <[email-masked]>
Date: Tue, 9 Aug 2016 10:17:41 -0400

Just catching up on this thread - sorry about the delayed response. 

My understanding is that this was not made a specific switching
capability as variable bandwidth is increasingly present across multiple
technologies and therefore should be usable by any.

It seems the problem in achieving this goal is that SCSI wasn't defined
as a TLV list, so only a per technology SCSI definition is possible. 
IMO this is unfortunate. 

Now this said, two technologies do have TLVs as part of their SCSI,
i.e.,  OTN-TDM SCSI RFC7138 and WSON-LSC SCSI RFC7688 so it is still
possible  to define a generic TLV structure and TLV code points for the
SCSIs that support TLVs (OTN-TDM and WSON-LSC). of course, the question
is then is it useful.  Perhaps for WSON, but I'm not sure about OTN.

Independent of this, any new SC type should adopt the TLV approach used
by the more recent SCSIs.

What SC are you thinking about adding?  And does it make sense to do it
in this document or another (derivative) document?

Thanks,

Lou

On 8/5/2016 9:29 AM, Daniele Ceccarelli wrote:
> The change is pretty much a major one and I see the draft has been
> placed in “Expert Review” state. Fatai and I will discuss with Deborah
> if the Expert Review will be enough or we’ll need to go for a second
> working group last call.
>
>  
>
> Thanks
>
> Daniele 
>
>  
>
> *From:*Jonathan Hardwick [mailto:[email-masked]]
> *Sent:* venerdì 5 agosto 2016 08:41
> *To:* Daniele Ceccarelli <[email-masked]>;
> <[email-masked]> ([email-masked]) <[email-masked]>; BRUNGARD,
> DEBORAH A <[email-masked]>;
> [email-masked]; Yemin (Amy)
> <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: Routing directorate review of
> draft-ietf-ccamp-ospf-availability-extension
>
>  
>
> Hi Daniele, Amy,
>
> I would prefer the idea to define a new Switching
> Capability(e.g.,Discrete-BW ).
>
> According to RFC4202, a single interface could support multiple
> Switching Capabilities, see section 4 of RFC4202.
>
>  
>
> BR,
>
> Amy
>
>  
>
> *From:*Daniele Ceccarelli [mailto:[email-masked]]
> *Sent:* Monday, August 01, 2016 4:40 PM
> *To:* Jonathan Hardwick; Yemin (Amy); <[email-masked]
> <mailto:[email-masked]>> ([email-masked]
> <mailto:[email-masked]>); BRUNGARD, DEBORAH A;
> [email-masked]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: Routing directorate review of
> draft-ietf-ccamp-ospf-availability-extension
>
>  
>
> Hi Jon,
>
>  
>
> There we were defining a new Sub-TLV for the SCSI of the ISCD, but
> since the SCSI associated to the TDM Switching Capability was already
> defined, we introduces a new Switching Capability value (OTN-TDM).
>
> This allowed us putting a new sub-TLV into the SCSI field and solve
> all the compatibility issues as the new switching capability would be
> treated as all the other not known Switching Capabilities.
>
>  
>
> Now the question, to the authors and the WG is: is it ok to have the
> Availability defined only against a single (newly defined) Switching
> capability or it is something that needs to be applicable to all the
> switching capabilities? If the former we can proceed ala RFC7138,
> otherwise we need to find an alternate solution.
>
>  
>
> *From:*CCAMP [mailto:[email-masked]] *On Behalf Of *Jonathan
> Hardwick
> *Sent:* mercoledì 27 luglio 2016 13:02
> *To:* Yemin (Amy) <[email-masked]
> <mailto:[email-masked]>>; <[email-masked]
> <mailto:[email-masked]>> ([email-masked]
> <mailto:[email-masked]>) <[email-masked]
> <mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]
> <mailto:[email-masked]>>;
> [email-masked]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [CCAMP] Routing directorate review of
> draft-ietf-ccamp-ospf-availability-extension
>
>  
>
> Hi Amy
>
>  
>
> I am still concerned about the lack of backwards compatibility.  Where
> possible, we want our protocols to be able to be deployed into a mixed
> environment with some non-compliant nodes.  As things stand, in a
> mixed environment, non-compliant nodes will disregard the ISCDs and
> therefore will not be able to compute paths via the compliant nodes. 
> They are also quite likely to consider the whole LSA to be corrupted
> and not re-flood it.  My question (to the working group) is – are you
> SURE you want to publish a standard that would require a forklift
> upgrade of every node in order to be deployed in a running network? 
> Particularly as there are other options available that would not
> require that (such as, not making Availability a sub-TLV of ISCD).
>
>  
>
> Best regards
>
> Jon
>
>  
>
>  
>
> *From:*Yemin (Amy) [mailto:[email-masked]]
> *Sent:* 27 July 2016 07:53
> *To:* Jonathan Hardwick <[email-masked]
> <mailto:[email-masked]>>; <[email-masked]
> <mailto:[email-masked]>> ([email-masked]
> <mailto:[email-masked]>) <[email-masked]
> <mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]
> <mailto:[email-masked]>>;
> [email-masked]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: Routing directorate review of
> draft-ietf-ccamp-ospf-availability-extension
>
>  
>
> Hi Jon,
>
>  
>
> ------------------------------------------------------------------------
>
> *发件人**:*Jonathan Hardwick [[email-masked]]
> *发送时间**:*2016年7月27日0:47
> *收件人**:*<[email-masked] <mailto:[email-masked]>> ([email-masked]
> <mailto:[email-masked]>); BRUNGARD, DEBORAH A;
> [email-masked]
> <mailto:[email-masked]>
> *抄送**:[email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *主**题**:*Routing directorate review of
> draft-ietf-ccamp-ospf-availability-extension
>
> Hello,
>
>  
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
>  
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
>  
>
> I have significant concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
>
>  
>
> == Comments ==
>
> This document addresses the situation where the maximum bandwidth of
> some links in the network can vary over time, for example due to radio
> interference.  Specifically, it addresses the path computation
> problem, where service placement must take these fluctuations into
> account.
>
>  
>
> OSPF is extended to flood the “availability” of such links, which is
> defined as a sequence of <bandwidth, percentage> tuples.  Each tuple
> tells the percentage of time at which the bandwidth of the link will
> be at least as much as <bandwidth>, for example <100Mbps, 99.99%>. 
> This information is added to the ISCD TLV, defined in RFC 4203.  When
> services are being planned, the planner specifies the service’s
> availability requirement (e.g. 4-nines) and the path is computed
> accordingly.
>
>  
>
> The document is written in good English and easy enough to understand,
> and is commendably brief, although probably too brief – see below.
>
>  
>
> == Major Issues ==
>
>  
>
> The latest draft should not contain any text related with AI. Sorry
> for that,  I will go through the draft to remove the related text.
>
>  
>
> The following description of the Availability level is difficult to
> understand and leaves me with several questions:
>
> - What do you mean by the index of this sub-TLV?  Do you mean the
> position of this sub-TLV in the list of ISCD sub-TLVs?  What if
> somebody defines a new ISCD sub-TLV in future – won’t that mess up the
> indexing?
>
> 2) The proposed extensions are not backwards compatible, so do not
> support incremental deployment.  In section 3.2 it says:
>
>  
>
> However, it’s not possible for this document to specify the behaviour
> of nodes that do not support this document.  The issue is that the
> ISCD Availability TLV is defined as a sub-TLV of the ISCD TLV, but the
> ISCD TLV defined in RFC 4203 has no sub-TLVs.  Therefore,
> implementations of RFC 4203 that do not support this draft will reject
> the ISCD TLVs sent by implementations of this draft, because they will
> appear to have the wrong length.
>
> [Amy] You're right. How about this text "A node that doesn't support
> ISCD Availability sub-TLV will reject ISCD Availability sub-TLV."
>
> [Amy] If a node who support ISCD Availability TLVs doesn't receive the
> TLV, it indicatess that the link is with fixed bandwidth, the
> availability can be interpreted as the highest availability value,
> e.g., five nines.
>
> - How should a node interpret more than one ISCD Availability TLV for
> the same availability level?  Is that even legal to send?
>
> - Let’s say a node advertises a link with 10Gbps capacity, and
> includes an ISCD Availability TLV saying that the link has a 99%
> availability level at 8Gbps .  What (if anything) are we to conclude
> about its availability at 10Gbps?  At 5Gbps?
>
> [Amy] The availability at 10Gbps/5Gbps cannot be concluded from 8Gbps.
> The <bandwidth, percentage> tuples is usually decided by the
> modulation and the local condition.
>
> In the appendix of the accompanied draft,
> "draft-ietf-ccamp-rsvp-te-bandwidth-availability"
> (https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/?include_text=1 ),
> there is a example to explain. But there's an error in the table of
> the appendix, sorry for that. The correct one should be:
>
> Section 5 (IANA Considerations).  What allocation policy should IANA
> use for the new sub-registry?  See RFC 5226.
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Yemin (Amy)" <[email-masked]>
Date: Wed, 10 Aug 2016 09:05:06 +0000

Hi Lou,

I'm thinking of "MW" (microwave), or "Va-Dis-BW-link"(Variable Discrete Bandwidth link). 
But I'm open for a better name. 

Defining a generic TLV is a good approach to solve problem. It might be better to discuss in another document. Would like to hear other's opinion from WG. 

BR,
Amy
-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, August 09, 2016 10:18 PM
To: Daniele Ceccarelli; Jonathan Hardwick; <[email-masked]> ([email-masked]); BRUNGARD, DEBORAH A; [email-masked]; Yemin (Amy)
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

My understanding is that this was not made a specific switching capability as variable bandwidth is increasingly present across multiple technologies and therefore should be usable by any.

It seems the problem in achieving this goal is that SCSI wasn't defined as a TLV list, so only a per technology SCSI definition is possible. 
IMO this is unfortunate. 

Now this said, two technologies do have TLVs as part of their SCSI, i.e.,  OTN-TDM SCSI RFC7138 and WSON-LSC SCSI RFC7688 so it is still possible  to define a generic TLV structure and TLV code points for the SCSIs that support TLVs (OTN-TDM and WSON-LSC). of course, the question is then is it useful.  Perhaps for WSON, but I'm not sure about OTN.

Independent of this, any new SC type should adopt the TLV approach used by the more recent SCSIs.

What SC are you thinking about adding?  And does it make sense to do it in this document or another (derivative) document?

Thanks,

Lou

On 8/5/2016 9:29 AM, Daniele Ceccarelli wrote:
> (https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-a
> vailability/?include_text=1 ), there is a example to explain. But 
> there's an error in the table of the appendix, sorry for that. The correct one should be:
>

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 10 Aug 2016 12:10:07 +0200

Dear Amy,

Lou mentioned already that there are multiple technologies are using
discrete, variable, bandwidth.

Some of them (VCAT/LCAS, ODUflex/HAO) use "Adjustable" to indicate
the flexibility of the link, but also of the switching capability.

How about: DASC - Discrete Adjustable Switching Capability.

Best regards, Huub.

----------

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Aug 2016 09:05:31 -0400

Amy,

    Perhaps the right way to go is have this document define just the
TLV and have a new document define it's technology specific usage?  This
would probably be the cleanest and allow this document to progress at a
different rate (now) vs the SC-specific details that still need to be
written.

Lou

---

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 11 Aug 2016 07:13:53 +0000

Hi Lou,

The current draft defines the availability in the way of TLV. 
Are you suggesting to progress the current draft as it is (without new SC definition)? And another document to explain how the existing SC types use the availability TLV, e.g., by defining a new type code point?

BR,
Amy

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, August 10, 2016 9:06 PM
To: Yemin (Amy); Daniele Ceccarelli; Jonathan Hardwick; <[email-masked]> ([email-masked]); BRUNGARD, DEBORAH A; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

Amy,

    Perhaps the right way to go is have this document define just the TLV and have a new document define it's technology specific usage?  This would probably be the cleanest and allow this document to progress at a different rate (now) vs the SC-specific details that still need to be written.

Lou

On 8/10/2016 5:05 AM, Yemin (Amy) wrote:
> To: Daniele Ceccarelli; Jonathan Hardwick; <[email-masked]> 
> ([email-masked]); BRUNGARD, DEBORAH A; 
> Subject: Re: [CCAMP] Routing directorate review of 
>> placed in “Expert Review” state. Fatai and I will discuss with 
>> Deborah if the Expert Review will be enough or we’ll need to go for a 
>> second working group last call.
>>
>>  
>>
>> Thanks
>>
>> Daniele
>>
>>  
>>
>> I am still concerned about the lack of backwards compatibility.  
>> Where possible, we want our protocols to be able to be deployed into 
>> a mixed environment with some non-compliant nodes.  As things stand, 
>> in a mixed environment, non-compliant nodes will disregard the ISCDs 
>> and therefore will not be able to compute paths via the compliant nodes.
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> *收件人**:*<[email-masked] <mailto:[email-masked]>> 
>> ([email-masked] <mailto:[email-masked]>); BRUNGARD, DEBORAH A; 
>> review, and sometimes on special request. The purpose of the review 
>> is to provide assistance to the Routing ADs. For more information 
>> about the Routing Directorate, please see 
>> I have significant concerns about this document and recommend that 
>> the Routing ADs discuss these issues further with the authors.
>>
>>  
>>
>> == Comments ==
>>
>> some links in the network can vary over time, for example due to 
>> radio interference.  Specifically, it addresses the path computation 
>> The document is written in good English and easy enough to 
>> understand, and is commendably brief, although probably too brief – see below.
>>
>>  
>>
>> == Major Issues ==
>>
>>  
>>
>> somebody defines a new ISCD sub-TLV in future – won’t that mess up 
>> the indexing?
>>
>> ISCD Availability TLV is defined as a sub-TLV of the ISCD TLV, but 
>> the ISCD TLV defined in RFC 4203 has no sub-TLVs.  Therefore, 
>> implementations of RFC 4203 that do not support this draft will 
>> reject the ISCD TLVs sent by implementations of this draft, because 
>> they will appear to have the wrong length.
>>
>> [Amy] If a node who support ISCD Availability TLVs doesn't receive 
>> the TLV, it indicatess that the link is with fixed bandwidth, the

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Aug 2016 06:11:14 -0400

Amy,

On August 11, 2016 3:15:18 AM "Yemin (Amy)" <[email-masked]> wrote:

> Are you suggesting to progress the current draft as it is (without new SC 
> definition)?

Yes.

> And another document to explain how the existing SC types use the 
> availability TLV, e.g., by defining a new type code point?
>

I would phrase it as defining a new SC pipe in the new document. This 
document or a different document could define how the two SCs that support 
TLVs can use the tlv defined in your first document.

Lou
> To: Yemin (Amy); Daniele Ceccarelli; Jonathan Hardwick; <[email-masked]> 
>     Perhaps the right way to go is have this document define just the TLV and 
>     have a new document define it's technology specific usage?  This would 
>     probably be the cleanest and allow this document to progress at a different 
>     rate (now) vs the SC-specific details that still need to be written.
>
> Lou
>
>> Defining a generic TLV is a good approach to solve problem. It might be 
>> better to discuss in another document. Would like to hear other's opinion 
>> from WG.
>>
>> BR,
>> Amy
>> My understanding is that this was not made a specific switching capability 
>> as variable bandwidth is increasingly present across multiple technologies 
>> and therefore should be usable by any.
>>
>>
>> It seems the problem in achieving this goal is that SCSI wasn't defined as 
>> a TLV list, so only a per technology SCSI definition is possible.
>> IMO this is unfortunate.
>>
>> Now this said, two technologies do have TLVs as part of their SCSI, i.e.,  
>> OTN-TDM SCSI RFC7138 and WSON-LSC SCSI RFC7688 so it is still possible  to 
>> define a generic TLV structure and TLV code points for the SCSIs that 
>> support TLVs (OTN-TDM and WSON-LSC). of course, the question is then is it 
>> useful.  Perhaps for WSON, but I'm not sure about OTN.
>>
>> What SC are you thinking about adding?  And does it make sense to do it in 
>> this document or another (derivative) document?
>>
>> Thanks,
>>
>> Lou
>>