Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

From: <[email-masked]>
Date: Mon, 1 Sep 2014 16:07:32 +0000

Support.

This is useful for network operator to express policy based on node capabilities/performance/roles (e.g. PE/P/ASBR/BNG, access/aggregation/POP/Core, odd/even.).
In particular I support uses cases 2, 3 and TE/explicit routing policy (a la CSPF excluding "even" or "ASBR" nodes, in particular in the SPRING context).

2 comments:
- I can provide text & ascii art for the above additional explicit routing use cases use case if authors agree
- :s/ I-D.litkowski-rtgwg-lfa-manageability/ I-D.ietf-rtgwg-lfa-manageability

Thanks,
Regards,
Bruno

----
From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, August 25, 2014 11:18 PM
To: [email-masked]
Subject: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

There are situations where node level policy is required and an OSPF advertised admin tag simplifies this. For example, advertisement of remote-LFA eligibility.

Please indicate your support or objections to adopting this draft as an OSPF WG document. 

Thanks,
Acee 

_________________________________________________________________________________________________________________________

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.

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 3 Sep 2014 06:28:19 +0000

Dhruv,

Thanks for detailed review and comments.
Pls see in-line for the response.

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Saturday, August 30, 2014 6:22 PM
To: Acee Lindem (acee)
Cc: [email-masked]
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi,

I have read the document and I support it for WG adoption.

I have following comments, that can be handled later

(1) Section 4.1
OLD:

   The format of the TLVs within the body of an RI LSA is the same as
   the format used by the Traffic Engineering Extensions to OSPF
   [RFC3630].

   The LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets.  The format of each TLV is:

NEW:

   As per [RFC4970], the format of the TLVs within the body of an RI LSA is the same as
   the format used by the Traffic Engineering Extensions to OSPF
   [RFC3630].

   The RI LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets.  The format of the per-node administrative tag TLV is:

END

<Shraddha> Accept. Will be updated in the next revision.

Also, it should be stated
- if are more than one instance of this TLV in RI LSA are allowed.

<Shraddha>More than one instance of the TLV can be added in same RI-LSA or in a multiple instance as defined
                       In  draft-acee-ospf-rfc4970bis-00.txt

- Minimum one tag must be present in the TLV
<Shraddha> Accept.

- What happens if the implementation does not know the Interpretation of the tag value
<Shraddha> This is mentioned in section 4.2, However will add explicit mention regarding the scenario you mentioned.

(2) It should be explicitly stated that - No IANA registry is required to store the meaning or interpretation of.the tag values.

<Shraddha> It's mentioned in the section 4.2 that no well known  tag values will be defined by this document.

(3) Backward compatibility - few lines may be added to state that as per [RFC4970], unknown TLV would be silently ignored.
<Shraddha> Accept

Nits
- Avoid using reference in abstract
- Expand LFA on first use
- Administrative Tag TLV or 'per-node Administrative Tag' : consistent naming through the document would be nice

<Shraddha> Accept.

Regards,
Dhruv

On Tue, Aug 26, 2014 at 2:48 AM, Acee Lindem (acee) <[email-masked]> wrote:
> There are situations where node level policy is required and an OSPF 
> advertised admin tag simplifies this. For example, advertisement of 
> remote-LFA eligibility.
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Rob Shakir <[email-masked]>
Date: Wed, 3 Sep 2014 09:08:31 +0100

Hi Peter.

On 26 Aug 2014, at 16:43, Peter Psenak <[email-masked]> wrote:

> 
> On 8/26/14 17:32 , Hannes Gredler wrote:
>> 
>> operators want to assign node-tags as per router function (ABR, PE, core) and then
>> the LFA-selection becomes much easier to specify. - e.g.
>> - only pick a LFA that does not cross another PE router.
>> 
>> similarily it is desirable for "LFA tunnel termination"
>> to put out a constraint which says
>> - only pick a PQ neighbor which has node tag 'X'
> 
> my point is that with the above approach you have to:
> 1. On candidate PQ nodes configure the tag X
> 2. on all other nodes configure "only pick a PQ neighbor which has node tag 'X'"
> 
> It's (2) which makes me feel uncomfortable, as it's a config to be applied to many nodes.

I’m unclear on how one would solve this — the key thing is that there are number of scenarios where it is *operator* preference rather than node capabilities that mean that we want to select a particular node for some certain application. This preference may be on a per-calculating node basis. If this is the case, then a single capability that says that a particular target node is capable of acting in a particular role is not sufficient.

(Consider this scenario:
	- rtr-A is in country 1.
	- rtr-B is in country 2.
	- Both rtr-A and rtf-B are capable of acting as PQ nodes,and need to act as such for ‘local’ nodes (i.e., those in the same country as them).
	- rtr-A should never select rtr-B as a PQ.
In this case, we need some tag that specifies country, as well as some tag that specifies that it is a valid PQ node. We then need specific policy on rtr-A and rtr-B to implement this policy.)

