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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 25 Aug 2014 21:18:09 +0000

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

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 26 Aug 2014 00:29:08 +0200

support (as an author :-)) - 

note that in the latest version we have added also added a use-case
example for building auto-LSP-meshes  ...

/hannes

On Mon, Aug 25, 2014 at 09:18:09PM +0000, Acee Lindem (acee) 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.
|    Please indicate your support or objections to adopting this draft as an
|    OSPF WG document.
|    Thanks,
|    Acee

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

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 26 Aug 2014 07:08:34 +0000

Support this.
..definitely useful beyond the RLFA eligibility use cases.

--
Uma C.

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

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Tue, 26 Aug 2014 10:05:44 +0200

On 8/25/14 23:18 , Acee Lindem (acee) 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.

my concern with the generic use of admin tags for signaling capability 
is that it's operationally unfriendly compared to explicit signaling of 
the capability (e.g. using a bit or a TLV). The reason is that you have 
to configure the tag meaning on all receiving routers.

thanks,
Peter

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 Aug 2014 13:45:31 +0000

Hi Peter, 
This is a valid concern and one that we¹ve discussed previously with
respect to routing behavior based on policies. I think that accepting this
draft as a WG document should not preclude standardization of capabilities
advertisement for popular applications.
Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Tue, 26 Aug 2014 16:30:26 +0200

Hi Acee,

> advertisement for popular applications.

sure. Just that the draft mentions applications like "Controlling Remote 
LFA tunnel termination", which I'm not sure the node tag is the best 
approach for.

thanks,
Peter

> .

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 26 Aug 2014 17:32:01 +0200

hi peter,

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'

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.

HTH,

/hannes

On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote:
| Hi Acee,
| 
| On 8/26/14 15:45 , Acee Lindem (acee) wrote:
| >Hi Peter,
| >This is a valid concern and one that we¹ve discussed previously with
| >respect to routing behavior based on policies. I think that accepting this
| >draft as a WG document should not preclude standardization of capabilities
| >advertisement for popular applications.
| 
| sure. Just that the draft mentions applications like "Controlling Remote LFA
| tunnel termination", which I'm not sure the node tag is the best approach
| for.
| 
| thanks,
| Peter
| 
| >Thanks,
| >Acee
| >
| >On 8/26/14, 4:05 AM, "Peter Psenak (ppsenak)" <[email-masked]> wrote:
| >
| >>On 8/25/14 23:18 , Acee Lindem (acee) 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.
| >>
| >>my concern with the generic use of admin tags for signaling capability
| >>is that it's operationally unfriendly compared to explicit signaling of
| >>the capability (e.g. using a bit or a TLV). The reason is that you have
| >>to configure the tag meaning on all receiving routers.
| >>
| >>thanks,
| >>Peter
| >>
| >>>
| >>>Please indicate your support or objections to adopting this draft as an
| >>>OSPF WG document.
| >>>
| >>>Thanks,
| >>>Acee
| >>>
| >>>
| >>>_______________________________________________
| >>>OSPF mailing list
| >>>[email-masked]
| >>>https://www.ietf.org/mailman/listinfo/ospf
| >>>
| >>
| >>_______________________________________________
| >>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: Peter Psenak <[email-masked]>
Date: Tue, 26 Aug 2014 17:43:48 +0200

Hi Hannes,

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

If we instead define a capability bit which would mean "PQ candidate", 
we would avoid (2).

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

thanks,
Peter

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 26 Aug 2014 17:59:17 +0200

hi peter,

understood - so what about simply reserving a certain range of the tag space
for well-known applications (+IANA registry etc.) such that
for 2) we can avoid distributing policies ?

/hannes

On Tue, Aug 26, 2014 at 05:43:48PM +0200, Peter Psenak wrote:
| Hi Hannes,
| 
| On 8/26/14 17:32 , Hannes Gredler wrote:
| >hi peter,
| >
| >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.
| 
| If we instead define a capability bit which would mean "PQ candidate", we
| would avoid (2).
| 
| >
| >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.
| 
| thanks,
| Peter
| 
| >
| >HTH,
| >
| >/hannes
| >
| >On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote:
| >| Hi Acee,
| >|
| >| On 8/26/14 15:45 , Acee Lindem (acee) wrote:
| >| >Hi Peter,
| >| >This is a valid concern and one that we¹ve discussed previously with
| >| >respect to routing behavior based on policies. I think that accepting this
| >| >draft as a WG document should not preclude standardization of capabilities
| >| >advertisement for popular applications.
| >|
| >| sure. Just that the draft mentions applications like "Controlling Remote LFA
| >| tunnel termination", which I'm not sure the node tag is the best approach
| >| for.
| >|
| >| thanks,
| >| Peter
| >|
| >| >Thanks,
| >| >Acee
| >| >
| >| >On 8/26/14, 4:05 AM, "Peter Psenak (ppsenak)" <[email-masked]> wrote:
| >| >
| >| >>On 8/25/14 23:18 , Acee Lindem (acee) 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.
| >| >>
| >| >>my concern with the generic use of admin tags for signaling capability
| >| >>is that it's operationally unfriendly compared to explicit signaling of
| >| >>the capability (e.g. using a bit or a TLV). The reason is that you have
| >| >>to configure the tag meaning on all receiving routers.
| >| >>
| >| >>thanks,
| >| >>Peter
| >| >>
| >| >>>
| >| >>>Please indicate your support or objections to adopting this draft as an
| >| >>>OSPF WG document.
| >| >>>
| >| >>>Thanks,
| >| >>>Acee
| >| >>>
| >| >>>
| >| >>>_______________________________________________
| >| >>>OSPF mailing list
| >| >>>[email-masked]
| >| >>>https://www.ietf.org/mailman/listinfo/ospf
| >| >>>
| >| >>
| >| >>_______________________________________________
| >| >>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: Peter Psenak <[email-masked]>
Date: Tue, 26 Aug 2014 18:40:22 +0200

Hi Hannes,

> for 2) we can avoid distributing policies ?

we have an existing mechanism for advertising capabilities - RFC4970, 
section 2.3 and 2.4. We can reserve a bit for each well-known application.

thanks,
Peter

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 26 Aug 2014 19:03:24 +0200

Hi Peter,
    the draft lists about 5 different *example* applications which COULD 
be addressed by node admin tags. So if you take 1 particular possible 
scenario out of the draft - you still have 4 possible applications. 
Examples are there to demonstrate that admin tags is useful general 
tool, not to require the solution.
    Sure, each of possible scenarios can be solved by tailored solution. 
But each tailored solution is required to go via IETF adoption and 
implementation by vendors. And indeed, in cases where tailored solution 
brings so much operational benefit that it warrants slow path of IETF 
adoption, feature development by multiple vendors and network deployment 
- it will be used and will kill desire to solve the problem with admin tags.
   And vice verse - tags (when widely supported) will facilitate rapid 
development and deployment of services which we otherwise can't (or 
slow) to offer.

    As for your particular example - operator still has to go to each 
and every device and enable Remote LFA on it. But we are not trying to 
solve this operational complexity with OSPF autoconfiguration. So it 
shouldn't be that complex to enable acceptable node tag at the same time 
as enabling rLFA itself.

Anton

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 26 Aug 2014 19:56:04 +0200

hi peter,

if you can convince stewart to add it as part of the rlfa spec
it would be certainly a good thing to have :-)

in the meantime i'd like to use the tagging scheme as described
and use it as a last resort tool for expressing network policy
in case there is lack of protocol support for doing so.

/hannes

On Tue, Aug 26, 2014 at 06:40:22PM +0200, Peter Psenak wrote:
| Hi Hannes,
| 
| On 8/26/14 17:59 , Hannes Gredler wrote:
| >hi peter,
| >
| >understood - so what about simply reserving a certain range of the tag space
| >for well-known applications (+IANA registry etc.) such that
| >for 2) we can avoid distributing policies ?
| 
| we have an existing mechanism for advertising capabilities - RFC4970,
| section 2.3 and 2.4. We can reserve a bit for each well-known application.
| 
| thanks,
| Peter
| 
| >
| >/hannes
| >
| >On Tue, Aug 26, 2014 at 05:43:48PM +0200, Peter Psenak wrote:
| >| Hi Hannes,
| >|
| >| On 8/26/14 17:32 , Hannes Gredler wrote:
| >| >hi peter,
| >| >
| >| >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.
| >|
| >| If we instead define a capability bit which would mean "PQ candidate", we
| >| would avoid (2).
| >|
| >| >
| >| >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.
| >|
| >| thanks,
| >| Peter
| >|
| >| >
| >| >HTH,
| >| >
| >| >/hannes
| >| >
| >| >On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote:
| >| >| Hi Acee,
| >| >|
| >| >| On 8/26/14 15:45 , Acee Lindem (acee) wrote:
| >| >| >Hi Peter,
| >| >| >This is a valid concern and one that we¹ve discussed previously with
| >| >| >respect to routing behavior based on policies. I think that accepting this
| >| >| >draft as a WG document should not preclude standardization of capabilities
| >| >| >advertisement for popular applications.
| >| >|
| >| >| sure. Just that the draft mentions applications like "Controlling Remote LFA
| >| >| tunnel termination", which I'm not sure the node tag is the best approach
| >| >| for.
| >| >|
| >| >| thanks,
| >| >| Peter
| >| >|
| >| >| >Thanks,
| >| >| >Acee
| >| >| >
| >| >| >On 8/26/14, 4:05 AM, "Peter Psenak (ppsenak)" <[email-masked]> wrote:
| >| >| >
| >| >| >>On 8/25/14 23:18 , Acee Lindem (acee) 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.
| >| >| >>
| >| >| >>my concern with the generic use of admin tags for signaling capability
| >| >| >>is that it's operationally unfriendly compared to explicit signaling of
| >| >| >>the capability (e.g. using a bit or a TLV). The reason is that you have
| >| >| >>to configure the tag meaning on all receiving routers.
| >| >| >>
| >| >| >>thanks,
| >| >| >>Peter
| >| >| >>
| >| >| >>>
| >| >| >>>Please indicate your support or objections to adopting this draft as an
| >| >| >>>OSPF WG document.
| >| >| >>>
| >| >| >>>Thanks,
| >| >| >>>Acee
| >| >| >>>
| >| >| >>>
| >| >| >>>_______________________________________________
| >| >| >>>OSPF mailing list
| >| >| >>>[email-masked]
| >| >| >>>https://www.ietf.org/mailman/listinfo/ospf
| >| >| >>>
| >| >| >>
| >| >| >>_______________________________________________
| >| >| >>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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 26 Aug 2014 21:50:47 +0000

I support making this draft a WG item - but I do think a much more complete discussion regarding the tradeoffs between using node tags vs capability identifiers needs to be included - if for no other reason than if/when this draft were to become an RFC we would have two mechanisms and it  is not so clear when it is more appropriate to use one over another.

We don't have to come to a conclusion on that issue in this thread - nor should it preclude making this a WG item - but it is definitely an important issue to be discussed.

   Les

> -----Original Message-----
> From: OSPF [mailto:[email-masked]] On Behalf Of Peter Psenak
> (ppsenak)
> Sent: Tuesday, August 26, 2014 9:40 AM
> To: Hannes Gredler
> Cc: [email-masked]
> Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-
> tag
> 
> Hi Hannes,
>

---

From: Lizhenbin <[email-masked]>
Date: Wed, 27 Aug 2014 05:15:04 +0000

Support as the co-author.

Best Regards,

Zhenbin(Robin)

________________________________
发件人: OSPF [[email-masked]] 代表 Acee Lindem (acee) [[email-masked]]
发送时间: 2014年8月26日 5:18
收件人: [email-masked]
主题: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 27 Aug 2014 07:59:12 +0000

Support WG adoption as author.

From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 26, 2014 2:48 AM
To: [email-masked]
Subject: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 27 Aug 2014 08:04:46 +0000

Agree with Anton that defining capability bits for each and every use-case that the operator comes up with and getting it
Standardized and get it implemented by each vendor is going to be a slow process. And we need a generic way of carrying node tags in protocols.

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Anton Smirnov
Sent: Tuesday, August 26, 2014 10:33 PM
To: Peter Psenak; [email-masked]
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

    Hi Peter,
    the draft lists about 5 different *example* applications which COULD be addressed by node admin tags. So if you take 1 particular possible scenario out of the draft - you still have 4 possible applications. 
Examples are there to demonstrate that admin tags is useful general tool, not to require the solution.
    Sure, each of possible scenarios can be solved by tailored solution. 
But each tailored solution is required to go via IETF adoption and implementation by vendors. And indeed, in cases where tailored solution brings so much operational benefit that it warrants slow path of IETF adoption, feature development by multiple vendors and network deployment
- it will be used and will kill desire to solve the problem with admin tags.
   And vice verse - tags (when widely supported) will facilitate rapid development and deployment of services which we otherwise can't (or
slow) to offer.

    As for your particular example - operator still has to go to each and every device and enable Remote LFA on it. But we are not trying to solve this operational complexity with OSPF autoconfiguration. So it shouldn't be that complex to enable acceptable node tag at the same time as enabling rLFA itself.

Anton

On 08/26/2014 10:05 AM, Peter Psenak wrote:
> is that it's operationally unfriendly compared to explicit signaling 
> of the capability (e.g. using a bit or a TLV). The reason is that you 
> have to configure the tag meaning on all receiving routers.
>
> thanks,
> Peter
>
>>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 27 Aug 2014 11:15:36 +0000

Les, While I know you are big fan of generic tags (for e.g. RFC 5130 link level!)  to solve everything the discussion I see here is very useful.

> We don't have to come to a conclusion on that issue in this thread - nor should it preclude making this a WG item - but it is definitely an important issue to be discussed.

+1

--
Uma C.

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, August 26, 2014 2:51 PM
To: Peter Psenak (ppsenak); Hannes Gredler
Cc: [email-masked]
Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

   Les

> Subject: Re: [OSPF] Poll for WG adoption of 
> draft-hegde-ospf-node-admin- tag
> 
> Hi Hannes,
> 
> > understood - so what about simply reserving a certain range of the 
> > tag
> space
> > for well-known applications (+IANA registry etc.) such that for 2) 
> > we can avoid distributing policies ?
> 
> > | >operators want to assign node-tags as per router function (ABR, 
> > | >PE,
> core) and then
> > | 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.
> > |
> > | If we instead define a capability bit which would mean "PQ 
> > | candidate",
> we
> > | would avoid (2).
> > |
> > | >
> > | >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
> > | >| >This is a valid concern and one that we¹ve discussed 
> > | >| >previously with respect to routing behavior based on policies. 
> > | >| >I think that accepting
> this
> > | >| sure. Just that the draft mentions applications like 
> > | >| "Controlling
> Remote LFA
> > | >| tunnel termination", which I'm not sure the node tag is the 
> > | >| best
> approach
> > | >| for.
> > | >|
> > | >| thanks,
> > | >| Peter
> > | >|
> > | >| >Thanks,
> > | >| >Acee
> > | >| >
> > | >| >>>There are situations where node level policy is required and 
> > | >| >>>an
> OSPF
> > | >| >>>advertised admin tag simplifies this. For example, 
> > | >| >>>advertisement
> of
> > | >| >>is that it's operationally unfriendly compared to explicit 
> > | >| >>signaling of the capability (e.g. using a bit or a TLV). The 
> > | >| >>reason is that you have to configure the tag meaning on all receiving routers.
> > | >| >>
> > | >| >>thanks,
> > | >| >>Peter
> > | >| >>
> > | >| >>>
> > | >| >>>Please indicate your support or objections to adopting this 
> > | >| >>>draft as
> an

---

From: Karsten Thomann <[email-masked]>
Date: Thu, 28 Aug 2014 10:12:20 +0200

I support the adoption of the draft.

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 30 Aug 2014 18:22:07 +0530

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

Also, it should be stated
- if are more than one instance of this TLV in RI LSA are allowed.
- Minimum one tag must be present in the TLV
- What happens if the implementation does not know the Interpretation
of the tag value

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

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

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

Regards,
Dhruv