Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

[Stewart Bryant]

On 08/10/2013 12:26, stephane.litkow...@orange.com wrote:

So if the nodes to not accept the TLDP they you have a number of
alternatives:

1) Take it on the chin (it is FRR not convergence)
2) Replace the nodes with nodes that do
3) Modify the nodes to accept the TLDP
4) Get all other nodes to advertise the capability and address
5) Test the candidate nodes as part of the selection process

Are there any other approaches?

[SLI] The good approach would be to use policies to automatically 
prune these PQs as operators know which PQ may not to be able to 
accept TLDP.

So (6) is to have a local list of unacceptable PQ nodes to be excluded 
from the calculation.

What algorithm do you suggest?

[SLI] Do you have nothing to propose ? I know that CISCO has a working 
rLFA implementation , so I think you already have something to propose ...

In case you don't, we could use the following approach :

-Short term : use a tie breaker like (ISIS speaking) :

oUse IP in TLV134

oIf not existing, use IP in TLV132 if there's only one entry

oIf multiple entries in TLV132, use highest or lowest /32 IP listed as 
TLV135

Note that there is some corner cases where such algo would not work, 
e.g. when external /32 are advertised in ISIS using redistribution, in 
TLV135 you don't have the information of internal or external route 
and you may choose an external one.

-Long term : define an IGP extension to mark prefix associated with 
TLDP listening.

The idea is that the reader of the draft need to be aware on how the 
TLDP address is chosen and so may be able to adjust his LDP configs to 
make it working correctly.

I think that we have been through here before, and as I recall we concluded
that RTGWG should specify the requirement for the advertisement and there
should be a draft in OSPF and ISIS specifying how that advertsizement would
happen. As I recall in ISIS the draft would be very short.

Stewart

*Stephane Litkowski*
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>

*De :*Stewart Bryant [mailto:stbry...@cisco.com]
*Envoyé :* mardi 8 octobre 2013 11:38
*À :* LITKOWSKI Stephane DTF/DERX
*Cc :* Alvaro Retana (aretana); 
draft-ietf-rtgwg-remote-...@tools.ietf.org; rogeriomariano; rtgwg@ietf.org
*Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

On 08/10/2013 08:06, stephane.litkow...@orange.com 
<mailto:stephane.litkow...@orange.com> wrote:

    Stewart,

    >There are clearly only two solutions to this, either permit TLDP on any 
likely LSR,
    protected with an ACL if you wish, and accept the cases that fail
    as being a minority concern, or two (and out of scope for this
    draft) get the LSRs to advertise TLDP willingness in the IGP.


    [SLI] Some nodes are not accepting any TLDP session  at all and
    you cannot configure them to do it ...

So if the nodes to not accept the TLDP they you have a number of
alternatives:

1) Take it on the chin (it is FRR not convergence)
2) Replace the nodes with nodes that do
3) Modify the nodes to accept the TLDP
4) Get all other nodes to advertise the capability and address
5) Test the candidate nodes as part of the selection process

Are there any other approaches?


>We can certainly discuss the issue, but I am reluctant to specify a 
heuristic in an IETF draft, because then it is a specification and not 
a heuristic.

[SLI] Ok, so just specify an algorithm to choose the IP address to use 
to establish the TLDP session. By doing nothing, you can fall into 
situations where you PLR is unable to establish a TLDP session because 
it's choosing the wrong IP address.

What algorithm do you suggest?

Stewart


Thanks,

*Stephane Litkowski*
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>

*De :*Stewart Bryant [mailto:stbry...@cisco.com]
*Envoyé :* lundi 7 octobre 2013 17:56
*À :* LITKOWSKI Stephane DTF/DERX
*Cc :* Alvaro Retana (aretana); 
draft-ietf-rtgwg-remote-...@tools.ietf.org 
<mailto:draft-ietf-rtgwg-remote-...@tools.ietf.org>; rogeriomariano; 
rtgwg@ietf.org <mailto:rtgwg@ietf.org>
*Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

On 07/10/2013 09:59, stephane.litkow...@orange.com 
<mailto:stephane.litkow...@orange.com> wrote:

    Hi Stewart,

    Here are some old comments you didn't provide on feedback on :

    "Regarding remote LFA draft, I would hope to see some points
    addressed in the draft before going to WGLC.

    - It would be good to add some simulation results about how much
    TLDP session are required (TX and TX+RX), this in order to make
    people aware on how much rLFA may impact their TLDP session scaling

That is a issue for Mike to consider.


- We already raised the point some months ago about possibly "interop" 
issues in the following cases :

    * PLR choose a PQ which is not able to accept TLDP session : we 
verified it in a lab, and we can clearly fall into such situation in a 
live network, leading to protection not available.

There are clearly only two solutions to this, either permit TLDP on 
any likely LSR, protected with an ACL if you wish, and accept the 
cases that fail as being a minority concern, or two (and out of scope 
for this draft) get the LSRs to advertise TLDP willingness in the IGP.


    * PQ having multiple IP addresses /32 attached, so which one would 
be used to establish TLDP session ? Current implementations are using 
some heuristics and it would be good to document this

We can certainly discuss the issue, but I am reluctant to specify a 
heuristic in an IETF draft, because then it is a specification and not 
a heuristic.



- Current text states that rLFA is computed only when LFA are not 
available and our analysis pointed that this is really not a good idea 
as in term of manageability rLFA alternate may be better than LFA 
alternate. It would be good that rLFA draft points to potential 
manageability issues and refers to the appropriate draft.

Hopefully this can be an informative ref, but we can include some 
simple text that notes that it is up to the implementer how they need 
to make a trade-off between minimum cost and minimum compute.

Thanks for bringing this to my attention, hope to get some work done 
on this draft at  the end of this week.

- Stewart



"

Thanks

Stephane

*Stephane Litkowski*
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network

Orange Expert Network of Future
tél. +33 2 23 28 49 83

mob. +33 6 37 86 97 52
stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>

*De :*rtgwg-boun...@ietf.org <mailto:rtgwg-boun...@ietf.org> 
[mailto:rtgwg-boun...@ietf.org] *De la part de* Stewart Bryant
*Envoyé :* mercredi 2 octobre 2013 13:26
*À :* Alvaro Retana (aretana)
*Cc :* draft-ietf-rtgwg-remote-...@tools.ietf.org 
<mailto:draft-ietf-rtgwg-remote-...@tools.ietf.org>; rogeriomariano; 
rtgwg@ietf.org <mailto:rtgwg@ietf.org>
*Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

I will try to get a new version out this week or next.

I plan to put in the algorithm text, although having discussed
this with Mike, our inclination is to include this as an
appendix since it is not required for interoperability that
you do the computation that way.

I will look at the issues left unresolved and any comments
posted in response to this email.

I see no reason to request a slot at IETF88 unless there remain
technical issues that we are unable to resolve on this list.

- Stewart (as duty editor of the draft)



On 01/10/2013 15:40, Alvaro Retana (aretana) wrote:

    On 10/1/13 10:31 AM, "rogeriomariano" <rsouza....@gmail.com
    <mailto:rsouza....@gmail.com>> wrote:

    Rogerio:

        Folks, Does anyone know whether the draft deal will be treated
        in the IETF 88?

    We haven't started working on the agenda yet, so it is perhaps too
    early to talk about whether this draft will be discussed in
    Vancouver or not.

    In the meant time, if you have comments or questions on the draft,
    please post them to the list.

    Thanks!

    Alvaro.






    _______________________________________________

    rtgwg mailing list

    rtgwg@ietf.org  <mailto:rtgwg@ietf.org>

    https://www.ietf.org/mailman/listinfo/rtgwg






--
For corporate legal information go to:
  
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
  
_________________________________________________________________________________________________________________________
  
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.





--
For corporate legal information go to:
  
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
  
_________________________________________________________________________________________________________________________
  
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.




--
For corporate legal information go to:
  
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
  
_________________________________________________________________________________________________________________________

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.


--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg