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

["Santiago Alvarez (saalvare)" <[e-mail]>]

In addition, non-PHP is required to avoid packet replication by a
penultimate hop when it precedes a bud node. 
Cheers.

SA
--

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Shaleen Saxena (ssaxena)
> Sent: Friday, May 28, 2010 11:39 AM
> To: Nitin Bahadur; Shivakumar Channalli
> Cc: [e-mail]
> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> 
> 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
> > >
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls