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

From: <[email-masked]>
Date: Thu, 5 Mar 2015 07:36:27 +0000

Hi,

I updated the draft section in this way, I used MAY for per AF and per MPLS control plane. I think "MAY" is better as it may fit everyone's point of view (it's not strong and permit optional support).
Let me know your thoughts asap please. I would like to post the draft before cut off.

   An implementation of LFA SHOULD allow its activation with the
   following criteria:

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

   o  Per interface

   o  Per protocol instance, topology, area

   o  Per prefixes: prefix protection SHOULD have a better priority
      compared to interface protection.  This means that if a specific
      prefix must be protected due to a configuration request, LFA must
      be computed and installed for this prefix even if the primary
      outgoing interface is not configured for protection.

   An implementation of LFA MAY allow its activation with the following
   criteria:

   o  Per address-family: ipv4 unicast, ipv6 unicast

   o  Per MPLS control plane: for MPLS control planes that inherit
      routing decision from the IGP routing protocol, MPLS dataplane may
      be protected by LFA.  The implementation may allow operator to
      control this inheritance of protection from the IP prefix to the
      MPLS label bound to this prefix.  The protection inheritance will
      concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries.  As
      example, LDP and segment-routing extensions for ISIS and OSPF are
      control plane eligible to this inheritance of protection.

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of Hannes Gredler
Sent: Tuesday, February 24, 2015 18:30
To: Martin Horneffer
Cc: [email-masked]
Subject: Re: LFA manageability : per AF config => feedback required

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

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

_________________________________________________________________________________________________________________________

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: Hannes Gredler <[email-masked]>
Date: Thu, 5 Mar 2015 08:48:22 +0100

looks good to me thanks !

On Thu, Mar 05, 2015 at 07:36:27AM +0000, [email-masked] wrote:
| Hi,
| 
| I updated the draft section in this way, I used MAY for per AF and per MPLS control plane. I think "MAY" is better as it may fit everyone's point of view (it's not strong and permit optional support).
| Let me know your thoughts asap please. I would like to post the draft before cut off.
| 
| 
|    An implementation of LFA SHOULD allow its activation with the
|    following criteria:
| 
|    o  Per routing context: VRF, virtual/logical router, global routing
|       table, ...
| 
|    o  Per interface
| 
|    o  Per protocol instance, topology, area
| 
|    o  Per prefixes: prefix protection SHOULD have a better priority
|       compared to interface protection.  This means that if a specific
|       prefix must be protected due to a configuration request, LFA must
|       be computed and installed for this prefix even if the primary
|       outgoing interface is not configured for protection.
| 
|    An implementation of LFA MAY allow its activation with the following
|    criteria:
| 
|    o  Per address-family: ipv4 unicast, ipv6 unicast
| 
|    o  Per MPLS control plane: for MPLS control planes that inherit
|       routing decision from the IGP routing protocol, MPLS dataplane may
|       be protected by LFA.  The implementation may allow operator to
|       control this inheritance of protection from the IP prefix to the
|       MPLS label bound to this prefix.  The protection inheritance will
|       concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries.  As
|       example, LDP and segment-routing extensions for ISIS and OSPF are
|       control plane eligible to this inheritance of protection.
| 
| -----Original Message-----
| From: rtgwg [mailto:[email-masked]] On Behalf Of Hannes Gredler
| Sent: Tuesday, February 24, 2015 18:30
| To: Martin Horneffer
| Cc: [email-masked]
| Subject: Re: LFA manageability : per AF config => feedback required
| 
| 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
| 
| _______________________________________________
| rtgwg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/rtgwg
| 
| _________________________________________________________________________________________________________________________
| 
| 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: Thu, 5 Mar 2015 08:07:51 +0000

Hi Stephane,

Looks good.
How do you plan to express this in YANG model you have been working on?

Thanks!

Regards,
Jeff

> On Mar 5, 2015, at 8:36 AM, "[email-masked]" <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 5 Mar 2015 14:36:29 +0000

I¹m not sure why allowing the flexibility of per-AF configuration for the
ISIS dual-stack case has become such a lighting rod for contention.
However, you reminded me that I need to respond with a use case.
Acee 

On 3/5/15, 3:07 AM, "Jeff Tantsura" <[email-masked]> wrote:

>> I updated the draft section in this way, I used MAY for per AF and per
>>MPLS control plane. I think "MAY" is better as it may fit everyone's
>>point of view (it's not strong and permit optional support).
>> | >|  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.
>> | >|
>> | >|  
>> | >|  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
>> | >|   15. 
>>https://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-07#section
>>-5.1
>> | >|   17. 
>>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoic
>>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro
>>otservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
>> | >|   18. 
>>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoic
>>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro
>>otservice%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,
>> This message and its attachments may contain confidential or privileged
>>information that may be protected by law;

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 5 Mar 2015 14:39:00 +0000

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

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

One use case would be is that you are using IPv6 for business critical
services that require IP FRR protection. IPv4 is being used for in-band
network management and no protection is necessary.

Thanks,
Acee 

>
>/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]>
>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]]
>| >|      [8][email-masked]
>required
>| >|      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]]
>| >|      [10][email-masked]
>required
>| >|      From: rtgwg [[11]mailto:[email-masked]] On Behalf Of
>| >Pushpasis
>| >|      Sarkar
>| >|      To: Jeff Tantsura; [12][email-masked];
>| >[13][email-masked]
>required
>| >|      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.
>| >| 
>| >| 
>| >| 
>| >|      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
>| >|      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.
>| >| 
>| >| 
>| >| 
>| >|      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]>
>| >|      To: "[15][email-masked]"
>| >|      <[16][email-masked]>, "[17][email-masked]"
>| >|      <[18][email-masked]>
>required
>| >|      IMO in disjoined topologies one should have flexibility to
>| >|      enable/disable LFA as per AF.
>| >| 
>| >| 
>| >| 
>| >| 
>| >| 
>| >|      Cheers,
>| >| 
>| >|      Jeff
>| >| 
>| >| 
>| >| 
>| >|      From: "[19][email-masked]"
>| >|      <[20][email-masked]>
>| >|      To: "[21][email-masked]" <[22][email-masked]>
>| >|        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
>| >| 
>| >| 
>| >| 
>| >| 
>| >| 
>alternate
>| >unicast,
>routing
>| >|        ³
>| >|        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 ?
>| >| 
>| >| 
>| >| 
>| >|        [24]Orange logo
>| >|        phone: [25]+33 2 23 28 49 83
>| >|        mobile: [26]+33 6 37 86 97 52
>| >|        [27][email-masked]
>| >| 
>| >| 
>| >| 
>| >| 
>| >| 
>| >|  
>| 
>>_
>| >confidentielles ou privilegiees et ne doivent donc
>| >| 
>avez
>| >recu ce message par erreur, veuillez le signaler
>| >| 
>| >messages electroniques etant susceptibles d'alteration,
>| >| 
>| >|  Orange decline toute responsabilite si ce message a ete altere,
>| >deforme ou falsifie. Merci.
>| >| 
>| >| 
>| >| 
>| >privileged information that may be protected by law;
>| >| 
>| >|  If you have received this email in error, please notify the sender
>and
>| >delete this message and its attachments.
>| >| 
>have
>| >been modified, changed or falsified.
>| >| 
>| >|  Thank you.
>| >| 
>| >|  
>| 
>>_
>| >confidentielles ou privilegiees et ne doivent donc
>| >| 
>avez
>| >recu ce message par erreur, veuillez le signaler
>| >| 
>| >messages electroniques etant susceptibles d'alteration,
>| >| 
>| >|  Orange decline toute responsabilite si ce message a ete altere,
>| >deforme ou falsifie. Merci.
>| >| 
>| >| 
>| >| 
>| >privileged information that may be protected by law;
>| >| 
>| >|  If you have received this email in error, please notify the sender
>and
>| >delete this message and its attachments.
>| >| 
>have
>| >been modified, changed or falsified.
>| >| 
>| >|  Thank you.
>| >| 
>| >| References
>| >| 
>| >|    Visible links
>| >|    2. mailto:[email-masked]
>| >|    3. mailto:[email-masked]
>| >|    4. mailto:[email-masked]
>| >|    6. mailto:[email-masked]
>| >|    8. mailto:[email-masked]
>| >|    9. mailto:[email-masked]
>| >|   11. mailto:[email-masked]
>| >|   14. mailto:[email-masked]
>| >|   15. mailto:[email-masked]
>| >|   16. mailto:[email-masked]
>| >|   17. mailto:[email-masked]
>| >|   18. mailto:[email-masked]
>| >|   20. mailto:[email-masked]
>| >|   21. mailto:[email-masked]
>| >|   22. mailto:[email-masked]
>| >|   23. 
>| 
>>-
>| >5.1
>| >|   24. http://www.orange.com/
>| >|   25. 
>| 
>>e
>>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26roo
>>t
>| >service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
>| >|   26. 
>| 
>>e
>>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26roo
>>t
>| >service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20
>| >|   27. mailto:[email-masked]
>| >
>| >

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Mar 2015 15:51:13 +0100

On Thu, Mar 05, 2015 at 02:39:00PM +0000, Acee Lindem (acee) wrote:
| 
| 
| On 2/24/15, 11:00 AM, "Hannes Gredler" <[email-masked]> wrote:
| 
| >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 ?
| 
| One use case would be is that you are using IPv6 for business critical
| services that require IP FRR protection. IPv4 is being used for in-band
| network management and no protection is necessary.

again, arguing about the "usefulness" "not necessary". - what practical harm does it do ?

| >| 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%2Fclicvoic
| >>e
| >| 
| >>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26roo
| >>t
| >| >service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20
| >| >|   26. 
| >| 
| >>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoic
| >>e
| >| 
| >>.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26roo
| >>t
| >| >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: Martin Horneffer <[email-masked]>
Date: Thu, 05 Mar 2015 17:23:00 +0100

Hello Hannes,

sorry for the late response, the flu kept me offline for quite a while.

But sure I can describe my feelings about this. (Pain is about feelings, 
isn't it?)

Basically I have learnt during the last decade, that the IGP is better 
kept clean and neat. This is particularly valid for large networks with 
many different services and strict requirements in terms of availabiliy. 
Especially when it comes to forwarding ressources, it's better to 
consume as little ressources as neccessary, so that the those forwarding 
entries that really matter perform best.

One example ist fast IGP convergence: The less FIB entries you have, the 
faster the FIB download works and the faster the IGP convergence is.

Another one ist ECMP vs. IP-FRR. One of our vendors implemented IP-FRR 
in a way that consumes certain ressources that are also used for ECMP. 
Some time after we activated LFA in a certain part of our network, 
operations came back to me saying that now one of 16 available ECMP 
paths was suddenly empty. It turned out that LFA took away one ECMP slot 
and noone had warned me before.

Of course, I don't know how your exact implementation of LFA for IPv6 in 
ISIS will behave and whether any of the ressources it consumes would 
actually be critical in my network.

But all in all I'd consider it best to design a network with as little 
consumption of forwardings ressources as possible. And if one address 
family in my IGP would only be used for iBGP, SNMP and ssh, why should I 
protect it with LFA?

Best regards, Martin

Am 24.02.15 um 18:29 schrieb Hannes Gredler:
> | 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
> | 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.
> |
> | >|    Subject: RE: LFA manageability : per AF config => feedback required
> | >|
> | >|
> | >|
> | >|    Subject: RE: LFA manageability : per AF config => feedback required
> | >|
> | >|
> | >|
> | >|    Pushpassis -
> | >|
> | >|
> | >|
> | >|    Subject: Re: LFA manageability : per AF config => feedback required
> | >|
> | >|
> | >|
> | >|    HI Jeff et al,
> | >|
> | >|
> | >|
> | >|    Subject: Re: LFA manageability : per AF config => feedback required
> | >|
> | >|
> | >|
> | >|    Hi Stephane,
> | >|
> | >|
> | >|
> | >|    /chair hat off
> | >|
> | >|
> | >|
> | >|     The granularity of LFA activation should be controlled (as alternate
> | >|
> | >|     o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
> | >|
> | >|     o  Per routing context : VRF, virtual/logical router, global routing
> | >|
> | >|        table, ...
> | >|
> | >|
> | >|
> | >|      "
> | >|
> | >|
> | >|
> | >|  _________________________________________________________________________________________________________________________
> | >|
> | >|
> | >|
> | >|  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;
> | >|

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

# Mail Account for technical purposes only

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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 6 Mar 2015 03:28:20 +0000

Hi Martin,

I totally agree with the intentions I get from your reply here. I
absolutely 
support your idea of consuming as less forwarding resource as possible.
But 
I also think the intentions will not be met with this kind of Œper AF¹
knob, 
simply because we won¹t save any forwarding resources (or even CPU
resources)
if we deploy both AFs under single topology but enable protection for only
one.
So essentially the knob is kind of NO-OP other than not providing
protection 
for one of the AF.

Thanks
-Pushpasis

On 3/5/15, 9:53 PM, "Martin Horneffer" <[email-masked]> wrote:

>>just
>>are
>>more and
>>sense (e.g.
>>non-critical).
>>operator the
>>5308, then
>>reason of why
>>other even
>>operator the
>>enable/disable
>>unicast,
>>challenging this
>> | >|  Ce message et ses pieces jointes peuvent contenir des
>>informations confidentielles ou privilegiees et ne doivent donc
>> | >|
>>avez recu ce message par erreur, veuillez le signaler
>> | >|
>>deforme ou falsifie. Merci.
>> | >|
>> | >|
>> | >|
>>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
>> | >|
>>avez recu ce message par erreur, veuillez le signaler
>> | >|
>>deforme ou falsifie. Merci.
>> | >|
>> | >|
>> | >|
>>privileged information that may be protected by law;
>> | >|

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 06 Mar 2015 10:07:06 +0100

Hi Pushpasis,

ok, you know at least one implementation better than I know any. If this 
is truely a no-op in your implementation, the you have a point here.

Can we get confirmation or a different view from other core router 
vendors as well?

Best regards, Martin

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 9 Mar 2015 03:56:02 +0000

draft-ietf-rtgwg-lfa-manageability-07 said "SHOULD" regarding supporting per AF enablement.

draft-ietf-rtgwg-lfa-manageability-08 has changed that to a MAY.

In either case an implementation is NOT required to implement this support, so Pushpasis/Hannes - if you don’t want to implement this - then don't.

I have zero interest in trying to convince everyone that  they MUST implement per AF enablement. My only interest is in making sure that it is not forbidden - and since the draft specifically allows this I am satisfied.
Let's move on please.

   Les

> From: rtgwg [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
> Sent: Thursday, March 05, 2015 7:28 PM
> To: Martin Horneffer; Hannes Gredler
> Cc: [email-masked]
> I totally agree with the intentions I get from your reply here. I absolutely
> I also think the intentions will not be met with this kind of Œper AF¹ knob,
> So essentially the knob is kind of NO-OP other than not providing protection
> for one of the AF.
> 
> Thanks
> -Pushpasis
> 
> >But sure I can describe my feelings about this. (Pain is about
> >feelings, isn't it?)
> >
> >
> >consume as little ressources as neccessary, so that the those
> >forwarding entries that really matter perform best.
> >
> >One example ist fast IGP convergence: The less FIB entries you have,
> >the faster the FIB download works and the faster the IGP convergence is.
> >
> >paths was suddenly empty. It turned out that LFA took away one ECMP
> >slot and noone had warned me before.
> >
> >
> >Of course, I don't know how your exact implementation of LFA for IPv6
> >in ISIS will behave and whether any of the ressources it consumes would
> >family in my IGP would only be used for iBGP, SNMP and ssh, why should
> >I protect it with LFA?
> >
> >
> >Best regards, Martin
> >
> >
> >> | I really do see a good use-case for turning on IP-FRR protection
> >> | for
> >>just
> >> | 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
> >> |
> >> |
> >> | >|    [SLI] Agree but is the "resource saving" point strong enough
> >> | >| to
> >>mandate
> >> | >|    per AF activation ?
> >> | >|
> >> | >|
> >> | >|
> >> | >|    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
> >> | >|    protocol's POV a given topology can support any combinations
> >> | >| of
> >>address
> >> | >|    families. It is only a convention because of the reserved
> >> | >| MTIDs
> >>specified
> >> | >|    within the same topology we need another set of knobs for
> >> | >| each
> >>AF. Here,
> >> | >|    one set of backup computations needed to protect both IPV4
> >> | >| and
> >>IPv6
> >> | >|    traffic.
> >> | >|
> >> | >|
> >> | >|
> >> | >|    protection on only one AF and does not want to turn on for
> >> | >| the
> >>other even
> >> | >|    Subject: LFA manageability : per AF config => feedback
> >> | >| required
> >> | >|
> >> | >|
> >> | >|
> >> | >|      Hi Folks,
> >> | >|
> >> | >|
> >> | >|
> >> | >|      The current document states per AF granularity activation
> >> | >| as
> >>a SHOULD.
> >> | >|
> >> | >|      "
> >> | >|
> >> | >|     An implementation of LFA SHOULD allow its activation with
> >> | >| the
> >> | >|
> >> | >|     following criteria:
> >> | >|
> >> | >|
> >> | >|
> >> | >|      Please provide as soon as possible your feedback on this
> >> | >| and
> >>also
> >> | >|      provide clear drivers to support or not per AF activation
> >> | >| of
> >>LFA.
> >> | >|
> >> | >|
> >> | >|
> >> | >|
> >> | >|
> >>________________________________________________________
> ______________
> >>___ ________________________________________________
> >> | >|
> >> | >|
> >> | >|
> >> | >|  pas etre diffuses, exploites ou copies sans autorisation. Si
> >> | >| vous
> >> | >|  As emails may be altered, Orange is not liable for messages
> >> | >| that
> >>________________________________________________________
> ______________
> >>___ ________________________________________________
> >> | >|
> >> | >|
> >> | >|
> >> | >|  pas etre diffuses, exploites ou copies sans autorisation. Si
> >> | >| vous
> >> | >|  As emails may be altered, Orange is not liable for messages
> >> | >| that
> >>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic
> v
> >>oic
> >>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefaul
> t%2
> >>6ro
> >>https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic
> v
> >>oic
> >>e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefaul
> t%2
> >>6ro

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 9 Mar 2015 04:14:23 +0000

Hannes - wrt your review - are you happy with the changes, have the authors addressed your comments? 

Thanks!

Regards,
Jeff

> On Mar 8, 2015, at 8:56 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 9 Mar 2015 06:16:07 +0000

Hi Les,

Likewise our interest is.. As long it is NOT made Mandatory we are fine.
So we are okay here.. I was just clarifying to few things for Martin..

See you in Dallas :)

Thanks and Regards,
-Pushpasis

On 3/9/15, 9:26 AM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>In either case an implementation is NOT required to implement this
>support, so Pushpasis/Hannes - if you don’t want to implement this - then
>don't.
>
>I have zero interest in trying to convince everyone that  they MUST
>implement per AF enablement. My only interest is in making sure that it
>is not forbidden - and since the draft specifically allows this I am
>satisfied.
>Let's move on please.
>
>   Les
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 9 Mar 2015 06:20:37 +0000

So everyone agrees and vocabulary is clear - one MAY implement it per AF,
please speak up if there’s still unclarity.

Thanks!

Cheers,
Jeff

-----Original Message-----
From: Pushpasis Sarkar <[email-masked]>
Date: Sunday, March 8, 2015 at 10:16 PM
To: "Les Ginsberg (ginsberg)" <[email-masked]>, Martin Horneffer
<[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: LFA manageability : per AF config => feedback required

>>> >> | one address family, and it does not have anything to do with
>>>making
>>> >>IPv6
>>> >> | active in the backbone, but all customer traffic is carried in
>>>MPLS
>>> >>packets
>>> >> | protect this unlabeled IPv4 traffic in the same way as the
>>>customer
>>> >>MPLS
>>> >> | traffic.
>>> >> |
>>> >> | >|    I can think of a reason to have a knob per-level(or
>>>per-area)
>>> >>or per ISIS

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Mar 2015 08:46:52 +0100

hi jeff,

-08 is sane from my POV.
thanks to everybody involved for making the changes;

/hannes

On Mon, Mar 09, 2015 at 04:14:23AM +0000, Jeff Tantsura wrote:
| Hannes - wrt your review - are you happy with the changes, have the authors addressed your comments? 
| 
| Thanks!
| 
| Regards,
| Jeff
| 
| > On Mar 8, 2015, at 8:56 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
| > 
| > draft-ietf-rtgwg-lfa-manageability-07 said "SHOULD" regarding supporting per AF enablement.
| > 
| > draft-ietf-rtgwg-lfa-manageability-08 has changed that to a MAY.
| > 
| > In either case an implementation is NOT required to implement this support, so Pushpasis/Hannes - if you don’t want to implement this - then don't.
| > 
| > I have zero interest in trying to convince everyone that  they MUST implement per AF enablement. My only interest is in making sure that it is not forbidden - and since the draft specifically allows this I am satisfied.
| > Let's move on please.
| > 
| >   Les
| > 
| >> -----Original Message-----
| >> From: rtgwg [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
| >> Sent: Thursday, March 05, 2015 7:28 PM
| >> To: Martin Horneffer; Hannes Gredler
| >> Cc: [email-masked]
| >> Subject: Re: LFA manageability : per AF config => feedback required
| >> 
| >> Hi Martin,
| >> 
| >> I totally agree with the intentions I get from your reply here. I absolutely
| >> support your idea of consuming as less forwarding resource as possible.
| >> But
| >> I also think the intentions will not be met with this kind of Œper AF¹ knob,
| >> simply because we won¹t save any forwarding resources (or even CPU
| >> resources)
| >> if we deploy both AFs under single topology but enable protection for only
| >> one.
| >> So essentially the knob is kind of NO-OP other than not providing protection
| >> for one of the AF.
| >> 
| >> Thanks
| >> -Pushpasis
| >> 
| >>> On 3/5/15, 9:53 PM, "Martin Horneffer" <[email-masked]> wrote:
| >>> 
| >>> Hello Hannes,
| >>> 
| >>> sorry for the late response, the flu kept me offline for quite a while.
| >>> 
| >>> But sure I can describe my feelings about this. (Pain is about
| >>> feelings, isn't it?)
| >>> 
| >>> 
| >>> Basically I have learnt during the last decade, that the IGP is better
| >>> kept clean and neat. This is particularly valid for large networks with
| >>> many different services and strict requirements in terms of availabiliy.
| >>> Especially when it comes to forwarding ressources, it's better to
| >>> consume as little ressources as neccessary, so that the those
| >>> forwarding entries that really matter perform best.
| >>> 
| >>> One example ist fast IGP convergence: The less FIB entries you have,
| >>> the faster the FIB download works and the faster the IGP convergence is.
| >>> 
| >>> Another one ist ECMP vs. IP-FRR. One of our vendors implemented IP-FRR
| >>> in a way that consumes certain ressources that are also used for ECMP.
| >>> Some time after we activated LFA in a certain part of our network,
| >>> operations came back to me saying that now one of 16 available ECMP
| >>> paths was suddenly empty. It turned out that LFA took away one ECMP
| >>> slot and noone had warned me before.
| >>> 
| >>> 
| >>> Of course, I don't know how your exact implementation of LFA for IPv6
| >>> in ISIS will behave and whether any of the ressources it consumes would
| >>> actually be critical in my network.
| >>> 
| >>> But all in all I'd consider it best to design a network with as little
| >>> consumption of forwardings ressources as possible. And if one address
| >>> family in my IGP would only be used for iBGP, SNMP and ssh, why should
| >>> I protect it with LFA?
| >>> 
| >>> 
| >>> Best regards, Martin
| >>> 
| >>> 
| >>>> Am 24.02.15 um 18:29 schrieb Hannes Gredler:
| >>>> 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#sect
| >>>> ion
| >>>> -5.1
| >>>> | >|   16. http://www.orange.com/
| >>>> | >|   17.
| >>>> https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic
| >> v
| >>>> oic
| >>>> e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefaul
| >> t%2
| >>>> 6ro
| >>>> otservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%2
| >> 0
| >>>> | >|   18.
| >>>> https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclic
| >> v
| >>>> oic
| >>>> e.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefaul
| >> t%2
| >>>> 6ro
| >>>> otservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%2
| >> 0
| >>>> | >|   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
| >>> 
| >>> ##############################################
| >>> 
| >>> # Mail Account for technical purposes only
| >>> 
| >>> ##############################################
| >>> 
| >>> 
| >> 
| >> _______________________________________________
| >> rtgwg mailing list
| >> [email-masked]
| >> https://www.ietf.org/mailman/listinfo/rtgwg
| > 
| > _______________________________________________
| > rtgwg mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/rtgwg