Subject: Re: RFC : 3036 : Session establishment for multiple adjacencies.

From: Vikas D <[email-masked]>
Date: Wed, 18 Jul 2001 11:47:53 -0700 (PDT)

All,

A small doubt in Section 2.5.2, "Transport Connection
Establishment"
of LDP RFC.  It says:

             .............snip..................
 "An LSR MUST advertise the same transport address in all Hellos that
  advertise the same label space.  This requirement ensures that two
  LSRs linked by multiple Hello adjacencies using the same label
spaces
  play the same connection establishment role for each adjacency."
             .............snip....................

Now, under what circumstances would two LSRs, having multiple
hello adjacencies , using same label spaces on all adjacencies
try to establish multiple TCP sessions?

Is this not already precluded by the following rule in the same
section (Sec 2.5.2 of RFC 3036):

             .............snip..................
 "  1. If LSR1 does not already have an LDP session for the exchange
       of label spaces LSR1:a and LSR2:b it attempts to open a TCP
       connection for a new LDP session with LSR2."
             .............snip..................

Thanks
- Vikas

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

---

From: "chetan kumar s" <[email-masked]>
Date: Thu, 19 Jul 2001 09:32:39 +0530 (IST)

On Wed, 18 Jul 2001, Vikas D wrote:

Hi Vinod,
        LSR will not try to establish multiple sessions for the multiple
adjacencies under no conditions. The requirement for "An LSR MUST
advertise the same transport address in all Hellos" is due to the fact if
the LSR advertises diff transport address in diff hello adjacencies, the
role of the LSR will not be defined same on all adjacencies, it may be
active on one while on the other it may be passive. Now when the LSR is
passive on other adjacencies, the peer may try to establish the session,
which may result in setting up multiple session.

Hope this clears ur doubts..
Thanks
Chetan S

---

From: Vikas D <[email-masked]>
Date: Wed, 18 Jul 2001 11:47:53 -0700 (PDT)

All,

Thanks
- Vikas

---

From: "Dennis Hartmann" <[email-masked]>
Date: Fri, 20 Jul 2001 14:01:55 -0400

I could be wrong, but it would seem to me that they are saying different
things.  The latter is saying that we must have an active session (TCP
connection) over which we can advertise label spaces.  The latter is saying
that a LSR which is advertising a label space must have the same transport
protocol.  To relate this to a Cisco environment... We can't advertise the
same label space via two seperate processes (LDP and TDP).  This is most
probably why Cisco uses transport port 711 for TDP and transport port 646
for LDP.  Going by RFC 3036, these two processes can NOT be using the same
address space (to my knowledge, the Tag field in TDP is identical to the
MPLS header).  If true, this would be a limitation while migrating a large
deployment of TDP to LDP.  Each router would need to have statically
assigned label spaces.  I'm sure Rob or Eric will clear this up for us.

Sincerely,

Dennis J. Hartmann
White Pine Consulting
Global Knowledge-MPLS Course Director
http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571
[email-masked]
AOL IM: dennisjhartmann

-----Original Message-----
From: Vikas D [mailto:[email-masked]]
Sent: Wednesday, July 18, 2001 2:48 PM
To: [email-masked]; [email-masked]
Subject: Re: RFC : 3036 : Session establishment for multiple
adjacencies.

All,

Thanks
- Vikas

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

---

From: Eric Gray <[email-masked]>
Date: Fri, 20 Jul 2001 15:49:44 -0400

Dennis Hartmann wrote:

>         I could be wrong,

I suppose.

> but it would seem to me that they are saying different
> protocol.

Which 'latter' is which?

Both are wrong.  Label spaces are 'advertised' using Hello exchanges over
UDP.  Neither says anything about the transport protocol (references are to
the transport address).

> To relate this to a Cisco environment... We can't advertise the
> for LDP.

These are 'listening' ports used by the two signaling protocols and have
nothing really to do with label spaces, per-se.  It is just not reasonable
to attempt to establish an LDP peer relationship using a TDP port.

> Going by RFC 3036, these two processes can NOT be using the same

What do _you_mean by label spaces?

---

From: Eric Gray <[email-masked]>
Date: Fri, 20 Jul 2001 17:34:42 -0400

Dennis,

    See in-line below...

You wrote:

> **Comments in line
>
> Dennis Hartmann wrote:
>
> >         I could be wrong,
>
> I suppose.
>
> **Thanks for the positive affirmation :-)

Certainly, happy to oblige. :-)

> **Latter being the second subject
> **              .............snip..................
> **  "  1. If LSR1 does not already have an LDP session for the exchange
> **       of label spaces LSR1:a and LSR2:b it attempts to open a TCP
> **       connection for a new LDP session with LSR2."
> **             .............snip..................

So, the other 'latter' would be the former?  :-)

> **Think we have some crosstalk here.  That was not my intention.  UDP is a
> **transport protocol.  UDP ports 646 or 711 can be thought of as transport
> **addresses, no?  If not, what are they referring to as a transport address?

In section 2.5.2, of RFC 3036,Transport Address refers either to the address
provided in the "Transport Address TLV" or to the source address in the UDP
packet (in this preference order).  The TLV comes in two flavors: IPv4 and IPv6.

There is no Transport Address TLV for TCP/UDP port number.  See sections 2.5.2
(starting on page 13), 3.5.2 (starting on page 51) and 3.8 (page 82).  If no
Transport Address TLV is provided in the Hello, then the IP source address of
the Hello packet is used in its place.

In a nutshell, if an implementation wants to support the same label space across

multiple interfaces, it either MUST be able to force the source address to be
the
same in all Hello packets sent on any of these interfaces, or it MUST include
Transport Address TLVs in Hellos that would not otherwise have the same
source IP address.

> **True.  That may have been a bit off.  Perhaps they were talking about one
> **label space being advertised over multiple sessions when to physical
> **neighbors have many links between them.
>
> **Label spaces being 2^20=1048576.  Which can also be explicitly set with
> the **label range command.  Label Ranges are exchanged upon initialization
> of **messages during the discovery phase of session establishment between
> LDP **peers.

Exactly what I thought you meant (and why I was earlier lamenting the
naming choice).  In the context of advertising label spaces, label space
is an identifier that is part of an LDP-ID (see sections 2.2.1 and 2.2.2
on pages 9 and 10).

In this context, label space may be used to force multiple transport
connections because TCP transport connections are used in LDP
sessions and LDP sessions are between LDP protocol entities as
identified by the entire LSP-ID.

As described in section 2.5.2, Transport Addresses are either given
in a TLV (if included) or are determined from the packet source IP
address and are used to determine who initiates the TCP connection.
Since this determination is based on a simple comparison, both sides
MUST be comparing the same quantities in order to have a reasonable
expectation that they will both reliably make the same determination.

> > ---

--
Eric Gray

---

From: Vikas D <[email-masked]>
Date: Sun, 22 Jul 2001 11:57:12 -0700 (PDT)

In section 7.2, of the LSP hierarchy draft, a requirement for using
an already existing FA-LSP is:

   "the L3PID of the FA-LSP is compatible with the L3PID of
    the LSP being signaled".

Further, it also states :

  "The PHOP in the message is the address of the LSR at the
   head-end of the FA-LSP.  Before sending the Path/Request
   message, the ERO in that message is adjusted by removing
   the subsequence of the ERO that lies in the FA-LSP, and
   replacing it with just the end point of the FA-LSP."

I guess this requirement holds true ONLY if the egress node for the
tunneled LSP is same as the FA-LSP egress.  This does not hold true
when the (tunneled) LSP egress is beyond the region hosting the
(tunnelling) FA-LSP.

- Vikas

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 22 Jul 2001 15:16:13 -0700 (PDT)

Hi Vikas,

> when the (tunneled) LSP egress is beyond the region hosting the

The requirement holds for any tunneled LSP, whether it terminates
at the egress of the FA or goes beyond.

I'm not sure what role PHOP and ERO adjustment play here.

Kireeti.

---

From: "Dennis Hartmann" <[email-masked]>
Date: Fri, 20 Jul 2001 16:45:25 -0400

**Comments in line

I suppose.

Which 'latter' is which?

---

From: Vikas D <[email-masked]>
Date: Mon, 23 Jul 2001 15:39:09 -0700 (PDT)

Kireeti,

I am not sure if the requirement regarding L3 protocol ID to be same
holds true when the LSP egress is not same as FA egress.  The reason
is that as a "tunneling" LSP, the FA-LSP shall have to handle only
MPLS packets.  That is, packets for which the encapsulation type is
"MPLS Unicast".  FA-LSP does not need to look into the L3 protocol
header, and hence FA-LSP can be protocol agnostic.

The only time the nodes involved in FA-LSP need to look into the L3
header is when the FA-LSP egress is same as "tunneled" LSP egress.

- Vikas