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

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

Hi Lizhong,
                     Thanks for your clarification. Pls. see my responses inline to your answers.


?      [Lizhong] the forwarding state of HSMP_UP and HSMP_DN are disjoint.
> Their forwarding state programming are triggered by LDP message
> which is same as MP2MP LSP. Your understanding is right, it is the
> say way of MP2P. We will switch the last paragraph of section 4.3.1.
> 2 to the beginning of this section. Thanks.

<Pranjal>

I think it would be good to explicitly mention this other wise it makes the state machine a bit confusing between the boot strap pattern of HSMP
LSP and its death pattern (one part is broken). But my general concern is that - if existing protocol ways can lead to a HSMP LSP that is broken
by half then how does that help to keep the rest of 50% of HSMP functional. My rationale on this is because the HSMP_UP LSP set-up is boot
strapped by receipt of HSMP_DN label mapping. Thus boot strapping state machine for HSMP_UP and HSMP_DN are not disjoint completely.

</Pranjal>

?      [Lizhong] yes, "can" should be "MUST" here, thanks.

<Pranjal>   Looks good to me  </Pranjal>

?     [Lizhong] the HSMP_UP/HSMP_DN state should be withdrawed/released by
> only their corresponding withdraw/release message. Only the leaf
> node will send both withdraw for HSMP_DN and release for HSMP_UP to
> its upstream node, refer to RFC6388 section 3.3.2. BTW, the
> reference section 4.3.2 should be 3.3.2, will fix this in next version.

<Pranjal> OK, looks good to me. </Pranjal>

?     [Lizhong] when Z receives a release of HSMP_DN from U, it maybe
> because of lack of label resouce or other reasons, Z will send label
> release to downstream until to leaf node. When the leaf node
> receives a release of HSMP_DN from its upstream, and it already
> received label mapping of HSMP_UP from U before, leaf node should
> send label release of HSMP_UP to its upstream node. The procedure
> above reflect the disjointness betwen HSMP_DN and HSMP_UP.

<Pranjal> OK if you consider HSMP_UP and HSMP_DN are completely disjoint. </Pranjal>

?      [Lizhong] right, OAM is missing in current draft. Currently the OAM
> tool definition is not in the scope. Maybe another draft effort is necessary.

<Pranjal>

My personal opinion is that on OAM matters it is good to address the OAM solutions in same draft that generated the requirement.
This is in order to avoid fragmentation. I have observed similar case with LDP-MT as well. I don't think a vendor can sell or an operator
can deploy a solution that introduces new LDP tunnel(s) but without any OAM. OAM is very integral part of the solution. Another approach
that we discussed sometimes back is - to introduce a "generalized" LDP Target FEC stack to embed a LDP FEC element itself and thus
completely getting rid of defining new types every time new FEC elements are introduced.

</Pranjal>


I have couple of additional comments that I missed to send earlier. This is primarily with respect to IEEE-1588v2. I don't think the use case
justifies for HSMP and, HSMP as solution to IEEE-1588v2 is a bit flawed.  To be technically very precise, my rationale is as follows:


 1.  Asymmetric Routing Case - Most of the mLdp use cases I have seen so far has asymmetric routing deployed. HSMP would be able to
satisfy the requirements of IEEE-1588 only if by routing it is ensured that topology is not asymmetric between upstream and downstream.
mLdp as a protocol should be agnostic of how routing topology is designed. In fact I would contest the highlighted statement from RFC 6388 to
which the HSMP draft has been repeated references on next-hop resolution. It severely binds mLdp tunnel set-up to routing topology.
Instead the ldp adjacency interface + ldp address database matching with local interface sub-net provides the least common denominator
for mLdp next-hop resolution and works in any routing topology.

2.4.1.2<http://tools.ietf.org/html/rfc6388#section-2.4.1.2>.  Determining the Forwarding Interface to an LSR





   Suppose LSR U receives an MP Label Mapping message from a downstream

   LSR D, specifying label L.  Suppose further that U is connected to D

   over several LDP enabled interfaces or RSVP-TE Tunnel interfaces.  If

   U needs to transmit to D a data packet whose top label is L, U is

   free to transmit the packet on any of those interfaces.  The

   algorithm it uses to choose a particular interface and next-hop for a

   particular such packet is a local matter.  For completeness, the

   following procedure MAY be used.  LSR U may do a lookup in the

   unicast routing table to find the best interface and next-hop to

   reach LSR D. If the next-hop and interface are also advertised by LSR

   D via the LDP session, it can be used to transmit the packet to LSR

   D.

Keeping aside the LAN case, for mLdp the least common denominator is the next-hops associated with the interfaces.
It doesn't require reference to unicast routing since then asymmetric routing does not work. Also mLdp upstream
redundancy (MoFRR) may not work in asymmetric routing case -   if upstream does next-hop resolution is done based
on unicast routing table.

The HSMP draft makes multiple references to the above section 2.4.1.2 in RFC 6388 but I think there is a need to explicitly
mention something like "all rules of 2.4.1.2 except so and so".


 1.  There is an existing WG item http://tools.ietf.org/html/draft-ietf-mpls-targeted-mldp-00 (ahead of HSMP) that enabled
mLdp set-up between indirect next-hops, for example using RSVP-TE "intermediate tunnels". It doesn't ensure that reverse
IP/MPLS node path be same although mLdp overlay can be same and thus IEEE-1588 breaks here.

Section 7 brushes over Co-Routed Path Exceptions without getting into details, but I would consider those exceptions are key
points that restricts HSMP significantly.



  "The LSR/LER in HSMP LSP could detect if the

   path is co-routed or not, if not co-routed, an indication could be

   generated to the management system."

Section 3.2 talks about reducing operational cost significantly by providing both downstream and upstream paths for existing
P2MP mLdp LSPs and thus I would visualize that HSMP would replace mLdp tunnels wherever required (e,g VPMS or IPTV).
But while an operator upgrades the solutions from existing P2MP/MP2MP to HSMP then it also comes with additional caveats
that it may requires an operator to change the existing routing topology to ensure symmetric routing and get rid of
 http://tools.ietf.org/html/draft-ietf-mpls-targeted-mldp-00. I am not sure whether such undertaking may be desirable in a true
multi-service network.

Thus either HSMP gets rid of use case of IEEE-1588 or restricts itself severely in terms of VPMS or IPTV.

Thus I can't support the IEEE-1588 as the use case of this draft if HSMP can support IEEE-1588 only in very restricted
Scenerios (symmetric routing and no targeted mLdp). If we remove IEEE-1588 use case from the draft then we can talk about
the rest of use cases that justify introduction of a new protocol machinery into mLdp.


Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:[e-mail]]
Sent: Sunday, September 16, 2012 8:56 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Dutta, Pranjal K (Pranjal)
Subject: RE: [mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a mpls wg document


Sorry, forget to cc to the mpls list.

Lizhong


-------------------------------
> Hi Pranjal,
> Thank you for the review, please see the clarification inline below.
> Hope it helps.
>
> Lizhong
>
>
> "Dutta, Pranjal K (Pranjal)" <[e-mail]>
> wrote 2012/09/13 04:30:20:
>
> > 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.  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, 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.  Node Z determines
> >    the downstream HSMP LSR as per 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.
> [Lizhong] the forwarding state of HSMP_UP and HSMP_DN are disjoint.
> Their forwarding state programming are triggered by LDP message
> which is same as MP2MP LSP. Your understanding is right, it is the
> say way of MP2P. We will switch the last paragraph of section 4.3.1.
> 2 to the beginning of this section. Thanks.
>
> >
> > 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."
> [Lizhong] yes, "can" should be "MUST" here, thanks.
>
> >
> >
> > On following 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, 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.
> [Lizhong] the HSMP_UP/HSMP_DN state should be withdrawed/released by
> only their corresponding withdraw/release message. Only the leaf
> node will send both withdraw for HSMP_DN and release for HSMP_UP to
> its upstream node, refer to RFC6388 section 3.3.2. BTW, the
> reference section 4.3.2 should be 3.3.2, will fix this in next version.
>
> >
> >
> > 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.
> [Lizhong] when Z receives a release of HSMP_DN from U, it maybe
> because of lack of label resouce or other reasons, Z will send label
> release to downstream until to leaf node. When the leaf node
> receives a release of HSMP_DN from its upstream, and it already
> received label mapping of HSMP_UP from U before, leaf node should
> send label release of HSMP_UP to its upstream node. The procedure
> above reflect the disjointness betwen HSMP_DN and HSMP_UP.
>
> >
> >
> > 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.
> [Lizhong] right, OAM is missing in current draft. Currently the OAM
> tool definition is not in the scope. Maybe another draft effort is necessary.
>
> >
> > Thanks,
> > Pranjal
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Loa Andersson
> > Sent: Monday, September 03, 2012 11:16 PM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: [mpls] poll on making draft-jjwl-mpls-mldp-hsmp-01.txt a
> > mpls wg document
> >
> > 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 ([e-mail]).
> >
> > This poll is extended and will end Sep 19th, 2012.
> >
> > /Loa
> > (mpls wg co-chair)
> > --
> >
> >
> > Loa Andersson                         email: [e-mail]
> > Sr Strategy and Standards Manager            [e-mail]
> > Ericsson Inc                          phone: [phone]
> >                                               [phone]
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls