[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Inter AS TE Req'ts draft

Hi Dave,

Please see comments in line...

Regards.
Raymond
At 11:32 AM 2/24/2003 -0500, David Allan wrote:


Hi Raymond:

No issue with moving the discussion to the list....

Snipped down to only discussion points.....

<snip>
> >section 5.2 statement that tools to check LSPs haven't been
> established
> >yet. There's actually a few, Y.1711 would work for TE LSPs
> and provide
> >automated e2e fault detection. LSP_PING would have similar
> capability, but
> >provides a more ambiguous result as it would depend on a
> working return path.
>
> I am not familiar with Y.1711 and will download from ITU site and
> review.  Thanks for suggesting.

If you need any clarifications, consider me a resource....

Surely.. Thanks in advance.
>
> >BTW the draft should mention that the tunnel HE needs to be
> routable inter
> >area and that means the HE address needs to be advertised to
> peer areas. I
> >think this also has implications with respect to the nodeid
> subobject draft.
>
> You mean inter igp areas (ospf) or levels (is-is)... Good
> point. Will
> incorporate.

Yes, I meant inter area(OSPF)/level(ISIS).

> As for the nodeid draft, I assume you are referring to
> "draft-vasseur-mpls-nodeid-subobject-00.txt"... In our
> thinking, this
> draft actually proposes a solution which may be used in
> leaking NHOP in FRR
> where the HE/TE backup tunnels reside in two different ASes
> across the ASBR.

Yes I was referring to that draft. Understood it's applicability to FRR, not sure if there were other implications w.r.t. ensuring that the tunnel head end was properly advertised to other areas/levels so that diagnositic tools had a viable return path.
Right...
Perhaps simply ensuring that there is a viable return path is the requirement. (e.g. if we pursue bi-directional LSPs at some point in the future, a return path is not dependent on the routing system).
Interesting point.  Will consider to include some wording about this...
>
>
> >I'm not sure why you postulate automated diagnosis is
> required (and we're
> >looking at rather strange black hole effects that do not
> appear as link or
> >node outages that would appear only to Y.1711/LSP_PING).
>
> This is actually per requirement from a couple of SP
> contributors to this
> draft. Today, as you know, when the LSP is broken, we have
> to examine hop
> by hop along the path and check if the problem lies with control
> plane/node/link/router/interface events... It is rather
> cumbersome. A tool
> that can provide both data and control information assisting
> isolating the
> trouble areas would be very helpful - that's the level of automation
> (cohesive trouble-shooting tools for both data forwarding and control
> plane)...

Then my question assumed a different interpretation of "automated tool". If by automated, you mean can be executed from a single point in the network by a craftsperson and does not reuqire manual examination of forwarding tables, then I am in complete agreement :-)
Right... We don't mean the sense of automation in your previous comments. That's level of requirement we have so far... Do you have different suggestions in terms of automation ?

> >Section 5.5 Diverse routing between providers may be
> problematic as SRLG
> >admin is not global. Probably less of a problem than I
> imagine as the
> >liklihood of two areas using the same duct while the
> asociated SRLGs are
> >enumerated under different plans is probably not that high.
> Coordinating
> >setup of working and diverse paths would be a bit trickier as graph
> >splitting probably cannot work without a god box.
>
> Indeed, the implementation of which needs to be coordinated
> on a case by
> case basis depending upon the physical path layout.  Not a
> straightforward
> process.
>
> >When considering path protection mechanisms, a reference to
> Y.1720 (1:1
> >and 1+1 protection switching structures for MPLS) may be a useful
> >reference in addition to other multiple path schemes.
>
> Good point.  Will review Y.1720 a bit further and
> incorporate.  Thanks.

Note 1720 is only consented, not a reccomendation as of yet.

Understood...
>
> >section 5.10: This gets interesting w.r.t LSP-PING and GTTP.
> Ideally if
> >you really want to hide stuff while permitting at least some
> superficial
> >testability, you'd need to run a one hop label between ASBR2
> and B such
> >that the intervening topology was hidden from any TTL based
> tools used
> >from A....or depend on one way tools (e.g. Y1711 CV) only
> and obstruct
> >responding to LSP_PING at 'B' for anything outside the local AS.
>
> I am not sure how this "one hop label" may be implemented in this
> case. Would you elaborate it a bit ? Maybe use the label for
> ASBR2 from
> ASBR1 to represent the LSP to B inside AS2.

I was actually thinking that connectivity from ASBR2 to B was overlaid via a single label so that there was only one TTL hop and any traceroute tool would only see ASBR2 and B and no intervening network. Adds some complexity but the alternative is authentication/permissions etc.
Maybe a requirement for tracing loosely routed LSP to a known specific tunnel ending address ?

> As a general
> practice today,
> ttl propagation is disabled at the edge of the network.

Wasn't aware of that. Need to think that one through as it both simplifies and complicates life. Presumably it would introduce a discontinuity in tracing that would have the same effect as my one hop LSP. (e.g. if ttl is overwritten with 255 at an ASBR, then any traceroute would never see details outside of the originating area/level).

> So TTL based tools
> will not able to see the explicit path within a different AS
> expanded by a
> loose ASBR node... By the way, this section is trying to
> scope out the
> requirements where A in AS1 needs to be able to seek an
> optimum path to B
> in AS2 without knowing the details of AS2, as one of the options.

Understood. Presumably ASBR2 owns that problem... ;-)

cheers
Dave