Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)

[<[e-mail]>]

Hi Alvaro,

Thanks for your review and feedback.
Please see inline [Bruno]

> From: Alvaro Retana [mailto:[e-mail]]
 > Sent: Wednesday, August 30, 2017 8:41 PM
> 
 > Alvaro Retana has entered the following ballot position for
 > draft-ietf-ospf-encapsulation-cap-06: No Objection
 > 
 > 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-ospf-encapsulation-cap/
 > 
 > 
 > 
 > ----------------------------------------------------------------------
 > COMMENT:
 > ----------------------------------------------------------------------
 > 
 > I think there's a normative conflict in these two pieces of text; the first one
 > from Section 3, and the second from Section 5:
 > 
 >    ...If the Encapsulation Capability
 >    TLV appears more than once in an OSPF Router Information LSA, only
 >    the first occurrence MUST be processed and others MUST be ignored.
 
[Bruno] Actually, I'm not sure why there is such restriction. Others OSPF RI allows multiple occurences. e.g. https://tools.ietf.org/html/rfc7777
Proposed NEW:
      The Tunnels Encapsulations TLV MAY appear more than once
      within a given OSPF Router Information (RI) Opaque LSA. If the Tunnels
      Encapsulations TLV appears more than once in an OSPF Router
      Information LSA, the set of all Tunnel Sub-TLVs from all Tunnels Encapsulations TLV SHOULD be considered.
 
Note: MUST is not required for interoperability as we advertise information that MAY or MAY NOT be used

 > ...
 > 
 >    Any unknown Sub-TLVs MUST be ignored and skipped upon receipt.
 > 
 >    If a Sub-TLV is invalid, its Tunnel Encapsulation TLV MUST be ignored
 >    and skipped.  However, other Tunnel Encapsulation TLVs MUST be
 >    considered.
 > 
 > The text from Section 3 says that only the first TLV [*] is to be processed --
 > but during such processing the receiver may find an invalid sub-TLV, which then
 > mandates (in Section 5) for other TLVs to be considered.
 
[Bruno] I think that the behavior is fine, however, as previously noted, the terminology is unclear.
I'm changing the terminology in -08. Could you have a look at -08 and see if this point is still unclear? Thanks.
 
 > I think that the easy solution is to change the second "MUST" from Section 3
 > for a "SHOULD".
 > 
 > It would be nice to describe what is an "invalid" sub-TLV, and that "invalid"
 > is not the same as "unknown" (right?)...but that an "unknown [tunnel] types are
 > to be ignored and skipped upon receipt", which would result in processing the
 > second (if any) TLV.

[Bruno] Proposed NEW:
Any unknown Tunnel Parameter Sub-Type MUST be ignored. When a reserved
      value (See <xref target="ParametersRegistry"/>) is seen in an LSA, it
      MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel Parameter Value has an incorrect syntax of semantic, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is invalid, its
      Tunnel Sub-TLV MUST be ignored and skipped. However,
      other Tunnel Sub-TLVs MUST be considered.

 
 > [*] Benoit's ballot pointed at the need for consistency in the names.

[Bruno] Agreed. Replying on Benoit's thread.
 
Thanks,
--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.