Your Discusses and Comments on draft-ietf-ccamp-mpls-gmpls-interwork-fmwk

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

I think we have proposals to resolve your issues with 
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk.

Can you confirm that they would meet your needs?

Thanks,
Adrian

===
Tim Polk
Discuss
"This is a discuss discuss.  Personally, I find the phased migration model 
terrifying.  Selective introduction of features seems like a great 
opportunity to perform a DoS attack on your own network.  Are there features 
of GMPLS that assume the existence of other features for consistent 
operation?  It seems like you are developing your own interim internal 
"standards" that need to be self-consistent.  Is this really a good thing 
for the IETF to recommend?"

Ross is right that the intention of CCAMP in this I-D was to not recommend 
the phased model (although it should be noted that this is exactly what the 
vendors are doing)-:  So section 4.3 is a fine place to add additional 
warnings as follows...

>   Interoperability concerns though are exacerbated by this migration
>   model, unless all LSRs in the network are updated simultaneously and
>   there is a clear understanding of which subset of features are to be
>   included in the hybrid LSRs. Interworking between a hybrid LSR and an
>   unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS
>   LSR as described in the previous sections and puts the unchanged LSR
>   in the role of an MPLS LSR. The potential for different hybrids
>   within the network will complicate matters considerably.
   This model is, therefore, only appropriate for use when the set of new
   features to be deployed is well known and limited, and where there is
   a clear understanding of and agreement on this set of features by the
   network operators of the ISP(s) involved as well as all vendors whose
   equipment will be involved in the migration.

===

Tim Polk
Comment
"Section 5, Paragraph 4 first sentence currently reads:

 The second strategy for PSC and non-PSC networks is to migrate from
 the PSC network to GMPLS, first, and then enable GMPLS within the
 non-PSC network.

I suggest:

 The second strategy is to migrate from
 the PSC network to GMPLS, first, and then enable GMPLS within the
 non-PSC network."

This should actually read...
  The second strategy is to migrate
  the PSC network to GMPLS first, and then enable GMPLS within the
  non-PSC network."

===

Dave Ward
Comment
"There is no mention of using PCEs for this functionality."

PCE could fit usefully into the Island model and the Integrated model. It 
would not play any valuable role in the Phased model.

I think the best place to add a reference would be in section 5.1 since PCE 
may provide a component in the migration toolkit. This would not be as 
strong as a recommendation to use PCE since it is clear that the use of PCE 
is not a prerequisite for migration.

So we could add...

5.1.4. Path Computation Element

  The Path Computation Element (PCE) [RFC4655] may provide an
  additional tool to aid MPLS to GMPLS migration. If a layered network
  approach (Section 5.1.1) is used, PCEs may be used to facilitate the
  computation of paths for LSPs in the different layers
  [PCE-INTER-LAYER].

And to section 12.2

  [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture", RFC 4655, August 2006.

  [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A.,
                        "Framework for PCE-Based Inter-Layer MPLS
                         and GMPLS Traffic Engineering,"
                         draft-ietf-pce-inter-layer-frwk, work in progress.