Multiprotocol Label Switching
charter-ietf-mpls-08

[Ballot comment]
Thanks for adding `Note: All documents will be standards track unless otherwise specified in the milestones.` *even* if I was expecting some documents to have an intended status of informational, e.g.:

* Maintain existing MPLS requirements (if published in a separate document)
* Document use cases for MPLS protocols
* Document MPLS-specific aspects of traffic engineering ...

Thanks also for replying to all my previous comments.

[Ballot block]
I am afraid that all work items must specify the intended publication status (e.g., informational, experimental, ...), i.e., there is a lack of technical clarity on the deliverables.

[Ballot comment]
s/emulation of Layer 1, Layer 2, and Layer 3 frames, packets, and services; and mechanisms/emulation of layer-1, layer-2, and layer-3 frames, packets, services, and mechanisms/ ?

Should references be added to tLDP and mLDP ?

Should the WG acronym be expanded ? Even if well-known for 10+ years.

[Ballot comment]

"TEAS", paragraph 0
> •      Define YANG data models for MPLS working group related solutions.
> Coordinate with the NETMOD and ONIONS working groups for core YANG models.

Just one comment. ONIONS WG has not been formed as yet. Do we want to mention it here?

Ask about any chair changes.

[Ballot comment]
** There is no ONIONS WG per “Define YANG data models for MPLS working group related solutions. Coordinate with the NETMOD and ONIONS working groups for core YANG models.”

** Per “Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications to achieve a common set of approaches and tools across the full family of MPLS applications.”

-- What is meant by “tools”?

-- What are “MPLS applications”?

-- Editorial.  Something doesn’t parse with “Define an overall OAM framework for … and transport profile MPLS applications”

-- Is the deliverable for the “overall OAM framework”, draft-ietf-mpls-mna-ioam?  Is it this one document and the framework is “done”?

** Per “Maintain existing MPLS-based static and LDP-signaled pseudowire and L2VPN requirements, mechanisms, and protocols as currently documented in RFCs, and enhance them as necessary”, what does the “as necessary” add?  How is this necessity determined?

[Ballot comment]
Thank you for the work to update the charter.

Please find some comments below (ordered by charter flow, not importance):

# Be consistent with 8407bis

OLD: management objects expressed as YANG models.

NEW: OLD: management objects expressed as YANG data models.

# The protocol maintenance part is obvious, but I don’t understand the maintenance of “existing requirements” part. I see that this was inherited from the OLD charter, though.

CURRENT:
Maintain existing MPLS requirements, mechanisms, and protocols, as currently documented in RFCs,

# As the WG defines extensions to protocols defined by other WGs (e.g., draft-ietf-mpls-stamp-pw), please add IPPM to the list below

CURRENT:
  • …, in coordination with other working groups that work in overlapping areas including the BESS, BFD, BIER, CCAMP, DETNET, IDR, OPSAWG, SPRING, and TEAS working groups.


# I appreciate that ONIONS is listed here but not sure I would link it to “core YANG models”

CURRENT:
  • Define YANG data models for MPLS working group related solutions. Coordinate with the NETMOD and ONIONS working groups for core YANG models.

Better, you may avoid listing specific WGs, e.g.,

NEW:
• Define YANG data models for MPLS working group related solutions. Coordinate with relevant WGs for core and network models that involve MPLS protocols.

# What do you mean by “OAM framework for topology-driven”?

CURRENT:
  • Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications to achieve a common set of approaches and tools across the full family of MPLS applications.

BTW, do you need to maintain this item listed in the new charter? I see this framework promised since 2014.

# Use cases

CURRENT:
  • Document use cases for MPLS protocols.

## Move this item up in the list to be near the items about requirements

## MNA use cases (mentioned in the item right after) are covered by this item as well, but I understand the WG would prefer to have an explicit mention to cover MNA specifically. That’s fair as well.

# Group maintenance items

CURRENT:
  Maintain existing MPLS-based static and LDP-signaled pseudowire and L2VPN requirements

I would move that one to be listed right after “Maintain existing MPLS requirements, mechanisms, and protocols …” item.

Thank you.

Cheers,
Med

[Ballot comment]
Some comments:

1) A suggestion/nit

CURRENT
MPLS encapsulation and emulation of Layer 1, Layer 2, and Layer 3 frames, packets, and services

SUGGEST
MPLS encapsulation and emulation of Layer 1, Layer 2, and Layer 3 frames, packets, and services over MPLS

2) Please remove references to ONIONS as that group is not yet chartered. I don't understand if any coordination with NETMOD is required anymore for model development in individual WGs.

3) I have a concern with this item about "document use cases for MPLS protocols". Can this be qualified? MPLS being a mature technology, I wonder the value in producing use case documents. That said, this makes sense is for new work such as MNA - but that is already covered in a further bullet.

This charter update incorporates maintenance for the protocols produced by the PALS WG (that was recently closed) and formally updates to allow for the MNA work.

Added milestone "Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard", due December 2008, from current group milestones

Added milestone "Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)", due July 2004, from current group milestones

Added milestone "Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard", due October 2003, from current group milestones

Added milestone "Submit Multiprotocol Label Switching (MPLS) Traffic  Engineering Management Information Base to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

[Ballot comment]
To avoid any potential confusions with LIME, I would prefer:
OLD:

The working group's responsibilities include procedures and
protocols for the distribution of labels between Label Switching
Routers (LSRs), MPLS packet encapsulation, and for Operation,
Administration, and Maintenance (OAM) including the necessary
management objects expressed as YANG models or MIB modules.

NEW:

The working group's responsibilities include procedures and
protocols for the distribution of labels between Label Switching
Routers (LSRs), for MPLS packet encapsulation, and for the related Operation,
Administration, and Maintenance (OAM) including the necessary
management objects expressed as YANG models or MIB modules.


One clarifying question (sorry I missed that one during the previous review). I don't understand what the following means:

- Define an overall OAM framework for topology-driven, traffic
  engineered, and transport profile MPLS applications.

What is an OAM "framework"? An architecture, a new (set of) protocol(s), protocol extensions, something else?

[Ballot comment]
To avoid any potential confusions with LIME, I would prefer:
OLD:

The working group's responsibilities include procedures and
protocols for the distribution of labels between Label Switching
Routers (LSRs), MPLS packet encapsulation, and for Operation,
Administration, and Maintenance (OAM) including the necessary
management objects expressed as YANG models or MIB modules.

NEW:

The working group's responsibilities include procedures and
protocols for the distribution of labels between Label Switching
Routers (LSRs), for MPLS packet encapsulation, and for the related Operation,
Administration, and Maintenance (OAM) including the necessary
management objects expressed as YANG models or MIB modules.


One clarifying question (sorry I missed that one during the previous review). I don't understand what the following mean:

- Define an overall OAM framework for topology-driven, traffic
  engineered, and transport profile MPLS applications.

What is an OAM "framework"? An architecture, a new (set of) protocol(s), protocol extensions, something else?

[Ballot comment]
Some bits I think should be clarified, but can wait until external review:

  The working group's responsibilities include procedures and protocols
 
What do you mean by "procedures"? Operational guidance?
 
  - Determine MPLS-specific aspects of traffic engineering including
    for multi-areas/multi-AS scenarios in cooperation with the TEAS
    working group.

As with the CCAMP charter, I'm a bit mystified by the word "Determine" here. What exactly does the WG do on this point?

[Ballot comment]
Same remark as for the TEAS charter.

OLD:
- Define YANG models and MIB modules for MPLS working group related
  solutions. Coordinate with the LIME and NETMOD working groups for
  core YANG models.

NEW:
- Data models (YANG and MIB modules may be considered.) for MPLS
  working group related solutions. Coordinate with the LIME and NETMOD
  working groups for core YANG models.

[Ballot block]
  - Coordinate the work on RSVP-TE with CCAMP and TEAS, and
    document where the work will be undertaken. In the cases where
    there is an overlap, generic parts will be done by the TEAS working
    group, MPLS data plane specific parts will be done by the MPLS
    working group, and support for any other specific data planes will
    be done by the CCAMP working group. The TEAS working group acts as
    the coordination point for this work.

The first sentence and the last sentence of this bullet seem to contradict each other: Does this group do the coordination, or does TEAS? But even so, I'm a bit concerned by a WG coordinating work and documenting where it will be undertaken. Are you really saying that the WG has to come to consensus on where a particular piece of protocol work is to be done and then document that decision? That seems like an awfully bizzarre item of work. Please clarify.

[Ballot comment]
  The working group's responsibilities include procedures and protocols
 
What do you mean by "procedures"? Operational guidance?
 
  - Determine MPLS-specific aspects of traffic engineering including
    for multi-areas/multi-AS scenarios in cooperation with the TEAS
    working group.

As with the CCAMP charter, I'm a bit mystified by the word "Determine" here. What exactly does the WG do on this point?

Added milestone "Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard", due December 2008, from current group milestones

Added milestone "Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)", due July 2004, from current group milestones

Added milestone "Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard", due October 2003, from current group milestones

Added milestone "Submit Multiprotocol Label Switching (MPLS) Traffic  Engineering Management Information Base to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

Added milestone "Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards", due August 2001, from current group milestones

[Ballot comment]
Just one little innocent question:-)

This says:

-  Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE
    and LSP Ping to meet new requirements.

and

-  Document mechanisms for securing MPLS networks in coordination
    with the KARP working group.

Karp is precluded from considering confidentiality and its charter
doesn't mention privacy.

Assuming that MPLS might be used e.g. near the endpoints of
transatlantic fibres, (is it?) do you think the WG might be open
to considering work on confidentiality/privacy, perpaps even on
opportunistic encryption or the like? I guess one could argue
that there are requirements there that have only recently
become clear.

[Ballot block]

Just one little innocent question:-)

This says:

-  Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE
    and LSP Ping to meet new requirements.

and

-  Document mechanisms for securing MPLS networks in coordination
    with the KARP working group.

Karp is precluded from considering confidentiality and its charter
doesn't mention privacy.

Assuming that MPLS might be used e.g. near the endpoints of
transatlantic fibres, (is it?) do you think the WG might be open
to considering work on confidentiality/privacy, perpaps even on
opportunistic encryption or the like? I guess one could argue
that there are requirements there that have only recently
become clear.

If this will go for external review I'm fine with asking the question
on ietf@ietf.org and will unblock.

If not, I'd appreciate a quick chat about this before I unblock.

[Ballot comment]
I'm fine to have this go forward, but as a general observation: Some RAI participants have been suggesting that WG charters have a clear definition of success -- when will we know the WG is done?  Having the answer to this question be clear in the charter seems to me like a good way to avoid scope creep and endless WGs. 

This charter seems to take completely the opposite approach, so it does give me some concern of MPLS creep.  However, I'll leave it to the responsible ADs to decide whether this is an issue in this case.

[Ballot comment]
  "The responsibility includes..."

What an odd construction. Can better words be chosen?

-  Maintain existing MPLS requirements, mechanisms, and protocols,
    in coordination with other working groups, e.g. CCAMP, PWE3
    and OPSAWG working groups.

I'm not sure what work item(s) you're talking about here. Is the WG updating existing requirements documents and/or protocol documents in response to new requirements from CCAMP, PWE3, and OPSAWG? Not clear from what's said what is being referred to.

-  Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE
    and LSP Ping to meet new requirements.

Same question as above. "Evolve" is an odd word to choose, and I'm curious if the list of protocols is exhaustive. Please clarify.

-  Determine MPLS-specific aspects of traffic engineering for
    multi-areas/multi-AS in cooperation with the CCAMP WG

Is there a reason this bullet changed from the previous version? It seems to have removed the "and document it" part.

I'm not going to block this rechartering, but I would like to hear why the charter became (apparently) more mushy than it had been.

[Ballot comment]
I am Ok with the charter, but the headline in the tool says "Is this charter ready for external review? Is this charter ready for approval without external review?", interesting isn't it?

Is it now w/ or w/o external review?