Hi,
On re-reading this I-D it does seem that there are a lot of words! Any edits
that you make along the way to reduce the verbiage would be welcome.
Some editorial nits that it would be nice to fix in order to make the
reviewers' job a little easier.
===
Header
Right-justify the authors' names
Use initials not first names (e.g. D. Fedyk)
===
Page bottoms
Nice to have a blank line between the text and the page footer.
===
Abstract
The first sentence lacks some grammar.
OLD
This draft describes the basic mode of Layer 1 VPNs (L1VPN BM) that
is port based VPNs.
NEW
This draft describes the basic mode of Layer 1 VPNs (L1VPN BM). Basic
mode L1VPNs are port-based VPNs.
===
Conventions Used in the Document
1. The "assumed to be familiar" text doesn't belong in this section
2. The referenced RFCs need to be normative not informative if the
reader needs to be familiar with the terminology
3. What is meant by the final "...and referenced." ?
===
Table of contents
Needs to be indented three spaces (but watch the line length)
===
Section 1
s/that outlined in/that is outlined in/
===
Section 1
It may also be helpful to add a reference to
draft-ietf-l1vpn-applicability-basic-mode as this provides more details on
the basic mode.
===
Section 1
You say
"In this document, we consider a
service provider network that consists of devices that support GMPLS
(e.g., Lambda Switch Capable devices, Optical Cross Connects, SDH
Cross Connects, etc.)."
Don't you actually mean a "layer 1 service provider network"?
===
Section 1
s/(either Ps, or PEs)/(either Ps or PEs)/
s/outside of the services provider network/outside of the service provider
network/
s/The [RFC4208] draft/[RFC4208]/
s/In the [RFC4208] draft/In [RFC4208]/
===
Section 1
"In the [RFC4208] draft the terms Core Node (CN) and Edge Node
(EN) correspond to PE and CE respectively."
I think that a CN covers both a P and a PE.
===
Figure 1
Could you label the PEs inside their boxes?
Is it deliberate that the top Ps are not connected?
Can you please insert some text to describe and/or reference figure 1.
===
Section 1
"This draft specifies how the L1VPN Basic Mode (BM) service can be
realized using provisioning or VPN auto-discovery, Generalized
Multi-Protocol Label Switching (GMPLS) Signaling
[RFC3471],[RFC3473], Routing [RFC4202] and LMP [RFC4204] mechanisms."
Doesn't that mean that those RFCs should be normative references?
s/[RFC3471],[RFC3473]/[RFC3471], [RFC3473]/
===
Section 2
s/L1/Layer 1/
===
Section 2
"Interfaces at the end of each link are limited to type LSC or
TDM interfaces that are supported by GMPLS."
Do you deliberately exclude other layer 1 switching types?
Viz. FSC.
===
Section 2 (etc.)
The use of square brackets [ ] is usually reserved for BNF and references.
It may be better to use angle brackets < >
===
Section 2
"More specifically a
[CE,PE] link MUST be of the type [X,LSC] or [Y,TDM] where X = PSC,
L2SC, or TDM and Y = PSC or L2SC, in case the LSP is not terminated
by the CE, X MAY also = LSC and Y = TDM (the latter case is outside
the scope of this document)."
I don't think this should be outside the scope of this document and
(fortunately) I don't think it is outside the scope of the rest of the text
in the document.
You need to observe that one of the applications of a L1VPN connection is
simply to provide a "virtual private lambda" or similar. In this case, the
CE is truly the end point in GMPLS terms and its switching capability on the
TE link is not relevant (although its GPID and adaptation capabilities may
be interesting). I'm not really sure why you present this whole sentence,
but I do think that the I-D needs to cover all of the use-cases.
===
Section 2
"For the
purpose of this discussion we assume that all the channels within a
given link have similar shared characteristics"
Making an assumption immediately begs a question.
If it is a requirement, please say MUST.
If mixed data channel characteristics is simply for future study, then say
that and explain why.
===
Section 2
s/etc_)/etc.)/
s/one port per each PE)/one port per PE)/
===
Section 2
"If a CE is connected to a PE via multiple TE links and all the links
belong to the same VPN, for the purpose of this document,"
Suggest to strike "for the purpose of this document"
===
Section 2
"A link MAY have only data bearing channels, or only control bearing
channels, or both."
But a few paragraphs earlier you said:
"In the context of
this document a link is a GMPLS Traffic Engineering (TE) link
construct, as defined in [RFC4202]."
I suspect you need to revisit the terminology around links, and clean it up.
===
Section 2
"For the purpose of this discussion it is
REQUIRED that for a given CE-PE pair at least one of the links
between them has at least one data bearing channel, and at least one
control bearing channel, or there is IP reachability between the CE
and the PE that could be used to exchange control information."
1. Instead of "For the purpose of this discussion" do you mean: "In order to
satisfy the requirements of the L1VPN Basic Mode..."
2. The punctuation here is wonderfully ambiguous! It actually says that it
is acceptable to have no data channels between CE and PE provided there is
IP reachability :-)
It is not clear whether you are requiring that at least one of the links has
both a data channel and a control channel, or whether you are saying that
there must be at least one link with a data channel and at least one link
with a control channel.
===
Section 2
"A point-to-point link has two end-points"
This appears to suggest that you will consider p2mp or multi-access links.
But, of course, you don't.
Can you either say that multi-access links are out of scope and unlikely to
be applicable to Layer 1 technologies, or simply say that "A link has two
end-points".
===
Section 2
"At any point in time, a given port on a PE is associated with at
most one L1VPN, or to be more precise with at most one Port
Information Table maintained by the PE"
Please include a reference for the PIT. Section 4 of this document is good
enough.
===
Section 2
"The association of
a port with a VPN MAY be defined by provisioning the relationship on
the services provider devices."
This implies that there are other mechanisms that could be used by default.
The document does not list those mechanisms, and it should if the "MAY" is
to be used. On the other hand we should look at the Basic Mode definition we
see in RFC4847:
"In this service model, the CE-PE interface's functional repertoire is
limited to path setup signaling only."
So it is unclear what other mechanisms you might be considering.
===
Section 2
"This document assumes that the interface between the CE and PE"
Again, why are you making assumptions and not stating requirements?
===
Section 3
s/Addressing/addressing/
s/in the [RFC3945] documents/in [RFC3945]/
s/Customer/customer/
s/Context/context/
===
Section 3.1
"This document assumes that a service provider, or a group of service
providers that collectively offer L1VPN service, have a single
addressing realm that spans all PE devices involved in providing the
L1VPN service. This is necessary to enable GMPLS mechanisms for path
establishment and maintenance."
I am neither sure why this statement is in scope, nor whether it is true.
Why cannot different L1 service providers use private address realms and yet
still cooperate to provide a single L1VPN service? I think this is enabled
perfectly well by RFC4208 (which should maybe have been entitled "GMPLS UNI
and E-NNI".)
====
Section 3.1
"This document further assumes
that each L1VPN customer has its own addressing realm. We will refer
to such realms as the customer addressing realms. Customer
addressing realms MAY overlap with each other, and MAY also overlap
with the service provider addressing realm."
Yet again, Assumptions are not helpful. Make simple statements.
What does "overlap" mean?
I think you need to first state that the addressing realms are completely
separate and there is no use of an address from one realm within another
realm. Then you may say "overlap" and explain what it means.
Otherwise "overlap" between the customer and provider realms may be taken to
mean that an address in one realm can be valid in the other realm (a concept
which is, itself, ambiguous).
===
Figure 2
I think the tag "Customer realm" needs some left-shift.
Can you please make some reference to figure 2 from within the text.
===
Section 3.3
"For a given link connecting a CE to a PE, if the CPI is an IPv4/IPv6
address, then the VPN-PPI has to be an IPv4/IPv6 address as well."
This is ambiguous. I think you are using shorthand and do not mean that if
the CPI is either an IPv4 or IPv6 address, then the PPI must also be either
an IPv4 address or an IPv6 address. I think you are saying that the CPI and
PPI must both be the same address type.
You should explain why this is the case since it appears to contradict the
previous discussion of the C and P address realms being independent. That
is, why do you prevent the customer network using IPv6 addresses and the
provider network using IPv4 addresses?
===
Section 3.3
"This document assumes that assignment of the PPIs is controlled
solely by the service provider (without any coordination with the
L1VPN customers)"
Why is this assumption made? Why is it relevant?
If there is coordination (presumably using the management plane or the
business layer), does that in any way affect the implementation or
protocols?
Why not just say:
"The assignment of PPIs is controlled solely by the service provider,"
===
Section 3.3
"while assignment of addresses used by the CPIs and
VPN-PPIs is controlled solely by the administrators of L1VPN. The
L1VPN administrator is the entity that controls the L1VPN service
specifics for the L1VPN customers. This function may be owned by the
service provider but may also be performed by a third party who has
agreements with the service provider."
But don't the CPI addresses come from the customer address realm? So doesn't
the customer have to have some say about what addresses are used?
===
Section 4
"In the L1VPN, the service provider does not initiate the creation of
an LSP between a pair of PE ports. This is done rather by the CEs,
which attach to the ports."
Well, that is a bit confusing.
The CEs don't establish LSPs between PE ports either. The CEs establish LSPs
between CE ports.
On the other hand, the service provider MAY establish LSPs between PE ports
if it chooses. In fact, the service provider can manage its own network in
any way it likes.
===
Section 4
s/matrix;/matrix)./
===
Figure 3
Format typo in left-hand VPN-B PIT.
Please reference and describe this figure in the text.
===
Section 4
"The PIT is by nature VPN-specific in that entries for a L1VPN are
only REQUIRED on a PE if that PE locally supports that L1VPN by
having CEs belonging to that VPN attached to the PE."
The 2119 REQUIRED looks wrong here with "only".
Perhaps re-word as:
The PIT is by nature VPN-specific. A PE is REQUIRED to
maintain a PIT for each L1VPN for which it has member CEs
locally attached. A PE is does not need to maintain PITs for
other L1VPNs.
===
Section 4
s/identifier ie the remote CEs of this VPN could/identifier (i.e., the
remote CEs of this VPN) could/
===
Section 4.1.1
"The information that needs to be discovered on a PE local port is
the remote CPI and the VPN-PPI."
Do you mean the "local CPI and the VPN-PPI"?
Does this information need to be discovered "on a PE local port" or "on a PE
about each local port"?
"In many cases if LMP is used
between the CE and PE, LMP can exchange this information. Other
mechanism MAY also be used but discussion of these mechanisms is
outside the scope of this document."
Surely configuration is in scope for this document?
===
Section 4.1.2
"The encoding of the auto-discovery information uses BGP address
family identifiers (AFIs), and defines a new AFI for L1VPN (to be
assigned by the IANA). This information should be consistent
regardless of the mechanism use to distribute the information.
[L1VPN-BGP-AD], [L1VPN-OSPF-AD]."
I don't think this document makes any requests for IANA action, and I don;t
think that the encoding presented in the figure requires the use of an AFI.
===
Figure 4
I think you should omit the length octet from this figure and the
descriptive text.
The use of a length indicator is dependent on the protocol mechanism used
for transport and is distinct from the encoding of the autodiscovery
information presented here.
===
Section 4.2
"RSOH DCC" used without acronym expansion.
===
Section 4.3.1
"When an ingress CE sends an RSVP Path message to an ingress PE, the
source IP address in the IP packet that carries the message is set
to the appropriate CE-CC-Addr, and the destination IP address in the
packet is set to the appropriate PE-CC-Addr."
"Appropriate" indeed! :-)
But please say which address is appropriate.
(Also the subsequent paragraph.)
===
Section 4.3.1
OLD
Additional processing related to unnumbered links is described in
the"Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID
TLV",and "Unnumbered Forwarding Adjacencies" sections of RFC 3477
[RFC3477].
NEW
Additional processing related to unnumbered links is described in
the "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID
TLV", and "Unnumbered Forwarding Adjacencies" sections of RFC 3477
[RFC3477].
===
Section 4.3.1.2
"- Associating an already established PE-PE FA-LSP to the
destination that meets the requested parameters."
While this is true, it is not the case that this option is limited to the
pre-established PE-PE being an FA-LSP. That is, the LSP does not need to be
advertised as a TE link within the provider's network. Indeed, there may be
many advantages to not advertising this TE link since the only Ps that need
to know of its existence are its end-points.
===
Section 4.4
"A PE receiving a message containing a Notify Request object SHOULD
store the Notify Node Address in the corresponding state block. The
PE SHOULD also include a Notify Request object in the outgoing Path
or Resv message. The outgoing Notify Node Address MAY be updated
based on local policy. This means that a PE upon reception of this
object from the CE MAY update its value."
I think that if you are doing shuffling, the PE MUST update the Notify
Request object since otherwise it will contain information that will cause a
catastrophe if the core network attempts to use the addresses.
===
Section 4.4
"If the ingress CE includes a NOTIFY_REQUEST object into the Path
message, the ingress PE MAY replace the received 'IPv4 Notify Node
Address' by its own selected 'IPv4 Notify Node Address', and in
particular the local TE Router_ID. The Notify Request Object MAY be
carried in Path or Resv messages (Section 7 of [RFC3473]). The
format of the NOTIFY_REQUEST object is defined in [RFC3473]."
This sort of says the same as the previous paragraph and is subject to the
same issues if shuffling is used.
===
Section 5
I suspect we may be going to have trouble with this section during SecDir
review. Are you saying that the CE-PE control channel relies predominantly
on physical security and that no further signaling issues arise compared to
normal RSVP-TE?
The risk of connecting to the wrong L1VPN (owing to provider network error)
is pretty significant and would stand a paragraph to describe why it won't
happen.
The risk of a CE requesting connection to some other VPN (my mistake or
mischief) is important, and you should say how it is refuted.
RFC 4847 has a reasonably long security section. You might explicitly
address the items listed in section 12.2 and then examine how the MUSTs and
SHOULDs of the whole of section 12 are addressed in your solution.
===
Section 8.1
L1VPN-FRAMEWORK is now RFC 4847
===
Cheers,
Adrian
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
