Subject: [rbridge] Fwd: Re: [Isis-wg] WG last call on draft-ietf-trill-adj-01.txt

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Jan 2011 09:44:00 -0800

Forwarded from the isis list so all the trill discussion is visible on 
the rbridge list.

    Erik

-------- Original Message --------
Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-01.txt
Date: Tue, 18 Jan 2011 12:44:53 +0000
From: mike shand <[email-masked]>
To: [email-masked]

  To be absolutely clear on this, perhaps the text should also describe
what the non DRBs do. I appreciate that the example includes this,
but it is somewhat anomalous that the normative text describes the
changed actions of the DRB, but not (explicitly) those of the non-DRBs.

So how about:-

"If the DRB sets the bypass pseudonode bit in its TRILL
    LAN Hellos, the RBridges on the link (including the DRB) just
directly report all their
    adjacencies on the LAN that are in the Report state. If the DRB does
not set the
    bypass pseudonode bit in its TRILL Hellos, then (as in ISO/IEC
10589) it sends LSPs on behalf of the pseudonode, and all RBridges
report only their adjacency to the pseudonode. Setting the bypass
pseudonode bit has no effect on how LSPs
    are flooded on a link. It only affects what LSPs are generated."

     Mike

On 15/01/2011 22:45, Les Ginsberg (ginsberg) wrote:
>> 6. Pseudonodes
>> >
>> >      The Designated RBridge (DRB), determined as described above,
>> >  controls
>> >      whether a pseudonode will be used on a link.
>> >
>> >      It is anticipated that many links between RBridges will actually be
>> >      point-to-point, in which case using a pseudonode merely adds to the
>> >      complexity. If the DRB sets the bypass pseudonode bit in its TRILL
>> >      LAN Hellos, the RBridges on the link just directly report their
>> >      adjacencies that are in the Report state. If the DRB does not set
>> >  the
>> >      bypass pseudonode bit in its TRILL Hellos, then it specifies a
>> >      pseudonode for the link and sends LSPs on behalf of the pseudonode
>> >  as
>> >      usual. Setting the bypass pseudonode bit has no effect on how LSPs
>> >      are flooded on a link. It only affects what LSPs are generated.
>> >
>> >  LES: The phrase "specifies a pseudo-node for the link" suggests that
>> >  the LANID sent by the DRB may be different depending on whether the
>> >  bypass pseudo-node bit is set or not. Do you really mean that?
>> >
>> >  <DEE3>  No, it is not meant to imply that. How about, "..., then the
> LAN
>> >  ID in the DRB's Hellos specifies the pseudonode for the link and the
>> >  DRB sends ..."
>> >
>> >  he DRB does not set the
>> >      bypass pseudonode bit in its TRILL Hellos, then it specifies a
>> >      pseudonode for the link and sends LSPs on behalf of the pseudonode
>> >  as
>> >      usual. Setting the bypass pseudonode bit has no effect on how LSPs
>> >      are flooded on a link. It only affects what LSPs are generated.
>> >
> If we agree that the contents of the LANID field are not affected by the
> state of the bypass bit - which I think we do - then I think removing
> the phrase is the best thing to do.
>
>     Les
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Jan 2011 09:43:39 -0800

Erik

-------- Original Message --------
Subject: Re: [Isis-wg] [rbridge] WG last call on draft-ietf-trill-adj-01.txt
Date: Tue, 18 Jan 2011 13:36:48 +0000
From: mike shand <[email-masked]>
To: [email-masked]

  Vishwas,
     If the consequences of failure for this information to be correctly
exchanged, as a result of loss a single message, are that "bad things
happen", then I don't think it can be considered an optimization to
provide a mechanism which guarantees correct delivery.

     An optimization, in my view, is something like the sending of CSNPs
on pt-pt circuit start up. If they are correctly received the
synchronization process is speeded up, but if they are not, correct
synchronization is still guaranteed to occur, albeit at the expense of
further message exchanges.

     What am I failing to understand? How likely is a failure scenario,
