Re: [mpls] draft-ietf-mpls-forwarding

[Curtis Villamizar <[e-mail]>]

In message <003a01cf2f17$4eede300$[e-mail]>
"t.petch" writes:
 
> Curtis
>  
> I just finished reading this - and see that the IESG have approved it.
> Ah well, perhaps the RFC Editor will be interested.

Approved with discussion so there will be some change before it hits
the editor queue.  It is up to the responsible AD to approve and
further change.

> s.1 /advise/advice/

Ooops - yeah.

>    CC-CV Connectivity Check and Connectivity Verification
> we have used Continuity Check elsewhere (e.g. mpls-tp-oam-framework)

I'm not sure what you are asking me to change.

> s2.3
>  
> "For example, an on-chip buffer capable of handling 4K packets
>    of 64 bytes in length, or 256KB, corresponds to 2 msec on a 10 Mb/s"
>  
> My maths is hopeless.   4K packets of 64byte is 256Kbyte which is
> 2048Kbit  on a 10Mbit/s link is 2048K divided by 10M/s which is '2mS' -
> why do I keep getting 200mS or 2dS?

Oops --

2048*10^3 bits / 10*10^6 bits/sec =
204.8 * 10^-6 sec ~= 200 * 10^-3 sec (200 msec).

I'll have to mention this on one of the IESG threads in which this was
brought up.

> s2.4.5.1 5)
> /closest to the bottom of stack/closer to the bottom of stack/

I meant closest.  The fat-pw label is at the very bottom.  The most
entropy is at the very bottom.  At least one chip today can search for
BOS, and use the bottom N (for very small value of N).

> s2.6.4
> we have used  Continuity Check elsewhere (e.g. mpls-tp-oam-framework)

Less demanding uses of CC don't dictate the hardware assist
requirements if you mean on-demand CC.  Not sure what you are getting
at.

> s3
> This is quite cryptic where no references are given, e.g. Q40 for
> Pseudowire OAM, MPLS-TP OAM, Layer-2 OAM Interworking

Ask the prior three questions (what is supported, performance limits,
consequence of exceeding performance limits) for each of those types
of OAM.  There is a reference to Section 2.6.2 where MPLS OAM is
described, though perhaps it should be to 2.6.

> Tom Petch

Thanks,

Curtis

> ----- Original Message -----
> From: "Curtis Villamizar" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Thursday, January 30, 2014 9:06 PM
>  
> >
> > In message <00ce01cf1de4$45fb9ba0$[e-mail]>
> > "t.petch" writes:
> >
> > > Curtis
> > >
> > > MP2MP Multipoint to Point ?
> >
> > Multipoint to multipoint.  Ie: capable of supporting <*,G> though
> > possibly for a policy constrained value of "*".  Some chips can do it
> > but I'm not sure what routers can do (whether software supports it)
> > and if so if anyone deploys MP2MP.  At least some P2MP for
> > distribution of stuff like video, maybe a lot but I don't know.
> > Plenty of MP2P since LDP is inherently MP2P.
> >
> > > I would like the first sentence of the Abstract to start the
> > > Introduction - otherwise there is no intended audience (and I tend
> to
> > > skip Abstracts when I know I am going to be interested in a
> document).
> >
> > The intended audience is in the intro later on in Section 1.4 ("Target
> > Audience").
> >
> > > And is that second clause for Operators eg
> > > a basis for operators to evaluate forwarding implementations.
> >
> > It is meant for both operators and system designers.  System designers
> > (ie: people working for router vendors that buy off the shelf silicon)
> > need to pick a forwarding chip long before operators are evaluating.
> > See Section 1.4.
> >
> > In the case of forwarding the "implementor" is designing a chip.  The
> > "system designer" is using it in a product.  The operator is (we hope)
> > trying to find out what if any bad decisions were made in an
> > evaluation to determine what effect any shortcomings would have before
> > deploying and finding out the hard way.
> >
> > > (more to follow - the I-D is big and my reading is slow:-(
> >
> > No problem.  Thanks for taking a look.
> >
> > > Tom Petch
> >
> > Curtis