Subject: [Mpls-interop] Proposed text

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 15 Oct 2008 12:00:46 -0700 (PDT)

Here is some proposed text to cover upstream-assigned labels that we
discussed today.

"MPLS-TP MUST support both downstream-assigned and upstream-assigned
MPLS labels. Note that upstream-assigned MPLS labels are always looked up
in a context-specific label space [RFC 5331]. They should not be confused
with the use of the term upstream labels used in signaling bi-directional
P2P LSPs in GMPLS [RFC 3473]."

rahul

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

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 23:28:47 +0200

Hi.

I agree with the requirement, but I'm not really comfortable with seeing
those detailed explanations in the requirement document. In GMPLS,
upstream refers to signaling direction as opposed to data+signaling in
MPLS, and the reader shouldn't be required to be familiar with all that
at this point (currently, no up/down-stream concepts in the doc).
Furthermore, if MPLS-TP control plane is GMPLS, excluding the GMPLS
terminology to write this requirement isn't really satisfying.

What about something like:

"MPLS-TP MUST support both data receiver-assigned and data
sender-assigned MPLS labels. Note that data sender-assigned MPLS labels
are always looked up in a context-specific label space."?

Maybe we can find better terms, but I think it's worth avoiding
mentioning "upstream" which proved to be confusing is this context (data
upstream vs. signaling upstream).

Best regards,

Julien

P.S. : Considering that UNI and E-NNI are answers to high level
requirements put in the framework, shouldn't label assignment follow the
same fate?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rahul Aggarwal

"MPLS-TP MUST support both downstream-assigned and upstream-assigned
MPLS labels. [RFC 5331]. They should not be confused
with the use of the term upstream labels used in signaling
bi-directional
P2P LSPs in GMPLS [RFC 3473]."

rahul

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Oct 2008 17:39:21 -0400

Julien,
         see below.

>terminology to write this requirement isn't really satisfying.

I completely agree with you.

>sender-assigned MPLS labels.

>Note that data sender-assigned MPLS labels

The last sentence isn't accurate when GMPLS bidirectional signaling 
is used.  (Where upstream label space is completely in the control of 
the data receiver.)

>upstream vs. signaling upstream).

Again, I completely agree.  I had proposed stating the requirement 
along the lines of:

"MPLS-TP MUST allow for both context-specific context-independent labels."

Lou

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 15 Oct 2008 14:39:51 -0700

I do not agree with this.  RFC 5331 is *not* part of the base MPLS/GMPLS
technology suite, and this 'requirement' is an attempt to force it into
MPLS TP.

Thanks,

John  

>From: Rahul Aggarwal [mailto:[email-masked]] 
>Sent: Wednesday, October 15, 2008 12:01 PM
>To: Ben Niven-Jenkins
>Cc: 'MEAD team'
>Subject: [Mpls-interop] Proposed text
>
>
>Here is some proposed text to cover upstream-assigned labels 
>that we discussed today.
>
>"MPLS-TP MUST support both downstream-assigned and 
>upstream-assigned MPLS labels. Note that upstream-assigned 
>MPLS labels are always looked up in a context-specific label 
>space [RFC 5331]. They should not be confused with the use of 
>the term upstream labels used in signaling bi-directional P2P 
>LSPs in GMPLS [RFC 3473]."
>
>rahul
>

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 16 Oct 2008 11:26:57 -0700 (PDT)

Hi John,

> technology suite, and this 'requirement' is an attempt to force it into

Would you be ok with making upstream-assigned labels optional for MPLS-TP?

If yes, how about:

""MPLS-TP MUST support downstream-assigned MPLS labels and
MAY support upstream-assigned MPLS labels. Note that upstream-assigned
MPLS labels are always looked up in a context-specific label
space [RFC 5331]. They should not be confused with the use of
the term upstream labels used in signaling bi-directional P2P
LSPs in GMPLS [RFC 3473]."

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 16 Oct 2008 11:28:29 -0700 (PDT)

Hi Julien,

> upstream vs. signaling upstream).

