Subject: [CCAMP] Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

From: "Alia Atlas" <[email-masked]>
Date: Wed, 05 Aug 2015 07:46:46 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-ccamp-wson-signal-compatibility-ospf-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to see clearer descriptions on particularly the error-handling
around multiple TLVs and sub-TLVs. 
I see a few points of ambiguity - as described below.  I think these
should be straightforward to clarify but
interoperability could be affected if this isn't done.   Thanks!

In Sec 2, it says "Only one Optical Node Property TLV shall be advertised
in each LSA." What is the error-handling if multiple of this TLV are
seen?
Is that a SHALL or a "at most one... MUST be advertised"?  I'd expect
normative language.

In Sec 2, it says "   Among the sub-TLVs defined above, the Resource
Block Pool State sub-
   TLV and Resource Block Shared Access Wavelength Availability are
   dynamic in nature while the rest are static. As such, they can be
   separated out from the rest and be advertised with multiple TE LSAs
   per OSPF router, as described in [RFC3630] and [RFC5250]."
So - one can advertise multiple TE LSAs - each with at most one  Optical
Node Property TLV 
and at most one of these sub-TLVs?  If the same sub-TLV appears in
different TE LSAs, how
are they merged or is a particular one preferred and the rest ignored?  I
see the text in the
previous paragraph of "If more than one copy of a sub-TLV is received,
   only the first one of the same type is processed and the rest are
   ignored upon receipt." but what does the "first one" mean?  Is that
decided based on
a particular identifier?

In Sec 3.1, "The format of the SCSI MUST be as depicted in the following
figure:" implies that
both the Available Label Sub-TLV and the Shared Backup Label Sub-TLV must
be included and
in the specified order.   Please clarify (and use separate diagrams)
details about how many times
each sub-TLV can appear, if ordering matters, and how to handle conflicts
or duplicates.

End of Sec 4: "In case where the new sub-TLVs or their attendant
encodings are
   malformed, the proper action would be to log the problem and
ignore..."  First, please be explicit in
what behavior MUST be done.  Is this just for malformed sub-TLVs?  Is it
safe to assume that sub-TLVs
further on in the TLV (or following TLVs) can be properly parsed? 
Second, please add in some words
about the expected load of logs.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Sec 2, it's useful to use TBA1, TBA2, etc. instead of reusing TBA -
adds to clarity of the text and makes it easier to make sure replacement
is done
properly when the values are assigned.

In Sec 3.1, it says "   The technology specific part of the WSON ISCD may
include a variable
   number of sub-TLVs called Bandwidth sub-TLVs.  Two types of
   Bandwidth sub-TLV are defined (TBA by IANA):"   If this document is
creating the
bandwidth sub-tlv space, then this draft simply assigns initial values -
so no need for the "TBA
by IANA".

In Sec 4, "In a typical node configuration, the optical node property TLV
will not exceed the IP MTU."
Can you please describe the assumptions about a "typical node
configuration"?  In a few years, these
assumptions are likely to have changed.

---

From: Leeyoung <[email-masked]>
Date: Wed, 5 Aug 2015 19:11:18 +0000

Hi Alia,

Thank you first of all for providing very useful comments. 

Here's my attempt to your comments/DISCUSS. Please see inline. 

Thanks.
Young

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2015 9:47 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

YOUNG>> This is to allow for fine granularity changes in topology per [RFC3630]. It is not an error per se if there are multiple of this TLV are in each LSA. 

YOUNG>> "SHALL" seems to be right one, again per [RFC3630].

and at most one of these sub-TLVs?  

YOUNG>> This is correct except that the Optical Node Property TLV would carry "at least" one of these sub-TLVs as opposed to "at most one of these sub-TLVs." For instance, one TE LSA can carry one Optical Node Property TLV under which two dynamic sub-TLVs (i.e., the Resource
Block Pool State sub-TLV and Resource Block Shared Access Wavelength Availability sub-TLV) can be advertised while another TE LSA can carry one Optical Node Property TLV under which the rest of static sub-TLVs can be advertised.  

If the same sub-TLV appears in
different TE LSAs, how

YOUNG>> The text in Section 2 you quoted is not dealing with the case for two different TE LSAs. In such case, then the sub-TLVs will identify by the value of the sub-TLV. 

The case you are referring to is for the case where the same sub-TLV is advertised in different TE LSAs. It should NOT happen that way, but in case it happens by mistake of packaging, then it will be updated one after another. There is no way for the routers to distinguish this sub-TLV as the same one (as it is under different TE LSAs), which is actually fine. It is not an error condition. The router would simply process the same sub-TLV multiple times. 

I can suggest the following changes:

OLD: 

   All sub-TLVs defined here may occur at most once in any given
   Optical Node TLV. If more than one copy of a sub-TLV is received,
   only the first one of the same type is processed and the rest are
   ignored upon receipt. These restriction need not apply to future
   sub-TLVs. Unrecognized sub-TLVs are ignored.

NEW: 

   All sub-TLVs defined here may occur at most once in any given
   Optical Node TLV under one TE LSA. If more than one copy of a sub-TLV is received,
   only the first one of the same type is processed and the rest are
   ignored upon receipt. These restriction need not apply to future
   sub-TLVs. Unrecognized sub-TLVs are ignored.

   In case where the same sub-TLV is advertised in different TE LSAs (which would take place by a 
   packaging error), then the sub-TLV will be updated one after another. There is no way for the  
   routers to distinguish this sub-TLV as the same one (as it is under different TE LSAs), which is 
   actually fine. It is not an error condition. The router would simply process the same sub-TLV 
   multiple times.

END.

YOUNG>> Good point. I would relax "MUST" to "SHALL" as there is no issue of ordering here. The number of each sub-TLV depends on the number of labels this field describes. If we were talking about, 100 channel (wavelength) system, this can be as many as 100 sub-TLVs for the Available Label sub-TLV + Shared Backup Label TLV. But there are ways to reduce the entry by Label Range, etc per [Gen-Encode]. 

In case duplicated sub-TLVs appear (which should not happen), the router/node will ignore the duplicated labels which are identified by the Label format defined in [RFC6205]. 

May I suggest the following changes:

OLD

	The format of the SCSI MUST be as depicted in the following figure:

NEW

	The format of the SCSI SHALL be as depicted in the following figure:

END

OLD

	Where the Available Label Sub-TLV and Shared Backup Label sub-TLV
   	are defined in [Gen-Encode]. (right below Figure 1)

NEW

	Where the Available Label Sub-TLV and Shared Backup Label sub-TLV
   	are defined in [Gen-Encode]. In case where duplicated sub-TLVs are advertised, 
      the router/node will ignore the duplicated labels which are identified by the Label format 
      defined in [RFC6205].

END

End of Sec 4: "In case where the new sub-TLVs or their attendant
encodings are
   malformed, the proper action would be to log the problem and
ignore..."  First, please be explicit in
what behavior MUST be done.  

YOUNG>> malformed sub-TLVs or their attendant encodings refer to that which are not parse-able due to corruption, etc. and cannot be stored in the TED. 

How about adding a new sentence to describe the expected action as follows:

OLD

   In case where the new sub-TLVs or their attendant encodings are
   malformed, the proper action would be to log the problem and ignore
   just the sub-TLVs in GMPLS path computations rather than ignoring
   the entire LSA.

NEW

   In case where the new sub-TLVs or their attendant encodings are
   malformed, the proper action would be to log the problem and ignore
   just the sub-TLVs in GMPLS path computations rather than ignoring
   the entire LSA. This should not stop the LSA advertisement process. 

Is this just for malformed sub-TLVs?  Is it
safe to assume that sub-TLVs
further on in the TLV (or following TLVs) can be properly parsed? 

YOUNG>> Yes we are just talking about malformed sub-TLVs. It is safe to assume that other sub-TLVs in the TLV or following TLVs can be properly parsed as they are a distinct sets of info elements with proper sub-TLV types, TLV types. 

YOUNG>> How about adding one sentence followed by "In case..."

NEW
	The expected load of logs is not expected to be a high volume as malformed TLVs do not occur 
      frequently in GMPLS.  

END

YOUNG>> Good point. I will change that way as you suggest. 

YOUNG>> Correct. Will address that. 

YOUNG>> I can add:

NEW

	A typical node configuration refers to a system with several hundreds of channels. In addition, [WSON-Encode] provides mechanisms to compactly encode required information elements. 

END

---

From: Alia Atlas <[email-masked]>
Date: Fri, 21 Aug 2015 17:07:01 -0400

Hi Young,

My apologies for the long delay in responding.  My responses are in-line.

Thanks,
Alia

On Wed, Aug 5, 2015 at 3:11 PM, Leeyoung <[email-masked]> wrote:

