Subject: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00

From: Hannes Gredler <[email-masked]>
Date: Wed, 12 Dec 2012 15:49:43 +0100

clarence, stewart,

In favor of interoperable implementations i feel one should document how to 
identify the transport IP address (in lieu of protocols extensions who would
explicitly advertise the transport IP addresses) to the PQ node for the targeted LDP session.

I am proposing to append the following text to 3.2. "Tunnel requirements":

3.2.  Tunnel Requirements
   [ … ]

   When a failure is detected, it is necessary to immediately redirect
   traffic to the repair path.  Consequently, the repair tunnel used
   must be provisioned beforehand in anticipation of the failure.  Since
   the location of the repair tunnels is dynamically determined it is
   necessary to establish the repair tunnels without management action.
   Multiple repairs may share a tunnel end point.

<added-text>

Targeted LDP sessions are brought up using a pair of source (PLR) and destination
(PQ node) loopback addresses. The following heuristics should be applied for deriving the
loopback IP address from a PQ nodes link-state advertisement.

for the IS-IS routing protocol:

A PLR router should connect to the address

 traffic-engineering deployments:
  - reported both in the TE-router ID TLV 134
  - and IP Reach TLVs (128,135) given that
  - the prefix length is /32

    or

 no traffic-engineering deployments:
  - reported both in the IP interface address TLV 132
  - and IP Reach TLVs (128,135), given that
  - there is only a single interface address advertised per the router
  - the prefix length is /32

for the OSPF routing protocol:

A PLR router should connect to the address

 traffic-engineering deployments:
  - reported in the Router Address TLV  (Type 10 LSA) and
  - router (Type 1 LSA) ) stub network  advertisement and
  - the address mask is 255.255.255.255

    or

 non-traffic-engineering deployments:
  - reported in the  router-id field of the Type-1 LSA)
  - the router (Type 1 LSA) stub network  advertisement and
  - the address mask is 255.255.255.255

</added-text>

tx,

/hannes

---

From: Peter Psenak <[email-masked]>
Date: Wed, 12 Dec 2012 16:27:52 +0100

Hi Hannes,

please see inline:

>   traffic-engineering deployments:

why do we need to distinguish between TE and non-TE deployments?
All we need in rLFA context is a reachable IPv4 address advertised by PQ 
node. That should be independent of TE being deployed or not.

>    - the address mask is 255.255.255.255

can we say that the PQ node address used for targeted LDP session is 
selected in following order of preference:

1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ 
node itself

2. Highest /32 address advertised by PQ node in it's Router LSA

thanks,
Peter

>
> </added-text>
>
> tx,
>
> /hannes
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 12 Dec 2012 17:05:51 +0100

> why do we need to distinguish between TE and non-TE deployments?

for OSPF things are less ambiguous than for IS-IS, agreed.

for IS-IS  the advantage of TE extensions is really that it serves as an explicit identifier of a node,
if this router-ID has got IP reachability as well then its usually the transport IP address;
for OSPF we have the router-ID in every type-1 LSA for IS-IS we don't.

> All we need in rLFA context is a reachable IPv4 address advertised by PQ node. That should be independent of TE being deployed or not.

by ensuring a deterministic address selection you safe T-LDP sessions:
if any source address can connect to any destination address then you have
doubled the overall number of T-LDP by two. however if you ensure that all nodes
agree to use a single IP address then you only need one T-LDP for
a given source/destination router pair.

> can we say that the PQ node address used for targeted LDP session is selected in following order of preference:
> 
> 1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node itself
> 

in favor of explicit advertisement, i'd rather do 3 rules here :

1. PQ node OSPF router-id, if it is advertised as /32 prefix by the PQ node itself
2. PQ node TE adress, if it is advertised as /32 prefix by the PQ node itself
3.  Highest /32 address advertised by PQ node in it's Router LSA

---

From: Peter Psenak <[email-masked]>
Date: Wed, 12 Dec 2012 17:34:11 +0100

Hannes,

> 3.  Highest /32 address advertised by PQ node in it's Router LSA

ether (1) or (3) is mandatory for the t-LDP session creation. (2) is 
optional and not sufficient for t-LDP session, so we can not have it 
before (3).

It looks to me we are trying to solve the configuration problem which 
should not be addressed here.

thanks,
Peter

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 11:51:08 +0100

Hi all,

I would bring the following comment :

As far as I know, LDP and IGP are quite independent in term of managing their "addresses".
An operator may choose a router ID for ISIS that could be different from LDP one. Personnally I don't really see an interrest in doing that but it's a possibility. Moreover I would be more worry on transient situations when you let the router choosing router IDs, you activate ISIS (ISIS choose a router ID based on IP address available), then you configure a new high address loopback, and then you configure LDP, in this case you will have a high probability to have a different router ID for each ... (it's clearly implementation dependant but the solution must work with all cases) -> we already had such situation with BGP having a different router-id than ISIS/LDP.

Moreover regarding TLDP, I think implementations could be different in the way they are accepting T-LDP sessions. I don't know if there are some guidelines in LDP spec for this ... Some may accept  TLDP sessions only on LDP router-id, some may accept on all loopbacks ... 

So is it a good think to rely on IGP router-id or IP address TLV 132 as it may not reflect how LDP is behaving ?
Issue with TLV 135 is that it could transport external redistributed routes (we have the case ...)

It could be good to have some tie breakers as Hannes proposed, the main point to address would be , how implementation must behave when the TLDP session cannot establish (for example because we chosen the bad IP address ...) ? Does it fallback and try another IP, does it fallback to another PQ ? (but problem would be the same with another PQ if problem comes from bad IP choice).

I would see two complementary options :
- define a spec, as Hannes proposed, where we rely on IGP address infos (router ID, TLV 132 ...) and give some guidelines to reader on how LDP must be parametered to ensure that it will work. 

- permit user to define by himself the addresses rLFA would use as transport address for TLDP (using admin tags for example).

Regards,

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Peter Psenak
Envoyé : mercredi 12 décembre 2012 17:34
À : Hannes Gredler
Cc : [email-masked]; [email-masked]
Objet : Re: identifying IP address of targeted LDP session in draft-ietf-rtgwg-remote-lfa-00

Hannes,

On 12.12.2012 17:05, Hannes Gredler wrote:

> node itself 2. PQ node TE adress, if it is advertised as /32 prefix by 
> the PQ node itself 3.  Highest /32 address advertised by PQ node in 
> it's Router LSA

ether (1) or (3) is mandatory for the t-LDP session creation. (2) is optional and not sufficient for t-LDP session, so we can not have it before (3).

It looks to me we are trying to solve the configuration problem which should not be addressed here.

thanks,
Peter

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Dec 2012 11:38:52 +0000

Hannes

The draft as it stands is not MPLS specific and thus I am not convinced
we should add the information you propose to this draft, although
perhaps some text could go in a new section. However if we include
this text, we need to consider what we should say about IP tunnels.

However it might be better if this information were in IGP specific
drafts put through the IGP WGs. Certainly I think that we need to
specify more than this text since there are for example security
and capability considerations.

I have some explicit questions inline.

> Targeted LDP sessions are brought up using a pair of source (PLR) and destination
What does PLR stand for?

>    - the prefix length is /32
The text above does not scan (nor does the text below)

> .
- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Dec 2012 11:43:02 +0000

On 12/12/2012 15:27, Peter Psenak wrote:
> All we need in rLFA context is a reachable IPv4 address advertised by 
> PQ node. That should be independent of TE being deployed or not.
Surely "reachable IP address", not "reachable IPv4 address".
> 2. Highest /32 address advertised by PQ node in it's Router LSA
Why do we need (2). What do we do if an interface cycles?

Surely the most we should say is that we SHOULD establish a TLDP session 
with the
OSPF router-id, if it is advertised as /32 prefix by the PQ node itself, 
else any
other IP address for the node may be sued.

Stewart

-- 
For corporate legal information go to:

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Dec 2012 11:45:12 +0000

> should not be addressed here.

I am inclined to agree, and note that the draft is tunnel independent.

We may want a deployment guidelines document, or some protocol specific 
text in another document, but this draft can stand alone without this text.

Stewart

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 14:21:40 +0000

Peter,

>From: Peter Psenak

It looks to me that we are trying to address the network management problem and deployability/interoperability in a multi-vendor network.
May be this can be done by configuration. In this case, could you please elaborate on what you propose?
Given that at least two routers (the PLR and the PQ) must agree on establishing the T-LDP session, there is a priori room for coordination. And given that a PLR (resp. PQ) needs to be able to use (resp. used) "any" PQ (resp. PLR), it seems useful that the same mechanism be shared by all PQs and PLRs, rathers than one relying on ISIS tag, another on order of IP addresses, another on static address range...
Hannes' request seems a relevant point to discuss on the mailing list and IMO the R-LFA draft should discuss this.
Even if the R-LFA proposition is not specific to a network environment (e.g. type of tunnels) the goal is to _deploy_ the R-LFA proposition. And that deployment will be a specific environment, where this is expected to work. I also think MPLS tunnels (LSPs) established by LDP seems a reasonably popular target deployment.

Unless it is believed that a local algorithm, without coordination between routers/vendor, can work in 100% of the cases. Is this your point?

Thanks,
Regards,
Bruno

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 13 Dec 2012 15:21:23 +0100

On Dec 13, 2012, at 12:43 PM, Stewart Bryant wrote:

[ … ]

> Surely the most we should say is that we SHOULD establish a TLDP session with the
> OSPF router-id, if it is advertised as /32 prefix by the PQ node itself, else any
> other IP address for the node may be used.

other implementations may not be willing to accept T-LDP sessions on non-loopback
adresses.

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 13 Dec 2012 15:18:04 +0100

> this text, we need to consider what we should say about IP tunnels.

rfc5286 is not MPLS specific either, yet the majority (>90%) of my customers
see it as lightweight alternative to get local-repair protection for their LDP networks.
draft-ietf-rtgwg-remote-lfa-00 is not LDP specific either, however the
it will be deployed by a majority of customers who have an LDP/MPLS background
as well. 

> and capability considerations.

if we go down the road of explicitly advertising the transport loopback
then i agree this work should be done in ospf-wg and isis-wg.
the question is wether we can go without protocol extension and
identify the loopback IP based on existing protocols.

>> Targeted LDP sessions are brought up using a pair of source (PLR) and destination

This is the point of local repair (PLR) -

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 13 Dec 2012 15:31:36 +0100

On Dec 13, 2012, at 3:25 PM, Peter Psenak wrote:

> Bruno,
> 
> On 13.12.2012 15:21, [email-masked] wrote:
>> Peter,
>> 
>>> From: Peter Psenak
>>> 
>>> Hannes,
>>> 
> local algorithm that picks any of the /32 IP addresses advertised by PQ node will work in 100% of cases.

peter,

two questions:

1) how do you know that the other side will be accepting the T-LDP session at a non loopback IP address ?
2) what is your proposed scheme for minimizing the amount of T-LDP sessions between a pair of routers ?
    (is it numerically highest IP ?)

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 13 Dec 2012 15:24:04 +0100

