[L1vpn] Your Discusses and Comments on draft-ietf-l1vpn-basic-mode-04.txt

["Adrian Farrel" <[e-mail]>]

Hi,

Thank you for your Discusses and Comments during IESG review of 
draft-ietf-l1vpn-basic-mode-04.txt

The authors have updated the I-D to address the issues you raised according 
to various email exchanges we had with you. The -05 version has been posted.

Below, please find your notes together with pointers to the resolutions. We 
hope that those of you with Discusses can now clear them

(You should be able to find a diff at 
http://tools.ietf.org/wg/l1vpn/draft-ietf-l1vpn-basic-mode/)

Thanks,
Adrian

===
Pasi Eronen - Discuss

> As noted by Charlie Kaufman's and Sandy Murphy's SecDir reviews: the
> security considerations text is very sparse. At the very least, it
> should point to the (much more extensive) security considerations in
> RFC 4847 and draft-ietf-l1vpn-applicability-basic-mode-05, and briefly
> describe the existing security mechanisms (e.g. GMPLS/RSVP-TE) that
> can be used to address those concerns.

References to RFC 4847 and draft-ietf-l1vpn-applicability-basic-mode-05 have
been added to the top of Section 5.

A paragraph pointing to all of the prior art for GMPLS control plane 
security has been added together with a reference to 
draft-ietf-mpls-mpls-and-gmpls-security-framework that covers the wider 
security environment.

A significant re-write of the security section converts it from a single 
paragraph to five paragraphs.

> In Section 4.1.2, something more should be said about the L1VPN
> globally unique identifiers, and in particular, who selects them and
> how global uniqueness is ensured (or is uniqueness within a service
> provider sufficient?), and how they're encoded (e.g. the format here
> doesn't match the VPN Identifier defined in RFC 2685).

A piece of text has been added to 4.1.2 to say...
   The globally unique identifiers are
   under control of network providers. Uniqueness within a service
   provider administrative domain is sufficient for basic mode
   operation. In the case of multiple provider networks which is beyond
   the scope of this document, the globally unique identifier need only
   be unique and consistent between the those providers.

Text already exists in the section to describe the encoding.
The L1VPN identify is identical to the VPN Index defined in RFC 2685. Other 
elements of the VPN identifier (i.e. the OUI) defined in RFC 2685 are not 
applicable to Basic Mode L1VPNs.

> Section 4.1.2 needs a reference to a document that defines the CPI AFI
> values.

Pointer to [L1VPN-BGP-AD] has been added.

===
Pasi Eronen - Comment

> The document could perhaps use a slightly longer explanation of how
> the PE, when it receives a RSVP message, determines which L1VPN it's
> associated with (since apparently the RSVP messages are not
> necessarily sent over the CE-PE link identified by CPI/PPI, and the
> L1VPN is not uniquely identified by CE-CC-Addr/PE-CC-Addr).

Clarification has been added to section 3.3.

> Sandy's SecDir review also identified a number of places that
> would benefit from some clarification of the text, and provided
> editorial comments that should be taken into acccount.

We believe we have addressed these through email discussion and updates to 
the I-D.

===
Russ Housley - Comment

> There has been a dialogue between Sandy Murphy and Adrian Farrel that
> was begun by Sandy's SecDir Review.  The Security Considerations in
> this document are very sparse, saying essentially that because the
> matching of customer channels to provider ports is assumed to be done
> correctly and out of band there are no security considerations.
> However, the dialogue between Sandy and Adrian shows that there is
> actually more to say.
>
> I support the DISCUSS position that Pasi has entered ...

Discussions with Sandy were very helpful.
Updates made to several areas of the I-D and considerable updates to the 
Security section.

===
Tim Polk - Comment

> Note that I support Pasi's discuss wrt security considerations.

Security section updated.

> One nit:
>
> s 4.1, 1st sentence
> s/there/their/

Got it.

===
Ron Bonica - Comment

> In Section 1, you say:
>
> As with L3VPNs, there are protocol options to be made with auto-discovery.
>
> Did you mean protocol choices?

Changed to "choices"

> In Setion 2, you say:
>
>  Since the mechanisms specified in this document
>  use GMPLS as the signaling mechanism, and since GMPLS applies to
>  both SONET/SDH (TDM) and Lambda Switch Capable (LSC) interfaces, it
>  results that L1VPN services include (but are not restricted) to
>  Lambda Switch Capable or TDM-based equipment.
>
> Did you mean "it follows that"?

Changed

===
Ron Bonica - Comment

> In Section 3.1, you say
>
> Is is further REQUIRED that each L1VPN customer have its own addressing
> realm.
>
> Does this mean that a customer cannot use globally routable address space?
> If so, why?

Sentence now reads...
   It is further REQUIRED that each
   L1VPN customer have its own addressing realm with complete freedom
   to use private or public addresses

=== 


_______________________________________________
L1vpn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l1vpn