some comments on I-D Action:draft-takacs-ccamp-revertive-ps-00.txt

Attila,

I have planned respond to this for same time, but did not really
had time to get around to it.

Attila Takacs wrote:
> Hi Loa,
> 
> I assume a part of your comment/question relates to problems with
> reversion if LSP setup and holding priorities are mismatched.

that would be one case, but not really what i was thinking of

> In this
> case the worker may be already deleted before the reversion would take
> place. This is certainly an interesting question...

sure
> 
> ...at a first thought an explicit revertive bit may be used to override
> the priorities for LSPs with revertive protection.

I've two questions:

1. If revertiveness is the normal procedure, wouldn't it be better to
    let indicate LSPs that *shouldn't* revert?

2. What I really thought about was, how does revertiveness work with
traffic placement policies?

Re: MPLS over OTN

Hi Howard,

[adding MPLS-TP mailing list]

Accurate representation of our conversation.
That is, in GMPLS we have label type, switching type, encoding type, and 
G-PID.
G-PID identifies the payload and re-uses the Ethertype codepoints. Thus we 
can carry MPLS.
If GFP is used for framing, it must also identify the payload and, as you 
point out, GFP has an MPLS codepoint.

That the GFP codepoint for MPLS is the same as that for "T-MPLS" is good for 
Option 1 (which is where we are) since there is no practical difference 
between MPLS and MPLS-TP.

Now, the operation of MPLS over OTN that you describe is actually the 
operation of an OTN. So the issues of control channels in OTN are exactly as 
you describe, but have nothing to do with the payload protocol. This is 
simply GMPLS control of OTN. Period.

GMPLS control of MPLS-TP is a different kettle of ball games. Here the 
switching type is PSC: the same switching type as for MPLS. A feature of 
GMPLS is that there is *logical* separation of control plane and data plane. 
This means that the control plane can be in-band (MPLS-TE), out-of-band but 
in-fibre (SONET/SDH or OSC), or out-of-fibre.

MPLS-TP requirements say that it must be possible to operate the network "in 
the absence of IP." I have taken this to mean "in the absence of IP routing 
and forwarding" (but this is my opinion and there is no explicit evidence in 

Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

RE: MPLS over OTN

Adrian
Thanks (for the homily as well!)
My apologies for some lack of clarity.
As you say, GMPLS control of OTN is what it is. The use of a G-PID
describing an MPLS payload does, presumably, allow an OTN path to be
advertised (with suitable policy constraints) as an MPLS forwarding
adjacency. In the MPLS layer above this OTN, it is not so obvious how to
carry IP "in band", and therefore the GMPLS mechanics seem to be
required. As you say, the control plane could be "OOB but in fiber" (or
here, in OTN path) or out of fibre. Thus there would seem to be utility
in an optional associated channel mechanism for the control plane. I
wonder whether there may be a requirement of the reverse kind (maximum
diversity between data plane and control plane) in some circumstances.
/Howard

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian <at> olddog.co.uk] 
> Sent: 01 August 2008 10:53
> To: Howard Green; ccamp <at> ops.ietf.org
> Cc: mpls-tp <at> ietf.org
> Subject: Re: MPLS over OTN
> 
> Hi Howard,
> 
> [adding MPLS-TP mailing list]
> 
> Accurate representation of our conversation.
> That is, in GMPLS we have label type, switching type, 
> encoding type, and G-PID.
> G-PID identifies the payload and re-uses the Ethertype 
> codepoints. Thus we can carry MPLS.
> If GFP is used for framing, it must also identify the payload 
> and, as you point out, GFP has an MPLS codepoint.
> 
> That the GFP codepoint for MPLS is the same as that for 
> "T-MPLS" is good for Option 1 (which is where we are) since 
> there is no practical difference between MPLS and MPLS-TP.
> 
> Now, the operation of MPLS over OTN that you describe is 
> actually the operation of an OTN. So the issues of control 
> channels in OTN are exactly as you describe, but have nothing 
> to do with the payload protocol. This is simply GMPLS control 
> of OTN. Period.
> 
> GMPLS control of MPLS-TP is a different kettle of ball games. 
> Here the switching type is PSC: the same switching type as 
> for MPLS. A feature of GMPLS is that there is *logical* 
> separation of control plane and data plane. 
> This means that the control plane can be in-band (MPLS-TE), 
> out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre.
> 
> MPLS-TP requirements say that it must be possible to operate 
> the network "in the absence of IP." I have taken this to mean 
> "in the absence of IP routing and forwarding" (but this is my 
> opinion and there is no explicit evidence in the requirements 
> I-D). With this view...
> - We can use IP identifiers (addresses) in the data plane and 
> the control plane
> - We can use IP-based control protocols (GMPLS)
> - We can use an IP-based control network if available, but we cannot
>    mandate it
> - Control entities that need to communicate must be allowed to be
>    IP-adjacent so that there is no requirement for 
> IP-forwarding in the
>    network
> 
> I believe we can do all of the above, and often do in GMPLS networks.
> The crunch questions are:
> 1. What is the physical technology for the data links in the 
> control plane?
> 2. How do we identify control plane traffic when it arrives at a node?
> 3. How do we exchange control plane messages between nodes that
>    do not have a common data link in the control plane?
> 
> Answers are:
> 1. We don't care 
>     But a possible answer in MPLS-TP is an LSP (e.g. a 
> reserved label) 2. From the data link (since there is no need 
> to disambiguate the control
>    plane traffic from any other traffic on the data link) 3. 
> This is a more tricky question. However nearly all of the messages
>    are exchanged only between data-plane-adjacent nodes. This can be
>    the case in the IGP-TE protocols, and is true for all messages in
>    RSVP-TE with a couple of exceptions (below). It is also 
> the case for
>    LMP. So IP forwarding is not required in the control plane.
>    The tricky cases are:
>    - echo response in LSP Ping (we are rebuilding the OAM)
>    - Notify message in RSVP-TE (we are considering OAM approaches
>      for the uses of Notify where IP forwarding is not available)
>    - "Targeted Path messages" used in hierarchical LSPs (and LSP
>       stitching). In these cases we are effectively building a virtual
>       data plane adjacency and should build a parallel virtual control
>       plane link between the end points (e.g. an LSP).
> 
> We should note that the output of the JWT *appears* to be 
> that "GMPLS meets the requirements of a control plane for MPLS-TP."
> 
> We should also note that management plane operation of 
> MPLS-TP is a requirement, and we must assume that management 
> plane messages may need to be exchanged between management 
> stations and network nodes using some protocol and connectivity.
> 
> </homily>
> 
> Adrian
> ----- Original Message -----
> From: "Howard Green" <howard.green <at> ericsson.com>
> To: <ccamp <at> ops.ietf.org>
> Sent: Thursday, July 31, 2008 5:55 PM
> Subject: MPLS over OTN
> 
> 
> Just to record for the list a chat with Adrian and Lou Berger. I
> discover from reading G.7041 Amendment 2 that there is a codepoint
> defined to allow unicast MPLS frames to be carried over OTN (ODUx)
> channels by way of GFP encoding. Reading RFC 4328, there is 
> an encoding
> type for ODUx, and the switching type is TDM. There is no 
> specific G-PID
> value defined for the MPLS codepoint (which was probably defined
> concurrently with the writing of RFC 4328). Adrian and Lou 
> took the view
> that in this situation, the use of the unicast MPLS ethertype (#8847)
> would define for signalling this bearer type (as described in 
> RFC 3471).
> 
> This is relevant partly because G.7041 amendment 2 defines 
> the codepoint
> to be for "MPLS or T-MPLS". I assume that this usage carries over to
> MPLS-TP. In this situation,interestingly, there is no 
> prospect of inband
> IP control, and so GMPLS is the only control plane option.
> Is this correct?
> Regards Howard
> 
> 
> 
> 

Re: MPLS over OTN

Hi again Howard,

So, to pick apart the control plane in an MPLS network ( I think I am 
agreeing with you fully)...

In band
This could only happen using the sort of mechanisms being proposed for ACH.
That is, each control plane message is packaged as an MPLS packet and 
labelled as for the LSP that it is controlling. The TTL is set to one (or 
more to allow non-adjacent signalling). A secondary label on the stack might 
be used to identify the control plane when the top-level label expires. We 
already have the Router Alert label defined.
However, such a mechanism would only work for existing LSPs meaning that we 
could never set up new ones!

Out of band in fibre
(Bear in mind that the nature of MPLS means that this is very similar to in 
band except within the switching fabric)
To make this work we simply need a reserved label to identify control plane 
traffic. The Router Alert label already provides this.
However, we lack a mechanism for non-adjacent signalling. There are two use 
cases in GMPLS...
1. Hierarchical and stitched LSPs
  In this case, we can use the hierarchical or stitched LSP to carry
  the control traffic. For hierarchical, it is simple since we can put the
  Router Alert label second on the stack where it will be discovered
  when the top label is popped. For stitching, we must also set the
  TTL to expire at the end of the stitching segment.
2. Notify messages
  These messages may be exchanged between non-adjacent nodes.
  Normally they rely on IP routing, but there is an option to get them
  forwarded hop-by-hop by the control planes of the nodes along the
  LSP - this is NOT IP-based forwarding, but relies on each node on
  the path of an LSP knowing the next control plane node in each
  direction (something that is required by RSVP-TE anyway).
  An alternative is to use the LSP that is being notified, and to set the
  TTL as necessary also using a Router Alert label just as for stitching.
A further alternative (sufficient but not necessary) approach would be to 
set up a mesh of LSPs to support the control plane.

Out of band out of fibre
I am inclined to agree that there may often be good reasons to operate this 
way.
Using an IP network as a DCN makes a lot of sense and it should be noted 
that this does not require that the NEs have IP forwarding capabilities.

Cheers,
Adrian

----- Original Message ----- 
From: "Howard Green" <howard.green <at> ericsson.com>
To: "Adrian Farrel" <adrian <at> olddog.co.uk>; <ccamp <at> ops.ietf.org>
Cc: <mpls-tp <at> ietf.org>
Sent: Monday, August 04, 2008 9:23 AM
Subject: RE: MPLS over OTN

Adrian
Thanks (for the homily as well!)
My apologies for some lack of clarity.
As you say, GMPLS control of OTN is what it is. The use of a G-PID
describing an MPLS payload does, presumably, allow an OTN path to be
advertised (with suitable policy constraints) as an MPLS forwarding
adjacency. In the MPLS layer above this OTN, it is not so obvious how to
carry IP "in band", and therefore the GMPLS mechanics seem to be
required. As you say, the control plane could be "OOB but in fiber" (or
here, in OTN path) or out of fibre. Thus there would seem to be utility
in an optional associated channel mechanism for the control plane. I
wonder whether there may be a requirement of the reverse kind (maximum
diversity between data plane and control plane) in some circumstances.
/Howard

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian <at> olddog.co.uk]
> Sent: 01 August 2008 10:53
> To: Howard Green; ccamp <at> ops.ietf.org
> Cc: mpls-tp <at> ietf.org
> Subject: Re: MPLS over OTN
>
> Hi Howard,
>
> [adding MPLS-TP mailing list]
>
> Accurate representation of our conversation.
> That is, in GMPLS we have label type, switching type,
> encoding type, and G-PID.
> G-PID identifies the payload and re-uses the Ethertype
> codepoints. Thus we can carry MPLS.
> If GFP is used for framing, it must also identify the payload
> and, as you point out, GFP has an MPLS codepoint.
>
> That the GFP codepoint for MPLS is the same as that for
> "T-MPLS" is good for Option 1 (which is where we are) since
> there is no practical difference between MPLS and MPLS-TP.
>
> Now, the operation of MPLS over OTN that you describe is
> actually the operation of an OTN. So the issues of control
> channels in OTN are exactly as you describe, but have nothing
> to do with the payload protocol. This is simply GMPLS control
> of OTN. Period.
>
> GMPLS control of MPLS-TP is a different kettle of ball games.
> Here the switching type is PSC: the same switching type as
> for MPLS. A feature of GMPLS is that there is *logical*
> separation of control plane and data plane.
> This means that the control plane can be in-band (MPLS-TE),
> out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre.
>
> MPLS-TP requirements say that it must be possible to operate
> the network "in the absence of IP." I have taken this to mean
> "in the absence of IP routing and forwarding" (but this is my
> opinion and there is no explicit evidence in the requirements
> I-D). With this view...
> - We can use IP identifiers (addresses) in the data plane and
> the control plane
> - We can use IP-based control protocols (GMPLS)
> - We can use an IP-based control network if available, but we cannot
>    mandate it
> - Control entities that need to communicate must be allowed to be
>    IP-adjacent so that there is no requirement for
> IP-forwarding in the
>    network
>
> I believe we can do all of the above, and often do in GMPLS networks.
> The crunch questions are:
> 1. What is the physical technology for the data links in the
> control plane?
> 2. How do we identify control plane traffic when it arrives at a node?
> 3. How do we exchange control plane messages between nodes that
>    do not have a common data link in the control plane?
>
> Answers are:
> 1. We don't care 
>     But a possible answer in MPLS-TP is an LSP (e.g. a
> reserved label) 2. From the data link (since there is no need
> to disambiguate the control
>    plane traffic from any other traffic on the data link) 3.
> This is a more tricky question. However nearly all of the messages
>    are exchanged only between data-plane-adjacent nodes. This can be
>    the case in the IGP-TE protocols, and is true for all messages in
>    RSVP-TE with a couple of exceptions (below). It is also
> the case for
>    LMP. So IP forwarding is not required in the control plane.
>    The tricky cases are:
>    - echo response in LSP Ping (we are rebuilding the OAM)
>    - Notify message in RSVP-TE (we are considering OAM approaches
>      for the uses of Notify where IP forwarding is not available)
>    - "Targeted Path messages" used in hierarchical LSPs (and LSP
>       stitching). In these cases we are effectively building a virtual
>       data plane adjacency and should build a parallel virtual control
>       plane link between the end points (e.g. an LSP).
>
> We should note that the output of the JWT *appears* to be
> that "GMPLS meets the requirements of a control plane for MPLS-TP."
>
> We should also note that management plane operation of
> MPLS-TP is a requirement, and we must assume that management
> plane messages may need to be exchanged between management
> stations and network nodes using some protocol and connectivity.
>
> </homily>
>
> Adrian
> ----- Original Message -----
> From: "Howard Green" <howard.green <at> ericsson.com>
> To: <ccamp <at> ops.ietf.org>
> Sent: Thursday, July 31, 2008 5:55 PM
> Subject: MPLS over OTN
>
>
> Just to record for the list a chat with Adrian and Lou Berger. I
> discover from reading G.7041 Amendment 2 that there is a codepoint
> defined to allow unicast MPLS frames to be carried over OTN (ODUx)
> channels by way of GFP encoding. Reading RFC 4328, there is
> an encoding
> type for ODUx, and the switching type is TDM. There is no
> specific G-PID
> value defined for the MPLS codepoint (which was probably defined
> concurrently with the writing of RFC 4328). Adrian and Lou
> took the view
> that in this situation, the use of the unicast MPLS ethertype (#8847)
> would define for signalling this bearer type (as described in
> RFC 3471).
>
> This is relevant partly because G.7041 amendment 2 defines
> the codepoint
> to be for "MPLS or T-MPLS". I assume that this usage carries over to
> MPLS-TP. In this situation,interestingly, there is no
> prospect of inband
> IP control, and so GMPLS is the only control plane option.
> Is this correct?
> Regards Howard
>
>
>
>

RE: [mpls-tp] MPLS over OTN

Hi,
   I think that the Maarten interpretation is correct.

BR

Diego

> -----Original Message-----
> From: mpls-tp-bounces <at> ietf.org [mailto:mpls-tp-bounces <at> ietf.org] On Behalf
> Of Maarten Vissers
> Sent: lunedì 4 agosto 2008 16.28
> To: 'Francesco Fondelli'
> Cc: ccamp <at> ops.ietf.org; mpls-tp <at> ietf.org
> Subject: Re: [mpls-tp] MPLS over OTN
> 
> Francesco,
> 
> This requirement defines that the MPLS-TP data (transport) plane operates
> in
> the absence of an IP data (transport) plane. This requirement does not say
> anything about the DCN, and the technologies deployed in this DCN.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: Francesco Fondelli [mailto:francesco.fondelli <at> gmail.com]
> Sent: 04 August 2008 15:00
> To: Maarten Vissers
> Cc: Adrian Farrel; Howard Green; ccamp <at> ops.ietf.org; mpls-tp <at> ietf.org
> Subject: Re: [mpls-tp] MPLS over OTN
> 
> On Mon, Aug 4, 2008 at 2:50 PM, Maarten Vissers
> <maarten.vissers <at> huawei.com>
> wrote:
> > Adrian, Howard,
> >
> > The transport network has a DCN, and this DCN inlcudes today a mix of
> > OSI and IP technologies.
> 
> Hi,
> 
> --- draft-jenkins-mpls-mpls-tp-requirements-00
> 
>    o  It MUST be possible to operate and configure the MPLS-TP data
>       (transport) plane without any IP functionality.
> 
> ---
> 
> So what do you think about this requirement?
> 
> Ciao
> FF
> 
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp

RE: [mpls-tp] MPLS over OTN

Opsss you are right!

I've missed the term configure! I was focused on the fact that an MPLS-TP equipment doesn't need to be able to
perform IP forwarding at the data plane.

BR

Diego

> -----Original Message-----
> From: mpls-tp-bounces <at> ietf.org [mailto:mpls-tp-bounces <at> ietf.org] On Behalf
> Of Francesco Fondelli
> Sent: lunedì 4 agosto 2008 17.32
> To: Maarten Vissers
> Cc: ccamp <at> ops.ietf.org; mpls-tp <at> ietf.org
> Subject: Re: [mpls-tp] MPLS over OTN
> 
> On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers
> <maarten.vissers <at> huawei.com> wrote:
> > Francesco,
> 
> Hi Maarten,
> 
> > This requirement defines that the MPLS-TP data (transport) plane
> operates in
> > the absence of an IP data (transport) plane. This requirement does not
> say
> > anything about the DCN, and the technologies deployed in this DCN.
> 
> I agree with you, but I think that "and configure" should be removed.
> 
> How can you *configure* MPLS-TP data plane without IP (or OSI)?
> Am I the only one that feel uncomfortable with this piece of text?
> 
> > Regards,
> > Maarten
> 
> Ciao
> FF
> _______________________________________________
> mpls-tp mailing list
> mpls-tp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp

RE: [mpls-tp] MPLS over OTN

Hi Francesco.

I guess I understand your concern. I believe the original intention was
to say implicitely "It MUST be possible to operate and configure the
MPLS-TP data (transport) plane without any IP functionality *in the data
plane*." My interpretation of these requirements is indeed that they
apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment,
nor the MPLS-TP control plane...

Anyway you're right, this could be confusing and it deserves a small
rewording.

Regards,

Julien

-----Original Message-----
From: mpls-tp-bounces <at> ietf.org [mailto:mpls-tp-bounces <at> ietf.org] On
Behalf Of Francesco Fondelli

On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers
<maarten.vissers <at> huawei.com> wrote:
> Francesco,

Hi Maarten,

> This requirement defines that the MPLS-TP data (transport) plane
operates in
> the absence of an IP data (transport) plane. This requirement does not
say
> anything about the DCN, and the technologies deployed in this DCN.

I agree with you, but I think that "and configure" should be removed.

How can you *configure* MPLS-TP data plane without IP (or OSI)?
Am I the only one that feel uncomfortable with this piece of text?

> Regards,
> Maarten

Ciao
FF
_______________________________________________
mpls-tp mailing list
mpls-tp <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

Re: [mpls-tp] MPLS over OTN

Hi Francesco,

You replied:

>> This requirement defines that the MPLS-TP data (transport) plane operates in
>> the absence of an IP data (transport) plane. This requirement does not say
>> anything about the DCN, and the technologies deployed in this DCN.
> 
> I agree with you, but I think that "and configure" should be removed.
> 
> How can you *configure* MPLS-TP data plane without IP (or OSI)?
> Am I the only one that feel uncomfortable with this piece of text?

By using the same NMS that is used to configure the OTN node.

Ciao, Huub.

--

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

NomCom-volunteer

Volunteers needed... 

-----Original Message-----
From: wgchairs-bounces <at> ietf.org [mailto:wgchairs-bounces <at> ietf.org] On
Behalf Of NomCom Chair
Sent: Sunday, August 03, 2008 10:43 AM
To: Working Group Chairs
Subject: Please ask your WG... 

To volunteer for the nomcom.
The nomcom process is (in my opinion) better served by a large pool of
volunteers drawn from a wide spectrum of IETF attendees.
As such, please ask on your individual mailing lists for folks to
volunteer.

Obviously, the exact method for doing so is up to you.
The most recent call for volunteers can be reference here:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617
Whether you copy that message, or reference is probably up to you and
the
habits of your working group mailing list.
If you want to reference or copy the status message I sent out, that can
be found at:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618

Thank you,
Joel M. Halpern
Nomcom Chair
jmh <at> joelahlpern.com
nomcom-chair <at> ietf.org