The MPLS WG Archive

[Naiming Shen <naiming@redback.com>]

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