Subject: [mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a mpls wg document

From: Loa Andersson <[email-masked]>
Date: Tue, 04 Sep 2012 08:16:23 +0200

Working group,

this is to start a two week poll on adopting
draft-jjwl-mpls-mldp-hsmp-01.txt
as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]).

This poll is extended and will end Sep 19th, 2012.

/Loa
(mpls wg co-chair)
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 4 Sep 2012 09:30:29 +0200

Dear WG,

Being a co-author I obviously support this draft.

My reasons for supporting this draft;

A HSMP LSP provides an upstream path to the root, associated with a specific downstream path, without the need for additional overlay procedures. This is good for applications that require co-routed up and downstream paths. There has been some discussion whether or not the use-cases in this draft are strong enough, IMO this is a good toolkit to have in the mLDP box and I'm sure other use-cases will follow later. 

Thx,

Ice.

On 04 Sep 2012, at 08:16, Loa Andersson <[email-masked]> wrote:

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

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 10 Sep 2012 05:43:34 +0530

I support the draft.

Cheers, Manav

---

From: Jounay Frédéric <[email-masked]>
Date: Mon, 10 Sep 2012 09:02:57 +0200

Hi,
Support (as co-author)

Fred

On Tue, Sep 4, 2012 at 11:46 AM, Loa Andersson <[email-masked]> wrote:
> draft-jjwl-mpls-mldp-hsmp-01.txt as an MPLS working group document.
>

---

From: Ryan Zheng<[email-masked]>
Date: Tue, 11 Sep 2012 14:23:11 +0800

Yes/Support.

A very useful draft for several existing scenarios and even more in 
future.

Thanks,
Ryan

Loa Andersson <[email-masked]> 
Sent by: [email-masked]
2012-09-04 14:16

To
"[email-masked]" <[email-masked]>
cc
[email-masked], "[email-masked]" 
<[email-masked]>
Subject
[mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a mpls wg document

Working group,

/Loa
(mpls wg co-chair)
--

---

From: venkatesan mahalingam <[email-masked]>
Date: Tue, 11 Sep 2012 01:32:10 -0700

Yes/Support.

Thanks,
Venkat.

On Mon, Sep 3, 2012 at 11:16 PM, Loa Andersson <[email-masked]> wrote:

> draft-jjwl-mpls-mldp-hsmp-01.**txt
> ______________________________**_________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Raymond Key <[email-masked]>
Date: Wed, 12 Sep 2012 00:09:12 +1030

Support > Date: Tue, 4 Sep 2012 08:16:23 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: [mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a mpls wg	document
> 
> Working group,
>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 11 Sep 2012 10:50:57 -0400

Yes/support
On Mon, Sep 3, 2012 at 11:16 PM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Working group,

Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]<mailto:[email-masked]>).

/Loa
(mpls wg co-chair)
--

Loa Andersson                         email: [email-masked]<mailto:[email-masked]>
Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
Ericsson Inc                          phone: +46 10 717 52 13<tel:%2B46%2010%20717%2052%2013>
                                             +46 767 72 92 13<tel:%2B46%20767%2072%2092%2013>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 11 Sep 2012 15:56:03 -0400

Support, as this looks like useful functionality for the toolkit.

Cheers,
Andy

---

From: [email-masked]
Date: Wed, 12 Sep 2012 08:04:50 +0800

Support

Fei

Loa Andersson <[email-masked]> 
发件人:  [email-masked]
2012-09-04 14:16

收件人
抄送
主题

Working group,

/Loa
(mpls wg co-chair)
--

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 13 Sep 2012 02:00:20 +0530

Dear Authors,

               I apologize if some of this had been already discussed before. I
have couple of questions on this draft and I am looking for some clarifications

on the some aspects.

On procedures described in section below:
"4.3.1.2<http://tools.ietf.org/html/draft-jjwl-mpls-mldp-hsmp-01#section-4.3.1.2>.  HSMP LSP transit node operation

   Suppose node Z receives a HSMP-D Label Map <X, Y, L> from LSR D, the

   procedure is same as processing MP2MP-D Label Mapping message defined

   in [RFC6388] section 4.3.1.5<http://tools.ietf.org/html/rfc6388#section-4.3.1.5>, and the processing protocol entity is

   HSMP-D label mapping message.  The different procedure is specified

   below.

   Node Z checks if upstream LSR U already assigned a label Lu to

   upstream <X, Y>.  If not, transit node Z waits until it receives a

   HSMP-U Label Map <X, Y, Lu> from LSR U. Once the HSMP-U Label Map is

   received from LSR U, node Z checks whether it already has forwarding

   state upstream <X, Y> with incoming label Lu' and outgoing label Lu.

   If it does, Z sends a HSMP-U Label Map <X, Y, Lu'> to downstream

   node.  If it does not, it allocates a label Lu' and creates a new

   label swap for Lu' with Label Lu over interface Iu.  Interface Iu is

   determined via the procedures in Section 4.3.1<http://tools.ietf.org/html/draft-jjwl-mpls-mldp-hsmp-01#section-4.3.1>.  Node Z determines

   the downstream HSMP LSR as per Section 4.3.1<http://tools.ietf.org/html/draft-jjwl-mpls-mldp-hsmp-01#section-4.3.1>, and sends a HSMP-U

   Label Map <X, Y, Lu'> to node D."

                          U

                          |

                          Z

                        /  \

                       D    D'

   "Node Z checks if upstream LSR U already assigned a label Lu to

    upstream <X, Y>."

