Subject: Re: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document

From: Zhang Haiyan <[email-masked]>
Date: Fri, 02 Jul 2010 09:53:54 +0800

No/ do not support.

Several comments need clarification: 

1) We do not see how the content of the draft satisfies "on-demand-cv" as claimed in the title. We only see "LSP-Ping" and "LSP Traceroute" in the main part of the draft. 
In the introduction part we also see the "on-demand Connectivity Verification, Route Tracing and Adjacency functions". 
Could the authors clarify the "on-demand CV"? 

2) Could the authors clarify the purpose of describing "LSP-Ping with IP encapsulation" and "LSP Traceroute with IP encapsulation"?

The draft seems to be just a regular extension of MPLS LSP ping, not particular for MPLS-TP. Shouldn't it be a draft with the name "mpls-lsp-ping-extensions"?

B.R.
Haiyan

----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc team" <[email-masked]>
Sent: Monday, June 21, 2010 8:07 PM
Subject: [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document

> 
> Working Group,
> 
> this email is to start poll to adopt
> draft-nitinb-mpls-tp-on-demand-cv-00.txt
> as an MPLS working group draft.
> 
> After recent experience, the chairs would like to remind you all
> what it means to conduct a poll to adopt a draft as a working group
> draft.
> 
> - Please recall that the IETF does not "vote." Polls of a working
>   group are to gather information to help the chairs make their
>   decisions. Voting is not part of the normal working methods of
>   an IETF working group.
> 
> - The "rough consensus" process used in the working group assumes
>   that people expressing opinions are also participating in the
>   development of standards documents.
> 
> - Subscription to the list specifically to express an opinion is
>   noticed by the chairs who has access to information on the new list
>   members. Such behavior is not part of the normal working methods.
> 
> - The purpose of a poll for adoption is to help the chairs understand
>   the level of support for a document (i.e. who has read it, who
>   believes it is a good starting point for working group work, who
>   will contribute to the work) and whether there are any significant
>   technical issues. Statements of objection must be backed up by
>   proper technical reasons.
> 
> So please respond to this poll indicating whether you support the 
> adoption of this draft or stating your technical issues.
> 
> Please also not that this draft has after a discussion with the
> working group chairs been renamed, it was earlier know as
> draft-nitinb-mpls-tp-lsp-ping-extensions-01.
> 
> This poll ends eob July 5.
> 
> 
> Loa and George
> mpls wg co-chairs
> 
> -- 
> 
> 
> 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
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Mon, 5 Jul 2010 12:25:42 +0200

The current draft does not clearly articulate how the solution mechanism is satisfying the requirements and behaviors associated with on-demand CV (e.g., support of per-interface MIP model).  It is important that this be documented.

Italo 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: lunedì 21 giugno 2010 14.08
> To: [email-masked]; [email-masked]; MPLS-TP ad hoc team
> Subject: [mpls] poll to adopt 
> draft-nitinb-mpls-tp-on-demand-cv as a working group document
> 
> 
> Working Group,
> 
> After recent experience, the chairs would like to remind you 
> all what it means to conduct a poll to adopt a draft as a 
> working group draft.
> 
> So please respond to this poll indicating whether you support 
> the adoption of this draft or stating your technical issues.
> 
> Please also not that this draft has after a discussion with 
> the working group chairs been renamed, it was earlier know as 
>                                               +46 767 72 92 
> 13 _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 05 Jul 2010 13:55:35 +0200

No/do not support

The change of the name of this draft gives the impression
that the content of the draft changed as well.
So before it can be adopted the text has to be aligned
with the title: On-demand CV for MPLS-TP.

I see that it is still focused on extending LSP-Ping but
not for use in a transport environment.
It does not indicate where the transport OAM requirements
are met.
It does not indicate how the ACh is used.
What is the meaning of "adjacency" in the context of MPLS-TP?
It does not document how this tool can be used in transport
environment where tools are enabled/disabled static (compared
to the dynamic set-up of LSP-ping.

Regards, Huub.

==============

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Loa Andersson <[email-masked]>
Date: Tue, 06 Jul 2010 17:44:54 +0200

Working Group,

this poll has ended.

We have a new working group draft, could the authors
please republish as:

draft-ietf-mpls-tp-on-demand-cv-00.txt

this version of the document should be identical to the
document we polled with the exception on name and date
changes.

There has also been good comments that the authors should
take care to respond to and address in the -01 version of the
document.

/Loa

--

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 6 Jul 2010 18:29:02 +0200

Huub,

Please see inline.

Best regards,

Nurit

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Huub van Helvoort

Sent: Monday, July 05, 2010 2:56 PM

To: Loa Andersson

Cc: [email-masked]; MPLS-TP ad hoc team; [email-masked]

Subject: Re: [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv
as a working group document

No/do not support

<Nurit> please be more specific. For me it looks that you just missed
the statement in the document saying "In such scenarios, LSP-Ping SHOULD
be run without IP addressing, using the ACH channel type specified in
(I-D.ietf-mpls-tp-lsp-ping-bfd-procedures]. Maybe you should look at
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-lsp-ping-bfd-procedur
es/ \<Nurit>

are met.

<Nurit> the assumption it is unless you prove otherwise \<Nurit>

<Nurit> see above. You probably missed in your review the reference to
ietf-mpls-tp-lsp-ping-bfd-procedures \<Nurit>

<Nurit> your comment is not clear \<Nurit>

Regards, Huub.

==============

On 21-06-10 14:07, Loa Andersson wrote:

-- 

mpls-tp mailing list

[email-masked]

---

From: Lavanya Srivatsa <[email-masked]>
Date: Mon, 5 Jul 2010 18:22:57 +0530

Yes / Support.

However, I have some comments/queries that I would request be updated in the next version (if the authors
agree with my comments, of course!).

(1)  In Section 2.2, it states "When sending LSP-Ping packets using ACH, without IP encapsulation,
   there MAY be a need to identify the source address of the packet.
   This source address will be specified via the Source Address TLV,
   being defined in [I-D.ietf-mpls-tp-ach-tlv]"
[LS] The ACH TLV draft has Source Address only in
the IP format and not in the non-IP format as per mpls-tp-identifiers draft.

(2) Section 2.3 states - "Only one identifier (MEP or MIP) MUST be present in a packet."
[LS] Would there not be a scenario that a Source MEP and a Destination MIP might need
to be carried in the packet for connectivity verification to intermediate/transit nodes?
I agree that source MEP/source MIP and destination MEP/destination MIP are invalid combinations
but Source MEP/Destination MIP seems a "possible" combination?

(3) Section 3.3 states that the Egress Node may add the Target FEC Stack TLV in its echo responses.
[LS] How will the egress node know when to do so? Is it expected/mandated that the echo request
should have an newly defined bit set in the Global Flags field to indicate that the response should
contain a Target FEC stack? If so, then I think that this draft needs to explain this modification on
the base rfc 4379.
On the same lines, would it also be recommended that the echo response contains the V bit
set in the Global Flags to indicate that the ingress must validate the reverse FEC?

- Lavanya

---------- Forwarded message ----------
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jun 21, 2010 at 5:37 PM
Subject: [mpls] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, MPLS-TP ad hoc team <[email-masked]<mailto:[email-masked]>>

Working Group,

So please respond to this poll indicating whether you support the adoption of this draft or stating your technical issues.

Loa and George
mpls wg co-chairs

--

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
                                            +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 8 Jul 2010 12:39:53 -0700

Hi Hubb,

> It does not indicate where the transport OAM requirements

The authors will clarify that in the next revision. As you and others have
pointed out, the text is more centered today around the solution (lsp-ping),
rather than the how the requirement is met.

> It does not indicate how the ACh is used.

Section 3.2 alludes to it. I will update that section to have a pointer to
the first normative reference.

> What is the meaning of "adjacency" in the context of MPLS-TP?

Adjacency came from -01 version of mpls-tp-oam-requirements draft. Currently
there is no adjacency requirement, so we'll get rid of the term of this
draft as well.

> to the dynamic set-up of LSP-ping.

LSP-Ping is indeed dynamic in the request/response sense. However, the LSP
by itself can be setup statically or using RSVP-TE. If it is setup
statically, then section 2.4 applies. Can you clarify your comment.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 8 Jul 2010 12:17:39 -0700

Hi Haiyan,

On 7/1/10 6:53 PM, "Zhang Haiyan" <[email-masked]> wrote:

> 1) We do not see how the content of the draft satisfies "on-demand-cv" as
> claimed in the title. We only see "LSP-Ping" and "LSP Traceroute" in the main
> part of the draft.

> Could the authors clarify the "on-demand CV"?

I agree that the text needs a little working to make it clear how on-demand
CV, Route tracing and Adjaceny are achieved. The current text is based
around the solution (lsp-ping), rather than the requirement (cv,
route-tracing). The authors will fix this in the next revision.
 
> 2) Could the authors clarify the purpose of describing "LSP-Ping with IP
> encapsulation" and "LSP Traceroute with IP encapsulation"?

Thanks for asking. As per Section 2.1.4 of RFC 5860

" It MUST be possible to deploy the OAM functionality in any of these
   environments.  As a result, it MUST be possible to operate OAM
   functions with or without relying on IP capabilities, and it MUST be
   possible to choose to make use of IP capabilities when these are
   present."

To ensure that the above requirement was met, we added the sections on
LSP-ping with IP encap.

> The draft seems to be just a regular extension of MPLS LSP ping, not
> particular for MPLS-TP. Shouldn't it be a draft with the name
> "mpls-lsp-ping-extensions"?

Godo question. It is true that the extensions apply equally well to regular
MPLS LSPs. As per the MPLS-TP Joint Working Team guidelines, all drafts that
address mpls-tp requirement/solutions should have a mpls-tp name (for
simplicity for IETF WG chairs and their ITU counter-parts).
 
Hope that helps.
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 8 Jul 2010 12:48:49 -0700

Hi Lavanya,

> the IP format and not in the non-IP format as per mpls-tp-identifiers draft.

New address types for src-addr tlv is not in the purview of this draft.
 
> but Source MEP/Destination MIP seems a "possible" combination?

I'm not sure. I am willing to change this if others on the wg mailing list
think so as well.

> explain this modification on

This section needs some work. Next revision :-)

> set in the Global Flags to indicate that the ingress must validate the reverse

Yes, I will add some text to indicate that V flag can be set in the reverse
direction as well.
 
> To: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> [email-masked]<mailto:[email-masked]>, MPLS-TP ad hoc team
> <[email-masked]<mailto:[email-masked]>>
> 
> 
> 
> Working Group,
> 
> So please respond to this poll indicating whether you support the adoption of
> this draft or stating your technical issues.
> 
> Loa Andersson                         email:
> [email-masked]<mailto:[email-masked]>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 19 Jul 2010 15:03:19 +0200

Hello Nitin,

> statically, then section 2.4 applies. Can you clarify your comment.

Section 2.4 describes how to identify a static LSP.

My question concerns the activation/enabling/instantiation of
the tool.
In transport networks when tools are enabled the appropriate
parameters are set (e.g. periodicity, MEL, thresholds, etc.)
and it is expected that no negotiation between the end-points
takes place after this provisioning. If one of the end-points
gets an unexpected result this is reported to the NMS.
This enabling is considered to be static.
I cannot find any description of this expected behaviour in
transport netwroks in the draft.

Regards, Huub.