Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE

From: Jeff Parker <[email-masked]>
Date: Fri, 23 Jun 2000 10:05:59 -0400

> Folks,
> 
> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
> be accepted as a work group document.  So far I've only seen support.
> If there are no objects by 6/27, we'll declare it so.
> 
> ...George

I find this draft a useful addition to the discussion of TE, and would
support it's adoption as an MPLS group document.

However, I am a bit puzzled by the last paragraph before
section 4.3 (bottom of page 5).

	"Route computation procedures should not perform two-way
	 connectivity check on the links used by the procedures.
	 That is, the two way check should not be performed on
	 one-way pipes, as they will fail."

I agree that relaxing this test for one-way links is a Good Thing.  But 
looking at the aged out draft "IS-IS extensions for Traffic Engineering"
<draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish 
"forward adjacencies" that are unidirectional LSPs from point-to-point 
adjacencies, where we should retain the test.  

Perhaps this will be addressed in the next rev of the IS-IS TE doc.  

- jeff parker
- Lucent Technologies

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Fri, 23 Jun 2000 14:49:29 -0700

don't want to speak for the authors, but the difference from a
disabled TE link is that this LSP link has a usable TE metric set.
this hierarchy scheme is independent of LSP bundling, you can announce
and set different metric on different LSPs the same source/dest pair.
so i don't see why the Mux TLV should be required.

an interesting question is how do you set the link metric to
be max(1, (the TE metric of the FA-LSP path) - 1)? something like
the one mentioned in an expired draft:-)

thanks.

 ]Naiming Shen wrote:
 ]
 ]> I think you can use the cue which normal IS-IS ignores this type of
 ]> links, which is the links are having the default metric of (2^24 - 1).
 ]
 ]there is a chance to confuse that with a disabled TE link of course.
 ]Also (although that's minor) it's a disadvantage that if i choose not to
 ]support LSP bundling. I'd loose control about which of the forwarding
 ]adjacencies other LSRs prefer based on admin metric.
 ]
 ]It seems to me much wiser to use the presence of the Link Mux Capability sub-
TLV
 ]as indication that only a one-way check is necessary. I assume that
 ]sub-TLV is mandatory on forwarding adjacencies, the draft is not 100%
 ]clear about that one.
 ]
 ]    any clarification from the authors ?
 ]
 ]    -- tony
 ]
 ]
 ]>
 ]>
 ]>  ]> Folks,
 ]>  ]>
 ]>  ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.t
xt
 ]>  ]> be accepted as a work group document.  So far I've only seen support.
 ]>  ]> If there are no objects by 6/27, we'll declare it so.
 ]>  ]>
 ]>  ]> ...George
 ]>  ]
 ]>  ]I find this draft a useful addition to the discussion of TE, and would
 ]>  ]support it's adoption as an MPLS group document.
 ]>  ]
 ]>  ]However, I am a bit puzzled by the last paragraph before
 ]>  ]section 4.3 (bottom of page 5).
 ]>  ]
 ]>  ]      "Route computation procedures should not perform two-way
 ]>  ]       connectivity check on the links used by the procedures.
 ]>  ]       That is, the two way check should not be performed on
 ]>  ]       one-way pipes, as they will fail."
 ]>  ]
 ]>  ]I agree that relaxing this test for one-way links is a Good Thing.  But
 ]>  ]looking at the aged out draft "IS-IS extensions for Traffic Engineering"
 ]>  ]<draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish
 ]>  ]"forward adjacencies" that are unidirectional LSPs from point-to-point
 ]>  ]adjacencies, where we should retain the test.
 ]>  ]
 ]>  ]Perhaps this will be addressed in the next rev of the IS-IS TE doc.
 ]>  ]
 ]
 ]
 ]

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Fri, 23 Jun 2000 08:27:43 -0700

I think you can use the cue which normal IS-IS ignores this type of
links, which is the links are having the default metric of (2^24 - 1).

 ]> Folks,
 ]> 
 ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
 ]> be accepted as a work group document.  So far I've only seen support.
 ]> If there are no objects by 6/27, we'll declare it so.
 ]> 
 ]> ...George
 ]
 ]I find this draft a useful addition to the discussion of TE, and would
 ]support it's adoption as an MPLS group document.
 ]
 ]However, I am a bit puzzled by the last paragraph before
 ]section 4.3 (bottom of page 5).
 ]
 ]	"Route computation procedures should not perform two-way
 ]	 connectivity check on the links used by the procedures.
 ]	 That is, the two way check should not be performed on
 ]	 one-way pipes, as they will fail."
 ]
 ]I agree that relaxing this test for one-way links is a Good Thing.  But 
 ]looking at the aged out draft "IS-IS extensions for Traffic Engineering"
 ]<draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish 
 ]"forward adjacencies" that are unidirectional LSPs from point-to-point 
 ]adjacencies, where we should retain the test.  
 ]
 ]Perhaps this will be addressed in the next rev of the IS-IS TE doc.  
 ]
 ]- jeff parker
 ]- Lucent Technologies
 ]
 ]
 ]_______________________________________________
 ]Isis-wg mailing list  -  [email-masked]
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 23 Jun 2000 11:07:19 -0700

> links, which is the links are having the default metric of (2^24 - 1).

there is a chance to confuse that with a disabled TE link of course.
Also (although that's minor) it's a disadvantage that if i choose not to
support LSP bundling. I'd loose control about which of the forwarding
adjacencies other LSRs prefer based on admin metric.

It seems to me much wiser to use the presence of the Link Mux Capability sub-TLV
as indication that only a one-way check is necessary. I assume that
sub-TLV is mandatory on forwarding adjacencies, the draft is not 100%
clear about that one.

    any clarification from the authors ?

    -- tony