Subject: Fwd: Re: Inter AS TE Req'ts draft

From: raymond zhang <[email-masked]>
Date: Mon, 24 Feb 2003 11:24:16 -0800

Hi,

I am forwarding this correspondence to the list on behalf of Dave (with his 
permission) so that we can carry out this discussion on the list..

Regards,
Raymond

>Date: Sat, 22 Feb 2003 01:45:27 -0800
>To: "David Allan" <[email-masked]>
>From: raymond zhang <[email-masked]>
>Subject: Re: Inter AS TE Req'ts draft
>Cc: Jean Philippe Vasseur <[email-masked]>
>
>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

---

From: raymond zhang <[email-masked]>
Date: Mon, 24 Feb 2003 11:48:30 -0800

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>
> > >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.
> >
>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.
> >
> > incorporate.
>Yes, I meant inter area(OSPF)/level(ISIS).
>
> > As for the nodeid draft, I assume you are referring to
> > 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...

> > >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).
> >
> > 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 ?

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

Understood...

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

---

From: raymond zhang <[email-masked]>
Date: Mon, 24 Feb 2003 15:52:36 -0800

Hi Dave,

> > >provides a more ambiguous result as it would depend on a

I'd like to get back to this point...  An end-to-end automated OAM 
mechanism over LSP in Y.1711 sounds indeed very interesting.  Now I 
understand the working return path issue brought forth by LSP_PING.  I am 
sure this has been discussed in the ITU wg but I am a bit concerned as to 
how scalable would this be since for the most cases, these LSPs are 
terminated at P/PE devices...  If implemented, it may be turned on as 
needed basis should some LSP path become chronically unstable ?

The other question is how to extend this over AS boundaries with revealing 
network details in a loose LSP path ?

Regards,
Raymond