Subject: [Isis-wg] Re: draft-zinin-flood-opt-01.txt (was draft-ietf-zinin-flood-opt-01.txt)

From: Alex Zinin <[email-masked]>
Date: Tue, 31 Oct 2000 11:16:07 -0800

Curtis:

>> 3. Do we need it of we do bundling in a cooler way.
>> 
>>    First, let me emphasize that the approach in this draft
>>    is not specific to optical networks, so you may have
>>    parallel links btw normal routers and still not want to
>>    do any type of bundling (just because you don't like that
>>    "right" bundling approach, or whatever ;)).
>> 
>>    Second, even if bundling is used in optical networks,
>>    you may have a number of bundles, each assigned to its
>>    control channel, and there maybe more than one control
>>    channel btw boxes, so you hit the same problem.

> My understanding of LMP is that it is moving toward one control
> channel for as many bundles as exist between a given router and PXC or
> PXC to PXC (I should say network element to network element that
> sounds so ITU/ISOish :).  This would also mean one IGP adjacency with
> the PXC for many bundles.

Not exactly like this.
We are removing the 1-to-1 correspondence between the bundle and
the control channel, so it will be possible to have one CC for
more than one bundle, but there will be no limitation on the number
of control channels between two OXCs.

> The point is that we could do a much better job of bundling and if we
> did, the zinin-flood stuff would be a good optimization to have handy
> but would not be needed as a result of a bad job designing bundling.

As, I think, we both understand, one does not eliminate the other.

>> 4. FAs, etc.
>> 
>>    The concept of FAs includes the possibility for it to
>>    be announced as native IGP adjacency, and even without
>>    Hellos being exchanged. I actually do not think we need
>>    to exchange Hellos. Just recall how VLs work in OSPF.

> You are right that the hellos are not really needed.  I did mention
> that some people like the idea of some sort of continuity check over
> the FA.  A OSPF packet with TTL 1 or non-routeable ISIS PDU would tell
> us that we really do have bits flowing and not just signaling.

TTL 1 will not work in MPLS networks, since LSRs may decrement
the TTL in shim header.
In ISIS, an end-to-end IIH will require ISIS-in-IP encapsulation,
since one cannot expect CLNS routing in an IP-ISIS domain.

>   For
> this reason I think we should reccommend that it be possible to send
> hellos.  The alternative is to send no IGP signaling at all and just
> advertise one end of the adjacency when the RESV arrives.

I think this is the current understanding of the FA concept.

> Hellos also
> assume/assure that there is a one hop reverse path.

> A possible problem with a unidirectional advertisement with no hello
> is that if the other end goes down completely, it doesn't withdraw
> unidirectional adjacencies going out from the down LSR (because it is
> gone) and its FA neighbors don't withdraw FA adjacencies going into
> the down LSR and we have apparent hops (in the IGP) both in and out.

Before using an FA in your [C]SPF, you're supposed to check if
the node is reachable via the control plane at all.

> Other means exist to get rid of the advertisements such as SONET
> and/or PPP detecting the error in an optical path, or SONET/PPP on the
> physically adjacent link going down and PathError and/or avertised IGP
> infeasibility of the path that the FA-LSP is taking.

> The hellos avoid failing to detect a LSR along the path with a bad set
> of label mappings.  Some people are asking for this (having been
> burned by this sort of problem with ATM switches).

I see your point.
Note, however, that we cannot always assume that we can send IP
packets over an LSP, since it may have been established for
X-o-MPLS... I would vote for making the LSP end-to-end testing
independent of the routing protocol.

> ps - currently my mail to the OSPF list is not going through.

It is, actually.

Regards,

Alex.

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg