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 protected] wrote:
Hi Uma,
Inline comments,
-----Message d'origine-----
De : Uma Chunduri [mailto:[email protected]]
Envoyé : mardi 29 octobre 2013 07:00
À : LITKOWSKI Stephane DTF/DERX; [email protected]; Hannes Gredler
Cc : [email protected]; rogeriomariano; [email protected]
Objet : RE: I-D Action: draft-ietf-rtgwg-remote-lfa-02.txt
IMHO, there is no need for tie-breakers here (or it really *can't* help much).
This is a non-issue for OSPF.
[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.
Quick replies in-line [Uma]:
--
Uma C.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, October 28, 2013 6:42 PM
To: [email protected]; Hannes Gredler
Cc: [email protected]; rogeriomariano; [email protected]
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.
[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.
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).
[SLI] Right , with TE TLVs in ISIS we are loosing the "external" identification that's
why I added "when possible ...". But /32 is mandatory.
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 ?
_________________________________________________________________________________________________________________________
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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
