Subject: RE: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational

From: Jeff Learman <[email-masked]>
Date: Tue, 03 Jun 2003 10:52:19 -0400

Right, Jeff -- as long as everyone agrees who the DIS is, no
problem.

What if A and B elect B, but C elects A?  B gets left out of
the pseudonode.

For MT, I believe all nodes are required to check protocols
supported.  This is in contrast with Autoencap and 1195.
For 1195, there was no need to check protocols supported,
instead deployment rules were used to avoid routes that
wouldn't work.  For Autoencap, it's necessary for all nodes
to follow the 1195 rules and let nodes at the boundaries of
actual connectivity do the encapsulation.

Philip, isn't this another conflict between MT and Autoencap?

Jeff

At 09:53 AM 6/3/2003, Jeff Parker wrote:
> 
>>  - to share the same DR within the level, always setup adjacency
>>    with everyone on the LAN to elect a stable DR, but label the
>>    adjacency useable or unusable base on the address-family and/or
>>    topology sets. announce or don't announce the adjacency in LSP
>>    accordingly. as long as a system performs backlink checks in
>>    spf computation, this scheme should work just fine.
> 
>Sharing my ignorance again, I'm not sure I understand this.
>
>Assume that we have three routers: 
>
>        A       IPv4 & IP v6
>        B       IPv4
>        C       IPv6
>
>Assume A winds up being DIS.
>B forms adjacency with only A.  Advertises link to PNode
>A forms adjacency with B and C.  A's PNode shows link to A, B, C.  
>C forms adjacency with only A.  Advertises link to PNode
>
>Running the SPF, it isn't enough to look at links: they
>should all be there.  Don't I need to check the protocol
>supported bits in the LSPs as well?
>
>- jeff parker
>_______________________________________________
>Isis-wg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Philip Christian <[email-masked]>
Date: Tue, 3 Jun 2003 16:12:23 +0100 (BST)

> supported

where does it say that ?

MT is required to have multiple SPFs, each that limits
itself to an MT.  Nothing to do with protocols
supported TLV.

MT and autoencap together is actually really powerful.
 You can upgrade only a few nodes to route IPv6, which
would normally be contrary to RFC 1195, but then you
can assign an MT to those nodes and thus run a
separate SPF for IPv6.  Then you can use autoencap to
get rid of the IPv4 at a later time when you want to
put IPv6 only routers in.

Philip

__________________________________________________
Yahoo! Plus - For a better Internet experience
http://uk.promotions.yahoo.com/yplus/yoffer.html
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Tue, 03 Jun 2003 11:39:03 -0400

Right, thanks.  I forgot that the association between protocols and
a topology is a configured thing.  So the inconsistency is merely
whether or not to form adjacencies to nodes you don't have any data
protocols in common with.

At 11:12 AM 6/3/2003, Philip Christian wrote:

>> 
>> For MT, I believe all nodes are required to check
>> protocols supported
>
>where does it say that ?
>

---

From: Philip Christian <[email-masked]>
Date: Tue, 3 Jun 2003 19:38:59 +0100 (BST)

and a rather unnecessary inconsistency at that.  In my
opinion there is no need for the MT draft to state
anything on the subject.

So what do folks think about having one DIS election
(or two if L1 and L2) per network layer protocol on
multi-protocol routers?

There really isn't any disadvantage other than being
slightly different to what we did before.

Philip

 --- Jeff Learman <[email-masked]> wrote: >

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 03 Jun 2003 20:51:51 +0200

>slightly different to what we did before.
and that will interop with existing deployed routers ? I thought that
they look at all the existing routers on the net and then play internal
election. So if an old-style router gets on top in terms of priority,
how do you teach him that he's not 'participating' in a certain
protocol ?

    - tony

---

From: Philip Christian <[email-masked]>
Date: Tue, 3 Jun 2003 22:32:03 +0100 (BST)

It actually works with existing implementations really
well.

Let's do some scenarios.

1. v4v6_old and v4v6_new, v4v6_old is higher priority.
The v4v6_new runs two elections, one for v4 capable
and one for v6 capable.  It looses both to the
v4v6_old and so does not set up a pnode.  The v4v6_old
runs one election and wins it, and so makes a pnode
which advertises the v4v6_new and itself in its LSP.

2. v4v6_old and v4v6_new, v4v6_new is higher priority.
The v4v6_new runs two elections, one for v4 capable
and one for v6 capable.  It wins both and so sets up a
pnode.  Because it won both elections it adds both v4
capable and v6 capable to its LSP, in this case the
v4v6_old, plus itself. The v4v6_old runs one election
and looses it and so doesn't set up a pnode.

3. v4_old, v6_old and v4v6_new, v4_old is highest,
v6_old is lowest
The v4v6_new looses the v4 capable election, but wins
the v6 capable election.  Therefore it sets up a pnode
that mentions only the v6 capable (v6_old and itself)
in the pnode.  The v4_old wins its election and so
sets up a pnode mentioning everybody.  The v6_old
looses and so attaches itself to the v4_old pnode, it
doesn't think that v4v6 should be DIS so that pnode
fails the two way adjacency check and gets ignored by
everybody.  The v4v6_new lost to the v4_old so
attaches itself to the v4_old pnode in its LSPs.

4. v4_old, v6_new and v4v6_new, v4_old is highest,
v6_new is lowest
The v4v6_new looses the v4 capable election, but wins
the v6 capable election.  Therefore it sets up a pnode
that mentions only the v6 capable (v6_new and itself)
in the pnode.  The v4_old wins its election and so
sets up a pnode mentioning v4v6_new and itself.  It
doesn't have adjacency with v6_new so doesn't mention
it.  The v6_new looses and so attaches itself to the
v4v6_new pnode, it doesn't have adjacency with v4_old
and so doesn't include it in the election.  The
v4v6_new lost to the v4_old so attaches itself to the
v4_old pnode in its LSPs.

There are too many scenarios to go through them all
here, but I believe I looked at them all.  They all
work.

In summary a dual node runs two elections.  If it wins
either then it sets up a pnode.  The pnode mentions in
its LSPs everyone that voted for it, so if it wins
both it mentions all v4 capable and all v6 capable,
but if it wins only the v6 election (because a v4
capable was higher priority), then it only mentions v6
capable ISs in the pnode LSPs.

Philip

 --- Tony Przygienda <[email-masked]> wrote: > Philip

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 03 Jun 2003 23:48:12 +0200

>capable ISs in the pnode LSPs.
ok, I tried to understand this tricky business reading your newest
draft again and that will need some discussion in a smaller
implementor's list to weigh the pros vs. the risk.

    thanks

    -- tony