Telechat Review of draft-kompella-l2vpn-l2vpn-
review-kompella-l2vpn-l2vpn-genart-telechat-even-2012-01-13-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-kompella-l2vpn-l2vpn-genart-telechat-even-2012-01-13

Hi,
I looked at the 08 version and the major issues are addressed.
What about minor issue number 3?

Roni Even

> -----Original Message-----
> From: Kireeti Kompella [

mailto:kireeti

 at juniper.net]
> Sent: Friday, September 16, 2011 10:23 PM
> To: Roni Even
> Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all at tools.ietf.org;
> gen-art at ietf.org; IETF-Discussion list
> Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07
> 
> Hi Roni,
> 
> On Sep 7, 2011, at 4:37 , Roni Even wrote:
> 
> > I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Thanks!
> 
> > Please resolve these comments along with any other Last Call comments
> you may receive.
> >
> > Document: draft-kompella-l2vpn-l2vpn-07
> > Reviewer: Roni Even
> > Review Date: 2011-9-7
> > IETF LC End Date: 2011-9-27
> > IESG Telechat date:
> >
> > Summary: This draft is not ready for publication as an informational
> RFC.
> >
> > Major issues:
> >
> > The IANA considerations section says:
> > "the values  already allocated are in Table 1 of Section 4.  The
> allocation policy  for new entries up to and including value 127 is
> "Standards Action".  The allocation policy for values 128 through 251
> is "First Come First Served".  The values from 252 through 255 are for
> "Experimental Use"."
> 
> Standards Action will be changed to Expert Review.
> 
> > Yet this is document is intended for Informational status which
> contradict the standard action. This is also true for the second
> registry defined.
> >
> > Is this document really an Informational one?
> 
> My only comment is that it is not Historic.
> 
> > Minor issues:
> >
> > 1.       In section  1.2.2 "Since "traditional" Layer 2 VPNs (i.e.,
> real Frame Relay circuits connecting sites) are indistinguishable from
> tunnel-based VPNs from  the customer's point-of-view, migrating from
> one to the other raises  few issues." What are the few issues?
> 
> A subtlety: "few issues" means not many, not deep; it's a careful way
> of saying, "just about no issues".  "A few issues" would require
> elaboration.
> 
> > 2.       In section 4 "L2VPN TLVs can be added to extend the
> information carried in the NLRI, using the format shown in Figure 2".
> How is the TLV carried in the NLRI, in which field, section 4.1 only
> talk about the structure of the TLV.
> 
> I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go.
> 
> > 3.       Section 4.2 refers to section 4 but I am not sure where this
> mechanism in section 4 is.
> 
> Will clarify.
> 
> >
> >
> >
> >
> >
> > Nits/editorial comments:
> >
> > 1.       Section 3.1 is called network topology but the whole text is
> an example of a network topology. Maybe the title should be "Example of
> a network toplogy".
> 
> Sure.
> 
> > 2.       Section 5 starts with "As defined so far in the document .."
> But the using IP only is already discussed in previous sections.
> 
> Do you have a suggestion for rewording?
> 
> Thanks,
> Kireeti.
> 
> 
> >
> >
> > <ATT00001..txt>