IMO upstream-assigned is a well defined term and as long as we provide a
reference this should be clear and the text I provided disambiguated it
from upstream labels for GMPLS.

rahul

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Oct 2008 14:35:12 -0400

>LSPs in GMPLS [RFC 3473]."

I don't know how not to confuse this as GMPLS does have labels 
assigned by the upstream node.  Can you restate this in terms on 
"context sensitive labels" and avoid the overloaded " upstream-assigned" term?

Lou

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 16 Oct 2008 11:40:26 -0700 (PDT)

Hi Lou,

> "context sensitive labels" and avoid the overloaded " upstream-assigned" term?

How about:

"MPLS-TP MUST support downstream-assigned MPLS labels [RFC3031] and
MAY support context-specific MPLS labels [RFC5331]."

rahul

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Oct 2008 19:49:37 +0100

> MAY support context-specific MPLS labels [RFC5331]."

Sorry to be a pain, but what does "MAY support" mean?

It seems to me that if we want to support LSPs over a multi-access medium 
(or across a P2MP tunnel) we need the "context-specific" labels.

Does "MAY" mean that there is no requirement to support such LSPs?
Or does "MAY" mean that context-specific labels are only supported when the 
function is needed?

I think it is always helpful to push requirements back to the real base 
requirement.

Cheers,
Adrian

PS. I assume that this is only a control plane requirement, since the 
management plane would assign the label itself.

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Oct 2008 12:06:11 -0700

"the label allocation procedures of RFC 3351 MAY optionally be used"? 

>From: Lou Berger [mailto:[email-masked]] 
>Sent: Thursday, October 16, 2008 11:35 AM
>To: Rahul Aggarwal
>Cc: Drake, John E; MEAD team
>Subject: Re: [Mpls-interop] Proposed text
>
>> > I do not agree with this.  RFC 5331 is *not* part of the base 
>> > MPLS/GMPLS technology suite, and this 'requirement' is an 
>attempt to 
>> > force it into MPLS TP.
>> >
>>
>MAY support 
>MPLS labels 
>>are always looked up in a context-specific label space [RFC 
>5331]. They 
>>should not be confused with the use of the term upstream 
>labels used in 
>>signaling bi-directional P2P LSPs in GMPLS [RFC 3473]."
>
>assigned by the upstream node.  Can you restate this in terms 
>on "context sensitive labels" and avoid the overloaded " 
>upstream-assigned" term?
>
>Lou
>
>
>>rahul
>>
>> > Thanks,
>> >
>> > John
>> >
>> > >Here is some proposed text to cover upstream-assigned labels that 
>> > >we discussed today.
>> > >
>> > >upstream-assigned MPLS labels. Note that upstream-assigned MPLS 
>> > >labels are always looked up in a context-specific label 
>space [RFC 
>> > >5331]. They should not be confused with the use of the term 
>> > >upstream labels used in signaling bi-directional P2P LSPs 
>in GMPLS 
>> > >[RFC 3473]."
>> > >
>> > >rahul
>> > >

---

From: <[email-masked]>
Date: Thu, 16 Oct 2008 21:11:57 +0200

Hi Rahul.

In my view, (downstream and) "upstream-assigned is a well defined term"
in the context of MPLS that you are familiar with (which is
unidirectionnal unless you use a GMPLS control plane). Talk to a
transport guy working on GMPLS-controlled Sonet/SDH, you'll see that
"upstream-assigned is a well defined term", but with a different meaning
from yours.
In MPLS-TP, we are considering bidirectional uses, meaning that both
"upstream" and "downstream" terms have different meaning if you refer to
traffic or to signaling (the RSVP-TE upstream is in fact the downstream
node for the backward data plane flow). If we start defining things by
jumping into differences between MPLS and GMPLS, then I predict this is
going to introduce misunderstanding, even if the intention is (rather)
clear for us now, because we have exchanged much more information than
what should be in the requirement draft. Therefore, I suggest to find an
alternative to the word "downstream" (or at least to add something like
"data plane downstream").

Regards,

Julien 

-----Original Message-----

Hi Lou,

