'[mpls] =?euc-kr?b?yLi9xTogW1JURy1ESVJdIMi4vcU6ICAgUnRnRGlyIHJl?= =?euc-kr?q?view=3A_draft-ietf-mpls-'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    [mpls] =?euc-kr?b?yLi9xTogW1JURy1ESVJdIMi4vcU6ICAgUnRnRGlyIHJl?= =?euc-kr?q?view=3A_draft-ietf-mpls-
From:       <ryoo () etri ! re ! kr>
Date:       2014-07-24 21:08:35
Message-ID: 5B4A6CBE3924BB41A3BEE462A8E0B75A2874D304 () SMTP2 ! etri ! info
[Download RAW message or body]

Lou,

The text in the current draft (07 version) was reviewed by Yaacov before uploading in \
public. He might have some nits that can be fixed during the RFC editing, 
but  it is my understanding that he is ok with the current one.

Best regards,

Jeong-dong

________________________________________
КИГН ЛчЖї: Lou Berger [lberger@labn.net]
КИГН ГЏ Ѕ: 2014Гт 7Пљ 25РЯ БнПфРЯ ПРРќ 5:23
ЙоД  ЛчЖї: ЗљСЄЕП; Yaacov Weingarten
 ќСЖ: mpls@ietf.org; draft-ietf-mpls-smp-requirements.all@tools.ietf.org; \
rtg-dir@ietf.org; rtg-ads@tools.ietf.org СІИё: Re: [RTG-DIR] ШИНХ:  [mpls] RtgDir \
review: draft-ietf-mpls-smp-requirements-06.txt

I believe the ambiguity mentioned by Yacov still exists. I actually
defer to Yacov on this, and if he's happy with the text -- so am I.

Lou

PS I have a couple of more minor comments to send -- and will do so as
soon as I can.

On 7/24/2014 7:52 AM, ЗљСЄЕП wrote:
> Lou,
> 
> Any ambiguity is not intentional.
> 
> The latest text related to this issue is:
> ---
> 3. If multiple protection paths of equal priority are requesting the
> shared resources, the resources SHALL be utilized on a first come
> first served basis. Traffic of the protection paths that request
> the shared resources late SHALL be preempted. In order to cover
> the situation where the first come first served principle cannot
> resolve the contention among multiple equal priority requests,
> i.e., when the requests occur simultaneously, tie-breaking rules
> SHALL be defined in scope of an SMP domain.
> 
> 4. If a higher priority path requires the protection resources that
> are being utilized by a lower priority path, the resources SHALL
> be utilized by the higher priority path. Traffic with the lower
> priority SHALL be preempted.
> ---
> 
> The text is already saying that the preepmtion and utilization is per path basis.
> In my opinion, it seems to be ok without adding an LSP here.
> 
> Jeong-dong
> 
> 
> 
> ________________________________________
> КИГН ЛчЖї: Lou Berger [lberger@labn.net]
> КИГН ГЏ Ѕ: 2014Гт 7Пљ 23РЯ МіПфРЯ ПРШФ 9:05
> ЙоД  ЛчЖї: Yaacov Weingarten; ЗљСЄЕП
> ќСЖ: mpls@ietf.org; draft-ietf-mpls-smp-requirements.all@tools.ietf.org; \
> rtg-ads@tools.ietf.org; rtg-dir@ietf.org СІИё: Re: [RTG-DIR] [mpls] RtgDir review: \
> draft-ietf-mpls-smp-requirements-06.txt 
> Yaacov, Jeong,
> I'm not sure how the latest text addresses the ambiguity you
> identified below.  Perhaps adding the words "on a per LSP basis" to the
> requirement?  If the ambiguity is intentional, then of course no change
> is warranted.
> 
> Lou
> 
> On 7/5/2014 3:49 PM, Yaacov Weingarten wrote:
> > Lou, hi
> > I would like to address two of your comments, in your follow-up
> > message, since I am the source of the change in terminology.
> > 
> > Regarding the two occurences of "assigned" in place of "utilized" -
> > when I read the proposed changes,as discussed amongst the authors, I
> > felt that in those two instances the use of "utilized" could lead to
> > some ambiguity.
> > 
> > If we state that "resources SHOULD be utilized on a first come first
> > served basis" this could be interpreted (IMO) as referring to the
> > packet level, rather than  utilized by a specific path, such that
> > packets from different paths could be interspersed along the shared
> > segments. Therefore,I suggested that or this context it would be
> > better to use a word that meant that the first-come first served basis
> > was at the level of assigning (or allocating) the resources rather
> > than utilizing them.
> > 
> > Hope this clarifies this point. I am certain that I speak for the
> > other authors in  saying that I am open to other suggestions.
> > 
> > BR,
> > yaacov
> > 
> > On Jul 4, 2014 3:53 AM, "Jeong Ryoo" <ryoo@etri.re.kr
> > <mailto:ryoo@etri.re.kr>> wrote:
> > 
> > Dear Lou,
> > 
> > 
> > 
> > Thanks a lot for your valuable comments.
> > 
> > 
> > 
> > The authors of this draft have discussed your comments, and are
> > proposing our resolutions to your comments. Please, let us know if
> > the proposal is appropriate to address your comments and concerns.
> > 
> > 
> > 
> > Best regards,
> > 
> > 
> > 
> > Authors of draft-ietf-mpls-smp-requirements draft
> > 
> > 
> > 
> > ****** Beginning of Comment Resolution ******
> > 
> > 
> > 
> > - Document's usage of "committed" vs "allocated" resources:
> > 
> > In section 1 the document introduces the notion that the
> > distinction between protection and restoration is based on when
> > resources are "committed". This difference from past
> > definition. RFC4427 and 6372 make the distinction that protection
> > and restoration differ based on when resources are *allocated* not
> > *committed*. To quote RFC 4427:
> > 
> > The distinction between protection and restoration is made based
> > on the resource allocation done during the recovery LSP/span
> > establishment. The distinction between different types of
> > restoration is made based on the level of route computation,
> > signaling, and resource allocation during the restoration
> > LSP/span establishment.
> > 
> > This difference also leads to come confused statements in the
> > document as well as ambiguity in the text, i.e. confusion by the
> > reader. The term "committed" is not tightly defined in this
> > document (or earlier work) and is used differently than how
> > "allocated" has been used. An example of this can be found in
> > Section 3.1 which states:
> > 
> > However, the commitment of the resources, at least for the
> > shared segments, will only be finalized when the protection
> > path is actually activated. Therefore, for the purists -
> > regarding the terminology - SMP lies somewhere between
> > protection and restoration.
> > 
> > Both sentences are problematic. In the first, commitment seems to
> > cover a "protection switch" would "connect" the protection path
> > but not the earlier "allocation" of resources. (Quoted terms are
> > used in earlier RFCs.) The second conclusion is based on the new
> > distinction of protection vs. restoration and is unnecessary with
> > the existing distinction.
> > 
> > This issue exists in multiple places in the document where
> > "committed" is used and I'd recommend that each should be replaced
> > with terminology used in the referenced RFCs, i.e., "allocation",
> > "connection", "cross-connect", "protection switch(over)", ...
> > 
> > Note I'm *not* highlighting all cases where there are problems in the
> > document related to this issue. There are a couple of places in the
> > document where I think it's possible that once this terminology
> > ambiguity is corrected that I'll have other substantive comments.
> > 
> > 
> > 
> > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428,
> > we concluded that the distinction between protection and
> > restoration should be aligned with the exiting documents
> > normatively referenced by this document. Accordingly, the
> > following 16 modifications will be done in revision:
> > 
> > 
> > 
> > (1) Section 1, the third paragraph
> > 
> > OLD:
> > 
> > As pointed out
> > 
> > in [RFC6372] and [RFC4428], applying 1+1 linear protection requires
> > 
> > that resources are committed for use by both the working and
> > 
> > protection paths. Applying 1:1 protection requires that the same
> > 
> > resources are committed, but allows the resources of the protection
> > 
> > path to be utilized for pre-emptible extra traffic.
> > 
> > NEW:
> > 
> > As pointed out
> > 
> > in [RFC6372] and [RFC4428], applying 1+1 protection requires
> > 
> > that resources are allocated for use by both the working and
> > 
> > protection paths. Applying 1:1 protection requires that the same
> > 
> > resources are allocated, but allows the resources of the protection
> > 
> > path to be utilized for pre-emptible extra traffic.
> > 
> > 
> > 
> > (2) The whole text in Section 3.1 will be replaced with:
> > 
> > [RFC6372], based upon the definitions in [RFC4427], differentiates
> > between "protection" and "restoration" dependent upon the dynamism
> > of the resource allocation. The same distinction is used in
> > [RFC3945], [RFC4426], and [RFC4428]. This document also uses the
> > same distinction between protection and restoration as stated in
> > [RFC6372].
> > 
> > 
> > 
> > (3) In page 6,
> > 
> > OLD:
> > 
> > The use of preemption in the network is typically a business or
> > 
> > policy decision such that when protection resources are contended,
> > 
> > priority can be applied to determine to which parties the protection
> > 
> > resources are committed.
> > 
> > NEW:
> > 
> > The use of preemption in the network is typically a business or
> > 
> > policy decision such that when protection resources are contended,
> > 
> > priority can be applied to determine which parties utilize the
> > protection
> > 
> > resources.
> > 
> > 
> > 
> > (4) Page 7, the first paragraph:
> > 
> > OLD:
> > 
> > the resources for the protection path are fully committed,
> > 
> > NEW
> > 
> > the resources for the protection path are fully dedicated,
> > 
> > 
> > 
> > OLD:
> > 
> > resources may be planned but would not be committed until ЁІ
> > 
> > NEW:
> > 
> > resources may be planned but would not be utilized until ЁІ
> > 
> > 
> > 
> > (5) In the second paragraph in page 7,
> > 
> > OLD:
> > 
> > "Hard Preemption" requires the programming of selectors at the
> > ingress of each shared segment to specify which backup path has
> > the highest priority when committing protection resources, the
> > others being preempted.
> > 
> > NEW
> > 
> > "Hard Preemption" requires the programming of selectors at the
> > ingress of each shared segment to specify the priorities of backup
> > paths, so that traffic of lower priority paths can be preempted.
> > 
> > 
> > 
> > (6) The first paragraph of Section 4.1:
> > 
> > OLD:
> > 
> > ЁІ and commit the associated resources. The commitment of resources
> > 
> > is dependent upon ЁІ
> > 
> > NEW:
> > 
> > ЁІ and coordinate the utilization of the associated shared resources.
> > 
> > The resource utilization coordination is dependent upon ЁІ
> > 
> > 
> > 
> > (7) The second paragraph of Section 4.1:
> > 
> > OLD:
> > 
> > When the reserved resources of the shared segments are committed to a
> > 
> > particular protection path, there may not be sufficient resources
> > 
> > available for an additional protection path. This then implies that
> > 
> > if another working path of the SMP domain triggers a protection
> > 
> > switch, the commitment of the resources may fail. In order to
> > 
> > optimize the operation of the commitment and preparing for cases of
> > 
> > multiple working paths failing, the commitment of the shared
> > 
> > resources are be coordinated between the different working paths in
> > 
> > the SMP network.
> > 
> > NEW:
> > 
> > When the reserved resources of the shared segments are utilized by a
> > 
> > particular protection path, there may not be sufficient resources
> > 
> > available for an additional protection path. This then implies that
> > 
> > if another working path of the SMP domain triggers a protection
> > 
> > switch, the resource utilization coordination may fail. The
> > different working paths in
> > 
> > the SMP network are involved in the resource utilization
> > coordination.
> > 
> > .
> > 
> > 
> > 
> > (8) Section 5.1,
> > 
> > OLD:
> > 
> > ЁІ and commit the associated resources.
> > 
> > NEW
> > 
> > ЁІ and coordinate the utilization of the associated shared resources.
> > 
> > 
> > 
> > (9) In Section 5.1,
> > 
> > OLD:
> > 
> > In the case of multiple working paths failing, the commitment of the
> > 
> > shared resources SHALL be coordinated between the different working
> > 
> > paths in the SMP network.
> > 
> > NEW:
> > 
> > In the case of multiple working paths failing, the shared resource
> > utilization
> > 
> > coordination SHALL be between the different working
> > 
> > paths in the SMP network.
> > 
> > 
> > 
> > (10) Section 5.1.1.
> > 
> > OLD:
> > 
> > ЁІ because they already have been committed to the protection of,
> > for example, a higher priority working path.
> > 
> > NEW:
> > 
> > ЁІ because they already have been utilized for the protection of,
> > for example, a higher priority working path.
> > 
> > 
> > 
> > (11) Section 5.2, the second bullet item:
> > 
> > OLD:
> > 
> > Resources of the shared segments SHALL be committed to the
> > 
> > protection path ЁІ
> > 
> > NEW:
> > 
> > Resources of the shared segments SHALL be utilized by the
> > 
> > protection path ЁІ
> > 
> > 
> > 
> > (12) Section 5.2, the third bullet item:
> > 
> > OLD:
> > 
> > If multiple protection paths of equal priority are requesting
> > 
> > allocation of the shared resources, the resources SHOULD be
> > 
> > committed on a first come first served basis.
> > 
> > NEW:
> > 
> > If multiple protection paths of equal priority are requesting
> > 
> > the shared resources, the resources SHOULD be
> > 
> > assigned on a first come first served basis.
> > 
> > 
> > 
> > (13) Section 5.2, the fourth bullet item:
> > 
> > OLD:
> > 
> > If the protection resources are committed to a protection path,
> > 
> > whose working path has a lower priority, resources required for
> > 
> > the higher priority path SHALL be committed to the higher priority
> > 
> > path.
> > 
> > NEW:
> > 
> > If the protection resources are utilized by a protection path,
> > 
> > whose working path has a lower priority, resources required for
> > 
> > the higher priority path SHALL be assigned to the higher priority
> > 
> > path.
> > 
> > 
> > 
> > 
> > 
> > (14) Section 5.2. the seventh bullet item
> > 
> > OLD:
> > 
> > Once resources of shared segments have been successfully committed
> > 
> > to a protection path, ЁІ
> > 
> > NEW:
> > 
> > Once resources of shared segments have been successfully utilized
> > 
> > by a protection path, ЁІ
> > 
> > 
> > 
> > (15) Section 5.3, the first paragraph,
> > 
> > OLD:
> > 
> > ЁІ request the commitment of protection resources. If the necessary
> > 
> > shared resources are unavailable to be committed to the protection
> > 
> > path, the endpoints ЁІ
> > 
> > 
> > 
> > NEW:
> > 
> > ЁІ request the coordination of the shared resource utilization. If
> > the necessary
> > 
> > shared resources are unavailable, the endpoints ЁІ
> > 
> > 
> > 
> > (16) Section 5.3, the second paragraph,
> > 
> > OLD:
> > 
> > Similarly, if preemption is supported and the resources currently
> > 
> > committed for a particular working path are ЁІ
> > 
> > NEW:
> > 
> > Similarly, if preemption is supported and the resources currently
> > 
> > utilized by a particular working path are ЁІ
> > 
> > 
> > 
> > 
> > 
> > - Section 2, 1st paragraph, last sentence. This sentence really
> > defines
> > the scope/purpose of the document, i.e., "clarifies the instructions
> > to protocol designers producing solutions that satisfy the
> > requirements set out in this document." As such, I'd repeat this in
> > the abstract and move it to a more pronounced place in section 1 (or
> > 3).
> > 
> > [Authors] We can add the following paragraph at the end of Section 1:
> > 
> > ЁАThis document is intended to clarify the instructions to protocol
> > designers producing solutions that satisfy the requirements set
> > out in this document.ЁБ
> > 
> > 
> > 
> > 
> > - General comment: fate-sharing for co-routed bidirectional LSP
> > protection: How is co-routing preserved for the reverse path in SMP?
> > I'd assumed the protection switch coordination protocol would be
> > required to trigger a switchover of the reverse LSP in the co-routed
> > case, but don't see this in the document.
> > 
> > [Authors] Fate-sharing is not required by this document. Even in
> > the PSC linear protection switching, such as RFC 6378 (PSC) and
> > RFC 7271 (PSC in APS mode), fate-sharing is not required as
> > unidirectional switching is allowed. This document does not impose
> > any restriction on co-routing, either.
> > 
> > 
> > 
> > 
> > - In section 4 and 5.2 you reference 5712 and 3209 as defining
> > preemption terminology and behavior. I think 6372 is the right
> > reference here as it defines both in the context of survivability and
> > in dependent of control plane.
> > 
> > [Authors] One concern is that RFC 6372 describes both soft and
> > hard preemptions in the context of extra traffic, which is not
> > exactly the case for SMP.
> > 
> > 
> > 
> > 
> > - In section 4.2 you say "Therefore, it is suggested that this be
> > carried out under the control of a dynamic control plane similar to
> > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great,
> > please make the correction. If not, I think the debate of which
> > control protocol is used for MPLS-TP is way beyond the scope of this
> > document.
> > 
> > [Authors] Yes, we will make the correction.
> > 
> > 
> > 
> > 
> > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If
> > referring to solutions conformant with this document, then these are
> > informative statements, "and a non-control plane based SMP switchover
> > mechanism is used, the control plane SHALL NOT ...". If referring to
> > an operator's/user's choice of protection mechanism, I think the most
> > you can say is MAY.
> > 
> > [Authors] The first case is the one we are aiming at. We will use
> > SHALL NOT.
> > 
> > 
> > 
> > 
> > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP
> > domain." As this is a requirement, what you mean by "tie-breaking
> > rules" should be defined directly or by reference.
> > 
> > [Authors] The sentence can be rewritten as:
> > 
> > OLD:
> > 
> > Tie-breaking rules SHALL be defined in scope of an SMP domain.
> > 
> > NEW:
> > 
> > In order to cover the situation where the first come first served
> > principle cannot resolve the contention among multiple equal
> > priority requests, i.e., when the requests occur simultaneously,,
> > tie-breaking rules SHALL be defined in scope of an SMP domain.
> > 
> > 
> > 
> > 
> > 
> > 
> > - Section 5.3. RFC6372 takes an approach where preemption notification
> > leverages the standard MPLS-TP OAM mechanisms, is there any reason to
> > do more / not just follow 6372?
> > 
> > [Authors] We can add the following sentence at the end:
> > 
> > ЁАAs described in [RFC6372], the event of preemption may be
> > detected by OAM and reported as a fault or a degradation of
> > traffic delivery.ЁБ
> > 
> > 
> > - Section 5.7. There may be coordination required on
> > soft-preemption as
> > well (depending on the cross-connects established during LSP
> > establishment) so coordinated switching should be supported
> > independent of preemption mode.
> > 
> > [Authors] Yes, we will change the second paragraph from ЁАSMP in
> > hard-preemption mode SHOULD ЁІЁБ to ЁАSMP SHOULD ЁІЁБ and move the
> > changed paragraph above the first paragraph.
> > 
> > 
> > 
> > 
> > Nits:
> > 
> > - Abstract: I don't recall the term "executive action" being used
> > in any
> > earlier related/referenced RFCs. Rather than introduce a new (and
> > undefined) term, perhaps you can use an existing one, e.g.,
> > "protection switch"?
> > 
> > [Authors] Yes, the term will be changed as you suggested.
> > 
> > 
> > 
> > 
> > - Section 1, paragraph 1. Do we really need another definition of
> > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
> > document(s) and dropping the first four sentences.
> > 
> > The last sentence also makes a subjective statement. Whether it is
> > critical or no is unnecessary. You can just say something like 6372
> > provides a survivability framework for MPLS-TP and is the foundation
> > for this document.
> > 
> > [Authors] The proposed text for the paragraph 1 is:
> > 
> > ЁАThe MPLS Transport Profile (MPLS-TP) is described in [RFC5921],
> > 
> > and [RFC6372] provides a survivability framework for MPLS-TP
> > 
> > and is the foundation for this document.ЁБ
> > 
> > 
> > 
> > 
> > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
> > Also drop the word linear, as it is an unnecessary qualifier and
> > 4427/4428 don't use it.
> > 
> > [Authors] OK.
> > 
> > 
> > 
> > 
> > 
> > 
> > - Sections 3 (and to a lesser degree section 2) are really
> > introductory
> > text. I'm unsure as to why they aren't part of section 1.
> > 
> > [Authors] Section 3 was intended to present a reference model for
> > SMP. Some text of Section 2 is repeated in Section 1 as you
> > suggested earlier.
> > 
> > 
> > 
> > 
> > 
> > 
> > - Section 3.2 should have a reference for "existing control plane
> > solutions for SMP within MPLS".
> > 
> > [Authors] [RFC4206] will be added as a reference
> > 
> > 
> > - Section 3.2 again uses the "executive action" term.
> > 
> > [Authors] OK, the term will be changed.
> > 
> > 
> > 
> > 
> > - Section 4.1. You say "two operations simultaneously". Do you really
> > mean "simultaneously" or merely that they must both occur for
> > protection to be provided? (Same comment in section 5.1.
> > 
> > [Authors] Both actions should occur at the same time, or as
> > closely as possible to provide fast protection.
> > 
> > 
> > 
> > 
> > - Section 5.2. I suggest numbering the currently bulletted
> > requirements
> > list.
> > 
> > [Authors] OK, we will use numbers.
> > 
> > 
> > 
> > 
> > - Section 5.2: First paragraph and forth bullet last sentence. These
> > both basically cover the same topic (preemption) and actually say
> > slightly different things. I suggest combine into a single
> > requirement to ensure consistency and full coverage of the topic.
> > 
> > [Authors] The first paragraph is for soft-preemption, while the
> > fourth bullet belongs to the requirements of hard-preemption.
> > 
> > 
> > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't
> > the topics related to timing be consolidated?
> > 
> > [Authors] Yes, req 5 can be moved to Section 5.5.
> > 
> > 
> > 
> > 
> > - Section 5.2: requirement 6 seems to be a subset of 7, so it
> > should be
> > dropped.
> > 
> > [Authors] Yes, it will be deleted.
> > 
> > 
> > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out
> > just this one traffic treatment (sub) requirement?
> > 
> > [Authors] Req. 9 will be deleted as it seems to require control
> > plane supports.
> > 
> > 
> > 
> > - Section 5.3. s/MAY/will
> > 
> > [Authors] OK.
> > 
> > 
> > 
> > 
> > - section 5.4: " When the working path detects.." detection is by the
> > node not the path.
> > 
> > [Authors] Yes. We will simply say that ЁАWhen the condition that
> > triggered the protection switching is cleared, ЁІЁБ
> > 
> > 
> > - Section 5.4, last sentence. This is only the 2nd time you imply that
> > the document covers requirements on a new protocol. I think this
> > point is currently too subtle in the document. (This point was also
> > made as a minor comment.)
> > 
> > [Authors] As in other protection switching technologies, two modes
> > of operations (revertive and non-revertive) are required.
> > 
> > 
> > 
> > 
> > - section 5.6. RFC 6372 should be referenced
> > 
> > [Authors] We will add ЁАas described in [RFC6372]ЁБ to the ends of
> > two paragraphs for WTR timer and hold-off timer.
> > 
> > 
> > 
> > ***** End of Comment resolution *****
> > 
> > 
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > *КИГН ЛчЖї : *"Lou Berger" <lberger@labn.net
> > <mailto:lberger@labn.net>>
> > *КИГН ГЏ Ѕ : *2014-06-22 01:00:48 ( +09:00 )
> > *ЙоД  ЛчЖї : *rtg-ads@tools.ietf.org
> > <mailto:rtg-ads@tools.ietf.org> <rtg-ads@tools.ietf.org
> > <mailto:rtg-ads@tools.ietf.org>>
> > * ќСЖ : *rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>
> > <rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>>,
> > draft-ietf-mpls-smp-requirements.all@tools.ietf.org
> > <mailto:draft-ietf-mpls-smp-requirements.all@tools.ietf.org>
> > <draft-ietf-mpls-smp-requirements.all@tools.ietf.org
> > <mailto:draft-ietf-mpls-smp-requirements.all@tools.ietf.org>>,
> > mpls@ietf.org <mailto:mpls@ietf.org> <mpls@ietf.org
> > <mailto:mpls@ietf.org>>
> > *СІИё : *[mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt
> > 
> > 
> > Hello,
> > 
> > I have been selected as the Routing Directorate reviewer for this
> > draft. The Routing Directorate seeks to review all routing or
> > routing-related drafts as they pass through IETF last call and IESG
> > review, and sometimes on special request. The purpose of the review is
> > to provide assistance to the Routing ADs. For more information
> > about the
> > Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> > 
> > Although these comments are primarily for the use of the Routing
> > ADs, it
> > would be helpful if you could consider them along with any other IETF
> > Last Call comments that you receive, and strive to resolve them
> > through
> > discussion or by updating the draft.
> > 
> > Document: draft-ietf-mpls-smp-requirements-06.txt
> > Reviewer: Lou Berger
> > Review Date: June 21 2014
> > IETF LC End Date: 2014-06-23
> > Intended Status: Informational
> > 
> > Summary:
> > I have some minor concerns about this document that I think
> > should (must, actually) be resolved before publication.
> > 
> > Comments:
> > 
> > I think the document is well written and, other than a couple of
> > terminology related issues, easily understood. The document does
> > have a number of terminology and technical issues which should be
> > readily resolved prior to publication.
> > 
> > Major Issues:
> > 
> > Major issues are the type of concerns that will result in the
> > document being blocked until they are resolved. The Routing ADs will
> > become involved. Please include all of the major issues you have
> > found. Give as much context information as possible (e.g., section
> > numbers, paragraph counts). If you find no major issues, please
> > write: "No major issues found."
> > 
> > - No major issues found. In particular, I expect all issues can be
> > resolved without AD intervention. Some of the minor issues, if not
> > resolved will be escalated to the AD/major issue category.
> > 
> > Minor Issues:
> > 
> > Minor issues are concerns about clarity or technical accuracy that
> > should be discussed and resolved before publication, but which would
> > normally be resolved between the authors and the reviewers. Please
> > include all of the minor issues you have found. Give as much context
> > information as possible (e.g., section numbers, paragraph counts).
> > If you find no minor issues, please write: "No minor issues found."
> > 
> > - Document's usage of "committed" vs "allocated" resources:
> > 
> > In section 1 the document introduces the notion that the
> > distinction between protection and restoration is based on when
> > resources are "committed". This difference from past
> > definition. RFC4427 and 6372 make the distinction that protection
> > and restoration differ based on when resources are *allocated* not
> > *committed*. To quote RFC 4427:
> > 
> > The distinction between protection and restoration is made based
> > on the resource allocation done during the recovery LSP/span
> > establishment. The distinction between different types of
> > restoration is made based on the level of route computation,
> > signaling, and resource allocation during the restoration
> > LSP/span establishment.
> > 
> > This difference also leads to come confused statements in the
> > document as well as ambiguity in the text, i.e. confusion by the
> > reader. The term "committed" is not tightly defined in this
> > document (or earlier work) and is used differently than how
> > "allocated" has been used. An example of this can be found in
> > Section 3.1 which states:
> > 
> > However, the commitment of the resources, at least for the
> > shared segments, will only be finalized when the protection
> > path is actually activated. Therefore, for the purists -
> > regarding the terminology - SMP lies somewhere between
> > protection and restoration.
> > 
> > Both sentences are problematic. In the first, commitment seems to
> > cover a "protection switch" would "connect" the protection path
> > but not the earlier "allocation" of resources. (Quoted terms are
> > used in earlier RFCs.) The second conclusion is based on the new
> > distinction of protection vs. restoration and is unnecessary with
> > the existing distinction.
> > 
> > This issue exists in multiple places in the document where
> > "committed" is used and I'd recommend that each should be replaced
> > with terminology used in the referenced RFCs, i.e., "allocation",
> > "connection", "cross-connect", "protection switch(over)", ...
> > 
> > Note I'm *not* highlighting all cases where there are problems in the
> > document related to this issue. There are a couple of places in the
> > document where I think it's possible that once this terminology
> > ambiguity is corrected that I'll have other substantive comments.
> > 
> > - Section 2, 1st paragraph, last sentence. This sentence really
> > defines
> > the scope/purpose of the document, i.e., "clarifies the instructions
> > to protocol designers producing solutions that satisfy the
> > requirements set out in this document." As such, I'd repeat this in
> > the abstract and move it to a more pronounced place in section 1 (or
> > 3).
> > 
> > - General comment: fate-sharing for co-routed bidirectional LSP
> > protection: How is co-routing preserved for the reverse path in SMP?
> > I'd assumed the protection switch coordination protocol would be
> > required to trigger a switchover of the reverse LSP in the co-routed
> > case, but don't see this in the document.
> > 
> > - In section 4 and 5.2 you reference 5712 and 3209 as defining
> > preemption terminology and behavior. I think 6372 is the right
> > reference here as it defines both in the context of survivability and
> > in dependent of control plane.
> > 
> > - In section 4.2 you say "Therefore, it is suggested that this be
> > carried out under the control of a dynamic control plane similar to
> > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great,
> > please make the correction. If not, I think the debate of which
> > control protocol is used for MPLS-TP is way beyond the scope of this
> > document.
> > 
> > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If
> > referring to solutions conformant with this document, then these are
> > informative statements, "and a non-control plane based SMP switchover
> > mechanism is used, the control plane SHALL NOT ...". If referring to
> > an operator's/user's choice of protection mechanism, I think the most
> > you can say is MAY.
> > 
> > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP
> > domain." As this is a requirement, what you mean by "tie-breaking
> > rules" should be defined directly or by reference.
> > 
> > - Section 5.3. RFC6372 takes an approach where preemption notification
> > leverages the standard MPLS-TP OAM mechanisms, is there any reason to
> > do more / not just follow 6372?
> > 
> > - Section 5.7. There may be coordination required on
> > soft-preemption as
> > well (depending on the cross-connects established during LSP
> > establishment) so coordinated switching should be supported
> > independent of preemption mode.
> > 
> > Nits:
> > 
> > - Abstract: I don't recall the term "executive action" being used
> > in any
> > earlier related/referenced RFCs. Rather than introduce a new (and
> > undefined) term, perhaps you can use an existing one, e.g.,
> > "protection switch"?
> > 
> > - Section 1, paragraph 1. Do we really need another definition of
> > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
> > document(s) and dropping the first four sentences.
> > 
> > The last sentence also makes a subjective statement. Whether it is
> > critical or no is unnecessary. You can just say something like 6372
> > provides a survivability framework for MPLS-TP and is the foundation
> > for this document.
> > 
> > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
> > Also drop the word linear, as it is an unnecessary qualifier and
> > 4427/4428 don't use it.
> > 
> > - Sections 3 (and to a lesser degree section 2) are really
> > introductory
> > text. I'm unsure as to why they aren't part of section 1.
> > 
> > - Section 3.2 should have a reference for "existing control plane
> > solutions for SMP within MPLS".
> > 
> > - Section 3.2 again uses the "executive action" term.
> > 
> > - Section 4.1. You say "two operations simultaneously". Do you really
> > mean "simultaneously" or merely that they must both occur for
> > protection to be provided? (Same comment in section 5.1.
> > 
> > - Section 5.2. I suggest numbering the currently bulletted
> > requirements
> > list.
> > 
> > - Section 5.2: First paragraph and forth bullet last sentence. These
> > both basically cover the same topic (preemption) and actually say
> > slightly different things. I suggest combine into a single
> > requirement to ensure consistency and full coverage of the topic.
> > 
> > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't
> > the topics related to timing be consolidated?
> > 
> > - Section 5.2: requirement 6 seems to be a subset of 7, so it
> > should be
> > dropped.
> > 
> > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out
> > just this one traffic treatment (sub) requirement?
> > 
> > - Section 5.3. s/MAY/will
> > 
> > - section 5.4: " When the working path detects.." detection is by the
> > node not the path.
> > 
> > - Section 5.4, last sentence. This is only the 2nd time you imply that
> > the document covers requirements on a new protocol. I think this
> > point is currently too subtle in the document. (This point was also
> > made as a minor comment.)
> > 
> > - section 5.6. RFC 6372 should be referenced
> > 
> > 
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org <mailto:mpls@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mpls
> > 
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org <mailto:mpls@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mpls
> > 

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

[prev in list] [next in list] [prev in thread] [next in thread] 