RE: Liaison received from MFA

["MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ftgroup.com>]

Hi all.

The MFA appears to focus on PSC using GMPLS procedures: I agree we should wonder whether this as a specific GMPLS profile or a removal of the Generalized aspect. Anyway, I think the answer we'll give them should include a pointer to draft-ietf-ccamp-mpls-gmpls-interwork-fmwk.

I'm not sure this is the place for detailled comments, but I had a quick look on the specification and here are my thoughts.

- It seems their terminology is mixing MPLS/MPLS-TE/GMPLS, thus leading to the misused "GMPLS-TE" acronym. By the way, I don't think we mention any "GMPLS-TE capable interfaces" (p.6) in IETF.

- The section 7.2 named "GMPLS Signaling Channel" only mentions that "labeled packets share the same access connection as the RSVP-TE signaling". However, RFC 3945 says: "the control channels [...] exist independently of the links they manage", thus requiring in case of POS interface, for instance, to have a specific channel -- like DCC bytes -- pre-existing to any STS-3/VC-4 (or OC-3n/STM-n) connection. Here again, I'm not so sure they're really doing *G*MPLS.

As a result, I feel they're combining RFC 4208 and 4124, but they're also turning off the generalized aspects -- which I'm not very fond of: this is not GMPLS any more. Furthermore, I fear control and data plane separation is not properly understood in their document. This makes me think this is more an MPLS issue inspired by some "advanced" mechanisms from RFC 3473 and others.

Regards,

Julien


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel

Hi,

CCAMP has received a liaison from the MFA.
You can see this at http://www.olddog.co.uk/incoming.htm

I'm not quite sure whether this should actually be handled by us or by the 
MPLS working group, so I will be discussing it with the MPLS chairs.

All comments on this work gratefully received.

We are called upon to respond by February.

Adrian