Support as co-author. I am not aware of any IPR associated with this draft.
Ning
From: Alia Atlas <[email protected]>
To: [email protected]
Subject: poll on adopting draft-symmvo-rtgwg-cl-use-cases-00 as WG
draft
Message-ID:
<cag4d1re2my6-tiapwfp_qymdp7+umefapkhafzodxhk6aos...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
This is to start a poll and discussion about whether RTGWG should adopt
draft-symmvo-rtgwg-cl-use-cases-00 as a WG draft.
Please respond with comments and reasoning and if you have read the draft.
At our last meeting, very few people indicated that they had read the draft.
Authors, please indicate in email whether there is any IPR associated
with the draft.
Thanks,
Alia
------------------------------
Message: 4
Date: Tue, 12 Jun 2012 16:39:20 -0400
From: Alia Atlas <[email protected]>
To: [email protected]
Subject: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG
draft
Message-ID:
<cag4d1rf6x2u55iddngk4hwd-ozbrpexmyh4hyl9r-ao6tgo...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
This email is to start a poll and discussion on whether to adopt
draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft.
Please respond with opinions, comments, and whether you have read the draft.
Last IETF, there were very few people who had read the draft.
Authors, please indicate if there is any IPR associated with this draft.
Thanks,
Alia
Message: 10
Date: Wed, 13 Jun 2012 13:31:02 +0900
From: "Andrew G. Malis" <[email protected]>
To: Alia Atlas <[email protected]>
Cc: [email protected]
Subject: Re: poll to adopt draft-so-yong-rtgwg-cl-framework-05 as a WG
draft
Message-ID:
<CAA=duU1BcD7-Lh9EfnuA0XJL=+XyJTMVJxUSYC=c_jjboex...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I have read the draft and I support! Plus I am not aware of any IPR in
this draft.
Cheers,
Andy
On Wed, Jun 13, 2012 at 5:39 AM, Alia Atlas <[email protected]> wrote:
> This email is to start a poll and discussion on whether to adopt
> draft-so-yong-rtgwg-cl-framework-05 as an RTGWG draft.
> Please respond with opinions, comments, and whether you have read the draft.
> Last IETF, there were very few people who had read the draft.
>
> Authors, please indicate if there is any IPR associated with this draft.
>
> Thanks,
> Alia
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
------------------------------
Message: 11
Date: Wed, 13 Jun 2012 11:22:44 +0200
From: Andr?s Cs?sz?r <[email protected]>
To: Alia Atlas <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: RE: poll on draft-karan-mofrr-02 to become a WG draft
Message-ID:
<8dcd771bda4a394e9bcba8932e839297783e30f...@esesscms0363.eemea.ericsson.se>
Content-Type: text/plain; charset="utf-8"
Hi Alia,
MoFRR to me is a kind of applying the LFA idea to multicast, and also given
that implementations already exist (for quite some time now, if I'm correct), I
do support it.
Trying to be constructive again, I would give some feedback for this one, too
:-)
1. I suggest a little more glue between the text in chapter 7 (non-ECMP mode
MoFRR) and the LFA spec. Non-ECMP mode seems very much like the LFA rules, yet
they are redefined, which is not a problem, but I'd prefer having a similar
notation/syntax/terminology and rules as far as possible. If there are
differences, they should be highlighted.
2. Chapter 5, detecting failures. I think we should try to give a little more
details. Packet comparison details, what needs to be stored? Complete packet?
Packet hash? RTP seq number? ...
I think the "third option", to rely on IGPs is by definition not FRR, so this
should be the last option.
The fourth option is "leveraging connected link failure". I think this option
could be the easiest/most natural approach, and I guess since LoS, BFD and any
local DP failure detection mechanism is usually tied already to unicast FRR,
why not propose this to be the primary option for MoFRR, too?
3. Chapter 10: "The MoFRR principle may be applied to MVPNs." Let's give more
details, if possible.
4. Due to mLDP, probably the MPLS WG chairs should be involved, too, not only
PIM.
5. Why is the intended status "informational"? Why should it be different from
LFA or remote LFA? I agree the solution practically does not require any novel
cooperation method from other nodes, which is an advantage, so there is little
to be a "Standard", but that's true for LFA or RLFA as well. So?
6. We often used the terminology "live-live" in other drafts, such as in MRT. I
actually thought that it came from MoFRR, but now I did find no trace of it in
the doc. Maybe we should add a sentence about it, saying that MoFRR implements
what is often called "live-live" protection.
I started to realise I'm often too long, sorry for that :-)
Andr?s
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Alia Atlas
> Sent: 2012. j?nius 12. 22:42
> To: [email protected]; [email protected]
> Subject: poll on draft-karan-mofrr-02 to become a WG draft
>
> This email is to start a poll and discussion on whether
> draft-karan-mofrr-02 should
> become an RTGWG draft. Please include comments, details, and whether
> you have
> read the draft.
>
> The earlier version was presented positively to the PIM WG as well.
>
> Authors, please indicate whether there is any IPR associated with this
> draft.
>
> Thanks,
> Alia
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
------------------------------
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
End of rtgwg Digest, Vol 90, Issue 15
*************************************
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