It is very typical that where we have such policy implementations, then we need to configure the behaviour on a per-node basis. This is especially true where policies must consider characteristics of the topology.

>> 
>> i found it always strange that we for TE (as an example for
>> constraining paths) we have got ways to tag links, but
>> not way to tag nodes - that draft aims to fix that.
> 
> I'm not against tagging nodes as such. What worries me if we end up using node tags for signalling capabilities of node.

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, of course, support the adoption of this draft as a co-author.

Cheers,
r.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 03 Sep 2014 10:13:17 +0200

Hi Rob,

> 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 indi…

I understand. My point was that admin tags should not be used in cases 
where only a binary capability is signaled.

thanks,
Peter

> .

---

From: Rob Shakir <[email-masked]>
Date: Wed, 3 Sep 2014 09:16:05 +0100

Hi Peter,

On 3 Sep 2014, at 09:13, Peter Psenak <[email-masked]> wrote:

> 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.

Cheers,
r.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 03 Sep 2014 10:20:45 +0200

Hi Rob,

> 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.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 3 Sep 2014 10:25:07 +0000

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,
> 
> >>> 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 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.

Thanks,
Bruno

---

From: Peter Psenak <[email-masked]>
Date: Wed, 03 Sep 2014 12:32:24 +0200

Hi Bruno,

> - 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…

why is "IANA registered node tag" any better then IANA registered 
capability bit in the above case?

thanks,
Peter

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 3 Sep 2014 13:01:27 +0200

hi peter,

the question is not so much which registry is better;

we have existing proof-point (rlfa-spec not containing any capabilities)
that there may be the possibility that:

- a well-known, protocol specific tag does not exist
- the operator problem (excluding/including certain nodes
   from PQ capability) still does exist

so it looks like we have a practical case in favor of bruno's argument.

let me draw also some analogy to tagging of IP prefixes here:
draft-hegde-ospf-node-admin-tag is a generic vehicle just as
http://datatracker.ietf.org/doc/rfc5130/ has been conceived for
IP prefixes. - it is correct for the problem described in
RFC5130 we could have been applying application-specific
bits in IP prefixes that control the leaking behavior.

however a different model has been chosen:

1) use generic, application-context-free tags for a prefix
2) write the leaking policy which refers to those tags.

i find the flexibility of that model appealing and i'd
like to have something similar for "nodes" on link-state
graphs.

/hannes

On 9/3/14 12:32, Peter Psenak wrote:
>>
>> 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.
>> - 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.
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 03 Sep 2014 13:50:06 +0200

Hi Hannes,

> so it looks like we have a practical case in favor of bruno's argument.

well, a more practical solution for the above _capability_ case would be 
to define a bit in OSPF Router Informational Capabilities TLV. The 
reason is that the meaning of the bit is defined and as such no other 
configuration is required on any other nodes except the PQ ones.

> like to have something similar for "nodes" on link-state

as I expressed multiple times, I have no issue with the node admin tags 
draft as such. My concern is related to the usage of the admin tags for 
signaling capabilities for which there is a better existing solution 
available.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 3 Sep 2014 12:09:47 +0000

Hi Peter,

> From: Peter Psenak [mailto:[email-masked]] > Sent: Wednesday, September 03, 2014 12:32 PM
> 
> Hi Bruno,
> 
> > +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
> >
> >> 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.
> >>>>
> >>> 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 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.
> communication between PLR regarding their capabilities can be done using
> IANA/implemented code point.
> 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.

 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,
> > 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.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 03 Sep 2014 14:19:12 +0200

Hi Bruno,

> 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 a…

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.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 3 Sep 2014 13:50:28 +0000

Hi Peter,

> From: Peter Psenak [mailto:[email-masked]] > Sent: Wednesday, September 03, 2014 2:19 PM
> 
> Hi Bruno,
> 
> >>> possibility. In
> >> particular for feature allowing incremental deployment & interaction
> >> with non-compliant nodes.
> > 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.
> > 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.

Thanks,
Bruno

> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> .
> >>>
> >
> >
> >

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 3 Sep 2014 19:39:58 +0530

Hi Shraddha,

Thanks for your reply, snipping to the open point...

>                        In  draft-acee-ospf-rfc4970bis-00.txt
Okay, text may be added to reflect this.

> <Shraddha> It's mentioned in the section 4.2 that no well known  tag values will be defined by this document.
Since in the mailing list there is a discussion about possibility of
having well known tag value assigned by IANA. This document should
clarify (based on WG consensus) if admin tags can be assigned by IANA
in future documents or not. And if the answer is yes, a suitable range
should be set to avoid conflict.

Dhruv

---

From: Peter Psenak <[email-masked]>
Date: Wed, 03 Sep 2014 16:32:18 +0200

