Re: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv

[Les Ginsberg (ginsberg)]

Bruno -

Thanx for your comments.

V2 of the draft has been posted which addresses a number of the issues.
More inline.

From: bruno.decra...@orange.com 
Sent: Friday, March 22, 2019 4:02 AM
To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana 
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

§4
   The presence of a TLV (or sub-TLV) with content which does not
   conform to the relevant specification MUST NOT cause the LSP itself
   to be rejected.

Again, thank you for your effort to clarify the specification.

Given the "MUST", I feel that this sentence may be read as contradicting with 
some other text. E.g

"   An implementation that implements HMAC-MD5 authentication and
   receives HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect."
https://tools.ietf.org/html/rfc5304#section-2

Do you think it could be slightly rephrased? May be something along 
:s/rejected/considered invalid [or incorrect, although 10589 seems to use 
the term "invalid PDU"]
(as "rejected" could be read as similar to "discarded")

[Les:] The behavior described in RFC 5304 is normative (i.e., MUST is both 
intentional and correct) and implementations which conform to RFC 5304 will 
indeed discard such a PDU.
If your concern is about the word "discard" - this follows the terminology used 
in ISO 10589 - for example Section 7.3.14.2e:

"An Intermediate system receiving a Link State PDU with an incorrect LSP 
Checksum or with an invalid PDU syntax shall

1)   generate a corruptedLSPReceived circuit event,

2) discard the PDU.

Therefore I prefer to continue to use "discard".


Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, March 22, 2019 11:41 AM
To: lsr@ietf.org; 
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Cc: Alvaro Retana
Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv

Hi all,

To be clear, I support that document. Thanks for writing it.
I have some comments, mostly asking for even more of this/such document. 
(although I expect that some comments will trigger a discussion ;-) )


§3.1
"Any codes in a received PDU that are not recognised shall be
   ignored."

   Therefore the presence of TLVs in a PDU which are not allowed MUST
   NOT cause the PDU itself to be rejected by the receiving IS.


I don't think that "not recognized" is the same as "not allowed".

IMHO, the fact that unknown TLV are to be ignored seem rather obvious as this 
is a designed goal of the TLV format. Yet, it's good that 
[ISO10589]
 explicitly stated it.
I definitely support that LSR defines the behavior for TLV (and sub-TLV) which 
are not allowed. But I find the justification and reference debatable. I'd 
rather prefer that we remove it, or at least remove the "Therefore". I'd favor 
something along
OLD: Therefore
NEW: In addition, this document specifies that

§3.3

Registries associated with sub-TLVs are

   associated with the TLV Codepoints Registry and specify in which TLVs

   a given sub-TLV is allowed.  As with TLVs, it is required that sub-

   TLVs which are NOT allowed MUST be ignored on receipt.

In addition to "not recognized" and "not allowed by the registry" I believe 
that there are others cases that would benefit from been clarified. Such as:
- not allowed by the specification (in a given case/condition)
- REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on 
point-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3
- Malformed (bad syntax)
- Correctly formed but illegal value (in a given case/condition)

I would like LSR to specify all types of error handling. Either in this 
document, or in another document if general error handling is considered out of 
scope of this document.

[Les:] Error handling associated with incorrect encoding of a TLV is specific 
to the individual TLV. It is the responsibility of the document which defines 
the TLV encoding to specify what to do if a particular field does not conform 
to the set of allowed values, or if the TLV omits required information, or a 
Reserved bit is set,  etc. I don't think using a central document to define 
error handling for each individual TLV is a good option.
---

§1

"   PDUs which are valid MUST be accepted even if an individual TLV

   contained within that PDU is invalid in some way."



I wish "valid" be further defined. E.g. do you mean from a syntax/parsing point 
of view? Or do you mean something else?

In particular 
[ISO10589]
 use the terms "invalid PDU syntax". If you mean the same, I'd favor using the 
same terms. If you mean something different, please clarify the differences.

---

"   

Re: [Lsr] //Re: [Teas] "Packet Network Slicing using Segment Routing"

[chen.ran]

Hi chairs，

Thank you very much for your suggestions.

I will change the name of the draft, and continue the draft on the teas wG.

Regards,


Ran

Re: [Lsr] 
[Teas] "Packet Network Slicing using Segment Routing"
Lou Berger  Mon, 25 March 2019 23:32 UTCShow header


Authors, just resubmit with teas in place of lsr, when you do your 
update based on other feedback you received this week.

Thanks,

Lou

(TEAS co-chair)

On 3/25/2019 2:52 PM, Acee Lindem (acee) wrote:
>
> Hi Authors,
>
> I read this draft on the plane on the way to Prague and I don’t think 
> it belongs in LSR. I believe it belongs in TEAs as it is more about 
> the requirement and framework for TE slicing than it does about adding 
> the Administrative Instance Identifier (AII) to the OSPF and IS-IS TE 
> encodings. We will go forward with the presentation on Thursday with 
> the understanding that LSR will not adopt this work. If it is adopted 
> in TEAS, we can decide whether to proceed with a small LSR draft with 
> just the new AIIs or simply provide review and IANA code points in our 
> registries.
>
> Thanks,
> Acee
>
>___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr