Subject: [L1vpn] Chair review of draft-ietf-l1vpn-ospf-auto-discovery-03.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 30 Sep 2007 10:18:23 +0100

Hi,

Some things to tidy up before we give it to the IESG.

Thanks,
Adrian

===
Abstract
Abstract must not contain citations by reference. You have to expand the 
title of the referenced RFC or draft if you absolutely must include the 
citation.
===
Abstract
I'm afraid you need to expand the acronyms.
===
Sections 1 and 2
Unfortunately, the RFC Editor currently requires that the first section in 
the draft is the Introduction. That means you need to:
a. Swap sections 1 and 2
b. Expand all acronyms in the Introduction
===
Figure 1
Format error in the lefthand VPN-B PIT.
===
Section 2
Explanation of Figure 1. Could you add a sentence or two to explain what we 
are seeing in the Figure.
===
Section 2
s/(referred as a/(referred to as a/
s/as L1VPN Info TLV/as the L1VPN Info TLV/
===
Section 3.1
I think it would help to say in the definition that "A single L1VPN Info TLV 
MUST be included. Subsequent L1VPN Info TLVs SHOULD NOT be included and 
SHOULD be ignored if received."
===
Section 3.2
  "TLV length
   The length of the TLV in bytes, including the 4 bytes of
   the TLV header."
I think this is a change of behavior for OSPF. For example, from RFC 3630...
   The Length field defines the length of the value portion in octets
   (thus a TLV with no value portion would have a length of zero).  The
   TLV is padded to four-octet alignment; padding is not included in the
   length field (so a three octet value would have a length of three,
   but the total size of the TLV would be eight octets).
It would probably be best to stick to this form.
===
Section 3.2
  "PE TE Address
    Valid PE TE address: either TE Router ID specified in the
    Router Address TLV or local numbered TE link ID specified in
    the Local interface IP address sub-TLV of the TE Link TLV of the
    TE LSA originated by the PE"
Can you give a better pointer to where these TLVs are found?
It reads slightly like the Router Address TLV is in the L1VPN LSA, but I 
think you mean that both the Router Address TLV and the TE Link TLV may be 
found in the TE LSA originated by the PE. In this case, I think you need 
some explanatory text in the I-D saying how you can be sure that the TE LSA 
exists.
===
Section 4
  "PEs advertise local <CPI, PPI> tuples in L1VPN LSAs containing L1VPN
   Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS
   flooding scope for each local CE-PE link."
It may be helpful to remind the reader that this is a per-port VLN model so 
that the CE-PE link is guaranteed to apply to only one VPN.
===
Section 4
s/once on the PE restart/once on PE restart/
s/and every time when there/and every time there/
===
Section 4
"MAY include a single TE Link TLV"
You should indicate why it would do that.
===
Section 4
  "L1VPN LSAs are flooded to all PEs within the AS according to
   [RFC2370] or [2370BIS]."
Add "because the LS Type is set to 11."
===
Section 4
s/modified such LSA/modified L1VPN LSA/
===
Section 4.1
s/it should be/it SHOULD be/ ?
s/blocking information/blocking of information/
s/PITs and so/PITs, and so/
s/could be resolved/can be resolved/
s/paths towards the/paths toward the/
s/could be computed./can be computed./
s/consider example/consider the example/
s/presented on Figure/presented in Figure/
===
Figure 2
The text says that CE24 is connected to PE3. But the figure disagrees.
===
Section 4.2
s/in the steady mode/in steady state/
s/problematic on large/problematic in large/
===
Section 5 - Title
s/Backward compatibility/5. Backward Compatibility/
===
Section 5
s/do not support L1VPN/do not support the L1VPN/
===
Section 5
Can you give the reference for the behavior you describe.
===
Section 6.
We have recently seen several strong reviews of Security Considerations 
sections.
I think this section is a little thin. You might pick up some ideas from 
draft-ietf-l1vpn-bgp-auto-discovery-02.txt
The essential is to point out how subversion of L1VPN LSAs would impact the 
service provided, and to discuss what security options OSPF provides to 
protect against this.
I suspect that, since the L1VPN LSA is in some sense an end-to-end scoped 
application information exchange, we may be invited to use authentication or 
integrity mechanisms on the LSA. You either need to suggest this or refute 
it in the I-D.
===

_______________________________________________
L1vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn