[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
Hi, Tochio and Yuji Kamite,
I agree with the description of reverse traffic should be relaxed here, and
I appreciate the consideration of the reverse traffic requirements.
IMO, there are several options to achieve the reverse traffic in VPMS
instance, such as VPMS(forward traffic)+P2P(reverse traffic), VPMS(forward
traffic)+mp2p instance(reverse traffic), also may be bidirectional
VPMS(should redefine VPMS maybe).Actually, we have taken the implementation
of the reverse traffic into account. And a bidirectional VPMS instance
should be a better method IMO.
Here bidirectional VPMS should be defined as P2MP (forward
traffic)+multi-p2p(backward traffic).
What about your opinion?
Anyway, I appreciate the further work for reverse traffic and will be
concerned about it.
Regards
Sherry
Quote
{> <<Clause 6.1.3>>
> I-D says:
> The simplest way to accomplish this is to provide
> different VPMS instances for reverse traffic, i.e. a sender CE is a
> receiver of another VPMS instance.
>
> Since there are some alternatives for this way such that
> providing multiple VPWS (as reverse) or mp2p instance So I
> ask for relaxing the descrption, i.e. replace "the simplest
> way" by "the example"
>
>Agreed.
> I-D says:
> Such bi-directional instances can be easily created if two
> distinct ACs are provisioned for sending and receiving exclusively
>
> I am not sure this assumption (= exclusively) is easiest.
> I also ask for relaxing the descrption.
>
>
>It mostly depends on the implementation matter if a particular
>approach is the easiest or not, so I'll edit it
>not to cause misunderstanding.
Basically, I guess exlusive using (Tx and Rx) might be easy from
PE perspective, but from CE's view it could not be so simple.
Anyway, authors now think that the consideration of reverse traffic
needs more study. We're proposing new text in the next revision.}
> -----Original Message-----
> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On Behalf Of
> Yuji KAMITE
> Sent: Tuesday, July 07, 2009 7:15 PM
> To: tochio at labs.fujitsu.com; l2vpn at ietf.org
> Subject: RE: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
>
> Hi, Mr. Tochio,
>
> Thank you for your interest and reviewing.
> I wrote comments below inline.
>
> >
> > Dear Editors and all,
> >
> > FYI:
> > Here are my comments on this I-D through offline discussion
> > with Yuji (Mr. Kamite) though some had been posted by Greg
> >
> > <<Clause 4.3>>
> > I-D says:
> > As far as synchronization in a PSN environment is concerned,
> > different mechanisms can be considered to provide frequency
> > and phase clock
> >
> > "clock" should be replaced by "synchronization"
> > Or in generic manner, "to provide frequency and phase clock "
> > may be removed.
> >
>
> Ok, I'll change the word to avoid confusion.
>
>
> >
> > <<Clause 6.1.2 (& 6.4)>>
> > In general, It seems that contents of those clauses are
> > overlapped to each other so that editorial clean up should be
> > required.
> >
> > I think first these sentences are enough in 6.1.2 and the
> > rest of those in 6.1.2 with figure 2 should be merged to 6.4
> >
>
> I'm going to merge it.
>
>
> > A solution MUST support multiple sender topologies in one
> > VPMS instance, where a common receiver group is reachable
> > from two or more senders. This means that a solution needs to
> > support having multiple P2MP topologies in the backbone whose
> > roots are located apart in a common service. Thus a solution
> > will also need to support protection and restoration
> > mechanism combining these multiple P2MP topologies. (See
> > section 6.4 too).
> >
> >
> > And even if in clause 6.1.2., more clarification of Figure 2
> > should be considered. The most important is to clarify AC3 &
> > 4 or PE3 & PE4.
> > AC3 or 4 seems to share VPMS instance from either PE1 or PE2.
> > This point should be clarified.
> >
> > For example, proposed is
> >
> > Replace
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4 too).
> >
> > by
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. In the case of Figure 2, PE3 and
> > PE4 should select traffic from PE1 or PE2 and AC3 and AC4
> > should be single as attached to PE3 and PE4 respectively.
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4.2 too).
> >
> > Of cource, this could be better in align with 6.4.1.2
> >
>
> What you mean by "traffic selection" makes sense.
> This point will be described in the next revision.
> It will still need some of wording arrangement though.
>
>
> >
> > <<Clause 6.1.3>>
> > I-D says:
> > The simplest way to accomplish this is to provide
> > different VPMS instances for reverse traffic, i.e. a sender CE is a
> > receiver of another VPMS instance.
> >
> > Since there are some alternatives for this way such that
> > providing multiple VPWS (as reverse) or mp2p instance So I
> > ask for relaxing the descrption, i.e. replace "the simplest
> > way" by "the example"
> >
>
> Agreed.
>
> > I-D says:
> > Such bi-directional instances can be easily created if two
> > distinct ACs are provisioned for sending and receiving exclusively
> >
> > I am not sure this assumption (= exclusively) is easiest.
> > I also ask for relaxing the descrption.
> >
> >
>
> It mostly depends on the implementation matter if a particular
> approach is the easiest or not, so I'll edit it
> not to cause misunderstanding.
>
> Basically, I guess exlusive using (Tx and Rx) might be easy from
> PE perspective, but from CE's view it could not be so simple.
>
> Anyway, authors now think that the consideration of reverse traffic
> needs more study. We're proposing new text in the next revision.
>
>
> > <<Clause 6.1.4>>
> > In general, I think these subclauses should focus on
> > - Protetion/redundancy topology support as 6.1.4.1
> > - Traffic support in Protetion/redundancy as 6.1.4.1 As I
> > wrote above, this is overlapped with 6.1.2 Figure 2 should be
> > moved here and text should be merged with latter of 6.1.2
> >
>
> Agreed with your idea in general.
>
> I'd appreciate it if you could check again
> when we submit the next version.
>
>
> >
> > <<Clause 6.1.4.1>>
> > There are some areas that form protection/redundancy:
> > (1) (Sender) CE to (Sender/Ingress) PEs
> > (2) VPMS instances or inside PSN
> > (3) (Receiver) PEs to Receiver CE
> >
> > This clause should indicate this point, where
> > protection/redundancy is required. (The use of dual home may miss (2))
> >
>
> I'll make sure the next revision will explain
> the category of the protection briefly .
>
> Regarding (2), I think it needs to describe something for detail:
>
> "VPMS instance": This requirement is related to the PW signaling
> (and discovery etc) between PE nodes.
> Hence this will have common aspect of (1)/(3) in terms of solution level.
>
> "Inside PSN": This requirement will be satisfied by PSN protection
mechanism.
>
>
> >
> > <<Clause 6.1.4.2>>
> > As I wrote above, this is overlapped with 6.1.2 Figure 2
> > should be moved to this clause here and text should be merged
> > with latter of 6.1.2
> >
>
> All right.
>
>
> >
> > Regards,
> > Yuji Tochio
> >
> >
>
> Thanks.
>
> Best ragards,
> Yuji Kamite
>
>
> > -----Original Message-----
> > From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org]
> > On Behalf Of Yuji Tochio
> > Sent: Tuesday, June 09, 2009 8:21 PM
> > To: l2vpn at ietf.org
> > Subject: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
> >
> > Dear Editors and all,
> >
> > FYI:
> > Here are my comments on this I-D through offline discussion
> > with Yuji (Mr. Kamite) though some had been posted by Greg
> >
> > <<Clause 4.3>>
> > I-D says:
> > As far as synchronization in a PSN environment is concerned,
> > different mechanisms can be considered to provide frequency
> > and phase clock
> >
> > "clock" should be replaced by "synchronization"
> > Or in generic manner, "to provide frequency and phase clock "
> > may be removed.
> >
> >
> > <<Clause 6.1.2 (& 6.4)>>
> > In general, It seems that contents of those clauses are
> > overlapped to each other so that editorial clean up should be
> > required.
> >
> > I think first these sentences are enough in 6.1.2 and the
> > rest of those in 6.1.2 with figure 2 should be merged to 6.4
> >
> > A solution MUST support multiple sender topologies in one
> > VPMS instance, where a common receiver group is reachable
> > from two or more senders. This means that a solution needs to
> > support having multiple P2MP topologies in the backbone whose
> > roots are located apart in a common service. Thus a solution
> > will also need to support protection and restoration
> > mechanism combining these multiple P2MP topologies. (See
> > section 6.4 too).
> >
> >
> > And even if in clause 6.1.2., more clarification of Figure 2
> > should be considered. The most important is to clarify AC3 &
> > 4 or PE3 & PE4.
> > AC3 or 4 seems to share VPMS instance from either PE1 or PE2.
> > This point should be clarified.
> >
> > For example, proposed is
> >
> > Replace
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4 too).
> >
> > by
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. In the case of Figure 2, PE3 and
> > PE4 should select traffic from PE1 or PE2 and AC3 and AC4
> > should be single as attached to PE3 and PE4 respectively.
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4.2 too).
> >
> > Of cource, this could be better in align with 6.4.1.2
> >
> >
> > <<Clause 6.1.3>>
> > I-D says:
> > The simplest way to accomplish this is to provide
> > different VPMS instances for reverse traffic, i.e. a sender CE is a
> > receiver of another VPMS instance.
> >
> > Since there are some alternatives for this way such that
> > providing multiple VPWS (as reverse) or mp2p instance So I
> > ask for relaxing the descrption, i.e. replace "the simplest
> > way" by "the example"
> >
> > I-D says:
> > Such bi-directional instances can be easily created if two
> > distinct ACs are provisioned for sending and receiving exclusively
> >
> > I am not sure this assumption (= exclusively) is easiest.
> > I also ask for relaxing the descrption.
> >
> >
> > <<Clause 6.1.4>>
> > In general, I think these subclauses should focus on
> > - Protetion/redundancy topology support as 6.1.4.1
> > - Traffic support in Protetion/redundancy as 6.1.4.1 As I
> > wrote above, this is overlapped with 6.1.2 Figure 2 should be
> > moved here and text should be merged with latter of 6.1.2
> >
> >
> > <<Clause 6.1.4.1>>
> > There are some areas that form protection/redundancy:
> > (1) (Sender) CE to (Sender/Ingress) PEs
> > (2) VPMS instances or inside PSN
> > (3) (Receiver) PEs to Receiver CE
> >
> > This clause should indicate this point, where
> > protection/redundancy is required. (The use of dual home may miss (2))
> >
> >
> > <<Clause 6.1.4.2>>
> > As I wrote above, this is overlapped with 6.1.2 Figure 2
> > should be moved to this clause here and text should be merged
> > with latter of 6.1.2
> >
> >
> > Regards,
> > Yuji Tochio
> >
> >