> > > I do not agree with this.  RFC 5331 is *not* part of the base
MPLS/GMPLS

How about:

rahul

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Oct 2008 15:15:37 -0400

>MAY support context-specific MPLS labels [RFC5331]."

I think we're close.  I think it makes sense for there to be symmetry 
between the first and second parts of the requirement.  How about:

"MPLS-TP MUST support interface and node scope labels as defined in 
[RFC3031] and
MAY support context-specific MPLS labels [RFC5331]."

Lou

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 16 Oct 2008 12:10:08 -0700 (PDT)

Hi John,

> "the label allocation procedures of RFC 3351 MAY optionally be used"?

I gues you meant RFC 5331? If yes, the above is nice.

rahul

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Oct 2008 13:04:07 -0700

How about:

MPLS-TP MUST support downstream-assigned MPLS labels 
[RFC3031, RFC3473] and MAY support context-specific MPLS labels
[RFC5331]."
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Oct 2008 16:21:57 -0400

>[RFC3031, RFC3473] and MAY support context-specific MPLS labels

MPLS-TP MUST support MPLS labels that are assigned by the downstream 
(with respect to data flow) node per [RFC3031, RFC3473] and MAY 
support context-specific MPLS labels as defined in [RFC5331]."

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Oct 2008 13:23:48 -0700

done 

>Sent: Thursday, October 16, 2008 1:22 PM
>To: Drake, John E
>Cc: Rahul Aggarwal; Lou Berger; MEAD team
>Subject: RE: [Mpls-interop] Proposed text
>
>[RFC3031, RFC3473] 
>>and MAY support context-specific MPLS labels [RFC5331]."
>
>MPLS-TP MUST support MPLS labels that are assigned by the 
>downstream (with respect to data flow) node per [RFC3031, 
>RFC3473] and MAY support context-specific MPLS labels as 
>defined in [RFC5331]."
>
>
>

---

From: <[email-masked]>
Date: Thu, 16 Oct 2008 22:35:00 +0200

It reads clearer to me, but it doesn't address Adrian's comment. P2MP is
a requirement, therefore the MPLS-TP technology MUST support
context-specific labels, implementations MAY...

Julien

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lou Berger

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Oct 2008 13:47:57 -0700

I don't think P2MP requires RFC5331 

>From: [email-masked] 
>[mailto:[email-masked]] 
>Sent: Thursday, October 16, 2008 1:35 PM
>To: [email-masked]
>Cc: [email-masked]
>It reads clearer to me, but it doesn't address Adrian's 
>comment. P2MP is a requirement, therefore the MPLS-TP 
>technology MUST support context-specific labels, implementations MAY...
>
>Julien
>

---

From: "Lou Berger" <[email-masked]>
Date: Fri, 17 Oct 2008 11:51:43 +0000

I'm don't think I've heard anyone say it wouldn't...
-----Original Message-----
From:  Loa Andersson <[email-masked]>

Date: Fri, 17 Oct 2008 13:15:11 
To: Drake, John E<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [Mpls-interop] Proposed text

All,

one question - why won't "RSVP-TE for P2MP TE LSPs" RFC4875 satsify
the MPLS-TP requirements for P2MP?

/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: Loa Andersson <[email-masked]>
Date: Fri, 17 Oct 2008 14:47:03 +0200

if it does why do we need to bother about multicast and
context specific upstream allocated labels at all

/Loa

-- 
Loa Andersson

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 17 Oct 2008 06:06:44 -0700

It will.  RFC 5331 is simply an optimization 

>From: Loa Andersson [mailto:[email-masked]] 
>Sent: Friday, October 17, 2008 4:15 AM
>To: Drake, John E
>Cc: [email-masked]; [email-masked]; 
>[email-masked]
>one question - why won't "RSVP-TE for P2MP TE LSPs" RFC4875 
>satsify the MPLS-TP requirements for P2MP?
>
>/Loa
>
>Drake, John E wrote:
>comment. P2MP 
>>> is a requirement, therefore the MPLS-TP technology MUST support 
>downstream