Subject: Re: [Isis-wg] Proposed drafts to become WG documents[draft-shen-isis-oper-enhance-00, draft-amante-isis-reverse-metric-02]

From: <[email-masked]>
Date: Wed, 4 May 2011 12:06:00 +0200

Support both

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Hopps
Envoyé : mercredi 27 avril 2011 15:32
À : [email-masked] list
Cc : Christian Hopps
Objet : [Isis-wg] Proposed drafts to become WG documents[draft-shen-isis-oper-enhance-00,draft-amante-isis-reverse-metric-02]

During IETF 79 the following drafts were presented to the WG and a request to make them WG documents was not met with objection. Are there objections on the list to the following drafts becoming isis-wg documents?

http://tools.ietf.org/html/draft-shen-isis-oper-enhance-00
http://tools.ietf.org/html/draft-amante-isis-reverse-metric-02

Thanks,
CHopps & DWard.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Mohan Nanduri <[email-masked]>
Date: Wed, 4 May 2011 22:41:47 -0400

support adoption of both.

On Wed, Apr 27, 2011 at 9:32 AM, Christian Hopps <[email-masked]>wrote:

> During IETF 79 the following drafts were presented to the WG and a request
> to make them WG documents was not met with objection. Are there objections
> on the list to the following drafts becoming isis-wg documents?
>

---

From: CAUCHIE Grégory <[email-masked]>
Date: Thu, 19 May 2011 11:17:39 +0200

Hi everyone,

I don't have any opposition to these drafts becoming working group 
documents, I think even more that these are useful options for operations.

I just have one comment question about draft-shen-isis-oper-enhance. On 
one hand, I think having the possibility of pseudo-nodes sending metrics 
other than 0 is a useful idea. On the other hand, I am not sure to see 
the interest/benefit of the "Fast exit notification". IINM, the need is 
to take down one IS-IS adjacency without creating any traffic blackhole, 
and not to deal with taking down IS-IS as a whole on the node. If that's 
right, than I am not sure to see the value brought by "Fast exit 
notification".
As stated in the draft, when an adjacency is either unset or disabled on 
one end of a point-to-point link, several second elapse before the timer 
expire on the other end of the link to bring down the adjacency and then 
update+flood the LSP.
First I don't see why there would then be a blackhole of traffic as the 
node LSDB is not supposed to be flushed (remembering that the need is 
just to bring one adjacency down, not the entire IS-IS config/status), 
so the node should be able to forward the traffic it receives until the 
adjacent nodes react to the adjacency status change and update the rest 
of the network. Therefore no blackhole would be created. Am I missing 
something here?
Second, as IS-IS convergence is a great deal for us SPs, we usually 
enable BFD on IS-IS adjacency to detect adjacency status change under 
the order of the second. Even though this may still not be sufficient 
enough, I am  surprised not to see it mentionned in the draft and tend 
to think it could be of good for the draft to say something about it, 
whatever the answer to my previous point is.

Regards,

Greg

Le 27/04/2011 15:32, Christian Hopps a écrit :
> CHopps&  DWard.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 27 May 2011 10:01:26 -0400

Having received no objections, we will move forward with making these drafts WG documents.

Thanks,
CHopps & DWard.