> Cc: [email-masked];
> [email-masked]; [email-masked]
> Subject: Alia Atlas' Discuss on
> draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and
> COMMENT)
>
> YOUNG>> This is to allow for fine granularity changes in topology per
> [RFC3630]. It is not an error per se if there are multiple of this TLV are
> in each LSA.
>

[Alia] Ok - SHALL is fine.  Perhaps text like
"To allow for fine granularity changes in topology, only one Optical Node
Property TLV SHALL be
advertised in each LSA.  An implementation MUST support receiving multiple
Optical Node Property
TLVs in an LSA."

> YOUNG>> This is correct except that the Optical Node Property TLV would
> carry "at least" one of these sub-TLVs as opposed to "at most one of these
> sub-TLVs." For instance, one TE LSA can carry one Optical Node Property TLV
> under which two dynamic sub-TLVs (i.e., the Resource
> Block Pool State sub-TLV and Resource Block Shared Access Wavelength
> Availability sub-TLV) can be advertised while another TE LSA can carry one
> Optical Node Property TLV under which the rest of static sub-TLVs can be
> advertised.

 [Alia] Ok.  Thanks for clarifying.

> YOUNG>> The text in Section 2 you quoted is not dealing with the case for
> two different TE LSAs. In such case, then the sub-TLVs will identify by the
> value of the sub-TLV.
>
> The case you are referring to is for the case where the same sub-TLV is
> advertised in different TE LSAs. It should NOT happen that way, but in case
> it happens by mistake of packaging, then it will be updated one after
> another. There is no way for the routers to distinguish this sub-TLV as the
> same one (as it is under different TE LSAs), which is actually fine. It is
> not an error condition. The router would simply process the same sub-TLV
> multiple times.
>

[Alia] My concern is about the phrase "only the first one" because two
different routers may
received the TE LSAs in different order depending upon flooding dynamics.
I would much rather
that you define a tie-breaking mechanism - for instance  picking the
largest LSA ID (Sec 2.2 of RFC 3630),
because that is considered newer.

>    actually fine. It is not an error condition. The router would simply

[Alia] Wouldn't the information contained be redundant?  I'm not sure why
you think that the duplication
can't be detected based on fields in the sub-TLV.  Again, just a simple
tie-breaker would provide interoperability.

> YOUNG>> Good point. I would relax "MUST" to "SHALL" as there is no issue
> of ordering here. The number of each sub-TLV depends on the number of
> labels this field describes. If we were talking about, 100 channel
> (wavelength) system, this can be as many as 100 sub-TLVs for the Available
> Label sub-TLV + Shared Backup Label TLV. But there are ways to reduce the
> entry by Label Range, etc per [Gen-Encode].
>
> In case duplicated sub-TLVs appear (which should not happen), the
> router/node will ignore the duplicated labels which are identified by the
> Label format defined in [RFC6205].
>

[Alia] How about "A SCSI may contain multiple Available Label sub-TLVs and
multiple Shared Backup Label sub-TLVs.  The following figure shows the
format for a SCSI that contains these sub-TLVs.  The order of the sub-TLVs
in the SCSI is arbitrary."

> identified by the Label format

[Alia] Sounds good.

> YOUNG>> malformed sub-TLVs or their attendant encodings refer to that
> which are not parse-able due to corruption, etc. and cannot be stored in
> the TED.
>

[Alia] Usually, one doesn't reflood LSAs with malformed TLVs or sub-TLVs.
I'm certainly willing
to listen to reasoning on why flooding potentially corrupt data would be a
good idea, but you'll need
really clear reasoning.

> YOUNG>> Yes we are just talking about malformed sub-TLVs. It is safe to
> assume that other sub-TLVs in the TLV or following TLVs can be properly
> parsed as they are a distinct sets of info elements with proper sub-TLV
> types, TLV types.

[Alia]  Are you picturing that a sub-TLV is malformed if its length isn't
accurate or just if one of the fields inside the sub-TLV is using a bad
value or setting a reserved value?  In the latter cases, perhaps it might
be tolerable to assume that there wasn't data-corruption that will affect
the rest of the parsing - but I'm dubious.   For the first, if the length
is wrong, then you can't accurately know where the next sub-TLV starts so
all parsing after isn't trustable, IMHO.

> malformed TLVs do not occur

[Alia] Uh - of course error conditions aren't expected to be common!  How
about considering how often the
advertising router might send the LSA?  How about considering the number of
neighbors that will be flooding it?
How about dampening the number of logs?  Making it a MAY log also makes it
clear that it's up to the implementation.

>         A typical node configuration refers to a system with several
> hundreds of channels. In addition, [WSON-Encode] provides mechanisms to
> compactly encode required information elements.
>
> END
>

[Alia] Thanks - could you take this one step further and specify about the
expected size of the TLV based on these assumptions?

Thanks,
Alia

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 22 Aug 2015 09:05:59 +0100

Hi Young, Alia,

>>> should be straightforward to clarify but interoperability could be 
>>> affected if this isn't done.   Thanks!
>>>
> Property TLV SHALL be advertised in each LSA.  An implementation MUST
> support receiving multiple Optical Node Property TLVs in an LSA."

Sorry, but I think this reads as nonsense :-(
"SHALL" and "MUST" are identical in meaning.
So you have written "only one TLV MUST be advertised". That is ambiguous!
It could mean "no more than one" or it could mean "it is only necessary to advertise one must, but others may be included"
The thrust of the conversation appears to be for the latter, so don't try to do this in clever compact code - write it out in full!

That might give (if it is what you intend to say)...

When using the extensions defined in this document, at least one Optical Node Property TLV MUST be advertised in each LSA. To allow for fine granularity changes in topology, more than one Optical Node Property TLV MAY be advertised in a single LSA. Implementations MUST support receiving multiple Optical Node Property TLVs in an LSA.

[snip]

>>    The format of the SCSI SHALL be as depicted in the following figure:

These sentences are identical! MUST==SHALL

So Alia's text is nicer...

> in the SCSI is arbitrary."

[snip]
 
>>> encodings are malformed, the proper action would be to log the problem
>>> and ignore..."  First, please be explicit in what behavior MUST be done.

I think this request got lost in the discussions that follow. Alia is correctly asking for...

"When bad stuff happens you MUST do some things, SHOULD do other things, and MAY do additional things."

>> YOUNG>> malformed sub-TLVs or their attendant encodings refer to that which are
>> not parse-able due to corruption, etc. and cannot be stored in the TED.

Hmmm. The most common cause of unparsable TLVs will be encoding errors, bugs, misinterpretation of specs, up-level implementations, etc. Corruption doesn't happen much.
The upshot is the same - you can't process the TLV.

> I'm certainly willing to listen to reasoning on why flooding potentially corrupt
> data would be a good idea, but you'll need really clear reasoning.

Why is this any different to any other TLV in any other LSA? Don't we just call on standard OSPF behavior?

>>> Is this just for malformed sub-TLVs?  Is it safe to assume that sub-TLVs
>> YOUNG>> Yes we are just talking about malformed sub-TLVs. It is safe to assume
>> that other sub-TLVs in the TLV or following TLVs can be properly parsed as they
>> are a distinct sets of info elements with proper sub-TLV types, TLV types.
>
> [Alia]  Are you picturing that a sub-TLV is malformed if its length isn't accurate or just
> if one of the fields inside the sub-TLV is using a bad value or setting a reserved value?
>  In the latter cases, perhaps it might be tolerable to assume that there wasn't data-
> corruption that will affect the rest of the parsing - but I'm dubious.   For the first, if
> the length is wrong, then you can't accurately know where the next sub-TLV starts
> so all parsing after isn't trustable, IMHO. 

I think you have to handle both cases. Furthermore, if the TLV is of variable length, anything unexpected needs to be treated with caution.

>>        The expected load of logs is not expected to be a high volume as malformed
>>        TLVs do not occur frequently in GMPLS.
>>
>> END
>
> about considering how often the advertising router might send the LSA? 
> How about considering the number of neighbors that will be flooding it?
> How about dampening the number of logs?  Making it a MAY log also makes
> it clear that it's up to the implementation.

The normal way of handling this is...
"Errors of this nature SHOULD be logged for the local operator. Implementations MUST provide a rate limit on such logs, and that rate limit SHOULD be configurable."

Adrian

---

From: Leeyoung <[email-masked]>
Date: Wed, 26 Aug 2015 15:50:45 +0000

Hi Adrian and Alia,

Thanks for your comments. Please see inline for my comment.

I will comment the rest of the issues (raised by Alia) not addressed here in another email thread. 

Best regards,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Saturday, August 22, 2015 3:06 AM
To: 'Alia Atlas'; Leeyoung
Cc: [email-masked]; [email-masked]; [email-masked]; 'The IESG'
Subject: RE: [CCAMP] Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

Hi Young, Alia,

YOUNG>> Thanks. This works for me. I would accept Adrian's suggested text. 

[snip]

> in the SCSI is arbitrary."

YOUNG>> Accepted. 

[snip]

YOUNG>> Sorry that I missed this. Yes, this is a good question to ask. Please see the next resolution that basically says that the malformed LSA "MUST" be dropped while logging of this problem SHOULD be done. 

YOUNG>> Adrian, what is standard OSPF behavior in this case? I would assume we drop the entire LSA in which to contain malformed TLVs or sub-TLVs. If that is the case, how about:

NEW
	In case where the new sub-TLVs or their attendant encodings are
	malformed, the proper action SHOULD log the problem and MUST stop 
      sending the LSA in which to contain malformed TLVs or sub-TLVs. 
END

YOUNG>> Rethinking this issue, I would go with the previous resolution --- just stop sending the LSA in which to contain malformed TLVs and sub-TLVs. 

YOUNG>> I would accept Adrian's proposed text. 

Adrian

---

From: Leeyoung <[email-masked]>
Date: Wed, 26 Aug 2015 16:25:08 +0000

Hi Alia,

Thank you for providing your good comments.

Please see in-line for my comments.

Best regards,
Young

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, August 21, 2015 4:07 PM
To: Leeyoung
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

Hi Young,

Thanks,
Alia

On Wed, Aug 5, 2015 at 3:11 PM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Thanks.
Young

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 05, 2015 9:47 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

[Alia] Ok - SHALL is fine.  Perhaps text like
"To allow for fine granularity changes in topology, only one Optical Node Property TLV SHALL be
advertised in each LSA.  An implementation MUST support receiving multiple Optical Node Property
TLVs in an LSA."

YOUNG>> From another email thread (per Adrian), we discussed this.

NEW

END

OLD:

NEW:

[Alia] My concern is about the phrase "only the first one" because two different routers may
received the TE LSAs in different order depending upon flooding dynamics.  I would much rather
that you define a tie-breaking mechanism - for instance  picking the largest LSA ID (Sec 2.2 of RFC 3630),
because that is considered newer.

YOUNG>> Thanks for the reference. Taking the largest LSA ID is a good idea in this situation. How about then:

NEW

            All sub-TLVs defined here may occur at most once in any given
            Optical Node TLV under one TE LSA. If more than one copy of the sub-TLV is received,
            in the same LSA, the redundant sub-TLV SHOULD be ignored. In case where the same sub-TLV
            Is advertised in different TE LSA (which would take place only by a packaging error), then the sub-TLV
            with the largest LSA ID (Sec 2.2 of RFC 3630) SHOULD be picked.
            These restriction need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.

END

[Alia] Wouldn't the information contained be redundant?  I'm not sure why you think that the duplication
can't be detected based on fields in the sub-TLV.  Again, just a simple tie-breaker would provide interoperability.

YOUNG>> Please see the previous comment.

END.

OLD

NEW

END

[Alia] How about "A SCSI may contain multiple Available Label sub-TLVs and multiple Shared Backup Label sub-TLVs.  The following figure shows the format for a SCSI that contains these sub-TLVs.  The order of the sub-TLVs in the SCSI is arbitrary."

YOUNG>> Accepted.

OLD

NEW

END

[Alia] Sounds good.

OLD

NEW

[Alia] Usually, one doesn't reflood LSAs with malformed TLVs or sub-TLVs.  I'm certainly willing
to listen to reasoning on why flooding potentially corrupt data would be a good idea, but you'll need
really clear reasoning.

YOUNG>>  We discussed in other thread.  To-recap here, how about

NEW

END

[Alia]  Are you picturing that a sub-TLV is malformed if its length isn't accurate or just if one of the fields inside the sub-TLV is using a bad value or setting a reserved value?  In the latter cases, perhaps it might be tolerable to assume that there wasn't data-corruption that will affect the rest of the parsing - but I'm dubious.   For the first, if the length is wrong, then you can't accurately know where the next sub-TLV starts so all parsing after isn't trustable, IMHO.

YOUNG>> Both cases. Please see the previous comment. I think in either case, the safe way is to stop the LSA advertisement.

NEW

END

[Alia] Uh - of course error conditions aren't expected to be common!  How about considering how often the
advertising router might send the LSA?  How about considering the number of neighbors that will be flooding it?
How about dampening the number of logs?  Making it a MAY log also makes it clear that it's up to the implementation.

YOUNG>> Per Adrian’s suggestion, how about:

NEW

Errors of this nature SHOULD be logged for the local operator. Implementations MUST provide a rate limit on such logs, and that rate limit SHOULD be configurable.

END

YOUNG>> I can add:

NEW

END

[Alia] Thanks - could you take this one step further and specify about the expected size of the TLV based on these assumptions?

YOUNG>> OK. I will calculate this and add in the text in the revision.

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Aug 2015 14:56:37 -0400

Hi Young,

These all sound fine.

Alia

On Wed, Aug 26, 2015 at 11:50 AM, Leeyoung <[email-masked]> wrote:

> Cc: [email-masked];
> [email-masked]; [email-masked]; 'The IESG'
> Subject: RE: [CCAMP] Alia Atlas' Discuss on
> It could mean "no more than one" or it could mean "it is only necessary to
> advertise one must, but others may be included"
> The thrust of the conversation appears to be for the latter, so don't try
> to do this in clever compact code - write it out in full!
>
> When using the extensions defined in this document, at least one Optical
> Node Property TLV MUST be advertised in each LSA. To allow for fine
> granularity changes in topology, more than one Optical Node Property TLV
> MAY be advertised in a single LSA. Implementations MUST support receiving
> multiple Optical Node Property TLVs in an LSA.
>
> YOUNG>> Sorry that I missed this. Yes, this is a good question to ask.
> Please see the next resolution that basically says that the malformed LSA
> "MUST" be dropped while logging of this problem SHOULD be done.
>
> which are
> Hmmm. The most common cause of unparsable TLVs will be encoding errors,
> bugs, misinterpretation of specs, up-level implementations, etc. Corruption
> doesn't happen much.
> YOUNG>> Adrian, what is standard OSPF behavior in this case? I would
> assume we drop the entire LSA in which to contain malformed TLVs or
> sub-TLVs. If that is the case, how about:
>
> NEW
> assume
> I think you have to handle both cases. Furthermore, if the TLV is of
> variable length, anything unexpected needs to be treated with caution.
>
> YOUNG>> Rethinking this issue, I would go with the previous resolution ---
> just stop sending the LSA in which to contain malformed TLVs and sub-TLVs.
>
> "Errors of this nature SHOULD be logged for the local operator.
> Implementations MUST provide a rate limit on such logs, and that rate limit
> SHOULD be configurable."
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Aug 2015 15:01:10 -0400

Hi Young,

These resolutions all sound fine.  Can you get a new version out today or
tomorrow?
I'm out on vacation from August 28 - Sept 7.  I'd prefer to clear my
discuss before heading out.

Thanks,
Alia

On Wed, Aug 26, 2015 at 12:25 PM, Leeyoung <[email-masked]> wrote:

> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Friday, August 21, 2015 4:07 PM
> *To:* Leeyoung
> *Cc:* The IESG; [email-masked];
> *Subject:* Re: Alia Atlas' Discuss on
> YOUNG>> Both cases. Please see the previous comment. I think in either
> case, the safe way is to stop the LSA advertisement.
>
>
>
>
>
>
>
>
>
> Errors of this nature SHOULD be logged for the local operator.
> SHOULD be configurable.

---

From: Leeyoung <[email-masked]>
Date: Wed, 26 Aug 2015 19:29:24 +0000

Hi Alia,

Thanks for clearing out all pending issues. I will try to get the revision by no later than tomorrow.

Best regards,
Young

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, August 26, 2015 2:01 PM
To: Leeyoung
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

Hi Young,

These resolutions all sound fine.  Can you get a new version out today or tomorrow?
I'm out on vacation from August 28 - Sept 7.  I'd prefer to clear my discuss before heading out.

Thanks,
Alia

On Wed, Aug 26, 2015 at 12:25 PM, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Best regards,
Young

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 21, 2015 4:07 PM
To: Leeyoung
Cc: The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

Hi Young,

Thanks,
Alia

Thanks.
Young

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 05, 2015 9:47 AM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Alia Atlas' Discuss on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with DISCUSS and COMMENT)

NEW

END

OLD:

NEW:

NEW

END

END.

OLD

NEW

END

YOUNG>> Accepted.

OLD

NEW

END

[Alia] Sounds good.

OLD

NEW

NEW

END

NEW

END

NEW

END

YOUNG>> I can add:

NEW

END

Thanks,
Alia