The MPLS WG Archive

[Tony Przygienda <prz@redback.com>]

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.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.
>  ]