and what is the extent of the damage caused? It is a truism that if
something CAN go wrong it WILL go wrong just at the point where it will
cause maximum disruption. The Boston Hospital meltdown is but one of the
oft cited examples of this phenomenon.

     Mike

On 14/01/2011 22:25, Vishwas Manral wrote:
> Hi Les,
>
> You have good comments.
>
> Like I said we could send the same information multiple times to
> assume the information has reached its neighbor. If the information is
> in one Hello we already have the solution.
>
> I agree this can be improved, however I feel we do not need to do
> every optimization at this point.
>
> Thanks,
> Vishwas
>
>>>>> VM>  I agree with you. It is left to an implementation to decide how
>>> to
>>>>> do it.
>>>> OK. I do think some guidance would be good as the use of MTU PDUs is
>>> an entirely new functionality.
>>> VM>  A clarification could be added.
>>>
>>>> To requote the draft:
>>>>
>>>> " If there are no adjacencies with a non-zero Designated VLAN Hello
>>>>    Holding timer, an empty TRILL Neighbor TLV MUST be included in each
>>>>    Hello.  If there are such adjacencies, then the Hello MAY contain a
>>>>    TRILL Neighbor TLV..."
>>>>
>>>> I understand the motivation for an explicit "no neighbors"
>>> advertisement - but I am asking why you want to make inclusion of TRILL
>>> Neighbor TLV optional when you do have adjacencies?
>>> VM>  This can again be treated in the context of the fact that if the
>>> data does not fit in one Hello, we could send the other data in the
>>> other Hello, and include empty TRILL Neighbor TLV. It could also be
>>> treated in the context of the fact that we should allow receiving the
>>> empty TLV.
>>>
>>> I know this could be removed by itself, as there is no harm or benefit
>>> of the same, based on how the spec stands, however it could help to
>>> state that for some future use like mentioned above.
>>>
>>> Thanks,
>>> Vishwas
>>>
>>>>>>> On Thu, Jan 13, 2011 at 5:36 PM, Les Ginsberg (ginsberg)
>>>>>>> <[email-masked]>  wrote:
>>>>>>>> (resending w corrected TRILL WG address)
>>>>>>>>
>>>>>>>> Attached please find my comments on draft-ietf-trill-adj-01.
>>>>>>>>
>>>>>>>> The file draft-ietf-trill-adj-01_comments.txt contains
>>> substantive
>>>>>>>> comments identified by Section # - except in a couple of cases
>>>>> where
>>>>>>> the
>>>>>>>> remarks are more generic.
>>>>>>>>
>>>>>>>> The file draft-ietf-trill-adj-01_editorial.txt is portions of
>>> the
>>>>>>> draft
>>>>>>>> annotated with editorial comments. Search for "LES:" in the
>>> file.
>>>>>>>> As context, the requirements of [TRILL] introduce the need to
>>> send
>>>>> a
>>>>>>>> great deal more circuit scoped information on a LAN as compared
>>> to
>>>>>>> Layer
>>>>>>>> 3 IS-IS. Extensions to the IS-IS protocol defined in [TRILL],
>>>>>>>> [TRILL-ISIS], and [TRILL-ADJ] are designed to support this new
>>>>>>>> information and to provide robust loop prevention in the
>>>>> forwarding
>>>>>>> of
>>>>>>>> data. But I believe the extensions as currently defined have
>>>>>>> significant
>>>>>>>> scalability issues in the presence of a large number of
>>> neighbors
>>>>> on
>>>>>>> a
>>>>>>>> LAN and/or a large number of enabled VLANs. In my comments I
>>> have
>>>>>>>> confined myself to pointing out where I believe such issues
>>> arise.
>>>>> If
>>>>>>>> there is consensus that these are issues which should be
>>>>> addressed,
>>>>>>> then
>>>>>>>> additional discussions can be started as to how to do so.
>>>>>>>>
>>>>>>>> Finally, I would like to thank the authors of draft-ietf-trill-
>>>>> adj-01
>>>>>>>> for the effort and diligence they obviously applied to the
>>> writing
>>>>> of
>>>>>>>> this draft.
>>>>>>>>
>>>>>>>>    Les
>>>>>>>>
>>>>>>>>