Let's assume that at time T1, U hasn't assigned upstream label Lu to Z yet.  There

are two possible cases at time T1 -

D is the first mLdp join seen by node Z for <X,Y>

OR,

Z has already seen another D' earlier but waiting for response from U on Lu and

D is the join that is merging now.

In that case what should be the forwarding state at Z for HSMP_DN? Essentially Z has one

or more downstream HSMP-D label L and advertised HSMP-D label to U. Should the downstream

state for HSMP-D be not installed since we must have Lu in order to make the HSMP X-connect
logically complete + distribute label Lu' to D(s)? I would think it is important to precisely

describe the expected behaviour - means whether the HSMP_DN forwarding state and HSMP_UP

forwarding state programming are disjoint or bounded (one can't live without another)?

This is important further on the question on section 4.3.2 down below.

Now let's say Z receives upstream label from U - the Lu, at a time T2 > T1.

   "Once the HSMP-U Label Map is received from LSR U, node Z checks whether it already has

   Forwarding state upstream <X, Y> with incoming label Lu' and outgoing label Lu."

I am little confused in the text above on the procedure at Z on receipt of

Label mapping Lu from U. How is it possible that Z already has a forwarding

state Lu'->SWAP->Lu before receipt of Lu from U? Lu' can map to only one

outgoing label Lu, correct (since HSMP UP is unicast)? Or are we considering

the case of receipt of a duplicate label mapping from an upstream?

Further in next clause:

   "If it does, Z sends a HSMP-U Label Map <X, Y, Lu'> to downstream

   node.  If it does not, it allocates a label Lu' and creates a new

   label swap for Lu' with Label Lu over interface Iu."

So if a forwarding state Lu'->SWAP->Lu "already" exists in Z then Z distributes

label Lu'. But how is it possible that Lu'->SWAP->Lu already exists before Lu'

is distributed by Z to D?

The last paragraph in section 4.3.2.1 mentions that "same label (representing the

upstream path) can be distributed to all downstream nodes" - I look it at the same

way how ldp prefix tunnels are set-up in data path - MP2P. Thus it is possible that

Forwarding state Lu'->Lu already exists when Z received HSMP-D mapping from D, in

case of same HSMP-U label is distributed to all D.

I would suggest to discuss the last paragraph of section 4.3.2.1 prior to discuss

the detailed procedures in order to present a logical flow.

I am wondering whether following should be a MUST instead on "can".

   "Since a packet from any downstream node is forwarded only to the

   upstream node, the same label (representing the upstream path) can be

   distributed to all downstream nodes."

Because section 4.3 mentions as below on HSMP_UP label allocation from platform wide

space. It's a significant waste of label space if distinct label is distributed per

peer, unless there is a strong use case if any but such case is not evident from

the draft.

   "HSMP-U Label Map <X, Y, Lu>: A Label Map message with a single

   HSMP upstream FEC Element <X, Y> and label TLV with label Lu.  Label

   Lu MUST be allocated from the per-platform label space of the LSR

   sending the Label Map Message."

Section 3.2 mentions the goal to reduce operational cost by reducing labels/forwarding state.

   "In that case, the operational cost will be reduced for maintaining only one HSMP LSP, instead of

   P2MP LSP and n (number of leaf nodes) P2P reverse LSPs."

On following section:

"4.3.2<http://tools.ietf.org/html/draft-jjwl-mpls-mldp-hsmp-01#section-4.3.2>.  HSMP LSP Label Withdraw

   The HSMP Label Withdraw procedure is much same as MP2MP leaf

   operation defined in [RFC6388] section 4.3.2<http://tools.ietf.org/html/rfc6388#section-4.3.2>, and the processing

   protocol entities are HSMP FECs.  The only difference is process of

   HSMP-U label release message, which is specified below.

   When a transit node Z receives a HSMP-U label release message from

   downstream node D, Z should check if there are any incoming interface

   in forwarding state upstream <X, Y>.  If all downstream nodes are

   released and there is no incoming interface, Z should delete the

   forwarding state upstream <X, Y> and send HSMP-U label release

   message to its upstream node."

Let's say that node Z receives an unsolicited release for Lu' from downstream node D

in the context of HSMP_UP, then what should be the action on forwarding/control state

for HSMP_DN path? Does the HSMP_DN path continue to exist towards downstream D (means

leave the HSMP_UP broken from D->Z and HSMP_DN working from Z->D)? Perhaps it would be

good to clarify the resultant state since utility of HSMP LSP is based on presence of

both UP and DOWN state.

In the same way what happens if Z receives an unsolicited release of HSMP_DN label from

U? Should the HSMP_UP state continue at Z? I understand that by theory such things are

not defined by any spec but in real life situations a Z may face all possibilities of

messaging from its peers that may impact control and forwarding state.

The following section mentions about benefits offered by P2MP LSP Ping w.r.t Multi-Point

OAM, which is good from multiple perspectives. But I don't see the required toolkit to

implement OAM for HSMP LSP.

"3. Applications

   In some cases, the P2MP LSP may not have a reply path for the OAM

   message (e.g, LSP Ping).  If P2MP LSP is provided by HSMP LSP, then

   the upstream path could be exactly used as the OAM message reply

   path.  This is especially useful in the case of P2MP LSP fault

   detection, performance measurement, root node redundancy and etc.

   There are several other applications that could take advantage of

   such kind of LDP based HSMP LSP as described below."

I could find that section 3.1.2 in RFC 6425 defines following two FEC elements.

        Sub-Type #       Length              Value Field

        ----------       ------              -----------

              19       Variable            Multicast P2MP LDP FEC Stack

              20       Variable            Multicast MP2MP LDP FEC Stack

I am not able to see how to fit HSMP into one of RFC 6425 defined types.

IMO, HSMP requires a new sub-type since HSMP defines new FEC elements as

below:

"4.2. HSMP FEC Elements

   Similar as MP2MP LSP, we define two new protocol entities, the HSMP

   downstream FEC and upstream FEC Element.  If a FEC TLV contains an

   HSMP FEC Element, the HSMP FEC Element MUST be the only FEC Element

   in the FEC TLV.  The structure, encoding and error handling for the

   HSMP downstream and upstream FEC Elements are the same as for the

   MP2MP FEC Element described in [RFC6388] Section 4.2.  The difference

   is that two additional new FEC types are used: HSMP downstream type

   (TBD, IANA) and HSMP upstream type (TBD, IANA)."

I would think in order to develop and deploy a solution like HSMP, OAM

tools need to be precisely defined.

Thanks,

Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, September 03, 2012 11:16 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a mpls wg document

Working group,

/Loa

(mpls wg co-chair)

--

                                              +46 767 72 92 13

mpls mailing list

[email-masked]

---

From: <[email-masked]>
Date: Mon, 17 Sep 2012 13:29:24 +0000

Hi Ice,

I don't disagree that it can make sense to have such a protocol with the 
idea of augmenting the MPLS toolbox.
However after two years the proposal has been made, I'm surprised the 
use cases aren't stronger.
Should the IETF publish a standard track RFC each time something looks 
like potentially useful in the future ?

Anyways, if the document is going to document use cases, they should be 
more detailed. The recent revision has not improved a lot in this 
respect: the "Time synchronisation" and "IPTV" use cases are still not 
explaining why a co-routed return path is required or beneficial, and 
the "IPTV" use case is still lacking details about redundancy (it's 
clear to me how you have fail-over between IGMP Querier/PIM DF on a LAN, 
but it is not obvious to me how "node redundancy for IGMP querier could 
be provided by two independent VPMS instances with HSMP applied").

By and large, I'm not able to assert that the proposed extension won't 
have a use, but I find it hard to support adoption without stronger use 
cases.

-Thomas

>> This poll is extended and will end Sep 19th, 2012.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 17 Sep 2012 15:56:14 +0200

Support.

  Regards

    Nic

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Loa Andersson
Gesendet: Dienstag, 4. September 2012 08:16
An: [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: [mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a mpls wg document

Working group,

/Loa
(mpls wg co-chair)
--

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 18 Sep 2012 05:21:03 +0530

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 17, 2012 6:29 AM
To: [email-masked]
Subject: Re: [mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a mpls wg document

Hi Ice,

-Thomas

---

From: Yuji Kamite <[email-masked]>
Date: Wed, 19 Sep 2012 10:24:49 +0000

Support.

Regards,
Yuji

> Sent: Tuesday, September 04, 2012 3:16 PM
> To: [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Thu, 20 Sep 2012 15:21:50 +0200

Working group,

this poll has ended. We have a new working group document!

Can the authors please publish a new version of the document:

draft-ietf-mpls-mldp-hsmp-00.txt

without any other changes than date, file name and version number.

Please address the comments we received during the poll, e.g. on
use cases, for version -01.

We'd also like to remind the authors that as a WG document any
substantive document changes need to be based on WG discussion
and/or confirmed by the WG.

/Loa

--