Subject: draft-ietf-mpls-lsp-hierarchy-01 issues

From: "Dovolsky, Dan" <[email-masked]>
Date: Mon, 20 Nov 2000 23:38:58 +0200

BSD.

Hi ,

I am currently trying to implement the draft-ietf-mpls-lsp-hierarchy-01.txt
and facing with following issues:

1.	The draft defines following: 

   "Since LSPs are in general unidirectional, it follows that forwarding
   adjacencies are (by definition) unidirectional links.  Therefore, the
   TE path computation procedures should not perform two-way
   connectivity check on the links used by the procedures."

However, the LSPs are not always unidirectional. At least it might be not
correct for Ethernet network type. So, the path computation has in some
cases check the backward connectivity and in some case has not. In context
of TE Opaque LSAs there are no information, which specifies such a
difference. 
I would like to propose to allocate the new TE Link Option TLV with 4-bytes
long value, which will carry Options bitmask. The one of the bit could be
allocated for FA link type.
Alternatively, the new value for FA-type (3 ?) may be assigned for Link Type
TLV. 

2.	Bi-directional LSPs cannot be established over FA-links. The only
problem is, that the only FA head-end LSR establishes and advertises the
FA-link by TE Opaque LSA, while the tail-end could not establish it.

I would like to offer addition of the following functionality:

The head-end LSR originates it's FA-link Opaque LSA. When the tail-end LSR
receives such a LSA it can check, that this LSA has type "FA" and has the
tail-end address (carried in LinkId TLV) assigned to local Router Id. It
could, in this case, to originate the new FA-link Opaque LSA with tail-end
address set to head-end LSR Id.

In case of bi-directional path computation request, the both FA-link LSAs
have to be found and only in this case this FA-link could be taken as a
candidate link in path computation algorithm.

____________________________________________
Dan Dovolsky
MPLS&IP&ATM products leader 
Virata Corporation
(Formerly Inverness Systems Inc)
24 Kanfei-Nesharim 24/B
Jerusalem 95464, Israel
+972-2-6541734(w)
+972-54-477454(cel)
____________________________________________

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 20 Nov 2000 14:15:26 -0800 (PST)

Hi Dan,

> I am currently trying to implement the draft-ietf-mpls-lsp-hierarchy-01.txt

Super!

> correct for Ethernet network type.

I'm not sure what Ethernet networks have to do with unidirectionality
of LSPs.  LSPs set up according to RSVP-TE, LDP or CR-LDP are always
unidirectional, whether over Ethernet, point-to-point links, or NBMA
links.  draft-ietf-mpls-generalized-signaling-01.txt defines
bidirectional LSPs, but this applies equally to all types of LSPs.

> So, the path computation has in some
> cases check the backward connectivity and in some case has not.

The suggestion is that constraint-based routing (e.g., CSPF) should
*never* do the two-way connectivity, regardless of whether the
underlying links (or FAs) are unidirectional or bidirectional.

> FA-link by TE Opaque LSA, while the tail-end could not establish it.

Good point.  If an FA is bidirectional, it should be advertised by both
the head end and the tail end.  Thanks; we will update the draft to say
this.  (Note that the unnumbered drafts say this, but unfortunately not
the LSP hierarchy draft.)

Kireeti.

---

From: "Dovolsky, Dan" <[email-masked]>
Date: Tue, 21 Nov 2000 10:38:24 +0200

BSD.

Hi Kireeti,

The only one point still seems to me unclear.
I agree, that unidirectional links have to be checked only in one direction.
However, my suggestion is, that in bidirectional case, CSPF has to check 
if there is some link in backward direction between the same pair of
routers. This link should comply to the
same topology/bandwidth constrains like a forward direction link.

If this suggestion is correct, then in bidirectional FA case, CSPF could not
proceed bidirectional path computation 
until backward FA will be established. CSPF should wait until such FA will
be flooded by tail-end LSR. The triger for such 
a FA LSA origination by remote LSR may be receiving of FA LSA originated by
head-end LSR. Note, please, that at this moment
no Path/Request could be sent, because the ERO could not be constructed by
CSPF.

What do you think?

Dan.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tue, November 21, 2000 12:15 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-mpls-lsp-hierarchy-01 issues

Hi Dan,

Super!

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 22 Nov 2000 13:20:06 -0800 (PST)

Hi Dan,

> same topology/bandwidth constrains like a forward direction link.

Let me clarify: in setting up a unidirectional LSP, don't do the
bidirectional check.  Note that the bidirectional check only checks
for *some* reverse link, NOT a matching reverse link.  Check footnote
23 of RFC 2328 for OSPF's view on this.  IS-IS isn't clear on this
point, but I believe most implementations do what the OSPF spec says.

In setting up a bidirectional LSP, CSPF has to change -- this is a
new type of path set up.  CSPF has to compute two paths at once, the
forward path and the reverse path.  Depending on the type of
bidirectional LSP, the requirement on the reverse path may be that it
must follow the matching reverse half-links, or follow any reverse
half link.

> be flooded by tail-end LSR.

How does CSPF know that a particular FA will be used in the computation?
How long does CSPF wait for links/FAs to be announced?

Kireeti.

---

From: "Dovolsky, Dan" <[email-masked]>
Date: Thu, 23 Nov 2000 13:43:08 +0200

BSD.

Kireeti,

1.) I would offer following rule definition:
If establishing of bidirectional LSPs over FAs is required, 
this FA has to be bidirectional, i.e. it itself has to be established by
bidirectional LSP setup.
As it's already defined, unidirectional FAs should not be taken in account
when bidirectional path is computed.

2.) How the "matching reverse half-links" could be clearly defined?

Dan.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Wed, November 22, 2000 11:20 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-mpls-lsp-hierarchy-01 issues

Hi Dan,

Kireeti.