Hi Bruno,
On 9/3/14 15:50 , [email protected] wrote:
Hi Peter,
From: Peter Psenak [mailto:[email protected]] > Sent: Wednesday, September 03,
2014 2:19 PM
Hi Bruno,
On 9/3/14 14:09 , [email protected] wrote:
Hi Peter,
From: Peter Psenak [mailto:[email protected]] > Sent: Wednesday,
September 03, 2014 12:32 PM
Hi Bruno,
On 9/3/14 12:25 , [email protected] wrote:
Hi Peter, Rob,
+1 on Rob's comment regarding the use of admin tag for expressing
+operator policy (rather than spec/feature capability)
1 point in lined below
From: Peter Psenak > Sent: Wednesday, September 03, 2014 10:21 AM
Hi Rob,
On 9/3/14 10:16 , Rob Shakir wrote:
Hi Peter,
On 3 Sep 2014, at 09:13, Peter Psenak <[email protected]> wrote:
As per the above, I do not think that this mechanism replaces
any
capability, it just gives an operator a means to be more granular
than the binary "supported"/"not supported" view that a flag
indicating capabilities does.
I understand. My point was that admin tags should not be used in
cases
where only a binary capability is signaled.
ACK, I completely agree. Perhaps we should add something into the
draft that the admin-tag should not be used for such a purpose.
I would certainly appreciate that.
I agree as a general rule. Yet IMHO we should not kill this
possibility. In
particular for feature allowing incremental deployment & interaction
with non-compliant nodes.
One example would have been Remote LFA (RLFA):
- the PLR (FRR node) needs to be RLFA compliant. Therefore
(potential)
communication between PLR regarding their capabilities can be done
using IANA/implemented code point.
- the PQ node (Merge Point) does not need to be RLFA compliant. And
we
should keep this property to ease incremental deployment. Therefore
communication between PQ and PLR regarding PQ capabilities
should/may
be done using node tag. RLFA spec could have defined an IANA
registered node tag to be used by PQ (configured by the network
operator) to exclude them as PQ candidate. e.g. for PQ node not
accepting T-LDP session or nodes which should not be used as PQ per
policy.
why is "IANA registered node tag" any better then IANA registered
capability bit in the above case?
We need the value to be able to be set/cleared by configuration (by the
network operator) in order to allow for PQ node not compliant with RLFA to
advertise it.
Node-admin tag clear matches this requirement.
I assumed that the capability bits were controlled by the software and not
by the network operator and hence could not be used. However, I realize
that this is an assumption that may be incorrect as I'm not familiar with OSPF
implementations (as we are mostly using ISIS). If all OSPF implementations
allow the network operator to control any bits (or at least the non
allocated/supported ones) I think I agree that such bit could equally be used.
However, after quickly reading the RFC, I'm not seeing that those bits
MUST/SHOULD be configurable by configuration. Hence we can't really
guaranty that any (future) implementation would allow this.
RFC4970 does not pose any restrictions on setting of a capability bits in OSPF
Router Informational Capabilities TLV. Some bits may be set based on the
software capabilities of the originator but others may be set based on the
configuration and willingness of the originator to perform certain
functionality. The flexibility is there.
Agreed that the flexibility is there in the spec. But the feature may not be
implemented hence used. So if we add a text in node-admin-tag to forbid _any_
capability advertisement, I think we should also add a text to mandate the
ability for the SP to configure RFC 4970 capability bits advertisement.
spec can not forbid user/implementer to set a node tag and interpret it
in any possible way on the receiving router. What the draft should spell
though is that for advertising binary capabilities
RI Capabilities TLV SHOULD be a preferred solution and why.
Regarding the RFC 4970, I don't believe there is any new requirement,
current spec allows you to do what you are asking for.
thanks,
Peter
Thanks,
Bruno
thanks,
Peter
Thanks,
Bruno
thanks,
Peter
Thanks,
Bruno
thanks,
Peter
Cheers,
r.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
__________________________________________________________
____________
___________________________________________________
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.
.
__________________________________________________________
____________
___________________________________________________
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.
.
_________________________________________________________________________________________________________________________
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
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