On Dec 13, 2012, at 12:45 PM, Stewart Bryant wrote:

> We may want a deployment guidelines document, or some protocol specific text in another document, but this draft can stand alone without this text.

stewart,

do you think that the automated bringup of T-LDP sessions is
generic enough to warrant for a new draft ?

IMO this problem is specific to R-LFA deployment in LDP
networks and hence should be added to the remote-lfa draft.

/hannes

---

From: Peter Psenak <[email-masked]>
Date: Thu, 13 Dec 2012 15:31:28 +0100

Hannes,

> other implementations may not be willing to accept T-LDP sessions on non-loopback

how do you suggest to distinguish between /32 belonging to the loopback 
from /32 belonging to other interface types?

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 13 Dec 2012 15:25:22 +0100

Bruno,

> Unless it is believed that a local algorithm, without coordination between routers/vendor, can work in 100% of the cases. Is this your point?

local algorithm that picks any of the /32 IP addresses advertised by PQ 
node will work in 100% of cases.

thanks,
Peter

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 14:50:12 +0000

Peter,

>From: Peter Psenak [mailto:[email-masked]] >Sent: Thursday, December 13, 2012 3:25 PM
>
>Bruno,
>
>> It looks to me that we are trying to address the network management problem
>and deployability/interoperability in a multi-vendor network.
>> Given that at least two routers (the PLR and the PQ) must agree on
>establishing the T-LDP session, there is a priori room for coordination. And
>given that a PLR (resp. PQ) needs to be able to use (resp. used) "any" PQ
>(resp. PLR), it seems useful that the same mechanism be shared by all PQs and
>PLRs, rathers than one relying on ISIS tag, another on order of IP addresses,
>another on static address range...
>> Even if the R-LFA proposition is not specific to a network environment (e.g.
>type of tunnels) the goal is to _deploy_ the R-LFA proposition. And that
>deployment will be a specific environment, where this is expected to work. I
>also think MPLS tunnels (LSPs) established by LDP seems a reasonably popular
>target deployment.
>>
>> Unless it is believed that a local algorithm, without coordination between
>routers/vendor, can work in 100% of the cases. Is this your point?
>

