Re: [Roll] NSA PS-set metric/constraint

Hello all,

The discussion below prompts me to question the way the Parent Set (PS)
appears in the Dodag Metric Container (DMC). Sorry if this comes up late
in the process.

The NSA object carrying the PS TLV is currently specified to be Contraint.
This shows up only once in the text (page 11).
There are some issues associated with the PS being part of a constraint:
RFC6551 says
"In the presence of a constraint, a node MUST include a metric of the
same type.  That metric is used to check whether or not the   constraint
is met.  In all cases, a node MUST not change the content   of the
constraint."
The behaviour proposed in this draft would have to create an exception for
all of the above.

Alternate proposal:
Could the PS be part of an NSA Metric? After all, it is used to help
select which parent(s) are best suited for upward routing, not to prune
downlink propagation of the DIO along a path that exceed some metric
value. C=0, R=1, P=1 comes to mind for this metric.
I understand that you are trying to create a CA OF that mimicks as much of
the MRHOF as possible, and MRHOF says it doesn't use DMCs. So you would
have to specify that the CA OF is different in that it has to look at the
NSA Metric sub-object inside the DMC object. But in the current situation,
you already have to specify that the CA OF has to look at the NSA
Constraint sub-object inside the DMC object. With a metric, you could use
the Prec. field to highlight the fact that the PS TLV s a secondary
metric, beyond the implied ETX of MRHOF. Or you could send the ETX Metric
sub-object explicitely, at the expense of a few extra bytes, and state
that the CA OF simply uses DMCs.

Thoughts?

Dominique

Le 11/02/20 11:25, « Roll on behalf of Georgios Z. Papadopoulos »
<roll-bounces@ietf.org on behalf of
georgios.papadopoulos@imt-atlantique.fr> a écrit :

>Dear Rahul and all,
>
>Once again, thank you for spotting this issue. Great catch!
>We are happy with any of the following solutions :
>
>- We can indeed tie the PS set metric to CAOF specifically in the draft.
>Furthermore, the policies in CAOF are extensible (we only specify
>examples), so potentially another policy could make a different use of PS
>as part of CAOF.
>
>- We can indeed explain the issue in the draft so that the implementers
>decide on their own how to handle it.
>Additionally, since the whole RPL instance uses the same OF, we would
>expect that if an OF which understands the TLV is used, then all the
>nodes will know how to process it.
>So, this issue should not be very common.
>
>- Another option would be to add an exception to the "all TLVs need to be
>propagated” rule from RFC 6551 specifically for the PS TLV.
>The exception would specify that the PS TLV would be dropped if not
>understood.
>
>
>Best regards,
>Georgios and Aris
>
>
>> On Feb 11, 2020, at 04:32, Rahul Jadhav <rahul.ietf@gmail.com> wrote:
>> 
>> Hello Authors of NSA extn and all,
>> 
>> One more question in the context:
>> 
>> The draft adds new routing metrics/constraints (PS set) nested as part
>> of the NSA parent metric.
>> 
>> My question is with regards to what happens if this routing metric is
>> used outside of the CAOF. Any metrics/constraints could be used by any
>> OF and thus PS set metric defined by the draft can be used by other
>> OF.
>> 
>> RFC 6551 says that if the metric is not understood by the node and if
>> it is a 6LR then it may not process it but it has to propagate it.
>> Unlike other metrics, the PS set metric in this case contains
>> link-local values that cannot be used beyond link-local. As such upon
>> propagation, any downstream 6LR that understands the PS set metric
>> would use the information and get impacted adversely.
>> 
>> Should we tie the PS set metric to CAOF specifically in the draft, in
>> which case this problem won't be there? Or we can specify this issue
>> as it is for the readers to understand the problem if the PS set is
>> used outside of the CAOF. Either way works for me.
>> 
>> Best,
>> Rahul
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll

_________________________________________________________________________________________________________________________

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.