[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)
From:       <bruno.decraene () orange ! com>
Date:       2017-09-18 15:26:54
Message-ID: 30747_1505748415_59BFE5BF_30747_374_1_53C29892C857584299CBF5D05346208A47879458 () OPEXCLILM21 ! corporate ! adroot ! infra ! ftgroup
[Download RAW message or body]

Hi Alvaro,

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

> From: Alvaro Retana [mailto:aretana@cisco.com]
 > 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.

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


[prev in list] [next in list] [prev in thread] [next in thread]