Subject: [mpls] P2MP Requirements Issue 1

From: Seisho Yasukawa <[email-masked]>
Date: Tue, 21 Dec 2004 19:09:23 +0900

Hi MPLS List,

As promised, this is the first of several emails to resolve the remaining 
open issues in 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-sig-requirement-00.txt

Section 4.9 describes the variation of LSP parameters (e.g. priority, 
bandwidth, etc.) between different branches of a P2MP LSP. The text 
currently says

    Any solution MUST NOT allow for variance of these parameters. That
    is,
    - no attributes set and signaled by the ingress of a P2MP LSP may be
      varied by downstream LSRs
    - there MUST be homogeneous QoS from the root to all leaves.

There has been some discussion that it might be desirable to make some 
variations under the control of the ingress LSR. Also, it has been pointed 
out that make-before-break is commonly used to vary these parameters.

We would like to propose to clarify this by changing section 4.9 to read as 
follows.

4.9 Variation of LSP Parameters

    Various parameters to an LSP (such as priority, bandwidth, etc.) are
    signaled along each branch of the LSP.

    Any solution MUST NOT allow for variance of these parameters within a
    single P2MP LSP. That is:
    - No attributes set and signaled by the ingress of a P2MP LSP may be
      varied by downstream LSRs.
    - There MUST be homogeneous QoS from the root to all leaves of a
      single P2MP LSP.

    Variation of parameters may be allowed so long as it applies to the
    whole LSP from ingress to all egresses.

If you have comments opposed to this text it would be helpful if you could 
supply realistic functional requirements that explain how you might deploy 
anything different.

Thanks,
Seisho 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 21 Dec 2004 07:27:50 -0500

I have a comment on draft-ietf-mpls-p2mp-sig-requirement-00.txt.
The paragraph below seems to on the one hand, have no
requirements as is stated in the last paragraph, does
give a requirement. I suggest that this document simply
refer to draft-ietf-mpls-oam-requirements-05.txt, since the WG
agreed to include all MPLS OAM-related requirements in
this draft.

	--Tom

4.18 P2MP MPLS OAM

    Management of P2MP LSPs is as important as the management of P2P
    LSPs.

    The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE
    LSP management.

    In order to facilitate correct management, P2MP TE LSPs MUST have
    unique identifiers.

    OAM facilities will have special demands in P2MP environments
    especially within the context of tracing the paths and connectivity
    of P2MP TE LSPs. The precise requirements and mechanisms for OAM are
    out of the scope of this document. It is expected that a separate
    document will cover these requirements.

---

From: Monique Morrow <[email-masked]>
Date: Tue, 21 Dec 2004 07:55:19 -0500

I support this recommendation Tom -- this would be most efficent.

/monique

---

From: Loa Andersson <[email-masked]>
Date: Tue, 21 Dec 2004 14:44:03 +0100

Monique, Tom and doc authors,

I'm not sure it is good style putting requirements on
other documents (in this case in part from the same working
group in a requirement document. The document is intended to
become an RFC and if we have requirements on what goes into
other RFCs it will be hard to follow, especially after that
stuff has been put into that document.

Would be better to state something like "The MPLS and GMPLS
MIB will be / has been enhanced to provide P2MP TE LSP
management."

Please note that when you write this, you also commit to be
part of making it happen. So do that foot work (get
someone to edit the enhancements) before submitting.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Dec 2004 14:02:45 -0000

Hi Tom,

Thanks for reading!

> agreed to include all MPLS OAM-related requirements in

This is fine, I think.

Do the WG and the authors of draft-ietf-mpls-oam-requirements-05.txt agree
to delay that draft while the OAM requirements for P2MP MPLS-TE are
developed?

[Note to the readers: This is not just MIB modules or new MIB objects.
This is the whole OAM structure.]

It seems to me that you would be happy if the very last sentence was
changed to...
   These requirements are covered in [MPLS-OAM].
No other changes to the text would be needed.

Cheers,
Adrian

---

From: Loa Andersson <[email-masked]>
Date: Tue, 21 Dec 2004 15:46:32 +0100

All,

I'd some off-line discussion with Adrian and Seisho on
how to formulate the first sentence of section 4.9.

Adrian came up with the following suggestion:

"Various parameters (such as priority and bandwidth) are associated
with an LSP.
The parameters are installed by the signaling exchanges associated
with establishing and maintaining the LSP."

I had a comment on that the alliteration of various, variant,
variance and variation, made this kind of hard to read and
would suggest a change to:

"Certain parameters (such as priority and bandwidth) are associated
with an LSP.
The parameters are installed by the signaling exchanges associated
with establishing and maintaining the LSP."

/Loa

Seisho Yasukawa wrote:

> Hi MPLS List,
> 
> As promised, this is the first of several emails to resolve the 
> remaining open issues in 
> variations under the control of the ingress LSR. Also, it has been 
> pointed out that make-before-break is commonly used to vary these 
> parameters.
> 
> We would like to propose to clarify this by changing section 4.9 to read 
> as follows.
> 
> If you have comments opposed to this text it would be helpful if you 
> could supply realistic functional requirements that explain how you 
> might deploy anything different.
> 
> Thanks,
> Seisho
> 

-- 
Loa Andersson

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 21 Dec 2004 11:12:51 -0500

> MIB will be / has been enhanced to provide P2MP TE LSP

	This sounds like a reasonable approach as long as the
remaining text in the section is removed (as it doesn't seem
to belong, nor does it fit with your recommendation).

> someone to edit the enhancements) before submitting.

	I have long committed to doing this sort of stuff. *)

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 21 Dec 2004 11:14:14 -0500

> to delay that draft while the OAM requirements for P2MP MPLS-TE are

	Personally, no, so I suggest that the P2MP Reqs co-authors (and
WG folks) please review the OAM requirements draft ASAP to ensure
that it is not missing anything p2mp-related. *)

> No other changes to the text would be needed.

	Yes.

	--Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Dec 2004 17:08:19 -0000

Tom,

> > Do the WG and the authors of draft-ietf-mpls-oam-requirements-05.txt
> > agree to delay that draft while the OAM requirements for P2MP
> > MPLS-TE are developed?
>

Well, I think this is why I would prefer that the P2MP OAM requirements
went in a separate draft. That way we do no hold up the base MPLS OAM
requirements draft and we don't make any premature decisions on P2MP OAM.

But, in another email you commit to doing the work to making sure that
P2MP OAM requirements are covered, so perhaps you'd like to propose some
text for discussion.

> > No other changes to the text would be needed.

This seems to contradict your other email as well since there you support
Loa's recommendation

> > MIB will be / has been enhanced to provide P2MP TE LSP

and you say

> to belong, nor does it fit with your recommendation).

Can you point up what your objections to the text are. For reference, here
is the text...

4.18 P2MP MPLS OAM

Cheers,
Adrian

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 21 Dec 2004 16:24:47 -0500

> P2MP OAM requirements are covered, so perhaps you'd like to propose 

	I personally have none nor have I received any to-date,
which is why they didn't go into the MPLS OAM draft. *)
In any event, why is it unreasonable to request that these be given
by the editors of the MPLS OAM Requirements draft in the near
future?  I can't speak for Dave, but I personally
am willing to wait a couple of weeks to a month
to add these so that the draft is complete.  Can we agree
that if we don't get any say by January 15, then there
will be none?

> Can you point up what your objections to the text are. For reference, 
> here is the text...
>
> 4.18 P2MP MPLS OAM
>

	I don't see why the second or third sentences need to be a MUST,
especially since they have no corresponding justification.

>    document will cover these requirements.

	This sentence seems to indicate that precise OAM requirements
are out of the scope of this document -- so why then do the preceding
two sentences provide requirements for OAM for p2mp TE LSPs?! Based
on this, the preceding two sentences should be removed from this
document and put into a place where there are in the scope of the
document (i.e.: MPLS OAM Requirements). :P

	--tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Dec 2004 21:52:08 -0000

Tom,

Maybe I have flu and I'm not thinking straight.

> > P2MP OAM requirements are covered, so perhaps you'd like to propose
> > some text for discussion.
>

That's daft.

The fact that no-one supplies any OAM requirements for P2MP before January
15 doesn't mean there aren't any. It means that no-one has supplied them.

If the P2MP Sig Req draft is to refer to the MPLS OAM draft (as you
desire) then it must clearly be done only because the MPLS OAM draft
contains an adequate statement of the requirements. The choice is:
a. Do everything necessary to ensure that the MPLS OAM draft includes the
    P2MP OAM requirements
b. Put the P2MP OAM requirements in a separate draft.

> especially since they have no corresponding justification.

So, if we supply a justification we're in the clear?
The justification for the former is simple - the routing area requires
that MIB modules are prepared for all signaling protocols and extensions.
The second point is also simple; for how can you manage something if you
cannot identify it uniquely?

Nevertheless, these paragraphs could happily be subsumed into another
document describing the requirements for P2MP OAM.

> document (i.e.: MPLS OAM Requirements). :P

So put them in the MPLS OAM Requirements and then Seisho can remove them
from here.

A

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 21 Dec 2004 17:07:52 -0500

> 15 doesn't mean there aren't any. It means that no-one has supplied 

	Well, you have to draw a line in the sand at some time,
don't you?

> So put them in the MPLS OAM Requirements and then Seisho can remove 

	I am okay with that as long as we don't delay the OAM
requirements draft any longer than is necessary to capture
the p2mp requirements.

	--Tom