headers
Mach Chen | 1 Jun 2010 08:24
Favicon

Re: draft-chen-mpls-return-path-specified-lsp-ping

Hi Vishwas,

Thanks for your kindly reminder, I will check and correct it in the next 
revision.

Best regards,
Mach

--------------------------------------------------
From: "Vishwas Manral" <vishwas.ietf <at> gmail.com>
Sent: Monday, May 31, 2010 2:28 PM
To: <mpls <at> ietf.org>
Subject: [mpls] draft-chen-mpls-return-path-specified-lsp-ping

> Hi Mach,
>
> I noticed that we have used the address 0:0:0:0:0:FFFF:127/104. It is
> a wrong format and has been corrected in other drafts.
>
> Please use 0:0:0:0:0:FFFF:127.0.0.0/104 instead.
>
> Thanks,
> Vishwas
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls 

_______________________________________________
mpls mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
liu.guoman | 1 Jun 2010 08:37
Picon

Re: Last Call: draft-ietf-mpls-tp-data-plane (MPLS Transport Profile Data Plane Architecture) to Proposed Standard


hi,all editors
About section 3.2 , there is the following paragraph:
"   If the section is an LSP, this information MAY be implied by
  the LSP label or, if the LSP payload is MPLS-labeled, by the setting
  of the S bit.  Additional labels MAY also be used if necessary to
  distinguish different payload types"
IMO, if the client traffic of section layer is MPLS-labeled, the S bit of
section label must be set 1.
if my understanding is true, maybe violate MPLS-TP framework?
in my memory,only S bit of the lowest label should be set 1 in MPLS Label stack,
there can be only one S-bit set in a label stack.

maybe i  misunderstand the sentence? I hope it can clarify this paragragh clearly.

best regards
liu






The IESG <iesg-secretary <at> ietf.org>
发件人:  mpls-bounces <at> ietf.org

2010-06-01 06:27

请答复 给
ietf <at> ietf.org
收件人
 IETF-Announce <ietf-announce <at> ietf.org>
抄送
 mpls <at> ietf.org, mpls-tp <at> ietf.org
主题
 [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS Transport        Profile Data Plane Architecture) to Proposed Standard





The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:

- 'MPLS Transport Profile Data Plane Architecture '
  <draft-ietf-mpls-tp-data-plane-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2010-06-14. Exceptionally,
comments may be sent to iesg <at> ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-data-plane-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19671&rfc_flag=0

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



-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 11 comments |
headers
Loa Andersson | 1 Jun 2010 09:21
Picon

joint ccamp and mpls working group last call on draft-ietf-mpls-explicit-resource-control-bundle+07


All,

in mid-February the draft-ietf-mpls-explicit-resource-control-bundle
was retruned to the MPLS Working Group from the responsible AD
stating that:

- it had been a long time since the working group last call
- the version that were working group last called was much earlier
   than the one we requested publication for, i.e. the document has
   changed many times since the wg last call
- this document is also of interest for the CCAMP working group, and
   the working group last call should have been jointly between MPLS
   and CCAMP
- there is a need to poll both working group to see if there is
   an interest in this draft.

However it also needs to pointed out that there are at least two deployed
implementations and we need to amke the reservation of the code points
in the IANA section.

This is to start a joint CCAMP and MPLS working group last call on
draft-ietf-mpls-explicit-resource-control-bundle-07.

Please send your comments to the mpls and ccamp working group list.

The joint working group last call ends eob June 16.

/Loa
--

-- 

