Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map

["Shaleen Saxena (ssaxena)" <[e-mail]>]

Hi Nitin:

I was referring to
http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-04
. Do you have an application where you use PHP? Is P2MP TE with PHP
going to be deployed in service provider networks?

Regards,
Shaleen

> -----Original Message-----
> From: Nitin Bahadur [mailto:[e-mail]]
> Sent: Friday, May 28, 2010 1:08 PM
> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
> Cc: [e-mail]
> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> 
> Shaleen,
> 
> Can u point me to the relevant section in some RFC that specifics that
> PHP
> should not be used with RSVP P2MP-TE.
> 
> Thanks
> Nitin
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Shaleen Saxena (ssaxena)
> > Sent: Friday, May 28, 2010 6:18 AM
> > To: Shivakumar Channalli
> > Cc: [e-mail]
> > Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> >
> > Hi Shivakumar:
> >
> > In P2MP trees, for both P2MP TE and Multicast LDP, PHP is not
> > used. The packet should always have the label.
> >
> > Regards,
> > Shaleen
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of
> > > Shivakumar Channalli
> > > Sent: Friday, May 28, 2010 2:11 AM
> > > To: George Swallow (swallow); [e-mail]
> > > Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS
Map
> > >
> > >
> > > Hi all,
> > >
> > > I have some doubts regarding "section 3.4. Respond Only If
> > TTL Expired
> > > Flag"
> > > In draft-ietf-mpls-p2mp-lsp-ping-10.txt
> > >
> > > The section mentions that
> > > "If the T flag is set to 1, then the receiver SHOULD reply
> > only if the
> > > TTL of the incoming MPLS label is equal to 1; if the TTL is
> > more than
> > > 1, then no response should be sent back."
> > >
> > > But it doesn't specifies anything about a case where in the
> > packet is
> > > received without any label (NULL label)
> > >
> > > Example:
> > > Just think, all the penultimate hops in a p2mp LSP are
> > doing PHP, And
> > > we are using "Egress Address P2MP Responder Identifier"  to
> > trace p2mp
> > > LSP egress "F"
> > >
> > > As per 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs:
> > > "A node that receives an echo request with this Sub-TLV
> > present MUST
> > > respond only if the node lies on the path to the address in the
> > > Sub-TLV."
> > >
> > >
> > >
> > >           ttl-1        ttl-2       ttl-3      ttl-4      ttl-5
> > >          Bud node    Bud node    Bud node    Bud node Pure-egress
> > > A-----------B-----------C-----------D-----------E----------F
> > > |-----------| lsp1
> > > |-----------------------| lsp2
> > > |-----------------------------------| lsp3
> > > |-----------------------------------------------| lsp4
> > > |----------------------------------------------------------| lsp5
> > >
> > >
> > > From the figure above, we can see that all the bud nodes are on
the
> > > path to the egress node F. So with each TTL increment, we start
> > > getting multiple responses from all the bud nodes.
> > >
> > > To understand the problem, just think we are currently tracing
with
> > TTL
> > > 5.
> > > And in the ping request contains down map that of F.
> > >
> > > When we send out this trace message, each of the bud nodes will
> > receive
> > > a copy of the trace packet, as it's a p2mp LSP. But the packets
> > > received by the bud nodes ++don't contain any label as PHP is in
> > > use++.
> > >
> > > As a result when a bud node does processing of the packet,
> > interface
> > > and label validations will fail, and they will send out
> > send out error
> > > responses.
> > >
> > > So basically "section 3.4" doesn't really help in such cases
> > >
> > > [Suggestions]
> > > "In p2mp LSP case, if a node (other than pure egress)
> > receives a LSP
> > > ping packet, without any label, then we should drop the
> > packet without
> > > processing"
> > >
> > > Reason: In trace route mode we want packets to reach
> > control plane due
> > > to TTL expiry, but in PHP p2mp mode packets are also
> > received by bud
> > > nodes due the PHP. As a result we can conclude that the packet
> > received
> > > by control plane is not due to TTL expiry, and drop the packets.
> > >
> > >
> > >
> > > ...$hiv
> > >
> > >
> > > ________________________________________
> > > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of
> > > George Swallow
> > > Sent: Friday, May 28, 2010 4:13 AM
> > > To: [e-mail]
> > > Subject: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> > >
> > > This begins a two week last call on the follow two drafts.
> > > Mechanism for performing LSP-Ping over MPLS tunnels
> > > draft-ietf-mpls-lsp-ping-enhanced-dsmap-05
> > >
> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-
> enhanced-
> > > ds
> > > map-05.txt
> > >
> > > and
> > > Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
> > > Label Switching (MPLS)
> > > - Extensions to LSP Ping
> > > draft-ietf-mpls-p2mp-lsp-ping-10.txt
> > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-
> > > 10.txt
> > >
> > >
> > > The last call ends June 10, 2010 24:00 UTC
> > >
> > > George & Loa
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >