Subject: [L1vpn] Chair review of draft-ietf-l1vpn-basic-mode-02.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Oct 2007 17:04:42 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn

---

From: "Fedyk, Don (BL60:1A00)" <[email-masked]>
Date: Wed, 3 Oct 2007 12:25:57 -0400

Hi Adrian

Thanks for the input. I'll take a stab at addressing the points below
and recirculation to the group.  Is there a deadline we are working to?

Regards,
Don  

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 12:05 PM
> To: [email-masked]
> Cc: Yakov Rekhter; Fedyk, Don (BL60:1A00); Dimitri 
> Papadimitriou; Lou Berger; [email-masked]
> Subject: Chair review of draft-ietf-l1vpn-basic-mode-02.txt
> 
> Hi,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Oct 2007 17:32:54 +0100

Hi Don,

You could address my concerns any time in email if you like.

I would not recommend updating the I-D until after WG last call has 
completed.

Cheers,
Adrian
----- Original Message ----- 
From: "Fedyk, Don (BL60:1A00)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>; "Dimitri Papadimitriou" 
<[email-masked]>; "Lou Berger" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, October 03, 2007 5:25 PM
Subject: RE: Chair review of draft-ietf-l1vpn-basic-mode-02.txt

Hi Adrian

Regards,
Don