Loa Andersson                         email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager            loa <at> pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Shaleen Saxena (ssaxena | 1 Jun 2010 14:20
Picon
Favicon

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

Hi Shiv, Nitin,

I will updated the P2MP OAM draft to reflect the PHP scenario. 

So does PHP always happen before bud node? Consider the following
topology:

  H - M1 - B - M2 - T

Here:
 H: Head
 M1, M2: Two mid-point nodes
 B: Bud
 T: Tail

So will both M1 and M2 send out unlabelled packets? Will the TTL of the
packet cause any different behavior from M1 and M2?

Also, your suggestion applies to only packets with T bit turned on,
correct? If it is for all ping/trace packets, then I foresee some
issues, where certain nodes will never respond.

Thanks,
Shaleen

> -----Original Message-----
> From: Shivakumar Channalli [mailto:shivakumar <at> juniper.net]
> Sent: Saturday, May 29, 2010 11:13 AM
> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
> (ssaxena)
> Cc: mpls <at> ietf.org
> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> 
> 
> |> 1. precluding bud node support
> Another way is to try to solve bud node issue in case of PHP
> 
> |> 2. bud node receiving duplicate traffic (label and unlabeled)
> |> Cheers.
> Receiving unlabelled packet in case of PHP can be solved by following
a
> simple rule.
> 
> "In p2mp LSP case, if a node (other than pure egress) receives a +MPLS
> LSP trace 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 make an assumption that, the
> packet received by control plane is not due to TTL expiry, and drop
the
> packets.
> 
> 
> ...$hiv
> 
> 
> 
> |-----Original Message-----
> |From: Santiago Alvarez (saalvare) [mailto:saalvare <at> cisco.com]
> |Sent: Saturday, May 29, 2010 6:03 AM
> |To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar Channalli
> |Cc: mpls <at> ietf.org; Santiago Alvarez (saalvare)
> |Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> |
> |It seems to me that, in order to find PHP acceptable for P2MP LSPs,
> one
> |the these two need to be acceptable:
> |1. precluding bud node support
> |2. bud node receiving duplicate traffic (label and unlabeled)
> |Cheers.
> |
> |SA
> |--
> |> -----Original Message-----
> |> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On
Behalf
> |Of
> |> Nitin Bahadur
> |> Sent: Friday, May 28, 2010 4:52 PM
> |> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
> |> Cc: mpls <at> ietf.org
> |> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> |>
> |>
> |> Shaleen,
> |>
> |> > I was referring to
> |> > http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-
> |> > mapping-04
> |>
> |> This draft does not say that PHP *must not* be used ever for RSVP
> |P2MP.
> |> This draft specifies a requirement for non-PHP behavior and solves
> |that
> |> problem.
> |>
> |> > . Do you have an application where you use PHP? Is P2MP TE
> |> > with PHP going to be deployed in service provider networks?
> |>
> |> Yes...we have customers (in deployment) using P2MP with PHP.
> |>
> |> nitin
> |> _______________________________________________
> |> mpls mailing list
> |> mpls <at> ietf.org
> |> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 1 comment |
headers
John E Drake | 1 Jun 2010 14:44
Favicon

Re: Last Call: draft-ietf-mpls-tp-data-plane (MPLS Transport Profile Data Plane Architecture) to Proposed Standard

There is only one s bit per label stack.

> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> liu.guoman <at> zte.com.cn
> Sent: Monday, May 31, 2010 11:37 PM
> To: mpls-tp <at> ietf.org
> Cc: mpls <at> ietf.org; mpls-bounces <at> ietf.org; IETF-Announce; mpls-tp <at> ietf.org
> Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS
> Transport Profile Data Plane Architecture) to Proposed Standard
> 
> 
> hi,all editors
> About section 3.2 , there is the following paragraph:
> "   If the section is an LSP, this information MAY be implied by
>   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
>   of the S bit.  Additional labels MAY also be used if necessary to
>   distinguish different payload types"
> IMO, if the client traffic of section layer is MPLS-labeled, the S bit of
> section label must be set 1.
> if my understanding is true, maybe violate MPLS-TP framework?
> in my memory,only S bit of the lowest label should be set 1 in MPLS Label
> stack,
> there can be only one S-bit set in a label stack.
> 
> maybe i  misunderstand the sentence? I hope it can clarify this paragragh
> clearly.
> 
> best regards
> liu
> 
> 
> 
> 
> 
> 
> 
> 
> The IESG <iesg-secretary <at> ietf.org>
> 发件人:  mpls-bounces <at> ietf.org
> 
> 2010-06-01 06:27
> 请答复 给
> ietf <at> ietf.org
> 
> 收件人
> IETF-Announce <ietf-announce <at> ietf.org>
> 抄送
> mpls <at> ietf.org, mpls-tp <at> ietf.org
> 主题
> [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS Transport
> Profile Data Plane Architecture) to Proposed Standard
> 
> 
> 
> 
> 
> 
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> 
> - 'MPLS Transport Profile Data Plane Architecture '
>   <draft-ietf-mpls-tp-data-plane-03.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf <at> ietf.org mailing lists by 2010-06-14. Exceptionally,
> comments may be sent to iesg <at> ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-data-plane-03.txt

> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19

> 671&rfc_flag=0
> 
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

> 
> 
> 
> 
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is
> solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this communication to
> others.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the originator of
> the message. Any views expressed in this message are those of the
> individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 10 comments |
headers
Shivakumar Channalli | 1 Jun 2010 14:53
Favicon

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

Hi shaleen,

I have one more suggestion

Section:
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."

The above statement hold goods only in case of traceroute mode of LSP
ping.

if we want to do a normal p2mp ping (just consider pinging a single p2mp
egress), and apply the above rule we'll end up in a wrong scenario.

consider:

         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

The ping request sent from A will reach all the egress (including bud
nodes)
So as per the section 3.2.1 all the bud nodes are on the path to egress
and everybody will respond.

so i guess 3.2.1 section can be improved by mentioning that the rule is
applicable in case of traceroute mode of ping only and for normal ping
scenario a node must reply only if it the actual egress.

finding if a ping packets is for trace or not can be decided
1) examining if any down map tlvs are there.
2) may be add one more flag saying ++traceroute mode++ of LSP ping is
being done.

option 2 seems a cleaner way of handling this. As we may also need some
way of knowing , if the packet is for trace mode/ ping mode for some
other cases also.

in any case section 3.2.1 needs this updation.

...$hiv

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 2 comments |
headers
Shivakumar Channalli | 1 Jun 2010 14:47
Favicon

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

|I will updated the P2MP OAM draft to reflect the PHP scenario.
|
|So does PHP always happen before bud node? Consider the following
|topology:
|
|  H - M1 - B - M2 - T
|
|Here:
| H: Head
| M1, M2: Two mid-point nodes
| B: Bud
| T: Tail

PHP will happen before tail (T i.e pure egress) also.
In the example T is pure egress, so packet should be processed by T, but
in case of B (bud node) it should be dropped.

That's why it should be clearly specified as 

"In p2mp LSP case, if a node (other than ++pure egress++) receives a
+MPLS
LSP trace packet+, without any label, then it should drop the packet
without processing"

In other words, "if a bud node receives a unlabelled packets , then it
should be dropped"

|
|So will both M1 and M2 send out unlabelled packets? Will the TTL of the
|packet cause any different behavior from M1 and M2?

I guess, there should not be any problems as such.

|Also, your suggestion applies to only packets with T bit turned on,
|correct? If it is for all ping/trace packets, then I foresee some
|issues, where certain nodes will never respond.

That's correct. The packets should be dropped only if T bit is set.
Other wise in ping mode of operation, we may not get reply at all if we
apply this rule to all packets.

...$hiv

|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:ssaxena <at> cisco.com]
|Sent: Tuesday, June 01, 2010 5:51 PM
|To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
|Cc: mpls <at> ietf.org; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|
|Hi Shiv, Nitin,
|
|I will updated the P2MP OAM draft to reflect the PHP scenario.
|
|So does PHP always happen before bud node? Consider the following
|topology:
|
|  H - M1 - B - M2 - T
|
|Here:
| H: Head
| M1, M2: Two mid-point nodes
| B: Bud
| T: Tail
|
|So will both M1 and M2 send out unlabelled packets? Will the TTL of the
|packet cause any different behavior from M1 and M2?
|
|Also, your suggestion applies to only packets with T bit turned on,
|correct? If it is for all ping/trace packets, then I foresee some
|issues, where certain nodes will never respond.
|
|Thanks,
|Shaleen
|
|
|> -----Original Message-----
|> From: Shivakumar Channalli [mailto:shivakumar <at> juniper.net]
|> Sent: Saturday, May 29, 2010 11:13 AM
|> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
|> (ssaxena)
|> Cc: mpls <at> ietf.org
|> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|>
|>
|> |> 1. precluding bud node support
|> Another way is to try to solve bud node issue in case of PHP
|>
|> |> 2. bud node receiving duplicate traffic (label and unlabeled)
|> |> Cheers.
|> Receiving unlabelled packet in case of PHP can be solved by following
|a
|> simple rule.
|>
|> "In p2mp LSP case, if a node (other than pure egress) receives a
+MPLS
|> LSP trace 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 make an assumption that, the
|> packet received by control plane is not due to TTL expiry, and drop
|the
|> packets.
|>
|>
|> ...$hiv
|>
|>
|>
|> |-----Original Message-----
|> |From: Santiago Alvarez (saalvare) [mailto:saalvare <at> cisco.com]
|> |Sent: Saturday, May 29, 2010 6:03 AM
|> |To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar Channalli
|> |Cc: mpls <at> ietf.org; Santiago Alvarez (saalvare)
|> |Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|> |
|> |It seems to me that, in order to find PHP acceptable for P2MP LSPs,
|> one
|> |the these two need to be acceptable:
|> |1. precluding bud node support
|> |2. bud node receiving duplicate traffic (label and unlabeled)
|> |Cheers.
|> |
|> |SA
|> |--
|> |> -----Original Message-----
|> |> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On
|Behalf
|> |Of
|> |> Nitin Bahadur
|> |> Sent: Friday, May 28, 2010 4:52 PM
|> |> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
|> |> Cc: mpls <at> ietf.org
|> |> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS
Map
|> |>
|> |>
|> |> Shaleen,
|> |>
|> |> > I was referring to
|> |> > http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-
|> |> > mapping-04
|> |>
|> |> This draft does not say that PHP *must not* be used ever for RSVP
|> |P2MP.
|> |> This draft specifies a requirement for non-PHP behavior and solves
|> |that
|> |> problem.
|> |>
|> |> > . Do you have an application where you use PHP? Is P2MP TE
|> |> > with PHP going to be deployed in service provider networks?
|> |>
|> |> Yes...we have customers (in deployment) using P2MP with PHP.
|> |>
|> |> nitin
|> |> _______________________________________________
|> |> mpls mailing list
|> |> mpls <at> ietf.org
|> |> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
The IESG | 1 Jun 2010 15:49
Picon
Favicon

Document Action: 'Security Framework for MPLS and GMPLS Networks'

to Informational RFC

The IESG has approved the following document:

- 'Security Framework for MPLS and GMPLS Networks '
   <draft-ietf-mpls-mpls-and-gmpls-security-framework-09.txt> as an
Informational RFC

This document is the product of the Multiprotocol Label Switching Working
Group. 

The IESG contact persons is Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mpls-and-gmpls-security-framework-09.txt

Technical Summary

  This document provides a security framework for Multiprotocol Label
  Switching (MPLS) and Generalized Multiprotocol Label Switching
  (GMPLS) Networks. This document addresses the security aspects
  that are relevant in the context of MPLS and GMPLS. It describes
  the security threats, the related defensive techniques, and the
  mechanisms for detection and reporting. This document emphasizes
  RSVP-TE and LDP security considerations, as well as Inter-AS and
  Inter-provider security considerations for building and maintaining
  MPLS and GMPLS networks across different domains or different
  Service Providers.

Working Group Summary

  Nothing worth noting in the WG process. Good consensus.

Document Quality

  This is an informational framework.
  The Document is now widely referenced by other documents.
  The document has been well reviewed in the MPLS and CCAMP WGs.
  It has also received a substantial (earlyish) SecDir review and
  been updated
  The document was gen-Art reviewed.

Personnel

  Martin Vigoureux is the Document Shepherd
  Tim Polk is the responsible Area Director

RFC Editor Note

   RFC Editor: please note that this Informational document went
   through IETF Last Call and so has IETF consensus. Please add the 
   appropriate boilerplate.

   RFC Editor: please check with the sponsoring AD to ensure that
   a final copyright issue is resolved in AUTH48.

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Shaleen Saxena (ssaxena | 1 Jun 2010 15:59
Picon
Favicon

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

Hi,

Can you do ping with Node Address P2MP Responder Identifier instead of
Egress Address P2MP Responder Identifier? Then no other node would
respond.

Thanks,
Shaleen

> -----Original Message-----
> From: Shivakumar Channalli [mailto:shivakumar <at> juniper.net]
> Sent: Tuesday, June 01, 2010 8:53 AM
> To: Shaleen Saxena (ssaxena); Santiago Alvarez (saalvare); Nitin
> Bahadur
> Cc: mpls <at> ietf.org
> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
> 
> Hi shaleen,
> 
> I have one more suggestion
> 
> Section:
> 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."
> 
> The above statement hold goods only in case of traceroute mode of LSP
> ping.
> 
> if we want to do a normal p2mp ping (just consider pinging a single
> p2mp
> egress), and apply the above rule we'll end up in a wrong scenario.
> 
> consider:
> 
> 
>          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
> 
> The ping request sent from A will reach all the egress (including bud
> nodes)
> So as per the section 3.2.1 all the bud nodes are on the path to
egress
> and everybody will respond.
> 
> so i guess 3.2.1 section can be improved by mentioning that the rule
is
> applicable in case of traceroute mode of ping only and for normal ping
> scenario a node must reply only if it the actual egress.
> 
> finding if a ping packets is for trace or not can be decided
> 1) examining if any down map tlvs are there.
> 2) may be add one more flag saying ++traceroute mode++ of LSP ping is
> being done.
> 
> option 2 seems a cleaner way of handling this. As we may also need
some
> way of knowing , if the packet is for trace mode/ ping mode for some
> other cases also.
> 
> in any case section 3.2.1 needs this updation.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ...$hiv
> 
> 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 1 comment |
headers
Eric Gray | 1 Jun 2010 17:45
Picon
Favicon

Re: LDP Discovery

Somasundaram,

One area of discussion that is not allowed on this mailing list is discussion
of why a particular vendor does or does not do something in the way that
the standard(s) define(s).

Please address that part of this question to appropriate product support.

As for the rest of the question, it is not always possible to address issues
with misconfiguration in protocol specification and - unless a particular
misconfiguration is likely to produce drastic pathological behavior in a
network - it is usually not worth the trouble to try to identify all of the
(probably very many) ways that devices may be misconfigured.  In my
experience, this is particularly true when the major effect of such an
error in configuration is to embarras the vendor(s) that allowed it in
the first place.

--
Eric
________________________________
From: mpls-bounces <at> ietf.org [mpls-bounces <at> ietf.org] On Behalf Of Sundar Selveraj [contactsundar <at> gmail.com]
Sent: Thursday, May 27, 2010 8:45 AM
To: mpls <at> ietf.org
Subject: [mpls] LDP Discovery

     I have a question on LDP Basic Discovery Process.
Hi All,

        Am looking out for some clarification on LDP Discovery process.

        LDP Hellos are sent to All routers Multicast Address (224.0.0.2).So any LDP capable router on recieveing
this packet reaches Full neighborship.

          I had a strange (infact a misconfiguration) setup, wherein I had address configured incorrectly. For
example, address on a different subnet over the directly connected
interfaces.(1.1.1.1/24<http://1.1.1.1/24> <----> 1.1.2.1/24<http://1.1.2.1/24>)

        I could still see the adjacency coming up. In other words, we are not doing a source-address check.I went
through some juniper documentation on LDP and understood that they have a knob (CLI) to enable/disable source-address.

        I am just curious to understand why was the source-address check not mentioned in the RFC.

        Is it fine that the neighborship gets established inspite of having a misconfiguration? If the answer to
the question is yes, can you share your thoughts on why Juniper could have included the source-address check?

Regards
Somasundaram
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 1 comment |

Gmane