Hi Bruno,

> 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 shoul…

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

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 3 Sep 2014 16:45:43 +0200

hi dhruv,

On Wed, Sep 03, 2014 at 07:39:58PM +0530, Dhruv Dhody wrote:
| Hi Shraddha,
| 
| Thanks for your reply, snipping to the open point...
| 
| > Also, it should be stated
| > - if are more than one instance of this TLV in RI LSA are allowed.
| >
| > <Shraddha>More than one instance of the TLV can be added in same RI-LSA or in a multiple instance as defined
| >                        In  draft-acee-ospf-rfc4970bis-00.txt
| >
| Okay, text may be added to reflect this.
| 
| > (2) It should be explicitly stated that - No IANA registry is required to store the meaning or interpretation of.the tag values.
| >
| > <Shraddha> It's mentioned in the section 4.2 that no well known  tag values will be defined by this document.
| >
| Since in the mailing list there is a discussion about possibility of
| having well known tag value assigned by IANA. This document should
| clarify (based on WG consensus) if admin tags can be assigned by IANA
| in future documents or not. And if the answer is yes, a suitable range
| should be set to avoid conflict.

i have no concerns with that -
however peter seems in favor of using CAP Bits for well-known applications;

would be interesting to hear others' opinion on that.

/hannes

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 03 Sep 2014 21:23:35 +0200

Hi Hannes,

 > would be interesting to hear others' opinion on that.

    My opinion is that in future defining a new well-known admin tag 
value is by definition requires new IETF draft/RFC. But if new draft is 
being written then it is cleaner to define data container which suits 
the new feature best, be it new capability bit, new RI LSA TLV, new data 
in another LSA or combination of above.
    Problems with defining well-known tag values:
- It will be necessary to sacrifice a range of tag values for future 
well-known tags
- It will be necessary to define behavior of implementation receiving 
unknown tag

    Benefits of defining well-known tags vs. defining in future new TLVs 
for features as needed:
- Well, I can't think of any.

So my opinion is that there should be no well-known tags (neither in WG 
nor internally to an implementation) and tag values should have meaning 
in the context of policy of a particular network. Very much like there 
are no well-known values for tags attached to external LSAs.

Anton

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 4 Sep 2014 03:40:48 +0000

Hi Hannes, 

> |
> | > (2) It should be explicitly stated that - No IANA registry is required to
> store the meaning or interpretation of.the tag values.
> | >

FWIW I prefer CAP bits as well and yes! it would interesting to hear from others! 

Dhruv

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 4 Sep 2014 18:18:56 +0000

My preference would be to use Capability bits/new TLV for well known applications and
Using node-tags for config/policy driven generic applications. 

That said there is no-harm in reserving a range of tags in this document and mentioning it's for "future" use.

Rgds
shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Thursday, September 04, 2014 9:11 AM
To: Hannes Gredler; Dhruv Dhody
Cc: [email-masked]
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi Hannes, 

> |
> | > (2) It should be explicitly stated that - No IANA registry is 
> | > required to
> | > <Shraddha> It's mentioned in the section 4.2 that no well known  
> | > tag
> values will be defined by this document.
> | >
> | clarify (based on WG consensus) if admin tags can be assigned by 
> | IANA in future documents or not. And if the answer is yes, a 
> | suitable range should be set to avoid conflict.
> 

Dhruv

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 Sep 2014 21:23:12 +0000

Speaking as WG member:

 I agree with using capability bits for whether or not a OSPF router can
support something and administrative tags for policy. I don¹t think we
should have well-known tags and am not really even in favor of reserving a
range just in case we need them.
Thanks,
Acee

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 5 Sep 2014 09:18:07 +0530

I agree with Acee, it is cleaner to keep admin tags only for private use,
never to be allocated by IANA.

Dhruv

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 5 Sep 2014 06:37:16 +0000

+1

Best regards,
Xiaohu

From: OSPF [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Friday, September 05, 2014 11:48 AM
To: Acee Lindem (acee)
Cc: [email-masked]
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

I agree with Acee, it is cleaner to keep admin tags only for private use, never to be allocated by IANA.

Dhruv
On Sep 5, 2014 5:23 AM, "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as WG member:

On 9/4/14, 2:18 PM, "Shraddha Hegde" <[email-masked]<mailto:[email-masked]>> wrote:

>From: OSPF [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dhruv Dhody
>Cc: [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 5 Sep 2014 16:44:28 +0000

Hi,

I support Acee’s comments.

Cheers,
Jeff

-----Original Message-----
From: "Acee Lindem   (acee)" <[email-masked]>
Date: Thursday, September 4, 2014 at 2:23 PM
To: Shraddha Hegde <[email-masked]>, Dhruv Dhody
<[email-masked]>, "[email-masked]" <[email-masked]>, Dhruv
Dhody <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag