Subject: LFA manageability : per AF config => feedback required

From: <[email-masked]>
Date: Fri, 20 Feb 2015 07:21:07 +0000

Hi Folks,

As you know, LFA manageability draft is in final phasis ...
The current document states per AF granularity activation as a SHOULD.
"
5.1<https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1>.  LFA enabling/disabling scope

   The granularity of LFA activation should be controlled (as alternate

   nexthop consume memory in forwarding plane).

   An implementation of LFA SHOULD allow its activation with the

   following criteria:

   o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,

      LDP IPv6 unicast ...

   o  Per routing context : VRF, virtual/logical router, global routing

      table, ...

"

In the framework of ISIS/OSPF yang modelization, we are challenging this statement, do we really need to force implementation to support this "per AF" granularity ?

Please provide as soon as possible your feedback on this and also provide clear drivers to support or not per AF activation of LFA.

Thanks for your help !

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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: Jeff Tantsura <[email-masked]>
Date: Fri, 20 Feb 2015 07:29:34 +0000

Hi Stephane,

/chair hat off

IMO in disjoined topologies one should have flexibility to enable/disable LFA as per AF.

Cheers,
Jeff

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 19, 2015 at 11:21 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: LFA manageability : per AF config => feedback required

Hi Folks,

As you know, LFA manageability draft is in final phasis …
The current document states per AF granularity activation as a SHOULD.
“
5.1<https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1>.  LFA enabling/disabling scope

   following criteria:

      LDP IPv6 unicast ...

      table, ...

“

In the framework of ISIS/OSPF yang modelization, we are challenging this statement, do we really need to force implementation to support this “per AF” granularity ?

Thanks for your help !

Stephane Litkowski
Network Architect

---

From: Anton Smirnov <[email-masked]>
Date: Fri, 20 Feb 2015 10:17:03 +0100

Hi Stephane,
    I think concern of "alternate nexthops consume resources in the 
forwarding plane" is generally a valid one. But if you want to solve 
*this* problem then solution is to give to operator great flexibility to 
select set of prefixes which are allowed to have protection and this 
flexibility should go beyond of just per-AF selection.

    Per-context selection would actually solve different problem - CPU 
resources needed to compute LFAs (which are spent per-topology 
independent of number of nexthops which end up being protected).

    So IMO per-AF granularity might be useful (especially in disjoint 
topologies) but reason given in the draft does not connect with the 
solution.

Anton

On 02/20/2015 08:21 AM, [email-masked] wrote:
>       5.1
>       <https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1>.
>       LFA enabling/disabling scope
>
>
>
>
>
> In the framework of ISIS/OSPF yang modelization, we are challenging this
> statement, do we really need to force implementation to support this
> “per AF” granularity ?
>
> Please provide as soon as possible your feedback on this and also
> provide clear drivers to support or not per AF activation of LFA.
>
> Thanks for your help !
>
> Orange logo <http://www.orange.com/>
>
> *Stephane Litkowski *
> Network Architect
> phone: +33 2 23 28 49 83
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
> mobile: +33 6 37 86 97 52
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
> [email-masked] <mailto:[email-masked]>
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 20 Feb 2015 10:26:46 +0100

hi anton, et al,

there is one more quirk to this:

i have never heard of _LDP_ adress families:

| >    o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
| >       LDP IPv6 unicast ...
| >

so we're referring to something which does not exist - please see latest IANA registry:

http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

/hannes

On Fri, Feb 20, 2015 at 10:17:03AM +0100, Anton Smirnov wrote:
|    Hi Stephane,
|    I think concern of "alternate nexthops consume resources in the
| forwarding plane" is generally a valid one. But if you want to solve *this*
| problem then solution is to give to operator great flexibility to select set
| of prefixes which are allowed to have protection and this flexibility should
| go beyond of just per-AF selection.
| 
|    Per-context selection would actually solve different problem - CPU
| resources needed to compute LFAs (which are spent per-topology independent
| of number of nexthops which end up being protected).
| 
|    So IMO per-AF granularity might be useful (especially in disjoint
| topologies) but reason given in the draft does not connect with the
| solution.
| 
| Anton
| 
| 
| On 02/20/2015 08:21 AM, [email-masked] wrote:
| >Hi Folks,
| >
| >As you know, LFA manageability draft is in final phasis …
| >
| >The current document states per AF granularity activation as a SHOULD.
| >
| >“
| >
| >
| >      5.1
| >      <https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1>.
| >      LFA enabling/disabling scope
| >
| >
| >
| >
| >
| >    The granularity of LFA activation should be controlled (as alternate
| >
| >    nexthop consume memory in forwarding plane).
| >
| >
| >
| >    An implementation of LFA SHOULD allow its activation with the
| >
| >    following criteria:
| >
| >
| >
| >    o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
| >
| >       LDP IPv6 unicast ...
| >
| >
| >
| >    o  Per routing context : VRF, virtual/logical router, global routing
| >
| >       table, ...
| >
| >
| >
| >“
| >
| >In the framework of ISIS/OSPF yang modelization, we are challenging this
| >statement, do we really need to force implementation to support this
| >“per AF” granularity ?
| >
| >Please provide as soon as possible your feedback on this and also
| >provide clear drivers to support or not per AF activation of LFA.
| >
| >Thanks for your help !
| >
| >Orange logo <http://www.orange.com/>
| >
| >*Stephane Litkowski *
| >Network Architect
| >Orange/SCE/EQUANT/IBNF/ENDD/NDE
| >
| >Orange Expert Future Networks
| >
| >phone: +33 2 23 28 49 83
| ><https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
| >mobile: +33 6 37 86 97 52
| ><https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
| >[email-masked] <mailto:[email-masked]>
| >
| >_________________________________________________________________________________________________________________________
| >
| >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.
| >
| >
| >
| >_______________________________________________
| >rtgwg mailing list
| >[email-masked]
| >https://www.ietf.org/mailman/listinfo/rtgwg
| >
| 
| _______________________________________________
| rtgwg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Fri, 20 Feb 2015 10:36:29 +0000

Hi Jeff,

Thanks for your feedback.

In case of disjoined topology, this is another subject, it's per topology activation, not really per AF.
Per topology activation is also mentioned in the draft as granularity.

Does it make sense ?

Best regards,

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Friday, February 20, 2015 08:30
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

"

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

---

From: <[email-masked]>
Date: Fri, 20 Feb 2015 10:40:01 +0000

Hi Hannes,

You are right, maybe the text should be clarified. To be honest, this text part is old and I took a shortcut and mixing two things :)

First thing is really a per AF activation (ipv4 unicast, ipv6 unicast ...).

The second is do I need to protect "LDP routes" that are inheriting some IGP properties or do I consider that LDP is protected by something else (RSVP-TE :) ).

Best regards,

Stephane

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]] 
Sent: Friday, February 20, 2015 10:27
To: Anton Smirnov
Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

hi anton, et al,

/hannes

On Fri, Feb 20, 2015 at 10:17:03AM +0100, Anton Smirnov wrote:
|    Hi Stephane,
|    I think concern of "alternate nexthops consume resources in the 
| forwarding plane" is generally a valid one. But if you want to solve 
| *this* problem then solution is to give to operator great flexibility 
| to select set of prefixes which are allowed to have protection and 
| this flexibility should go beyond of just per-AF selection.
| 
|    Per-context selection would actually solve different problem - CPU 
| resources needed to compute LFAs (which are spent per-topology 
| independent of number of nexthops which end up being protected).
| 
|    So IMO per-AF granularity might be useful (especially in disjoint
| topologies) but reason given in the draft does not connect with the 
| solution.
| 
| Anton
| 
| 
| On 02/20/2015 08:21 AM, [email-masked] wrote:
| >Hi Folks,
| >
| >As you know, LFA manageability draft is in final phasis …
| >
| >The current document states per AF granularity activation as a SHOULD.
| >
| >“
| >
| >
| >      5.1
| >      <https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1>.
| >      LFA enabling/disabling scope
| >
| >
| >
| >
| >
| >    The granularity of LFA activation should be controlled (as 
| > alternate
| >
| >    nexthop consume memory in forwarding plane).
| >
| >
| >
| >    An implementation of LFA SHOULD allow its activation with the
| >
| >    following criteria:
| >
| >
| >
| >    o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 
| > unicast,
| >
| >       LDP IPv6 unicast ...
| >
| >
| >
| >    o  Per routing context : VRF, virtual/logical router, global 
| > routing
| >
| >       table, ...
| >
| >
| >
| >“
| >
| >In the framework of ISIS/OSPF yang modelization, we are challenging 
| >this statement, do we really need to force implementation to support 
| >this “per AF” granularity ?
| >
| >Please provide as soon as possible your feedback on this and also 
| >provide clear drivers to support or not per AF activation of LFA.
| >
| >Thanks for your help !
| >
| >Orange logo <http://www.orange.com/>
| >
| >*Stephane Litkowski *
| >Network Architect
| >Orange/SCE/EQUANT/IBNF/ENDD/NDE
| >
| >Orange Expert Future Networks
| >
| >phone: +33 2 23 28 49 83
| ><https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fcli
| >cvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddef
| >ault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
| >mobile: +33 6 37 86 97 52
| ><https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fcli
| >cvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddef
| >ault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
| >[email-masked] <mailto:[email-masked]>
| >
| >_____________________________________________________________________
| >____________________________________________________
| >
| >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.
| >
| >
| >
| >_______________________________________________
| >rtgwg mailing list
| >[email-masked]
| >https://www.ietf.org/mailman/listinfo/rtgwg
| >
| 
| _______________________________________________
| rtgwg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Fri, 20 Feb 2015 10:43:01 +0000

Hi Anton,

As I replied to Jeff, in case of disjoint topologies, we are no more related to per AF activation but more to a per topology activation which is different.

Regarding the "per-prefix" control, this is also proposed in the draft. Per-AF was added in order to have a simple mechanism to exclude a family of prefixes (sort of subset of per prefix).

Best Regards,

Stephane

-----Original Message-----
From: Anton Smirnov [mailto:[email-masked]] 
Sent: Friday, February 20, 2015 10:17
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

    Hi Stephane,
    I think concern of "alternate nexthops consume resources in the forwarding plane" is generally a valid one. But if you want to solve
*this* problem then solution is to give to operator great flexibility to select set of prefixes which are allowed to have protection and this flexibility should go beyond of just per-AF selection.

    Per-context selection would actually solve different problem - CPU resources needed to compute LFAs (which are spent per-topology independent of number of nexthops which end up being protected).

    So IMO per-AF granularity might be useful (especially in disjoint
topologies) but reason given in the draft does not connect with the solution.

Anton

On 02/20/2015 08:21 AM, [email-masked] wrote:
> In the framework of ISIS/OSPF yang modelization, we are challenging 
> this statement, do we really need to force implementation to support 
> this "per AF" granularity ?
>
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic
> voice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefau
> lt%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic
> voice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefau
> lt%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 20 Feb 2015 11:28:09 +0000

HI Jeff et al,

I can think of a reason to have a knob per-level(or per-area) or per ISIS topology(note in ISIS a topology in ISIS always corresponds to a single AF,) and per realm and topology in OSPF. But I cannot think of a reason of why within the same topology we need another set of knobs for each AF. Here, by AF I understand IPV4 or IPv6.

When both IPV4 and IPV6 are part of the same IGP topology, there is only one set of backup computations needed to protect both IPV4 and IPv6 traffic.

Also I cannot think of any motivation for an operator to turn on protection on only one AF and does not want to turn on for the other even if both AFs has been deployed for normal forwarding.

Thanks
-Pushpasis

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 20, 2015 at 12:59 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: LFA manageability : per AF config => feedback required

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

"

Thanks for your help !

Stephane Litkowski
Network Architect

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Feb 2015 04:00:51 +0000

Pushpassis -

From: rtgwg [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: Friday, February 20, 2015 3:28 AM
To: Jeff Tantsura; [email-masked]; [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

HI Jeff et al,

I can think of a reason to have a knob per-level(or per-area) or per ISIS topology(note in ISIS a topology in ISIS always corresponds to a single AF,)

[Les:] This is a common mistake to make. If one simply uses RFC 5308, then IPv6 prefixes can be advertised in the same topology as IPv4 (MTID #0) - and there are implementations which support this. More generally, from the protocol's POV a given topology can support any combinations of address families. It is only a convention because of the reserved MTIDs specified in RFC 5120 that certain MTIDs are "IPv6 only". But if one looks at the protocol capabilities such a restriction does not exist in general.

Interestingly you contradicted yourself below. :)
But I did want to set the record straight on this point - hopefully we are in agreement.

and per realm and topology in OSPF. But I cannot think of a reason of why within the same topology we need another set of knobs for each AF. Here, by AF I understand IPV4 or IPv6.

[Les:] I think your point here is that the LFA calculation is AF independent within a given topology - but resources are consumed independent of how many computations are required- giving an operator the ability to determine which prefixes are most critical seems useful. That could be per AF or per prefix.

   Les

Thanks
-Pushpasis

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

"

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 23 Feb 2015 06:01:57 +0000

Hi Les,

Some comments inline.

Thanks
-Pushpasis

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 23, 2015 at 9:30 AM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: LFA manageability : per AF config => feedback required

Pushpassis -

From: rtgwg [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: Friday, February 20, 2015 3:28 AM
To: Jeff Tantsura; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: LFA manageability : per AF config => feedback required

HI Jeff et al,

[Les:] This is a common mistake to make. If one simply uses RFC 5308, then IPv6 prefixes can be advertised in the same topology as IPv4 (MTID #0) – and there are implementations which support this. More generally, from the protocol’s POV a given topology can support any combinations of address families. It is only a convention because of the reserved MTIDs specified in RFC 5120 that certain MTIDs are “IPv6 only”. But if one looks at the protocol capabilities such a restriction does not exist in general.
[Pushpasis] The statement was made in the case where MT has been deployed. When MT is deployed, assumption is always that there is another topology configured other than MTID[0] for carrying the IPV6 topology. Isn’t it? In such cases MTID[0] still carries only IPV4 prefixes only. Right? :) One can argue that there can be a topology for just IPv4 mcast and not IPv6-ucast. But then what is the real usecase for that then?

Interestingly you contradicted yourself below. :)
But I did want to set the record straight on this point – hopefully we are in agreement.
[Pushpasis] Actually I did not, coz by topology I meant when MT has been deployed.  :)

[Les:] I think your point here is that the LFA calculation is AF independent within a given topology – but resources are consumed independent of how many computations are required- giving an operator the ability to determine which prefixes are most critical seems useful. That could be per AF or per prefix.
[Pushpasis] Yes exactly. Even if IPV4 and IPV6 prefixes are carried in same topology I am assuming the LFA knobs being discussed here is not the same as the backup selection policy described in draft-rtgwg-lfa-manageability. Coz, what you mentioned as per-prefix/per-AF can be easily controlled by the backup-selection-policy, which should have separate configurations than one discussed on this thread.

   Les

Thanks
-Pushpasis

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

“

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Feb 2015 06:16:29 +0000

Pushpassis -

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, February 22, 2015 10:02 PM
To: Les Ginsberg (ginsberg); Jeff Tantsura; [email-masked]; [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

Hi Les,

Some comments inline.

Thanks
-Pushpasis

Pushpassis -

HI Jeff et al,

[Les:] This is a common mistake to make. If one simply uses RFC 5308, then IPv6 prefixes can be advertised in the same topology as IPv4 (MTID #0) - and there are implementations which support this. More generally, from the protocol's POV a given topology can support any combinations of address families. It is only a convention because of the reserved MTIDs specified in RFC 5120 that certain MTIDs are "IPv6 only". But if one looks at the protocol capabilities such a restriction does not exist in general.
[Pushpasis] The statement was made in the case where MT has been deployed. When MT is deployed, assumption is always that there is another topology configured other than MTID[0] for carrying the IPV6 topology. Isn't it? In such cases MTID[0] still carries only IPV4 prefixes only. Right? :) One can argue that there can be a topology for just IPv4 mcast and not IPv6-ucast. But then what is the real usecase for that then?

[Les:] You are talking about the way MT is commonly used- that is NOT the same as saying that a topology MUST always be limited to supporting one AF. There is no such restriction in the protocol definition.

[Les:] Well, I was hoping...:)

[Les:] "backup-selection-policy" specifies which member of an LFA set should be preferred when there are multiple candidates for protecting a given prefix. What we are discussing here is controlling which prefixes are eligible for protection. These ae two different concepts.

    Les

   Les

Thanks
-Pushpasis

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

"

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 23 Feb 2015 06:33:13 +0000

Hi Les,

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 23, 2015 at 11:46 AM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: LFA manageability : per AF config => feedback required

[Pushpasis] Well, it is not only preferring. It can also be not-preferring-any (or pruning). So if no protection for any IPv6 is required, it can be achieved by a policy as belows:

Destination ipv6-all {
{
   Interface all
   {
       Neighbor exclude all;
   }
}

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Feb 2015 06:42:11 +0000

Pushpassis -

Conceptually, there are two different functionalities being discussed:

1)Supporting selection of what prefixes are eligible for protection. This is what Section 5.1 of the draft discusses.

2)For the set of prefixes which are eligible for protection, supporting policy to choose between multiple LFA candidates. This is discussed in Section 5.2 of the draft.

How you choose to implement this support is outside the scope of both the draft and this discussion.

    Les

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, February 22, 2015 10:33 PM
To: Les Ginsberg (ginsberg); Jeff Tantsura; [email-masked]<mailto:[email-masked]> abiloity to limit the set of prefixes m; [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

Hi Les,

Destination ipv6-all {
{
   Interface all
   {
       Neighbor exclude all;
   }
}

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 23 Feb 2015 07:09:10 +0000

Hi Les,

The point I am trying to make is that the following in section 5.1 does not make any sense to me anymore. And hence a per AF LFA knob too does not makes sense.

"An implementation of LFA SHOULD allow its activation with the

   following criteria:

      LDP IPv6 unicast ..."

I have mentioned this to Stephane as well.

Why will a operator choose to not protect an entire AF (IPV4/IPV6) when normal forwarding for both AF has been enabled. As long as a single AF is using protection the same backup computations can be used for other AFs as well without any extra cost. When operator is choosing protection only for sub-set of prefixes, backup computations still needs to be done for entire topology irrespective of the AF.

Thanks
-Pushpasis

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 23, 2015 at 12:12 PM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: LFA manageability : per AF config => feedback required

Pushpassis -

    Les

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Sunday, February 22, 2015 10:33 PM
To: Les Ginsberg (ginsberg); Jeff Tantsura; [email-masked]<mailto:[email-masked]> abiloity to limit the set of prefixes m; [email-masked]<mailto:[email-masked]>
Subject: Re: LFA manageability : per AF config => feedback required

Hi Les,

Destination ipv6-all {
{
   Interface all
   {
       Neighbor exclude all;
   }
}

---

From: <[email-masked]>
Date: Mon, 23 Feb 2015 07:10:00 +0000

+1, I confirm the two different goals to achieve in the draft. As Les mentioned, implementing it both in a common policy framework or in two different features is implementation dependent.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, February 23, 2015 07:42
To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: RE: LFA manageability : per AF config => feedback required

Pushpassis -

    Les

Hi Les,

Destination ipv6-all {
{
   Interface all
   {
       Neighbor exclude all;
   }
}

---

From: <[email-masked]>
Date: Mon, 23 Feb 2015 07:10:00 +0000

[SLI] Agree but is the "resource saving" point strong enough to mandate per AF activation ?

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, February 23, 2015 05:01
To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: RE: LFA manageability : per AF config => feedback required

Pushpassis -

HI Jeff et al,

   Les

Thanks
-Pushpasis

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

"

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Feb 2015 15:55:32 +0000

Stephane -

I can imagine cases in which the per AF enabling might make sense (e.g. when the network associated w one address family is deemed non-critical).

Section 5.1 is a SHOULD - as is most of the document. It is therefore a suggestion as to what an implementation should provide. If a given implementer thinks this is either too onerous or not useful they can omit it w/o being in violation. But I see no reason to eliminate this - and in actual practice I would expect the cost of supporting such a knob to be low cost. It is hard for me to see this as controversial.

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, February 22, 2015 11:10 PM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura; [email-masked]
Subject: RE: LFA manageability : per AF config => feedback required

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, February 23, 2015 05:01
To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF; [email-masked]<mailto:[email-masked]>
Subject: RE: LFA manageability : per AF config => feedback required

Pushpassis -

HI Jeff et al,

   Les

Thanks
-Pushpasis

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

"

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Feb 2015 18:26:15 +0000

I agree with Les.
Acee

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 23, 2015 at 10:55 AM
To: Stephane Litkowski <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: LFA manageability : per AF config => feedback required

Stephane –

Section 5.1 is a SHOULD – as is most of the document. It is therefore a suggestion as to what an implementation should provide. If a given implementer thinks this is either too onerous or not useful they can omit it w/o being in violation. But I see no reason to eliminate this – and in actual practice I would expect the cost of supporting such a knob to be low cost. It is hard for me to see this as controversial.

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Sunday, February 22, 2015 11:10 PM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura; [email-masked]<mailto:[email-masked]>
Subject: RE: LFA manageability : per AF config => feedback required

[SLI] Agree but is the “resource saving” point strong enough to mandate per AF activation ?

Pushpassis -

HI Jeff et al,

   Les

Thanks
-Pushpasis

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

“

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

Thank you.

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 23 Feb 2015 18:27:41 +0000

+1

--- tony

From: rtgwg [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Monday, February 23, 2015 10:26 AM
To: Les Ginsberg (ginsberg); [email-masked]; Pushpasis Sarkar; Jeff Tantsura; [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

I agree with Les.
Acee

Stephane -

   Les

Pushpassis -

HI Jeff et al,

   Les

Thanks
-Pushpasis

Hi Stephane,

/chair hat off

Cheers,
Jeff

Hi Folks,

   following criteria:

      LDP IPv6 unicast ...

      table, ...

"

Thanks for your help !

Stephane Litkowski
Network Architect

Thank you.

Thank you.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Feb 2015 15:58:44 +0100

hi les,

HG> inline.

On Mon, Feb 23, 2015 at 06:42:11AM +0000, Les Ginsberg (ginsberg) wrote:
|    Pushpassis -
| 
| 
| 
|    Conceptually, there are two different functionalities being discussed:
| 
| 
| 
|    1)Supporting selection of what prefixes are eligible for protection. This
|    is what Section 5.1 of the draft discusses.
| 
| 
| 
|    2)For the set of prefixes which are eligible for protection, supporting
|    policy to choose between multiple LFA candidates. This is discussed in
|    Section 5.2 of the draft.
| 
| 
| 
|    How you choose to implement this support is outside the scope of both the
|    draft and this discussion.
| 

yes and no; -

the troubling thing is that this document serves as a blueprint for the YANG
modeling. - as soon as we keep the optional nature of things in the yang model
itself i am fine, but then derek has to stop insisting on this in YANG.

| 
|    From: Pushpasis Sarkar [mailto:[email-masked]]
|    Sent: Sunday, February 22, 2015 10:33 PM
|    To: Les Ginsberg (ginsberg); Jeff Tantsura;
|    [1][email-masked] abiloity to limit the set of prefixes
|    m; [email-masked]
|    Subject: Re: LFA manageability : per AF config => feedback required
| 
| 
| 
|    Hi Les,
| 
| 
| 
|    From: "Les Ginsberg (ginsberg)" <[2][email-masked]>
|    Date: Monday, February 23, 2015 at 11:46 AM
|    To: Pushpasis Sarkar <[3][email-masked]>, Jeff Tantsura
|    <[4][email-masked]>, "[5][email-masked]"
|    <[6][email-masked]>, "[7][email-masked]"
|    <[8][email-masked]>
|    Subject: RE: LFA manageability : per AF config => feedback required
| 
| 
| 
|    [Les:] "backup-selection-policy" specifies which member of an LFA set
|    should be preferred when there are multiple candidates for protecting a
|    given prefix. What we are discussing here is controlling which prefixes
|    are eligible for protection. These ae two different concepts.
| 
| 
| 
|    [Pushpasis] Well, it is not only preferring. It can also be
|    not-preferring-any (or pruning). So if no protection for any IPv6 is
|    required, it can be achieved by a policy as belows:
| 
| 
| 
|    Destination ipv6-all {
| 
|    {
| 
|       Interface all
| 
|       {
| 
|           Neighbor exclude all;
| 
|       }
| 
|    }
| 
| 
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. mailto:[email-masked]
|    5. mailto:[email-masked]
|    6. mailto:[email-masked]
|    7. mailto:[email-masked]
|    8. mailto:[email-masked]

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Feb 2015 16:02:28 +0100

On Mon, Feb 23, 2015 at 03:55:32PM +0000, Les Ginsberg (ginsberg) wrote:
|    I can imagine cases in which the per AF enabling might make sense (e.g.
|    when the network associated w one address family is deemed non-critical).

HG> as it is unlikely that operators will tun off IPv4 protection,
    may i have a ask that you repeat that quote above in the 6man
    meeting ;-) ? - effectifely you're saying "IPv6 may be considered
    as less critical", and therefore we SHOULD provide a knob
    to turn protection off.

| 
| 
|    Section 5.1 is a SHOULD - as is most of the document. It is therefore a
|    suggestion as to what an implementation should provide. If a given
|    implementer thinks this is either too onerous or not useful they can omit
|    it w/o being in violation. But I see no reason to eliminate this - and in
|    actual practice I would expect the cost of supporting such a knob to be
|    low cost. It is hard for me to see this as controversial.
| 
| 
| 
|       Les
| 
| 
| 
| 
| 
|    From: [email-masked] [mailto:[email-masked]]
|    Sent: Sunday, February 22, 2015 11:10 PM
|    To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura;
|    [email-masked]
|    Subject: RE: LFA manageability : per AF config => feedback required
| 
| 
| 
|    [Les:] I think your point here is that the LFA calculation is AF
|    independent within a given topology - but resources are consumed
|    independent of how many computations are required- giving an operator the
|    ability to determine which prefixes are most critical seems useful. That
|    could be per AF or per prefix.
| 
| 
| 
|    [SLI] Agree but is the "resource saving" point strong enough to mandate
|    per AF activation ?
| 
| 
| 
|    From: Les Ginsberg (ginsberg) [[1]mailto:[email-masked]]
|    Sent: Monday, February 23, 2015 05:01
|    To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF;
|    [2][email-masked]
|    Subject: RE: LFA manageability : per AF config => feedback required
| 
| 
| 
|    Pushpassis -
| 
| 
| 
|    From: rtgwg [[3]mailto:[email-masked]] On Behalf Of Pushpasis
|    Sarkar
|    Sent: Friday, February 20, 2015 3:28 AM
|    To: Jeff Tantsura; [4][email-masked]; [5][email-masked]
|    Subject: Re: LFA manageability : per AF config => feedback required
| 
| 
| 
|    HI Jeff et al,
| 
| 
| 
|    I can think of a reason to have a knob per-level(or per-area) or per ISIS
|    topology(note in ISIS a topology in ISIS always corresponds to a single
|    AF,)
| 
| 
| 
|    [Les:] This is a common mistake to make. If one simply uses RFC 5308, then
|    IPv6 prefixes can be advertised in the same topology as IPv4 (MTID #0) -
|    and there are implementations which support this. More generally, from the
|    protocol's POV a given topology can support any combinations of address
|    families. It is only a convention because of the reserved MTIDs specified
|    in RFC 5120 that certain MTIDs are "IPv6 only". But if one looks at the
|    protocol capabilities such a restriction does not exist in general.
| 
| 
| 
|    Interestingly you contradicted yourself below. J
| 
|    But I did want to set the record straight on this point - hopefully we are
|    in agreement.
| 
| 
| 
|    and per realm and topology in OSPF. But I cannot think of a reason of why
|    within the same topology we need another set of knobs for each AF. Here,
|    by AF I understand IPV4 or IPv6.
| 
| 
| 
|    When both IPV4 and IPV6 are part of the same IGP topology, there is only
|    one set of backup computations needed to protect both IPV4 and IPv6
|    traffic.
| 
| 
| 
|    Also I cannot think of any motivation for an operator to turn on
|    protection on only one AF and does not want to turn on for the other even
|    if both AFs has been deployed for normal forwarding.
| 
| 
| 
|    [Les:] I think your point here is that the LFA calculation is AF
|    independent within a given topology - but resources are consumed
|    independent of how many computations are required- giving an operator the
|    ability to determine which prefixes are most critical seems useful. That
|    could be per AF or per prefix.
| 
| 
| 
|       Les
| 
| 
| 
|    Thanks
| 
|    -Pushpasis
| 
| 
| 
|    From: Jeff Tantsura <[6][email-masked]>
|    Date: Friday, February 20, 2015 at 12:59 PM
|    To: "[7][email-masked]" <[8][email-masked]>,
|    "[9][email-masked]" <[10][email-masked]>
|    Subject: Re: LFA manageability : per AF config => feedback required
| 
| 
| 
|    Hi Stephane,
| 
| 
| 
|    /chair hat off
| 
| 
| 
|    IMO in disjoined topologies one should have flexibility to enable/disable
|    LFA as per AF.
| 
| 
| 
| 
| 
|    Cheers,
| 
|    Jeff
| 
| 
| 
|    From: "[11][email-masked]"
|    <[12][email-masked]>
|    Date: Thursday, February 19, 2015 at 11:21 PM
|    To: "[13][email-masked]" <[14][email-masked]>
|    Subject: LFA manageability : per AF config => feedback required
| 
| 
| 
|      Hi Folks,
| 
| 
| 
|      As you know, LFA manageability draft is in final phasis ...
| 
|      The current document states per AF granularity activation as a SHOULD.
| 
|      "
| 
|   [15]5.1.  LFA enabling/disabling scope
| 
| 
| 
| 
| 
|     The granularity of LFA activation should be controlled (as alternate
| 
|     nexthop consume memory in forwarding plane).
| 
| 
| 
|     An implementation of LFA SHOULD allow its activation with the
| 
|     following criteria:
| 
| 
| 
|     o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
| 
|        LDP IPv6 unicast ...
| 
| 
| 
|     o  Per routing context : VRF, virtual/logical router, global routing
| 
|        table, ...
| 
| 
| 
|      "
| 
| 
| 
|      In the framework of ISIS/OSPF yang modelization, we are challenging this
|      statement, do we really need to force implementation to support this
|      "per AF" granularity ?
| 
| 
| 
|      Please provide as soon as possible your feedback on this and also
|      provide clear drivers to support or not per AF activation of LFA.
| 
| 
| 
| 
| 
|      Thanks for your help !
| 
| 
| 
| 
| 
|      [16]Orange logo
| 
| 
| 
|      Stephane Litkowski
|      Network Architect
|      Orange/SCE/EQUANT/IBNF/ENDD/NDE
| 
|      Orange Expert Future Networks
| 
|      phone: [17]+33 2 23 28 49 83
|      mobile: [18]+33 6 37 86 97 52
|      [19][email-masked]
| 
| 
| 
| 
| 
|  _________________________________________________________________________________________________________________________
| 
| 
| 
|  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.
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. mailto:[email-masked]
|    5. mailto:[email-masked]
|    6. mailto:[email-masked]
|    7. mailto:[email-masked]
|    8. mailto:[email-masked]
|    9. mailto:[email-masked]
|   10. mailto:[email-masked]
|   11. mailto:[email-masked]
|   12. mailto:[email-masked]
|   13. mailto:[email-masked]
|   14. mailto:[email-masked]
|   15. https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1
|   16. http://www.orange.com/
|   17. https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
|   18. https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
|   19. mailto:[email-masked]

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Feb 2015 16:03:32 +0100

HG> that IPv6 is less critical than IPv4 ? -
    the IESG review will be a lot of fun then - i'll make some popcorn ...

On Mon, Feb 23, 2015 at 06:26:15PM +0000, Acee Lindem (acee) wrote:
|    I agree with Les.
|    Acee
|    From: "Les Ginsberg (ginsberg)" <[1][email-masked]>
|    Date: Monday, February 23, 2015 at 10:55 AM
|    To: Stephane Litkowski <[2][email-masked]>, Pushpasis
|    Sarkar <[3][email-masked]>, Jeff Tantsura
|    <[4][email-masked]>, Routing WG <[5][email-masked]>
|    Subject: RE: LFA manageability : per AF config => feedback required
| 
|      Stephane –
| 
| 
| 
|      I can imagine cases in which the per AF enabling might make sense (e.g.
|      when the network associated w one address family is deemed
|      non-critical).
| 
| 
| 
|      Section 5.1 is a SHOULD – as is most of the document. It is therefore
|      a suggestion as to what an implementation should provide. If a given
|      implementer thinks this is either too onerous or not useful they can
|      omit it w/o being in violation. But I see no reason to eliminate this
|      – and in actual practice I would expect the cost of supporting such a
|      knob to be low cost. It is hard for me to see this as controversial.
| 
| 
| 
|         Les
| 
| 
| 
| 
| 
|      From: [6][email-masked]
|      [[7]mailto:[email-masked]]
|      Sent: Sunday, February 22, 2015 11:10 PM
|      To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura;
|      [8][email-masked]
|      Subject: RE: LFA manageability : per AF config => feedback required
| 
| 
| 
|      [Les:] I think your point here is that the LFA calculation is AF
|      independent within a given topology – but resources are consumed
|      independent of how many computations are required- giving an operator
|      the ability to determine which prefixes are most critical seems useful.
|      That could be per AF or per prefix.
| 
| 
| 
|      [SLI] Agree but is the “resource saving” point strong enough to
|      mandate per AF activation ?
| 
| 
| 
|      From: Les Ginsberg (ginsberg) [[9]mailto:[email-masked]]
|      Sent: Monday, February 23, 2015 05:01
|      To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF;
|      [10][email-masked]
|      Subject: RE: LFA manageability : per AF config => feedback required
| 
| 
| 
|      Pushpassis -
| 
| 
| 
|      From: rtgwg [[11]mailto:[email-masked]] On Behalf Of Pushpasis
|      Sarkar
|      Sent: Friday, February 20, 2015 3:28 AM
|      To: Jeff Tantsura; [12][email-masked]; [13][email-masked]
|      Subject: Re: LFA manageability : per AF config => feedback required
| 
| 
| 
|      HI Jeff et al,
| 
| 
| 
|      I can think of a reason to have a knob per-level(or per-area) or per
|      ISIS topology(note in ISIS a topology in ISIS always corresponds to a
|      single AF,)
| 
| 
| 
|      [Les:] This is a common mistake to make. If one simply uses RFC 5308,
|      then IPv6 prefixes can be advertised in the same topology as IPv4 (MTID
|      #0) – and there are implementations which support this. More
|      generally, from the protocol’s POV a given topology can support any
|      combinations of address families. It is only a convention because of the
|      reserved MTIDs specified in RFC 5120 that certain MTIDs are “IPv6
|      only”. But if one looks at the protocol capabilities such a
|      restriction does not exist in general.
| 
| 
| 
|      Interestingly you contradicted yourself below. J
| 
|      But I did want to set the record straight on this point – hopefully we
|      are in agreement.
| 
| 
| 
|      and per realm and topology in OSPF. But I cannot think of a reason of
|      why within the same topology we need another set of knobs for each AF.
|      Here, by AF I understand IPV4 or IPv6.
| 
| 
| 
|      When both IPV4 and IPV6 are part of the same IGP topology, there is only
|      one set of backup computations needed to protect both IPV4 and IPv6
|      traffic.
| 
| 
| 
|      Also I cannot think of any motivation for an operator to turn on
|      protection on only one AF and does not want to turn on for the other
|      even if both AFs has been deployed for normal forwarding.
| 
| 
| 
|      [Les:] I think your point here is that the LFA calculation is AF
|      independent within a given topology – but resources are consumed
|      independent of how many computations are required- giving an operator
|      the ability to determine which prefixes are most critical seems useful.
|      That could be per AF or per prefix.
| 
| 
| 
|         Les
| 
| 
| 
|      Thanks
| 
|      -Pushpasis
| 
| 
| 
|      From: Jeff Tantsura <[14][email-masked]>
|      Date: Friday, February 20, 2015 at 12:59 PM
|      To: "[15][email-masked]"
|      <[16][email-masked]>, "[17][email-masked]"
|      <[18][email-masked]>
|      Subject: Re: LFA manageability : per AF config => feedback required
| 
| 
| 
|      Hi Stephane,
| 
| 
| 
|      /chair hat off
| 
| 
| 
|      IMO in disjoined topologies one should have flexibility to
|      enable/disable LFA as per AF.
| 
| 
| 
| 
| 
|      Cheers,
| 
|      Jeff
| 
| 
| 
|      From: "[19][email-masked]"
|      <[20][email-masked]>
|      Date: Thursday, February 19, 2015 at 11:21 PM
|      To: "[21][email-masked]" <[22][email-masked]>
|      Subject: LFA manageability : per AF config => feedback required
| 
| 
| 
|        Hi Folks,
| 
| 
| 
|        As you know, LFA manageability draft is in final phasis
| 
|        The current document states per AF granularity activation as a SHOULD.
| 
|        “
| 
|   [23]5.1.  LFA enabling/disabling scope
| 
| 
| 
| 
| 
|     The granularity of LFA activation should be controlled (as alternate
| 
|     nexthop consume memory in forwarding plane).
| 
| 
| 
|     An implementation of LFA SHOULD allow its activation with the
| 
|     following criteria:
| 
| 
| 
|     o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
| 
|        LDP IPv6 unicast ...
| 
| 
| 
|     o  Per routing context : VRF, virtual/logical router, global routing
| 
|        table, ...
| 
| 
| 
|        “
| 
| 
| 
|        In the framework of ISIS/OSPF yang modelization, we are challenging
|        this statement, do we really need to force implementation to support
|        this “per AF” granularity ?
| 
| 
| 
|        Please provide as soon as possible your feedback on this and also
|        provide clear drivers to support or not per AF activation of LFA.
| 
| 
| 
| 
| 
|        Thanks for your help !
| 
| 
| 
| 
| 
|        [24]Orange logo
| 
| 
| 
|        Stephane Litkowski
|        Network Architect
|        Orange/SCE/EQUANT/IBNF/ENDD/NDE
| 
|        Orange Expert Future Networks
| 
|        phone: [25]+33 2 23 28 49 83
|        mobile: [26]+33 6 37 86 97 52
|        [27][email-masked]
| 
| 
| 
| 
| 
|  _________________________________________________________________________________________________________________________
| 
| 
| 
|  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.
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. mailto:[email-masked]
|    5. mailto:[email-masked]
|    6. mailto:[email-masked]
|    7. mailto:[email-masked]
|    8. mailto:[email-masked]
|    9. mailto:[email-masked]
|   10. mailto:[email-masked]
|   11. mailto:[email-masked]
|   12. mailto:[email-masked]
|   13. mailto:[email-masked]
|   14. mailto:[email-masked]
|   15. mailto:[email-masked]
|   16. mailto:[email-masked]
|   17. mailto:[email-masked]
|   18. mailto:[email-masked]
|   19. mailto:[email-masked]
|   20. mailto:[email-masked]
|   21. mailto:[email-masked]
|   22. mailto:[email-masked]
|   23. https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1
|   24. http://www.orange.com/
|   25. https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
|   26. https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
|   27. mailto:[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Feb 2015 15:35:11 +0000

Hannes - I don¹t see how you can jump to this conclusion - pretty lame ;^)
Having the ability to enable or disable fast reroute protection by address
family by no means favors one address family over the other. There just
may be deployments where protection is just not desired for both and it is
not like it comes for free (since you must account for the topologies
being non-congruent).
Acee  

On 2/24/15, 10:03 AM, "Hannes Gredler" <[email-masked]> wrote:

>|      Stephane 
>|      Section 5.1 is a SHOULD  as is most of the document. It is
>therefore
>|       and in actual practice I would expect the cost of supporting
>such a
>|      independent within a given topology  but resources are consumed
>|      [SLI] Agree but is the ³resource saving² point strong enough to
>|      #0)  and there are implementations which support this. More
>|      generally, from the protocol¹s POV a given topology can support any
>|      reserved MTIDs specified in RFC 5120 that certain MTIDs are ³IPv6
>|      only². But if one looks at the protocol capabilities such a
>|      But I did want to set the record straight on this point 
>hopefully we
>|      are in agreement.
>| 
>| 
>| 
>|      independent within a given topology  but resources are consumed
>|        ³
>|        ³
>|        this ³per AF² granularity ?
>| 
>| 
>| 
>__________________________________________________________________________
>|  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;
>| 
>__________________________________________________________________________
>|  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;
>| 
>|   23. 
>https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-
>5.1
>|   25. 
>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice
>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root
>service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
>|   26. 
>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice
>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root
>service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Feb 2015 17:00:17 +0100

On Tue, Feb 24, 2015 at 03:35:11PM +0000, Acee Lindem (acee) wrote:
| Hannes - I don¹t see how you can jump to this conclusion - pretty lame ;^)
| Having the ability to enable or disable fast reroute protection by address
| family by no means favors one address family over the other. There just
| may be deployments where protection is just not desired for both and it is
| not like it comes for free (since you must account for the topologies
| being non-congruent).

my point is that controlling LFA on a per-topology basis makes perfect sense.
(as per your example above (non-congruent topologies), to save some number crunching).

what does not make sense is: consider we've deployed IPv4/IPv6 in the default
topology (integrated IS-IS model) - to turn off LFA for V6 routes.

you have done already the number crunching, so why would you want
to make IPv6 routes a second class citizen here ? - 

can you highlight the use-case here ?

/hannes

| On 2/24/15, 10:03 AM, "Hannes Gredler" <[email-masked]> wrote:
| 
| >HG> that IPv6 is less critical than IPv4 ? -
| >    the IESG review will be a lot of fun then - i'll make some popcorn ...
| >
| >On Mon, Feb 23, 2015 at 06:26:15PM +0000, Acee Lindem (acee) wrote:
| >|    I agree with Les.
| >|    Acee
| >|    From: "Les Ginsberg (ginsberg)" <[1][email-masked]>
| >|    Date: Monday, February 23, 2015 at 10:55 AM
| >|    To: Stephane Litkowski <[2][email-masked]>, Pushpasis
| >|    Sarkar <[3][email-masked]>, Jeff Tantsura
| >|    <[4][email-masked]>, Routing WG <[5][email-masked]>
| >|    Subject: RE: LFA manageability : per AF config => feedback required
| >| 
| >|      Stephane 
| >| 
| >| 
| >| 
| >|      I can imagine cases in which the per AF enabling might make sense
| >(e.g.
| >|      when the network associated w one address family is deemed
| >|      non-critical).
| >| 
| >| 
| >| 
| >|      Section 5.1 is a SHOULD  as is most of the document. It is
| >therefore
| >|      a suggestion as to what an implementation should provide. If a
| >given
| >|      implementer thinks this is either too onerous or not useful they
| >can
| >|      omit it w/o being in violation. But I see no reason to eliminate
| >this
| >|       and in actual practice I would expect the cost of supporting
| >such a
| >|      knob to be low cost. It is hard for me to see this as
| >controversial.
| >| 
| >| 
| >| 
| >|         Les
| >| 
| >| 
| >| 
| >| 
| >| 
| >|      From: [6][email-masked]
| >|      [[7]mailto:[email-masked]]
| >|      Sent: Sunday, February 22, 2015 11:10 PM
| >|      To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura;
| >|      [8][email-masked]
| >|      Subject: RE: LFA manageability : per AF config => feedback required
| >| 
| >| 
| >| 
| >|      [Les:] I think your point here is that the LFA calculation is AF
| >|      independent within a given topology  but resources are consumed
| >|      independent of how many computations are required- giving an
| >operator
| >|      the ability to determine which prefixes are most critical seems
| >useful.
| >|      That could be per AF or per prefix.
| >| 
| >| 
| >| 
| >|      [SLI] Agree but is the ³resource saving² point strong enough to
| >|      mandate per AF activation ?
| >| 
| >| 
| >| 
| >|      From: Les Ginsberg (ginsberg) [[9]mailto:[email-masked]]
| >|      Sent: Monday, February 23, 2015 05:01
| >|      To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF;
| >|      [10][email-masked]
| >|      Subject: RE: LFA manageability : per AF config => feedback required
| >| 
| >| 
| >| 
| >|      Pushpassis -
| >| 
| >| 
| >| 
| >|      From: rtgwg [[11]mailto:[email-masked]] On Behalf Of
| >Pushpasis
| >|      Sarkar
| >|      Sent: Friday, February 20, 2015 3:28 AM
| >|      To: Jeff Tantsura; [12][email-masked];
| >[13][email-masked]
| >|      Subject: Re: LFA manageability : per AF config => feedback required
| >| 
| >| 
| >| 
| >|      HI Jeff et al,
| >| 
| >| 
| >| 
| >|      I can think of a reason to have a knob per-level(or per-area) or
| >per
| >|      ISIS topology(note in ISIS a topology in ISIS always corresponds
| >to a
| >|      single AF,)
| >| 
| >| 
| >| 
| >|      [Les:] This is a common mistake to make. If one simply uses RFC
| >5308,
| >|      then IPv6 prefixes can be advertised in the same topology as IPv4
| >(MTID
| >|      #0)  and there are implementations which support this. More
| >|      generally, from the protocol¹s POV a given topology can support any
| >|      combinations of address families. It is only a convention because
| >of the
| >|      reserved MTIDs specified in RFC 5120 that certain MTIDs are ³IPv6
| >|      only². But if one looks at the protocol capabilities such a
| >|      restriction does not exist in general.
| >| 
| >| 
| >| 
| >|      Interestingly you contradicted yourself below. J
| >| 
| >|      But I did want to set the record straight on this point 
| >hopefully we
| >|      are in agreement.
| >| 
| >| 
| >| 
| >|      and per realm and topology in OSPF. But I cannot think of a reason
| >of
| >|      why within the same topology we need another set of knobs for each
| >AF.
| >|      Here, by AF I understand IPV4 or IPv6.
| >| 
| >| 
| >| 
| >|      When both IPV4 and IPV6 are part of the same IGP topology, there
| >is only
| >|      one set of backup computations needed to protect both IPV4 and IPv6
| >|      traffic.
| >| 
| >| 
| >| 
| >|      Also I cannot think of any motivation for an operator to turn on
| >|      protection on only one AF and does not want to turn on for the
| >other
| >|      even if both AFs has been deployed for normal forwarding.
| >| 
| >| 
| >| 
| >|      [Les:] I think your point here is that the LFA calculation is AF
| >|      independent within a given topology  but resources are consumed
| >|      independent of how many computations are required- giving an
| >operator
| >|      the ability to determine which prefixes are most critical seems
| >useful.
| >|      That could be per AF or per prefix.
| >| 
| >| 
| >| 
| >|         Les
| >| 
| >| 
| >| 
| >|      Thanks
| >| 
| >|      -Pushpasis
| >| 
| >| 
| >| 
| >|      From: Jeff Tantsura <[14][email-masked]>
| >|      Date: Friday, February 20, 2015 at 12:59 PM
| >|      To: "[15][email-masked]"
| >|      <[16][email-masked]>, "[17][email-masked]"
| >|      <[18][email-masked]>
| >|      Subject: Re: LFA manageability : per AF config => feedback required
| >| 
| >| 
| >| 
| >|      Hi Stephane,
| >| 
| >| 
| >| 
| >|      /chair hat off
| >| 
| >| 
| >| 
| >|      IMO in disjoined topologies one should have flexibility to
| >|      enable/disable LFA as per AF.
| >| 
| >| 
| >| 
| >| 
| >| 
| >|      Cheers,
| >| 
| >|      Jeff
| >| 
| >| 
| >| 
| >|      From: "[19][email-masked]"
| >|      <[20][email-masked]>
| >|      Date: Thursday, February 19, 2015 at 11:21 PM
| >|      To: "[21][email-masked]" <[22][email-masked]>
| >|      Subject: LFA manageability : per AF config => feedback required
| >| 
| >| 
| >| 
| >|        Hi Folks,
| >| 
| >| 
| >| 
| >|        As you know, LFA manageability draft is in final phasis
| >| 
| >|        The current document states per AF granularity activation as a
| >SHOULD.
| >| 
| >|        ³
| >| 
| >|   [23]5.1.  LFA enabling/disabling scope
| >| 
| >| 
| >| 
| >| 
| >| 
| >|     The granularity of LFA activation should be controlled (as alternate
| >| 
| >|     nexthop consume memory in forwarding plane).
| >| 
| >| 
| >| 
| >|     An implementation of LFA SHOULD allow its activation with the
| >| 
| >|     following criteria:
| >| 
| >| 
| >| 
| >|     o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4
| >unicast,
| >| 
| >|        LDP IPv6 unicast ...
| >| 
| >| 
| >| 
| >|     o  Per routing context : VRF, virtual/logical router, global routing
| >| 
| >|        table, ...
| >| 
| >| 
| >| 
| >|        ³
| >| 
| >| 
| >| 
| >|        In the framework of ISIS/OSPF yang modelization, we are
| >challenging
| >|        this statement, do we really need to force implementation to
| >support
| >|        this ³per AF² granularity ?
| >| 
| >| 
| >| 
| >|        Please provide as soon as possible your feedback on this and also
| >|        provide clear drivers to support or not per AF activation of LFA.
| >| 
| >| 
| >| 
| >| 
| >| 
| >|        Thanks for your help !
| >| 
| >| 
| >| 
| >| 
| >| 
| >|        [24]Orange logo
| >| 
| >| 
| >| 
| >|        Stephane Litkowski
| >|        Network Architect
| >|        Orange/SCE/EQUANT/IBNF/ENDD/NDE
| >| 
| >|        Orange Expert Future Networks
| >| 
| >|        phone: [25]+33 2 23 28 49 83
| >|        mobile: [26]+33 6 37 86 97 52
| >|        [27][email-masked]
| >| 
| >| 
| >| 
| >| 
| >| 
| >|  
| >__________________________________________________________________________
| >_______________________________________________
| >| 
| >| 
| >| 
| >|  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.
| >| 
| >| References
| >| 
| >|    Visible links
| >|    1. mailto:[email-masked]
| >|    2. mailto:[email-masked]
| >|    3. mailto:[email-masked]
| >|    4. mailto:[email-masked]
| >|    5. mailto:[email-masked]
| >|    6. mailto:[email-masked]
| >|    7. mailto:[email-masked]
| >|    8. mailto:[email-masked]
| >|    9. mailto:[email-masked]
| >|   10. mailto:[email-masked]
| >|   11. mailto:[email-masked]
| >|   12. mailto:[email-masked]
| >|   13. mailto:[email-masked]
| >|   14. mailto:[email-masked]
| >|   15. mailto:[email-masked]
| >|   16. mailto:[email-masked]
| >|   17. mailto:[email-masked]
| >|   18. mailto:[email-masked]
| >|   19. mailto:[email-masked]
| >|   20. mailto:[email-masked]
| >|   21. mailto:[email-masked]
| >|   22. mailto:[email-masked]
| >|   23. 
| >https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-
| >5.1
| >|   24. http://www.orange.com/
| >|   25. 
| >https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice
| >.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root
| >service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
| >|   26. 
| >https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice
| >.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root
| >service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
| >|   27. mailto:[email-masked]
| >
| >
| >| _______________________________________________
| >| rtgwg mailing list
| >| [email-masked]
| >| https://www.ietf.org/mailman/listinfo/rtgwg
| >
|

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 24 Feb 2015 16:05:03 +0000

Hannes -

It would be good if you did not attribute statements to me that I did not make. I made no statement about the importance of one address family over another. Please do not attempt to create controversy by misrepresenting what I wrote.

I do like popcorn though - so if you really are going to make some - count me in. :-)

   Les

> Sent: Tuesday, February 24, 2015 7:04 AM
> To: Acee Lindem (acee)
> Cc: Les Ginsberg (ginsberg); [email-masked]; Pushpasis
> Sarkar; Jeff Tantsura; [email-masked]
> __________________________________________________________
> __________________________________________________________
> _____
> |
> |
> |
> |  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;
> |
> __________________________________________________________
> __________________________________________________________
> _____
> |
> |
> |
> |  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;
> |
> https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvo
> ice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault
> %26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083
> %20
> |   26.
> https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvo
> ice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault
> %26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052
> %20

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Feb 2015 17:13:15 +0100

les,

there is explicit statement and implicit statements.

it is correct that you have not made an explicit statement that
IPv6 is less important than IPv4 and yet there is
your last quote which implicitly makes me think so.

so can you clarify this use-case where a SP wants to have IPv4 protected
and not IPv6 in the default topology.

why would this make sense / why would a knob for this make sense ?

/hannes

On Tue, Feb 24, 2015 at 04:05:03PM +0000, Les Ginsberg (ginsberg) wrote:
| Hannes -
| 
| It would be good if you did not attribute statements to me that I did not make. I made no statement about the importance of one address family over another. Please do not attempt to create controversy by misrepresenting what I wrote.
| 
| I do like popcorn though - so if you really are going to make some - count me in. :-)
| 
|    Les
| 
| 
| > -----Original Message-----
| > From: Hannes Gredler [mailto:[email-masked]]
| > Sent: Tuesday, February 24, 2015 7:04 AM
| > To: Acee Lindem (acee)
| > Cc: Les Ginsberg (ginsberg); [email-masked]; Pushpasis
| > Sarkar; Jeff Tantsura; [email-masked]
| > Subject: Re: LFA manageability : per AF config => feedback required
| > 
| > HG> that IPv6 is less critical than IPv4 ? -
| >     the IESG review will be a lot of fun then - i'll make some popcorn ...
| > 
| > On Mon, Feb 23, 2015 at 06:26:15PM +0000, Acee Lindem (acee) wrote:
| > |    I agree with Les.
| > |    Acee
| > |    From: "Les Ginsberg (ginsberg)" <[1][email-masked]>
| > |    Date: Monday, February 23, 2015 at 10:55 AM
| > |    To: Stephane Litkowski <[2][email-masked]>, Pushpasis
| > |    Sarkar <[3][email-masked]>, Jeff Tantsura
| > |    <[4][email-masked]>, Routing WG <[5][email-masked]>
| > |    Subject: RE: LFA manageability : per AF config => feedback required
| > |
| > |      Stephane –
| > |
| > |
| > |
| > |      I can imagine cases in which the per AF enabling might make sense (e.g.
| > |      when the network associated w one address family is deemed
| > |      non-critical).
| > |
| > |
| > |
| > |      Section 5.1 is a SHOULD – as is most of the document. It is therefore
| > |      a suggestion as to what an implementation should provide. If a given
| > |      implementer thinks this is either too onerous or not useful they can
| > |      omit it w/o being in violation. But I see no reason to eliminate this
| > |      – and in actual practice I would expect the cost of supporting such a
| > |      knob to be low cost. It is hard for me to see this as controversial.
| > |
| > |
| > |
| > |         Les
| > |
| > |
| > |
| > |
| > |
| > |      From: [6][email-masked]
| > |      [[7]mailto:[email-masked]]
| > |      Sent: Sunday, February 22, 2015 11:10 PM
| > |      To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura;
| > |      [8][email-masked]
| > |      Subject: RE: LFA manageability : per AF config => feedback required
| > |
| > |
| > |
| > |      [Les:] I think your point here is that the LFA calculation is AF
| > |      independent within a given topology – but resources are consumed
| > |      independent of how many computations are required- giving an
| > operator
| > |      the ability to determine which prefixes are most critical seems useful.
| > |      That could be per AF or per prefix.
| > |
| > |
| > |
| > |      [SLI] Agree but is the “resource saving” point strong enough to
| > |      mandate per AF activation ?
| > |
| > |
| > |
| > |      From: Les Ginsberg (ginsberg) [[9]mailto:[email-masked]]
| > |      Sent: Monday, February 23, 2015 05:01
| > |      To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF;
| > |      [10][email-masked]
| > |      Subject: RE: LFA manageability : per AF config => feedback required
| > |
| > |
| > |
| > |      Pushpassis -
| > |
| > |
| > |
| > |      From: rtgwg [[11]mailto:[email-masked]] On Behalf Of
| > Pushpasis
| > |      Sarkar
| > |      Sent: Friday, February 20, 2015 3:28 AM
| > |      To: Jeff Tantsura; [12][email-masked];
| > [13][email-masked]
| > |      Subject: Re: LFA manageability : per AF config => feedback required
| > |
| > |
| > |
| > |      HI Jeff et al,
| > |
| > |
| > |
| > |      I can think of a reason to have a knob per-level(or per-area) or per
| > |      ISIS topology(note in ISIS a topology in ISIS always corresponds to a
| > |      single AF,)
| > |
| > |
| > |
| > |      [Les:] This is a common mistake to make. If one simply uses RFC 5308,
| > |      then IPv6 prefixes can be advertised in the same topology as IPv4 (MTID
| > |      #0) – and there are implementations which support this. More
| > |      generally, from the protocol’s POV a given topology can support any
| > |      combinations of address families. It is only a convention because of the
| > |      reserved MTIDs specified in RFC 5120 that certain MTIDs are “IPv6
| > |      only”. But if one looks at the protocol capabilities such a
| > |      restriction does not exist in general.
| > |
| > |
| > |
| > |      Interestingly you contradicted yourself below. J
| > |
| > |      But I did want to set the record straight on this point – hopefully we
| > |      are in agreement.
| > |
| > |
| > |
| > |      and per realm and topology in OSPF. But I cannot think of a reason of
| > |      why within the same topology we need another set of knobs for each
| > AF.
| > |      Here, by AF I understand IPV4 or IPv6.
| > |
| > |
| > |
| > |      When both IPV4 and IPV6 are part of the same IGP topology, there is
| > only
| > |      one set of backup computations needed to protect both IPV4 and IPv6
| > |      traffic.
| > |
| > |
| > |
| > |      Also I cannot think of any motivation for an operator to turn on
| > |      protection on only one AF and does not want to turn on for the other
| > |      even if both AFs has been deployed for normal forwarding.
| > |
| > |
| > |
| > |      [Les:] I think your point here is that the LFA calculation is AF
| > |      independent within a given topology – but resources are consumed
| > |      independent of how many computations are required- giving an
| > operator
| > |      the ability to determine which prefixes are most critical seems useful.
| > |      That could be per AF or per prefix.
| > |
| > |
| > |
| > |         Les
| > |
| > |
| > |
| > |      Thanks
| > |
| > |      -Pushpasis
| > |
| > |
| > |
| > |      From: Jeff Tantsura <[14][email-masked]>
| > |      Date: Friday, February 20, 2015 at 12:59 PM
| > |      To: "[15][email-masked]"
| > |      <[16][email-masked]>, "[17][email-masked]"
| > |      <[18][email-masked]>
| > |      Subject: Re: LFA manageability : per AF config => feedback required
| > |
| > |
| > |
| > |      Hi Stephane,
| > |
| > |
| > |
| > |      /chair hat off
| > |
| > |
| > |
| > |      IMO in disjoined topologies one should have flexibility to
| > |      enable/disable LFA as per AF.
| > |
| > |
| > |
| > |
| > |
| > |      Cheers,
| > |
| > |      Jeff
| > |
| > |
| > |
| > |      From: "[19][email-masked]"
| > |      <[20][email-masked]>
| > |      Date: Thursday, February 19, 2015 at 11:21 PM
| > |      To: "[21][email-masked]" <[22][email-masked]>
| > |      Subject: LFA manageability : per AF config => feedback required
| > |
| > |
| > |
| > |        Hi Folks,
| > |
| > |
| > |
| > |        As you know, LFA manageability draft is in final phasis
| > |
| > |        The current document states per AF granularity activation as a SHOULD.
| > |
| > |        “
| > |
| > |   [23]5.1.  LFA enabling/disabling scope
| > |
| > |
| > |
| > |
| > |
| > |     The granularity of LFA activation should be controlled (as alternate
| > |
| > |     nexthop consume memory in forwarding plane).
| > |
| > |
| > |
| > |     An implementation of LFA SHOULD allow its activation with the
| > |
| > |     following criteria:
| > |
| > |
| > |
| > |     o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
| > |
| > |        LDP IPv6 unicast ...
| > |
| > |
| > |
| > |     o  Per routing context : VRF, virtual/logical router, global routing
| > |
| > |        table, ...
| > |
| > |
| > |
| > |        “
| > |
| > |
| > |
| > |        In the framework of ISIS/OSPF yang modelization, we are challenging
| > |        this statement, do we really need to force implementation to support
| > |        this “per AF” granularity ?
| > |
| > |
| > |
| > |        Please provide as soon as possible your feedback on this and also
| > |        provide clear drivers to support or not per AF activation of LFA.
| > |
| > |
| > |
| > |
| > |
| > |        Thanks for your help !
| > |
| > |
| > |
| > |
| > |
| > |        [24]Orange logo
| > |
| > |
| > |
| > |        Stephane Litkowski
| > |        Network Architect
| > |        Orange/SCE/EQUANT/IBNF/ENDD/NDE
| > |
| > |        Orange Expert Future Networks
| > |
| > |        phone: [25]+33 2 23 28 49 83
| > |        mobile: [26]+33 6 37 86 97 52
| > |        [27][email-masked]
| > |
| > |
| > |
| > |
| > |
| > |
| > __________________________________________________________
| > __________________________________________________________
| > _____
| > |
| > |
| > |
| > |  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.
| > |
| > | References
| > |
| > |    Visible links
| > |    1. mailto:[email-masked]
| > |    2. mailto:[email-masked]
| > |    3. mailto:[email-masked]
| > |    4. mailto:[email-masked]
| > |    5. mailto:[email-masked]
| > |    6. mailto:[email-masked]
| > |    7. mailto:[email-masked]
| > |    8. mailto:[email-masked]
| > |    9. mailto:[email-masked]
| > |   10. mailto:[email-masked]
| > |   11. mailto:[email-masked]
| > |   12. mailto:[email-masked]
| > |   13. mailto:[email-masked]
| > |   14. mailto:[email-masked]
| > |   15. mailto:[email-masked]
| > |   16. mailto:[email-masked]
| > |   17. mailto:[email-masked]
| > |   18. mailto:[email-masked]
| > |   19. mailto:[email-masked]
| > |   20. mailto:[email-masked]
| > |   21. mailto:[email-masked]
| > |   22. mailto:[email-masked]
| > |   23. https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-
| > 07#section-5.1
| > |   24. http://www.orange.com/
| > |   25.
| > https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvo
| > ice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault
| > %26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083
| > %20
| > |   26.
| > https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvo
| > ice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault
| > %26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052
| > %20
| > |   27. mailto:[email-masked]
| > 
| > 
| > | _______________________________________________
| > | rtgwg mailing list
| > | [email-masked]
| > | https://www.ietf.org/mailman/listinfo/rtgwg
|

---

From: Martin Horneffer <[email-masked]>
Date: Tue, 24 Feb 2015 17:54:44 +0100

Hello everyone,

I really do see a good use-case for turning on IP-FRR protection for 
just one address family, and it does not have anything to do with making 
IPv6 customer better or worse than IPv4 customer traffic.

Consider the IP/MPLS network I have today. Several address families are 
active in the backbone, but all customer traffic is carried in MPLS 
packets guided by IPv4-signalled LDP. This holds for ANY customer 
traffic, whether it is public IPv4, public IPv6, VPNs in IPv4 or IPv6 or 
L2-VPNs. Unlabeled IPv4 traffic also exists in the same backbone, but 
only for routing protocols themselves, and/or network management. Thus 
there is no need to protect this unlabeled IPv4 traffic in the same way 
as the customer MPLS traffic.

In the future, I might activate IPv6 in the backbone and introduce more 
and more routing and management protocols with IPv6. Still no need to 
protect IPv6. Eventually I might shift LDP (or SR) from IPv4 controlled 
to IPv6 controlled. What was IPv6-over-IPv4-controlled-MPLS becomes 
plain IPv6-labeled traffic then, and IPv4-labeled traffic will become 
IPv4-over-IPv6-controlled-MPLS. At THAT point in time it becomes 
important to protect the IPv6 controlled MPLS traffic, and thus the IPv6 
address family in the IGP, but no earlier.

So please do not mix up control traffic and customer traffic, internal 
routing and customer routes. Thank you.

Best regards, Martin

> |      [19][email-masked]

##############################################

# Mail Account for technical purposes only

##############################################

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Feb 2015 18:29:54 +0100

martin,

can you describe what are the pain points of FRR protecting
*all* your traffic (IPv4/IPv6/labeled/unlabeled) ?

why would you want your traffic not being protected ?

/hannes

On Tue, Feb 24, 2015 at 05:54:44PM +0100, Martin Horneffer wrote:
| Hello everyone,
| 
| I really do see a good use-case for turning on IP-FRR protection for just
| one address family, and it does not have anything to do with making IPv6
| customer better or worse than IPv4 customer traffic.
| 
| Consider the IP/MPLS network I have today. Several address families are
| active in the backbone, but all customer traffic is carried in MPLS packets
| guided by IPv4-signalled LDP. This holds for ANY customer traffic, whether
| it is public IPv4, public IPv6, VPNs in IPv4 or IPv6 or L2-VPNs. Unlabeled
| IPv4 traffic also exists in the same backbone, but only for routing
| protocols themselves, and/or network management. Thus there is no need to
| protect this unlabeled IPv4 traffic in the same way as the customer MPLS
| traffic.
| 
| In the future, I might activate IPv6 in the backbone and introduce more and
| more routing and management protocols with IPv6. Still no need to protect
| IPv6. Eventually I might shift LDP (or SR) from IPv4 controlled to IPv6
| controlled. What was IPv6-over-IPv4-controlled-MPLS becomes plain
| IPv6-labeled traffic then, and IPv4-labeled traffic will become
| IPv4-over-IPv6-controlled-MPLS. At THAT point in time it becomes important
| to protect the IPv6 controlled MPLS traffic, and thus the IPv6 address
| family in the IGP, but no earlier.
| 
| So please do not mix up control traffic and customer traffic, internal
| routing and customer routes. Thank you.
| 
| Best regards, Martin
| 
| 
| Am 24.02.15 um 16:02 schrieb Hannes Gredler:
| >On Mon, Feb 23, 2015 at 03:55:32PM +0000, Les Ginsberg (ginsberg) wrote:
| >|    I can imagine cases in which the per AF enabling might make sense (e.g.
| >|    when the network associated w one address family is deemed non-critical).
| >
| >
| >HG> as it is unlikely that operators will tun off IPv4 protection,
| >     may i have a ask that you repeat that quote above in the 6man
| >     meeting ;-) ? - effectifely you're saying "IPv6 may be considered
| >     as less critical", and therefore we SHOULD provide a knob
| >     to turn protection off.
| >
| >|
| >|
| >|    Section 5.1 is a SHOULD - as is most of the document. It is therefore a
| >|    suggestion as to what an implementation should provide. If a given
| >|    implementer thinks this is either too onerous or not useful they can omit
| >|    it w/o being in violation. But I see no reason to eliminate this - and in
| >|    actual practice I would expect the cost of supporting such a knob to be
| >|    low cost. It is hard for me to see this as controversial.
| >|
| >|
| >|
| >|       Les
| >|
| >|
| >|
| >|
| >|
| >|    From: [email-masked] [mailto:[email-masked]]
| >|    Sent: Sunday, February 22, 2015 11:10 PM
| >|    To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Jeff Tantsura;
| >|    [email-masked]
| >|    Subject: RE: LFA manageability : per AF config => feedback required
| >|
| >|
| >|
| >|    [Les:] I think your point here is that the LFA calculation is AF
| >|    independent within a given topology - but resources are consumed
| >|    independent of how many computations are required- giving an operator the
| >|    ability to determine which prefixes are most critical seems useful. That
| >|    could be per AF or per prefix.
| >|
| >|
| >|
| >|    [SLI] Agree but is the "resource saving" point strong enough to mandate
| >|    per AF activation ?
| >|
| >|
| >|
| >|    From: Les Ginsberg (ginsberg) [[1]mailto:[email-masked]]
| >|    Sent: Monday, February 23, 2015 05:01
| >|    To: Pushpasis Sarkar; Jeff Tantsura; LITKOWSKI Stephane SCE/IBNF;
| >|    [2][email-masked]
| >|    Subject: RE: LFA manageability : per AF config => feedback required
| >|
| >|
| >|
| >|    Pushpassis -
| >|
| >|
| >|
| >|    From: rtgwg [[3]mailto:[email-masked]] On Behalf Of Pushpasis
| >|    Sarkar
| >|    Sent: Friday, February 20, 2015 3:28 AM
| >|    To: Jeff Tantsura; [4][email-masked]; [5][email-masked]
| >|    Subject: Re: LFA manageability : per AF config => feedback required
| >|
| >|
| >|
| >|    HI Jeff et al,
| >|
| >|
| >|
| >|    I can think of a reason to have a knob per-level(or per-area) or per ISIS
| >|    topology(note in ISIS a topology in ISIS always corresponds to a single
| >|    AF,)
| >|
| >|
| >|
| >|    [Les:] This is a common mistake to make. If one simply uses RFC 5308, then
| >|    IPv6 prefixes can be advertised in the same topology as IPv4 (MTID #0) -
| >|    and there are implementations which support this. More generally, from the
| >|    protocol's POV a given topology can support any combinations of address
| >|    families. It is only a convention because of the reserved MTIDs specified
| >|    in RFC 5120 that certain MTIDs are "IPv6 only". But if one looks at the
| >|    protocol capabilities such a restriction does not exist in general.
| >|
| >|
| >|
| >|    Interestingly you contradicted yourself below. J
| >|
| >|    But I did want to set the record straight on this point - hopefully we are
| >|    in agreement.
| >|
| >|
| >|
| >|    and per realm and topology in OSPF. But I cannot think of a reason of why
| >|    within the same topology we need another set of knobs for each AF. Here,
| >|    by AF I understand IPV4 or IPv6.
| >|
| >|
| >|
| >|    When both IPV4 and IPV6 are part of the same IGP topology, there is only
| >|    one set of backup computations needed to protect both IPV4 and IPv6
| >|    traffic.
| >|
| >|
| >|
| >|    Also I cannot think of any motivation for an operator to turn on
| >|    protection on only one AF and does not want to turn on for the other even
| >|    if both AFs has been deployed for normal forwarding.
| >|
| >|
| >|
| >|    [Les:] I think your point here is that the LFA calculation is AF
| >|    independent within a given topology - but resources are consumed
| >|    independent of how many computations are required- giving an operator the
| >|    ability to determine which prefixes are most critical seems useful. That
| >|    could be per AF or per prefix.
| >|
| >|
| >|
| >|       Les
| >|
| >|
| >|
| >|    Thanks
| >|
| >|    -Pushpasis
| >|
| >|
| >|
| >|    From: Jeff Tantsura <[6][email-masked]>
| >|    Date: Friday, February 20, 2015 at 12:59 PM
| >|    To: "[7][email-masked]" <[8][email-masked]>,
| >|    "[9][email-masked]" <[10][email-masked]>
| >|    Subject: Re: LFA manageability : per AF config => feedback required
| >|
| >|
| >|
| >|    Hi Stephane,
| >|
| >|
| >|
| >|    /chair hat off
| >|
| >|
| >|
| >|    IMO in disjoined topologies one should have flexibility to enable/disable
| >|    LFA as per AF.
| >|
| >|
| >|
| >|
| >|
| >|    Cheers,
| >|
| >|    Jeff
| >|
| >|
| >|
| >|    From: "[11][email-masked]"
| >|    <[12][email-masked]>
| >|    Date: Thursday, February 19, 2015 at 11:21 PM
| >|    To: "[13][email-masked]" <[14][email-masked]>
| >|    Subject: LFA manageability : per AF config => feedback required
| >|
| >|
| >|
| >|      Hi Folks,
| >|
| >|
| >|
| >|      As you know, LFA manageability draft is in final phasis ...
| >|
| >|      The current document states per AF granularity activation as a SHOULD.
| >|
| >|      "
| >|
| >|   [15]5.1.  LFA enabling/disabling scope
| >|
| >|
| >|
| >|
| >|
| >|     The granularity of LFA activation should be controlled (as alternate
| >|
| >|     nexthop consume memory in forwarding plane).
| >|
| >|
| >|
| >|     An implementation of LFA SHOULD allow its activation with the
| >|
| >|     following criteria:
| >|
| >|
| >|
| >|     o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
| >|
| >|        LDP IPv6 unicast ...
| >|
| >|
| >|
| >|     o  Per routing context : VRF, virtual/logical router, global routing
| >|
| >|        table, ...
| >|
| >|
| >|
| >|      "
| >|
| >|
| >|
| >|      In the framework of ISIS/OSPF yang modelization, we are challenging this
| >|      statement, do we really need to force implementation to support this
| >|      "per AF" granularity ?
| >|
| >|
| >|
| >|      Please provide as soon as possible your feedback on this and also
| >|      provide clear drivers to support or not per AF activation of LFA.
| >|
| >|
| >|
| >|
| >|
| >|      Thanks for your help !
| >|
| >|
| >|
| >|
| >|
| >|      [16]Orange logo
| >|
| >|
| >|
| >|      Stephane Litkowski
| >|      Network Architect
| >|      Orange/SCE/EQUANT/IBNF/ENDD/NDE
| >|
| >|      Orange Expert Future Networks
| >|
| >|      phone: [17]+33 2 23 28 49 83
| >|      mobile: [18]+33 6 37 86 97 52
| >|      [19][email-masked]
| >|
| >|
| >|
| >|
| >|
| >|  _________________________________________________________________________________________________________________________
| >|
| >|
| >|
| >|  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.
| >|
| >| References
| >|
| >|    Visible links
| >|    1. mailto:[email-masked]
| >|    2. mailto:[email-masked]
| >|    3. mailto:[email-masked]
| >|    4. mailto:[email-masked]
| >|    5. mailto:[email-masked]
| >|    6. mailto:[email-masked]
| >|    7. mailto:[email-masked]
| >|    8. mailto:[email-masked]
| >|    9. mailto:[email-masked]
| >|   10. mailto:[email-masked]
| >|   11. mailto:[email-masked]
| >|   12. mailto:[email-masked]
| >|   13. mailto:[email-masked]
| >|   14. mailto:[email-masked]
| >|   15. https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section-5.1
| >|   16. http://www.orange.com/
| >|   17. https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
| >|   18. https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
| >|   19. mailto:[email-masked]
| >
| >
| >
| >| _______________________________________________
| >| rtgwg mailing list
| >| [email-masked]
| >| https://www.ietf.org/mailman/listinfo/rtgwg
| >
| >_______________________________________________
| >rtgwg mailing list
| >[email-masked]
| >https://www.ietf.org/mailman/listinfo/rtgwg
| 
| ##############################################
| 
| # Mail Account for technical purposes only
| 
| ##############################################
| 
| _______________________________________________
| rtgwg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/rtgwg