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

From: rogeriomariano <[email-masked]>
Date: Tue, 1 Oct 2013 07:31:36 -0700 (PDT)

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

--
View this message in context: http://ietf.10.n7.nabble.com/I-D-Action-draft-ietf-rtgwg-remote-lfa-02-txt-tp369816p386319.html
Sent from the IETF - Rtgwg mailing list archive at Nabble.com.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 1 Oct 2013 14:40:19 +0000

On 10/1/13 10:31 AM, "rogeriomariano" <[email-masked]<mailto:[email-masked]>> 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.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 02 Oct 2013 12:26:11 +0100

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:
> 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.
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> 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

---

From: <[email-masked]>
Date: Mon, 7 Oct 2013 10:59:57 +0200

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

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

    * 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

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

"

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
[email-masked]<mailto:[email-masked]>
De : [email-masked] [mailto:[email-masked]] De la part de Stewart Bryant
Envoyé : mercredi 2 octobre 2013 13:26
À : Alvaro Retana (aretana)
Cc : [email-masked]; rogeriomariano; [email-masked]
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

Rogerio:

Thanks!

Alvaro.

rtgwg mailing list

[email-masked]<mailto:[email-masked]>

--

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Oct 2013 16:55:51 +0100

On 07/10/2013 09:59, [email-masked] wrote:
> - 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.
>     * 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

> *Stephane Litkowski*
> [email-masked] <mailto:[email-masked]>
>
> *De :[email-masked] [mailto:[email-masked]] *De la 
> part de* Stewart Bryant
> *Envoyé :* mercredi 2 octobre 2013 13:26
> *À :* Alvaro Retana (aretana)
> *Cc :* [email-masked]; rogeriomariano; 
> [email-masked]
> *Objet :* Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt
>
>     early to talk about whether this draft will be discussed in
>     Vancouver or not.
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: <[email-masked]>
Date: Tue, 8 Oct 2013 09:06:59 +0200

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

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

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
[email-masked]<mailto:[email-masked]>
De : Stewart Bryant [mailto:[email-masked]]
Envoyé : lundi 7 octobre 2013 17:56
À : LITKOWSKI Stephane DTF/DERX
Cc : Alvaro Retana (aretana); [email-masked]; rogeriomariano; [email-masked]
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

On 07/10/2013 09:59, [email-masked]<mailto:[email-masked]> wrote:
Hi Stewart,

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

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
[email-masked]<mailto:[email-masked]>
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Stewart Bryant
Envoyé : mercredi 2 octobre 2013 13:26
À : Alvaro Retana (aretana)
Cc : [email-masked]<mailto:[email-masked]>; rogeriomariano; [email-masked]<mailto:[email-masked]>
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

Rogerio:

Thanks!

Alvaro.

rtgwg mailing list

--

Thank you.

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 08 Oct 2013 10:37:30 +0100

On 08/10/2013 08:06, [email-masked] 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.
>
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?

> 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

> *De :*Stewart Bryant [mailto:[email-masked]]
> *Envoyé :* lundi 7 octobre 2013 17:56
> *À :* LITKOWSKI Stephane DTF/DERX
> *Cc :* Alvaro Retana (aretana); 
> [email-masked]; rogeriomariano; [email-masked]
> On 07/10/2013 09:59, [email-masked] 
> <mailto:[email-masked]> wrote:
>
>     Hi Stewart,
>
>     "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
>
> 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.
>
> heuristic in an IETF draft, because then it is a specification and not 
> a heuristic.
>
>
> 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.
>
> *De :[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *De la part de* Stewart Bryant
> *Cc :* [email-masked] 
> <mailto:[email-masked]>; rogeriomariano;

---

From: <[email-masked]>
Date: Tue, 8 Oct 2013 13:26:27 +0200

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

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) :

o   Use IP in TLV134

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

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

Stephane Litkowski
Envoyé : mardi 8 octobre 2013 11:38

On 08/10/2013 08:06, [email-masked]<mailto:[email-masked]> wrote:
Stewart,

Stewart

Thanks,

Stephane Litkowski
Cc : Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>; rogeriomariano; [email-masked]<mailto:[email-masked]>

- Stewart

"

Thanks

Stephane

Stephane Litkowski

Rogerio:

Thanks!

Alvaro.

rtgwg mailing list

--

Thank you.

--

Thank you.

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 08 Oct 2013 16:08:01 +0100

On 08/10/2013 12:26, [email-masked] wrote:
> [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.
> [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 ...
>
> -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

> *Envoyé :* mardi 8 octobre 2013 11:38
> On 08/10/2013 08:06, [email-masked] 
>     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
> [email-masked]

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 9 Oct 2013 11:10:21 +0200

hi stewart,

i am not much in favor of 'lets try if we can bring-up TLDP, and if not
lets pick another PQ' strategy, mainly because it may create cross
dependencies.

today the typical R-LFA flow between IGP and LSP is like this:

1. IGP determines PQ set
2. IGP installs IP-FRR routes and gives LDP a hint
   which PQ IP address shall be used for a given IP-FRR backup route
3. LDP tries to bring up T-LDP to the PQ set
4. LDP has learned PQ set LDP database(s) and sets the backup nexthop
   for its MPLS tunnel and MPLS transit routes accordingly

now if we need to add the PQ pruning logic it becomes like this:

1. IGP determines PQ set
2. IGP installs IP-FRR routes and gives LDP a hint
   which PQ IP address shall be used for a given IP-FRR backup route
3. LDP tries to bring up T-LDP to the PQ set
4. timeout for bringing up T-LDP to PQ set
5. prune 'unwilling' PQ neighbor, goto 1

now my question: what event *removes* the unwilling PQ neighbor
from the PQ prune list, ever? - even if the PQ neighbor has been
reconfigured and it would now accept T-LDP sessions,
the calculating router would never try to establish a T-LDP session
after the PQ is on the prune list.

and periodical fallback is not a good solution either, right ;-)

to avoid the above i'd like to see simple protocol extensions
to the IGPs of a node willing or not willing to accept T-LDP
sessions and avoid the cross-dependencies.

/hannes

On Oct 8, 2013, at 11:37 AM, Stewart Bryant wrote:
[ … ]
> On 08/10/2013 08:06, [email-masked] wrote:
[ .. ]
>> [SLI] Some nodes are not accepting any TLDP session  at all and you cannot configure them to do it …

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Oct 2013 18:06:08 +0100

> sessions and avoid the cross-dependencies.

I agree, this is my preferred approach because it is certain to work.

Let me see if I can craft some text.

Stewart

---

From: <[email-masked]>
Date: Thu, 10 Oct 2013 10:08:16 +0200

Stewart, Hannes

I agree that a simple IGP extension is the best solution but to ensure backward compatibility with legacy node that will never support this extension, there is still a need of tie breaker.

Stephane Litkowski

mob. +33 6 37 86 97 52
[email-masked]

-----Message d'origine-----
De : Stewart Bryant [mailto:[email-masked]] 
Envoyé : mercredi 9 octobre 2013 19:06
À : Hannes Gredler
Cc : LITKOWSKI Stephane DTF/DERX; [email-masked]; rogeriomariano; [email-masked]
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

On 09/10/2013 10:10, Hannes Gredler wrote:
> hi stewart,
>
> i am not much in favor of 'lets try if we can bring-up TLDP, and if 
> not lets pick another PQ' strategy, mainly because it may create cross 
> dependencies.
>
> 3. LDP tries to bring up T-LDP to the PQ set 4. LDP has learned PQ set 
> LDP database(s) and sets the backup nexthop
> 3. LDP tries to bring up T-LDP to the PQ set 4. timeout for bringing 
> up T-LDP to PQ set 5. prune 'unwilling' PQ neighbor, goto 1
>
> now my question: what event *removes* the unwilling PQ neighbor from 
> the PQ prune list, ever? - even if the PQ neighbor has been 
> reconfigured and it would now accept T-LDP sessions, the calculating 
> router would never try to establish a T-LDP session after the PQ is on 
> the prune list.
>
> to avoid the above i'd like to see simple protocol extensions to the 
> IGPs of a node willing or not willing to accept T-LDP sessions and 
> avoid the cross-dependencies.

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 28 Oct 2013 17:56:39 +0000

> aware on how much rLFA may impact their TLDP session scaling
Done
> live network, leading to protection not available.
I will discuss this in a later thread
> some heuristics and it would be good to document this
... and this
> manageability issues and refers to the appropriate draft.
I have included a management section which states:

The management of LFA and remote LFA is the subject of ongoing work 
withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the reader 
is refered. In contrast to this text which recoommends that LFAs be 
preferred over remote LFAs, [I-D.ietf-rtgwg-lfa-manageability] notes 
that there may be reason to use remote LFAs even if ordinary LFAs are 
available. This requires further study.

Hopefully this addresses this point.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 28 Oct 2013 18:24:57 +0000

How about the following text:

To establish an targeted LDP session with a candidate PQ node the 
repairing node (S) needs to know what IP address PQ is willing to use 
for targeted LDP sessions. Ideally this is provided by PQ advertising 
this address in the IGP in use. Which address is used, how this is 
advertised in the IGP, and whether this is a special IP address or an IP 
address also used for some other purpose is out of scope for this 
document and must be specified in an IGP specific RFC.

In the absence of a protocol to learn the prefered IP address for 
targetted LDP, a tie-breaking mechanism is required.  Unless otherwise 
configured, an LSR should attempt a targeted LDP session with the IP 
address with the lowest numerical value advertised by the target LSR. To 
determine the lowest numerical value the address is taken in network 
byte order and cast to an integer of appropriate size.

(in case you are wondering about the appropriate size, it to have common 
v4 and v6 text)

- Stewart

---

From: <[email-masked]>
Date: Tue, 29 Oct 2013 02:42:24 +0100

Hi Stewart,

It sounds good to me, except for the proposed tie breaker mechanism. As you know, today there is no existing mechanism for LDP to advertise the TLDP listening IP address in the IGP. So in short/mid term rLFA deployment, no IGP solution would be available. So the draft must propose a last resort "working" tie breaker. IMHO, using the lowest numerical value would be a very bad idea ... because this has no sense (just tie break, but without any insurance that the chosen prefix would be good)

In order to bring more insurance, at least, I think the the tie breaker must check that the prefix used is an internal one (when possible ...) and is a /32.  I don't think we could make something more precise because otherwise we would need to address IGP protocol specifities (TLVs, LSAs ... fields to check...). 

Thoughts ?

-----Message d'origine-----
De : Stewart Bryant [mailto:[email-masked]] 
Envoyé : lundi 28 octobre 2013 19:25
À : LITKOWSKI Stephane DTF/DERX; Hannes Gredler
Cc : [email-masked]; rogeriomariano; [email-masked]
Objet : Re: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

To establish an targeted LDP session with a candidate PQ node the repairing node (S) needs to know what IP address PQ is willing to use for targeted LDP sessions. Ideally this is provided by PQ advertising this address in the IGP in use. Which address is used, how this is advertised in the IGP, and whether this is a special IP address or an IP address also used for some other purpose is out of scope for this document and must be specified in an IGP specific RFC.

In the absence of a protocol to learn the prefered IP address for targetted LDP, a tie-breaking mechanism is required.  Unless otherwise configured, an LSR should attempt a targeted LDP session with the IP address with the lowest numerical value advertised by the target LSR. To determine the lowest numerical value the address is taken in network byte order and cast to an integer of appropriate size.

- Stewart

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 29 Oct 2013 06:00:27 +0000

IMHO, there is no need for tie-breakers here (or it really *can't* help much).

This is a non-issue for OSPF.

For the other IGP, if this is the perceived problem: (plz confirm) -
PQ node may not accept TLDP session from PLR, if PLR  chooses an incorrect 
IP  represented by PQ node (IGP/ISIS database).

Because, today there is no document mandates an IP address which effectively 
represents the ISIS node. We can't *fully* rely on TLV 134 because this is 
not mandated for non TE environments. 

Instead of inventing a new thing here, the closest and one possible approach 
is to have a document which mandates a reachable prefix (loopback) in TLV 134, 
**regardless of TE present/supported or not**. This is the key and it fully 
solves the issue (it's important to note here - though today it's optional to 
have TLV 134 per 5305, some vendors including Ericsson do emit this regardless 
of TE in the local ISIS LSP). Does it make sense? (Les ?)

Advantage of this approach is, lot of vendors need not do any thing for this and 
for the remaining folk who are *not* doing this; should upgrade to have this TLV 
(probably upgrade may be necessary with any other always "workable" approach too) 
to represent reachable loopback IP address of the node always.

Quick replies in-line [Uma]:

-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 28, 2013 6:42 PM
To: [email-masked]; Hannes Gredler
Cc: [email-masked]; rogeriomariano; [email-masked]
Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

Hi Stewart,

It sounds good to me, except for the proposed tie breaker mechanism. As you know, today there is no existing mechanism for LDP to advertise the TLDP listening IP address in the IGP. So in short/mid term rLFA deployment, no IGP solution would be available. 

[Uma]: True, only  if a non-TE ISIS node doesn't advertise TLV 134 today.

So the draft must propose a last resort "working" tie breaker. 

[Uma]: If the above is TRUE, I don't think you can do much by defining 
       a "working" tie breaker here. Also, I don't think there is one 
       possible really in that situation.

IMHO, using the lowest numerical value would be a very bad idea ... because this has no sense (just tie break, but without any insurance that the chosen prefix would be good). In order to bring more insurance, at least, I think the the tie breaker must check that the prefix used is an internal one (when possible ...) and is a /32. 

[Uma]: /32 is fine but you don't know from the TLV if it is a internal prefix or 
       external prefix always 
       (IMO, this could be the blocker for proposing any "working" tie breaker).

I don't think we could make something more precise because otherwise we would need to address IGP protocol specifities (TLVs, LSAs ... fields to check...). 

[Uma]: I don't think there is any issue for OSPF in this regard (LSA.. as you mentioned)
       For ISIS (TLV as you said), yes at times one may quickly lost in TLV 135s, if one wants 
       to really figure out this /32 (TLV 135) is indeed represents the PQ node.

Thoughts ?

---

From: <[email-masked]>
Date: Tue, 29 Oct 2013 07:35:28 +0100

Hi Uma,

Inline comments,

-----Message d'origine-----
De : Uma Chunduri [mailto:[email-masked]] 
Envoyé : mardi 29 octobre 2013 07:00
À : LITKOWSKI Stephane DTF/DERX; [email-masked]; Hannes Gredler
Cc : [email-masked]; rogeriomariano; [email-masked]
Objet : RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

[SLI] OSPF is an old time for me :) so plz correct me if I'm wrong. 
An OSPF router may advertise as an ISIS router many type of prefixes :
- internal
- external
- Stub (Loopback, or non adj network)
- transit (interface)

What is good in OSPF compared to ISIS, is that we know what are the prefixes belonging to the node compared to what is "external" (type 3 or type 5 ...).
But whatever, you would need to tiebreak and say, I'm only looking at type 1 LSA. And in type 1 LSA, I would have multiple infos :
	- OSPF router ID but it may not match the LDP listening IP. Or we have to say that LDP listening IP must match the IGP Router ID.
	- Links : Stub, Transit, Virtual ... and in Stub you may have /x and /32 ... so you may need to tiebreak ?

Do I miss something ?

For the other IGP, if this is the perceived problem: (plz confirm) - PQ node may not accept TLDP session from PLR, if PLR  chooses an incorrect IP  represented by PQ node (IGP/ISIS database).

[SLI] Right

Because, today there is no document mandates an IP address which effectively represents the ISIS node. We can't *fully* rely on TLV 134 because this is not mandated for non TE environments. 

[SLI] Right, TLV134 is not available everywhere ....

Instead of inventing a new thing here, the closest and one possible approach is to have a document which mandates a reachable prefix (loopback) in TLV 134, **regardless of TE present/supported or not**. This is the key and it fully solves the issue (it's important to note here - though today it's optional to have TLV 134 per 5305, some vendors including Ericsson do emit this regardless of TE in the local ISIS LSP). Does it make sense? (Les ?)

[SLI] I'm ok on the principle, but my concern is that this implies that LDP listening IP would mandatory need to be configured to match the TLV 134. This may cause issue in some networks using multiple loopbacks (one loopback per protocol or service ...). Is this critical or not ?
Note that Juniper also always advertise TLV134 based on what I know.
The simpler we can do, the better it would be :)

Advantage of this approach is, lot of vendors need not do any thing for this and for the remaining folk who are *not* doing this; should upgrade to have this TLV (probably upgrade may be necessary with any other always "workable" approach too) to represent reachable loopback IP address of the node always.

--
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 28, 2013 6:42 PM
To: [email-masked]; Hannes Gredler
Cc: [email-masked]; rogeriomariano; [email-masked]
Subject: RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt

Hi Stewart,

[SLI] : yes and no ... TLV134 may not represent the LDP listening IP address ... IGP and LDP are independent and each may have his own configuration.

[SLI] Right , with TE TLVs in ISIS we are loosing the "external" identification that's why I added "when possible ...". But /32 is mandatory.

Thoughts ?

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 29 Oct 2013 13:14:15 +0000

I propose a slight change to the text:

In the absence of a protocol to learn the prefered IP address for targetted LDP, a tie-breaking mechanism is required.  Unless otherwise configured, an LSR should attempt a targeted LDP session with the *local* IP address with the lowest numerical value advertised by the target LSR. To determine the lowest numerical value the address is taken in network byte order and cast to an integer of appropriate size.

This covers three address methods:

1) A documented advertisement protocol, which we all agree is the best way
and which we also agree belongs with the protocol group concerned.

2) "Unless otherwise configured" gives the implementer a lot of scope
     a) Trivially highest instead of lowest
     b) A locally configured list of OK addresses to look for in the network
     c) A locally configured list of LSR identifier-address mappings
     d) Anything else they can think of.
     (2) Is essentially a local matter

3) local IP address with the lowest numerical
     This assumes that the implementation is smart enough to figure out
     which addresses are local and then tells it which one it should pick.
     It is them up to the operator to makes sure the TLDP is enabled
     for the lowest local address they assign to the LSR

We could remove (3) and require the operator to just configure the
useable address set, which is a very simple default mechanism.

If anyone thinks we should delete 2 or 3, please say so, or if
you think that we need to modify 3, then please propose some text.

- Stewart

On 29/10/2013 06:35, [email-masked] wrote:
> .