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 PROTECTED] > Sent: Wednesday, October 03, 2007 12:05 PM > To: [EMAIL PROTECTED] > Cc: Yakov Rekhter; Fedyk, Don (BL60:1A00); Dimitri > Papadimitriou; Lou Berger; [EMAIL PROTECTED] > Subject: Chair review of draft-ietf-l1vpn-basic-mode-02.txt > > 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