Does this include the case of an IS-IS L1/L2 router (ABR) redistributing into L2 the loopbacks of the routers in L1?

>_______________________________________________________________________________
>__________________________________________
>>
>> 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;
>> As emails may be altered, France Telecom - Orange is not liable for messages
>that have been modified, changed or falsified.
>> Thank you.
>>
>>
>>
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 13 Dec 2012 15:56:59 +0100

Bruno,

> Does this include the case of an IS-IS L1/L2 router (ABR) redistributing into L2 the loopbacks of the routers in L1?

ISIS may have a specific problem of not distinguishing between 
intra/inter/external prefixes. For that case some local policy on the 
computing node can be used to pick the ones that will work for LDP.

thanks,
Peter

---

From: Alia Atlas <[email-masked]>
Date: Thu, 13 Dec 2012 09:58:50 -0500

Stewart,

I think it would be good to have the remote-LFA draft discuss and recommend
what addresses to use, what requirements there are on routers to make it
work (for IP or LDP), and what protocol gaps are identified.   What is
necessary for the PQ node to know to handle terminating an IP tunnel at
line rate?  What is needed to consistently pick the tLDP address, etc.?

Alia

On Thu, Dec 13, 2012 at 6:45 AM, Stewart Bryant <[email-masked]> wrote:

>> optional and not sufficient for t-LDP session, so we can not have it before
>> (3).
>>
> ______________________________**_________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtgwg<https://www.ietf.org/mailman/listinfo/rtgwg>
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 13 Dec 2012 10:03:28 -0500

Peter,

One of the goals of LFA & remote-LFA is for ease of manageability.  Why are
you pushing for requiring additional configuration, which I don't see as
adding any benefit from the flexibility, instead of documenting the
straightforward rules for automatic interoperabiity?

Alia

On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak <[email-masked]> wrote:

>> Does this include the case of an IS-IS L1/L2 router (ABR) redistributing
>> into L2 the loopbacks of the routers in L1?
>>
>
>>>>  ______________________________**______________________________**
>>> ___________________
>>> ______________________________**____________
>>>
>>>>
>>>> France Telecom - Orange decline toute responsabilite si ce message a ete
>>>>
>>> altere, deforme ou falsifie. Merci.
>>>
>>>>
>>>> If you have received this email in error, please notify the sender and
>>>> delete
>>>>
>>> this message and its attachments.
>>>
>> ______________________________**______________________________**
>> ______________________________**______________________________**_
>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> As emails may be altered, France Telecom - Orange is not liable for
>> messages that have been modified, changed or falsified.
>> Thank you.
>>
>>
>>
>>
>

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 13 Dec 2012 16:00:34 +0100

On Dec 13, 2012, at 3:56 PM, Peter Psenak wrote:

> ISIS may have a specific problem of not distinguishing between intra/inter/external prefixes.
> For that case some local policy on the computing node can be used to pick the ones that will work for LDP.

that would require explicit configuration and i am sure we can do smarter than that ;-)

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 13 Dec 2012 15:57:51 +0100

On Dec 13, 2012, at 3:31 PM, Peter Psenak wrote:

> how do you suggest to distinguish between /32 belonging to the loopback from /32 belonging to other interface types?

for OSPF traffic engineering deployments:
 - if a /32 stub route advertisement of a type-1 LSA matches the TE router address TLV in the type-10 LSA

for OSPF non-traffic engineering deployments:
 - if a /32 stub route advertisement of a type-1 LSA matches the router-id in the LS header

for IS-IS traffic-engineering deployments:
 - if a /32 reported in any IP Reach TLVs (128,135, 235) matches  the
    TE-router ID TLV 134
 
for non IS-IS traffic-engineering deployments:
- if a /32 reported in any IP Reach TLVs (128,135, 235) matches  the
- IP interface address TLV 132 (and this is the only IP interface address TLV advertisement)

---

From: Peter Psenak <[email-masked]>
Date: Thu, 13 Dec 2012 16:10:15 +0100

Hannes,

> 1) how do you know that the other side will be accepting the T-LDP session at a non loopback IP address ?

I'm proposing to use OSPF router-id as a first choice. In any reasonable 
deployment, that address belongs to loopback interface.

If OSPF router-id can not be used, then there is no way currently to 
tell which of the /32s advertised by PQ node belong to loopbacks. 
Operator have two choices:

- make sure that the highest /32 address advertised by PQ node is a 
loopback address

- use some local policy on the calculating node to pick the address on 
the PQ node that work with LDP.

> 2) what is your proposed scheme for minimizing the amount of T-LDP sessions between a pair of routers ?

I do not see how the IP address used for T-LDP peering makes an impact 
on the number of LDP sessions used for rLFA between any pair of routers. 
There should only be one session used for rLFA between any pair of routers.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 13 Dec 2012 16:13:28 +0100

Hannes,

>   - if a /32 stub route advertisement of a type-1 LSA matches the TE router address TLV in the type-10 LSA

are we only allowed to advertise loopbacks in the TE TLV?

>   - if a /32 stub route advertisement of a type-1 LSA matches the router-id in the LS header

does not work if the router-id is not advertised by the node as a 
stub-link, which is a valid case.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 13 Dec 2012 16:18:19 +0100

Alia,

On 13.12.2012 16:03, Alia Atlas wrote:
> Peter,
>
> One of the goals of LFA & remote-LFA is for ease of manageability.  Why
> are you pushing for requiring additional configuration, which I don't
> see as adding any benefit from the flexibility, instead of documenting
> the straightforward rules for automatic interoperabiity?

for most of the deployments, no config is required and picking the 
router-id or highest /32 address advertised by PQ node will work fine.

For those cases where above does not work, there are no magic rules that 
will make it work in all cases. We would need a protocol extension to 
guarantee it.

thanks,
Peter

>
> Alia
>
>
> On Thu, Dec 13, 2012 at 9:56 AM, Peter Psenak <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Bruno,
>
>     On 13.12.2012 15:50, [email-masked]
>     <mailto:[email-masked]> wrote:
>
>         Peter,
>
>         Does this include the case of an IS-IS L1/L2 router (ABR)
>         redistributing into L2 the loopbacks of the routers in L1?
>
>
>     intra/inter/external prefixes. For that case some local policy on
>     the computing node can be used to pick the ones that will work for LDP.
>
>     thanks,
>     Peter
>
>
>
>             thanks,
>             Peter
>
>
>                 Thanks,
>                 Regards,
>                 Bruno
>
>                     thanks,
>                     Peter
>                     _________________________________________________
>                     rtgwg mailing list
>                     [email-masked] <mailto:[email-masked]>
>                     https://www.ietf.org/mailman/__listinfo/rtgwg
>                     <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>
>
>             ___________________________________________________________________________________
>             ____________________________________________
>
>
>                 If you have received this email in error, please notify
>                 the sender and delete
>
>         _________________________________________________________________________________________________________________________________
>
>         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,
>         France Telecom - 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;
>         If you have received this email in error, please notify the
>         sender and delete this message and its attachments.
>         As emails may be altered, France Telecom - Orange is not liable
>         for messages that have been modified, changed or falsified.
>         Thank you.
>
>
>
>
>
>     _________________________________________________
>     rtgwg mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/rtgwg
>     <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 13 Dec 2012 11:04:12 -0500

Peter,

Then the draft should document that & the need for additional protocol
extensions if certainty is desired.
Then, there is the appropriate clarity & if a protocol extensions draft is
needed it can be considered in the
correct WG.

Alia

On Thu, Dec 13, 2012 at 10:18 AM, Peter Psenak <[email-masked]> wrote:

>>     <mailto:bruno.decraene@orange.**com <[email-masked]>>
>> wrote:
>>
>>         Peter,
>>
>>                     ______________________________**___________________
>>                     rtgwg mailing list
>>                     https://www.ietf.org/mailman/_**_listinfo/rtgwg<https://www.ietf.org/mailman/__listinfo/rtgwg>
>>                     <https://www.ietf.org/mailman/**listinfo/rtgwg<https://www.ietf.org/mailman/listinfo/rtgwg>
>> >
>>
>>
>>
>>             ______________________________**
>> ______________________________**_______________________
>>             ______________________________**______________
>>
>>
>>
>>                 informations
>> ______________________________**______________________________**_________
>>
>>
>>     ______________________________**___________________
>>     rtgwg mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/rtgwg<https://www.ietf.org/mailman/__listinfo/rtgwg>
>>     <https://www.ietf.org/mailman/**listinfo/rtgwg<https://www.ietf.org/mailman/listinfo/rtgwg>
>> >
>>
>>
>>
>
>

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 13 Dec 2012 17:28:45 +0100

> are we only allowed to advertise loopbacks in the TE TLV?

remember, in lieu of explicit signaling the purpose of this is finding the "most likely" transport IP for the T-LDP session.
Those are heuristics and as such imperfect. If i can cover a high percentile of the deployed base, then 
i usually can convince operators to fix their broken configs where the router-id/TE-router-ID does not match
the routable transport loopback IP.

> does not work if the router-id is not advertised by the node as a stub-link, which is a valid case.

perfect, so lets declare this a "broken" configuration for automated T-LDP bringup w/o explicit signaling.

i do sense some discomfort with the suggested heuristics - 

should be go down and spin off dedicated drafts for OSPF and IS-IS to explicitly advertise the
transport IP address ?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 Dec 2012 20:35:46 +0000

Hannes -

> should be go down and spin off dedicated drafts for OSPF and IS-IS to

Speaking specifically about IS-IS, why would we need to invent yet another type of advertisement specifically for remote LFA? Here's a snippet from RFC 5305 Section 4.3:

<snip>
   The router ID TLV contains the 4-octet router ID of the router
   originating the LSP.  This is useful in several regards:

      For traffic engineering, it guarantees that we have a single
      stable address that can always be referenced in a path that will
      be reachable from multiple hops away, regardless of the state of
      the node's interfaces...

   If a router does not implement traffic engineering, it MAY add or
   omit the Traffic Engineering router ID TLV.
<end snip>

Does this not provide exactly what is required for remote LFA support? And the RFC even specifically allows this to be present even if TE is not in use. What would your suggested "advertise the transport IP address do" that is not already done by TLV 134 (and the matching IP reachability advertisement)???

   Les

---

From: Rob Shakir <[email-masked]>
Date: Thu, 13 Dec 2012 19:56:02 +0000

Hi Peter,

> local algorithm that picks any of the /32 IP addresses advertised by PQ node will work in 100% of cases.

If there are local filters or control-plane protection ACLs deployed on the target node to which the T-LDP session is to be established, it is possible that these drop T-LDP traffic not targeted to a particular local address. I'm not clear on how this can be determined remotely?

It seems to me that we need deterministic behaviour in order to allow operators to clearly consider this within such policies (or to know that other protocol/signalling mechanisms are required), and to ensure inter-operability. I don't see a clear reason why Hannes' suggestions do not go at least some way to providing this. In the vast majority of deployments I have seen, a consistent router ID is used for intra-domain, inter-node session termination and protocol identifier. This is more common (imho) than the highest /32 being the most suitable address.

r.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 13 Dec 2012 22:15:56 +0000

Agree with Les, why reinvent the wheel?

Regards,
Jeff

---

From: Saku Ytti <[email-masked]>
Date: Fri, 14 Dec 2012 00:19:01 +0200

> It seems to me that we need deterministic behaviour in order to allow operators to clearly consider this within such policies (or to know that other protocol/signalling mechanisms are required), an…

In our ~1500 or so flat L2 ISIS network TLV 132 is always correct for
tLDP, mixed collection of various IOS and JunOS devices.

However I know people who run unlabeled INET4 in loop0 and labeled
VPNv4 for loop1 and desirable LDP is loop1. I would guess TLV 132 is
still loop0 for these people, it's probably their router-id as well.
No matter what you specify it, some people will be unhappy. But I
wonder if there any production network where TLV 132 would fail, after
allowing it in control-plane protection?

(Also hell with tLDP, give me global label TLV in ISIS, and we get
rLFA without any LDP, not even link LDP)
--
  ++ytti

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 Dec 2012 22:33:35 +0000

Rob -

I haven't seen anyone on this thread suggest that if a router ID is available/reachable that it should not be preferred/used. Local policies could make any particular address unusable, but it would seem unusual for a customer to configure a box to advertise a /32 which it also prevents from being used. So I think Peter's point is that it is not unreasonable to consider the set of all reachable /32 which a node has advertised as being viable candidates. 

Frankly, I find the discussion of a preference algorithm in selecting the endpoint address as useful/interesting - but much more appropriate for a vendor deployment guide than a normative specification. Vendors often are faced with idiosyncratic deployment constraints from their customers which need to be accommodated. In which case responsive vendors will provide various knobs to allow override of default behavior - while retaining the ease of "zero config" for the majority of customers. This is simply good business. We should not attempt to "standardize" this.

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob
> Shakir
> Sent: Thursday, December 13, 2012 11:56 AM
> To: Peter Psenak (ppsenak)
> Cc: [email-masked]; Stewart Bryant (stbryant)
> Subject: Re: identifying IP address of targeted LDP session in draft-ietf-
> rtgwg-remote-lfa-00
> 
> Hi Peter,
> 
> If there are local filters or control-plane protection ACLs deployed on the
> target node to which the T-LDP session is to be established, it is possible
> that these drop T-LDP traffic not targeted to a particular local address. I'm
> not clear on how this can be determined remotely?
> 
> It seems to me that we need deterministic behaviour in order to allow
> operators to clearly consider this within such policies (or to know that
> other protocol/signalling mechanisms are required), and to ensure inter-
> operability. I don't see a clear reason why Hannes' suggestions do not go at
> least some way to providing this. In the vast majority of deployments I have
> seen, a consistent router ID is used for intra-domain, inter-node session
> termination and protocol identifier. This is more common (imho) than the
> highest /32 being the most suitable address.
> 
> r.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 14 Dec 2012 10:01:11 +0100

Rob,

> It seems to me that we need deterministic behaviour in order to allow operators to clearly consider this within such policies (or to know that other protocol/signalling mechanisms are required), an…

my suggestion was to use rtr-id of the PQ node as a first choice and 
fallback to highest /32 address as a last resort.

Peter

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 14 Dec 2012 10:12:53 +0000

> Does this not provide exactly what is required for remote LFA support? And the RFC even specifically allows this to be present even if TE is not in use. What would your suggested "advertise the tra…
OK, so let's work up some text based on that and I will create a new 
Section IGP Address considerations with an ISIS and an OSPF section.

I plan to get a new version out next week.

Stewart

---

From: Anton Smirnov <[email-masked]>
Date: Fri, 14 Dec 2012 18:42:29 +0100

Hi Hannes,
    I saw this [lively] thread only today. I am not sure concerns which 
you brought up are really that big. You mentioned concerns of:
- interoperability
- efficiency (multiple LDP sessions)
- security

    What happens with MPLS if Remote LFA chose 'wrong' IP address to 
terminate the tunnel:
- IGP asks LDP to open targeted session to computed IP address
- LDP sends targeted Hello (UDP)
- Remote router responds with its ID and its transport address (which 
generally speaking is different than IP address where targeted Hello was 
received)
- TCP session is established between transport addresses.

So, after Hello exchange LDP has enough information to uniquely identify 
peer router and avoid duplicated TCP sessions.
Transport address is always selected by receiving router and rLFA does 
not have control over it.

    I do not see room for interoperability issues even if rLFA routers 
follow different selection algorithms. The only requirement is that rLFA 
selects /32 address belonging to the remote end router.
    There are no efficiency compromises - label exchange will happen 
over single TCP session.
    Security considerations - selection of address to terminate TCP 
session is controlled by LDP configuration of a router, not by rLFA.
    The only thing left is that tunnel tailend router must not block LDP 
targeted Hellos on IP address selected by rLFA of computing router. This 
is achievable even if rLFA algorithm of selecting termination IP address 
is unknown (because there is finite number of /32 addresses advertised 
by the router via IGP). With little help of vendor's documentation it 
should be easy.

    So it's good if authors add to the draft a possible algorithm but I 
do not see a need for it to be too complex or truly standardized.

Anton

---

From: <[email-masked]>
Date: Mon, 17 Dec 2012 10:07:24 +0000

In LDP networks, I see 2 problems and 2 goals.

2 problems:
- T-LDP (TL): finding an IP address of the PQ to set up the T-LDP session
- TUnnel end point (TU): finding an IP address of the PQ useable as tunnel end point.

And 2 goals:
- A short term goal is to maximize (>80% ?) the ability of the PLR/S/R-LFA to get the right IP address of the PQ, while the PQ is not compliant with R-LFA. To keep LFA deployments properties, it would be nice if the PLR would work out of the box, without requiring change (software/configuration) on other routers. This is the ingress (i) issue in current networks. One could say that this is a local issue that does not need standardization. However, this requires taking into account existing PQ implementations/capabilities. Hence RTGWG seems a useful place for discussing this, versus a full mesh of bi-lateral discussion between vendors which besides would not include SP. This does not prohibit an implementation to use a smarter solution.
- A long term goal is to guaranty (100%) the ability of the PLR/S/R-LFA to get the right IP address of the PQ, when the PQ is compliant with R-LFA. This is the egress (e) issue/requirements in future networks. This point requires standardization.

When combining, this gives 4 points to consider. Eventually, there will be some overlap between the solutions.

==TL== Regarding TL (T-LDP):
 =e=: for the egress long term, 2 solutions have been suggested
   - advertise the TLV 124 (TE Router ID) and accept T-LDP hello from this address. Then either advertise LDP Transport Address optional object or accept LDP session from this address. (Hannes)
   - accept T-LDP hello from all its /32 address advertise in the IGP. Then either advertise LDP Transport Address optional object or accept LDP session from these addresses. (Anton)

 =i=: for the ingress short term, 2 solutions:
   - TE-router ID TLV 134, alternatively the /32 IP interface address TLV 132 (both needs also be advertised in any IP Reach TLVs (128,135, 235)) (Hannes)
   - idem but trying all /32 IP interface in address TLV 132, or possibly all /32 advertised in any IP reach if the number of reach /32 if below a threshold (e.g. 5) or matching a configured prefix.

==TU== regarding TUnnel end point:
TU may be different than TL, for example in a network using multiple loopbacks addresses, one being advertised as FEC in LDP for MPLS traffic and one not being advertised for IP traffic routed hop-by-hop. So far this point has not been discussed.
 =i= for the ingress short term:
   - one could use TL if there is an LSP toward this FEC. Alternatively, a FEC received over the T-LDP session with a null label (explicit or implicit).
 =e= for the egress short term:
   - requiring the TL to be advertised in LDP may not be possible with existing configuration (e.g. setting both the Router ID and the range of FEC advertised in LDP). Seems a priori hard to me to require the change of the configuration (changing the loopback advertised in LDP is not an option. Changing the TE-router ID to prefer the one advertised in LDP seems easier. Should we require this by default? However, that does not seem to me like a long term solution when we can change the behavior both on the PLR & the PQ.
   - advertising all loopbacks in TLV 132 (IP interface address). Then the ingress intersects this set with the set of FEC advertised in LDP.
   - finding another existing field?
   - defining a new field (either in IGP or T-LDP)

Thanks,
Regards,
Bruno

>From: Anton Smirnov >Sent: Friday, December 14, 2012 6:42 PM
>
>    Hi Hannes,
>>     [ ... ]

---

From: Rob Shakir <[email-masked]>
Date: Tue, 18 Dec 2012 08:38:09 +0000

Hi Les,

Apologies for the delay in responding.

> Frankly, I find the discussion of a preference algorithm in selecting the endpoint address as useful/interesting - but much more appropriate for a vendor deployment guide than a normative specifica…

I agree that there are likely to be a variety of requirements, and I am not saying that we need a MUST in this document - but some guidance to implementors on this kind of deployment consideration is always useful from my perspective (some guidance as to what *could* be best practice, tends to result in a higher probability that different vendor's kit actually interoperates with each other).

Cheers,
r.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 20 Dec 2012 08:45:47 +0000

Rob -

So long as the WG is in agreement that what we are discussing is simply "best practice" - and that there is no interoperability issue - then I think we should have little trouble converging on text which is agreeable to everyone.

   Les

> From: Rob Shakir [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2012 12:38 AM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]
> > Frankly, I find the discussion of a preference algorithm in selecting the
> endpoint address as useful/interesting - but much more appropriate for a
> vendor deployment guide than a normative specification. Vendors often are
> faced with idiosyncratic deployment constraints from their customers which
> need to be accommodated. In which case responsive vendors will provide
> various knobs to allow override of default behavior - while retaining the
> ease of "zero config" for the majority of customers. This is simply good
> business. We should not attempt to "standardize" this.
> 
> I agree that there are likely to be a variety of requirements, and I am not
> saying that we need a MUST in this document - but some guidance to
> implementors on this kind of deployment consideration is always useful from
> my perspective (some guidance as to what *could* be best practice, tends to
> result in a higher probability that different vendor's kit actually
> interoperates with each other).
> 
> Cheers,
> r.