Date: Sat, 22 Feb 2003 01:45:27 -0800
To: "David Allan" <dallan@nortelnetworks.com>
From: raymond zhang <zhangr@info.net>
Subject: Re: Inter AS TE Req'ts draft
Cc: Jean Philippe Vasseur <jvasseur@cisco.com>
Hi Dave,
Thank you very much for your comments. See my comments in lines below.
I wonder if it is ok with you to take this discussion on the tewg
mailing-list ? The chair is concerned in adopting this draft as a wg
document due to not enough comments on the list ?
Regards,
Raymond
At 02:57 PM 2/20/2003 -0500, David Allan wrote:
A few comments...
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.
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. 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.
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)...
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.
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. As a general practice today,
ttl propagation is disabled at the edge of the network. 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.
interesting work...
Thanks for your comments once again.
cheers
Dave