Hi Bruno,
On 9/3/14 12:25 , bruno.decra...@orange.com 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 <ppse...@cisco.com> 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?
thanks,
Peter
Thanks,
Bruno
thanks,
Peter
Cheers,
r.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
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.
.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
