Re: GMPLS: RFC 3473 RSVP Notify Request Query

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

I-D Action:draft-ietf-ccamp-rwa-wson-encode-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-wson-encode-07.txt
	Pages           : 34
	Date            : 2010-12-01

A wavelength switched optical network (WSON) requires that certain 
key information elements are made available to facilitate path 
computation and the establishment of label switching paths (LSPs). 
The information model described in "Routing and Wavelength Assignment 
Information for Wavelength Switched Optical Networks" shows what 
information is required at specific points in the WSON. Part of the 
WSON information model contains aspects that may be of general 
applicability to other technologies, while other parts are fairly 
specific to WSONs.  

This document provides efficient, protocol-agnostic encodings for the 
WSON specific information elements. It is intended that protocol-
specific documents will reference this memo to describe how 
information is carried for specific uses. Such encodings can be used 
to extend GMPLS signaling and routing protocols. In addition these 
encodings could be used by other mechanisms to convey this same 
information to a path computation element (PCE).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

Re: GMPLS: RFC 3473 RSVP Notify Request Query

Hi Preeti,

You say:

> per our requirement , from the LSP ingress node we intend to signal 
> both the upstream and downstream notify receipt address to the LSP
> intermediate/egress node. 

Perhaps we need to spend some time exposing this requirement?
Why does the ingress need to tell a transit node which are the downstream notify
recipients?

You say in an earlier email that you want to be able to send both the upstream
and downstream notify recipients in the Path message, but you don't say why, or
how this is useful.

> As per the flow specified below, (suppose we have tunnel from Node A to Node
C).
> Node A (Tunnel ingress) sends two notify object in the RSVP path message to
node B .
> One Notify request object specifying the upstream notify receipent address and
the
> another specify downstream notify address.
>
> The address values being sent in notify request is as per rfc 4802 MIB objects
> (gmplsTunnelUpstreamNotifyRecipient, gmplsTunnelSendPathNotifyRecipient). 
 
But please read 4802 more carefully!
The first object...
    "Indicates the address of the upstream recipient for Notify
     messages relating to this tunnel and issued by this LSR.  This
     information is typically received from an upstream LSR in a Path
     message.

The second object...
    "Indicates to a downstream LSR the address to which it should
     send upstream Notify messages relating to this tunnel.

Only the second object is signaled by this LSR.

Cheers,
Adrian

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

FW: I-D Action:draft-shiomoto-ccamp-switch-programming-04.txt

FYI

This revision contains a few editorial clean-ups resulting from review by the
document shepherd.

Cheers,
Adrian

> -----Original Message-----
> From: i-d-announce-bounces <at> ietf.org [mailto:i-d-announce-bounces <at> ietf.org]
> On Behalf Of Internet-Drafts <at> ietf.org
> Sent: 05 December 2010 19:15
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-shiomoto-ccamp-switch-programming-04.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 	Title           : Advice on When It is Safe to Start Sending Data on
Label
> Switched Paths Established Using RSVP-TE
> 	Author(s)       : K. Shiomoto, A. Farrel
> 	Filename        : draft-shiomoto-ccamp-switch-programming-04.txt
> 	Pages           : 11
> 	Date            : 2010-12-05
> 
> The Resource Reservation Protocol (RSVP) has been extended to support
> Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and
> Generalized MPLS (GMPLS) networks. The protocol enables signaling
> exchanges to establish Label Switched Paths (LSPs) that traverse
> nodes and links to provide end-to-end data paths. Each node is
> programmed with "cross-connect" information as the signaling messages
> are processed. The cross-connection information instructs the node
> how to forward data that it receives.
> 
> End points of an LSP need to know when it is safe to start sending
> data so that it is not misdelivered, and so that safety issues
> specific to optical data plane technology are satisfied. Likewise,
> all label switching routers along the path of the LSP need to know
> when to programme their data planes relative to sending and receiving
> control plane messages.
> 
> This document clarifies and summarises the RSVP-TE protocol exchanges
> with relation to the programming of cross-connects along an LSP for
> both unidirectional and bidirectional LSPs. This document does not
> define any new procedures or protocol extensions, and defers
> completely to the documents that provide normative references. The
> clarifications set out in this document may also be used to help
> interpret LSP establishment performance figures for MPLS-TE and GMPLS
> devices.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-switch-
> programming-04.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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

Re: A question about RFC5392

Hi,

Since, in the current specification, an ASBR is responsible for advertising 
both directions of an inter-AS TE link and the parameters of the reverse 
direction are manually configured at the ASBR; as stated in the RFC, Remote 
AS number and ASBR ID are essential for inter-AS path computation and are 
rarely changed when configured. But for other alterable paramerters as you 
pointed out, they may be changed as time goes on (e.g., a TE LSP established 
over the link, unused bandwidth should be changed accordingly), and the ASBR 
may be difficult/impossible to get the lastest value of those permerters 
timely.

The vague sentence intends to give choice to the implementation and 
operators whehter to advertise the other TE link paramerters, and of cause 
the current specification does preclude advertising other paramerters when 
needed.

Hope this could clarify your question.

Best regards,
Mach

--------------------------------------------------
From: <wang.xuerong <at> zte.com.cn>
Sent: Tuesday, December 07, 2010 3:40 PM
To: <mach <at> huawei.com>; <zhangrenhai <at> huawei.com>; 
<duanxiaodong <at> chinamobile.com>
Cc: <ccamp <at> ietf.org>
Subject: A question about RFC5392

> Hi Mach, Renhai and Xiaodong
>
> I read the following words in RFC5392: "Only some essential TE information
> for the link needs to be
> advertised; i.e., the Link Type, the Remote AS number, and the Remote ASBR
> ID."
>
> I don't know why only Link Type, Remote AS number, and Remote ASBR ID are
> described in the above sentence?
> Since other parameters are also necessary for CSPF computation, such as
> Metrics, bandwith,etc.
> So, what's the consideration when you're writting this document? Could you
> tell me the reason?
>
> Many thanks!
>
> Best Regards,
> Xuerong Wang
>
>
>
> --------------------------------------------------------
> 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.
> 
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

A question about RFC5392

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

Fw: I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-09.txt

Hi all,

We just updated the g.694-lambda draft only with several editorial changes. If you compare with the
previous version (08), you can find out the changes.

Thanks,

Dan

----- Original Message ----- 
From: <Internet-Drafts <at> ietf.org>
To: <i-d-announce <at> ietf.org>
Cc: <ccamp <at> ietf.org>
Sent: Thursday, December 09, 2010 3:00 PM
Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-09.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
> 
> 
> Title           : Generalized Labels for Lambda-Switching Capable Label Switching Routers
> Author(s)       : T. Otani, et al.
> Filename        : draft-ietf-ccamp-gmpls-g-694-lambda-labels-09.txt
> Pages           : 14
> Date            : 2010-12-08
> 
> Technology in the optical domain is constantly evolving and as a 
> consequence new equipment providing lambda switching capability has 
> been developed and is currently being deployed. [RFC3471] has 
> defined that a wavelength label (section 3.2.1.1) "only has 
> significance between two neighbors" and global wavelength semantics 
> is not considered. In order to facilitate interoperability in a 
> network composed of next generation lambda switch-capable equipment, 
> this document defines a standard lambda label format, which is 
> compliant with both [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid).  
> This document is a companion to the Generalized Multi-Protocol Label 
> Switching (GMPLS) signaling. It defines the label format when Lambda 
> Switching is requested in an all optical network.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-09.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

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

Content-Type: text/plain
Content-ID: <2010-12-08225310.I-D <at> ietf.org>

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

Please publish: draft-ietf-ccamp-gmpls-g-694-lambda-labels-09.txt

Adrian,
	Here is the PROTO write up for 
draft-ietf-ccamp-gmpls-g-694-lambda-labels-09.txt.

Lou (and Deborah)
==========================================================================
PROTO-write-up for:	draft-ietf-ccamp-gmpls-g-694-lambda-labels
Intended status: 	Proposed Standard

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

Lou Berger is the Document Shepherd.
He has reviewed the document and believes it is ready for forwarding to
the IESG for publication.

   (1.b) Has the document had adequate review both from key WG members
         and from key non-WG members? Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

Yes.  The document has been extensively reviewed and the Shepherd
believes all issues have been addressed.

   (1.c) Does the Document Shepherd have concerns that the document
         needs more review from a particular or broader perspective,
         e.g., security, operational complexity, someone familiar with
         AAA, internationalization or XML?

No concerns or additional review needed.

   (1.d) Does the Document Shepherd have any specific concerns or
         issues with this document that the Responsible Area Director
         and/or the IESG should be aware of? For example, perhaps he
         or she is uncomfortable with certain parts of the document, or
         has concerns whether there really is a need for it. In any
         event, if the WG has discussed those issues and has indicated
         that it still wishes to advance the document, detail those
         concerns here. Has an IPR disclosure related to this document
         been filed? If so, please include a reference to the
         disclosure and summarize the WG discussion and conclusion on
         this issue.

No concerns or issues.  No IPR found in the datatracker.

   (1.e) How solid is the WG consensus behind this document? Does it
         represent the strong concurrence of a few individuals, with
         others being silent, or does the WG as a whole understand and
         agree with it?

There is strong consensus behind this document.

   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
         discontent? If so, please summarise the areas of conflict in
         separate email messages to the Responsible Area Director. (It
         should be in a separate email because this questionnaire is
         entered into the ID Tracker.)

No.

   (1.g) Has the Document Shepherd personally verified that the
         document satisfies all ID nits? (See the Internet-Drafts Checklist
         and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
         not enough; this check needs to be thorough. Has the document
         met all formal review criteria it needs to, such as the MIB
         Doctor, media type and URI type reviews?

Yes.  There is one instance of a line too long, this can be fixed as
part of the publication process.  No other reviews are required.

   (1.h) Has the document split its references into normative and
         informative? Are there normative references to documents that
         are not ready for advancement or are otherwise in an unclear
         state? If such normative references exist, what is the
         strategy for their completion? Are there normative references
         that are downward references, as described in [RFC3967]? If
         so, list these downward references to support the Area
         Director in the Last Call procedure for them [RFC3967].

Split looks good.

   (1.i) Has the Document Shepherd verified that the document IANA
         consideration section exists and is consistent with the body
         of the document? If the document specifies protocol
         extensions, are reservations requested in appropriate IANA
         registries? Are the IANA registries clearly identified? If
         the document creates a new registry, does it define the
         proposed initial contents of the registry and an allocation
         procedure for future registrations? Does it suggest a
         reasonable name for the new registry? See [RFC5226]. If the
         document describes an Expert Review process has Shepherd
         conferred with the Responsible Area Director so that the IESG
         can appoint the needed Expert during the IESG Evaluation?

No IANA implications.

   (1.j) Has the Document Shepherd verified that sections of the
         document that are written in a formal language, such as XML
         code, BNF rules, MIB definitions, etc., validate correctly in
         an automated checker?

Yes, no automated checks needed.

   (1.k) The IESG approval announcement includes a Document
         Announcement Write-Up. Please provide such a Document
         Announcement Write-Up? Recent examples can be found in the
         "Action" announcements for approved documents. The approval
         announcement contains the following sections:

      Technical Summary
         Relevant content can frequently be found in the abstract
         and/or introduction of the document. If not, this may be
         an indication that there are deficiencies in the abstract
         or introduction.

This document is a companion to the Generalized Multi-Protocol Label
Switching (GMPLS) signaling.  [RFC3471] defined that a wavelength label
(section 3.2.1.1) "only has significance between two neighbors" and
global wavelength semantics is not considered. In order to facilitate
interoperability in a network composed of lambda switch-capable
equipment, this document defines a standard lambda label format, which
is compliant with both [G.694.1](DWDM-grid) and [G.694.2](CWDM-grid).

      Working Group Summary
         Was there anything in WG process that is worth noting? For
         example, was there controversy about particular points or
         were there decisions where the consensus was particularly
         rough?

This document received much attention and discussion in its early
revisions.  The document has been largely stable for quite some time,
mainly needing revisions as part of the publication process.

      Document Quality
         Are there existing implementations of the protocol? Have a
         significant number of vendors indicated their plan to
         implement the specification? Are there any reviewers that
         merit special mention as having done a thorough review,
         e.g., one that resulted in important changes or a
         conclusion that the document had no substantive issues? If
         there was a MIB Doctor, Media Type or other expert review,
         what was its course (briefly)? In the case of a Media Type
         review, on what date was the request posted?

There have been no public statements related to intent to implement, but
the portions of the extensions are now being used as part of the GMPLS
tool set and are expected to implemented (at least) in those contexts.
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

AD review of draft-ietf-ccamp-gmpls-g-694-lambda-labels-09

Hi,

I have performed an AD review of your draft.

Don't panic!

I review all drafts that I am responsible for before putting them
forward for IETF last call. The main objective is to catch nits and
minor issues that would show up during the last call or in IESG
review. The intention is to help polish your document and make sure
it is clean and shiny so that other reviewers will stick to the
technical details.

I think your small draft is actually a very significant contribution to
the GMPLS family.

Most of my comments are pretty trivial, but a couple have more meat
on them and I'd like to see a quick respin of the document before I
issue the IETF last call. As soon as I see a new revision posted,
I'll set the ball in motion.

Of course, all of my issues are up for discussion.

Thanks for the work,
Adrian

---

idnits throws up a number of minor issues...

> ** There is 1 instance of too long lines in the document, the longest
>    one being 1 character in excess of 72.

This seems to be line 46

> == The 'Updates: ' line in the draft header should list only the
>    _numbers_ of the RFCs which will be updated by this document (if
>    approved); it should not include the word 'RFC' in the list.

This is in the document header...

s/Updates: RFC3471/Updates: 3471 (if approved)/

> == The document seems to lack a disclaimer for pre-RFC5378 work, but
>    was first submitted before 10 November 2008.  Should you add the 
>    disclaimer? (See the Legal Provisions document at
>    http://trustee.ietf.org/license-info for more information.) 
>    -- however, there's a paragraph with a matching beginning. 
>    Boilerplate error?

Just need to check with you that the authors are happy to not include
the boilerplate and are assigning the copyright. Usually not a problem,     
but if you have trouble tracking down the authors, just add the 
disclaimer boilerplate - it is quite safe!

> == Unused Reference: 'RFC3209' is defined on line 433, but no 
>    explicit reference was found in the text

You can just remove the reference.

---

The Abstract needs to be self-contained, so cannot include citations of
RFCs or other documents.

You also need to spell out acronyms.

Can I suggest:

OLD
   Technology in the optical domain is constantly evolving and as a 
   consequence new equipment providing lambda switching capability has 
   been developed and is currently being deployed. [RFC3471] has 
   defined that a wavelength label (section 3.2.1.1) "only has 
   significance between two neighbors" and global wavelength semantics 
   is not considered. In order to facilitate interoperability in a 
   network composed of next generation lambda switch-capable equipment, 
   this document defines a standard lambda label format, which is 
   compliant with both [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid).  
   This document is a companion to the Generalized Multi-Protocol Label 
   Switching (GMPLS) signaling. It defines the label format when Lambda 
   Switching is requested in an all optical network. 
NEW                       
   Technology in the optical domain is constantly evolving and as a 
   consequence new equipment providing lambda switching capability has 
   been developed and is currently being deployed. 

   Generalized MPLS (GMPLS) is a family of protocols that can be used 
   to operate networks built from a range of technologies including
   wavelength (or lambda) switching. For this purpose, GMPLS defined
   that a wavelength label only has significance between two neighbors 
   and global wavelength semantics are not considered.

   In order to facilitate interoperability in a network composed of next
   generation lambda switch-capable equipment, this document defines a
   standard lambda label format that is compliant with Dense Wavelength
   Division Multiplexing and Coarse Wavelength Division Multiplexing 
   grids defined by the International Telecommunication Union
   Telecommunication Standardization Sector. The label format defined in
   this document can be used in GMPLS signaling and routing protocols.
END

---

You are not required to include a Table of Contents in a document of less
than fifteen pages (but you are allowed to).

---

Section 1

You need to expand DWDM and CWDM on first use.
You can then remove the expansions from Section 2.

---

Section 2

Could you capitalise the section header to match the others.

---

Section 2

s/vendor's/vendors'/
s/consists of number/consists of a number/

---

Section 2

s/a LSP/an LSP/

---

Section 2 (last line)

Expand "LSR" on first use.

---                                                                

Section 3.3

   We do not need to define a new type as the information stored is 
   either a port label or a wavelength label. Only the wavelength label 
   as above needs to be defined. 

This is very true, but I think the text does not belong here.
I would try to work it into Section 3.1

---

Section 4

   This document introduces no new security considerations to [RFC3473]. 
   For a general discussion on MPLS and GMPLS related security issues, 
   see the MPLS/GMPLS security framework [RFC5920]. 

I think you should 
s/[RFC3473]/[RFC3471] and [RFC3473]/
because this I-D updates 3471.

---

Section 5

Why did you decide that there is no requirement for IANA to track the
codepoints (Grid and C.S.) used in the DWDM and CWDM Wavelength Labels? 

It looks like you could have three registries {Grid, DWDM C.S., and 
CWDM C.S.)

---

Section 8

OLD
8. Author's Address
NEW
8. Authors' Addresses
END

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

Question on Extended Association I-D

Hi,

Can you tell me, how many associations do you think you actually need?
Certainly 2**48 should be enough.
And, you are making the claim that 2**16 is too few (although I wonder how many
deployments have used more than 2**8 associations).

I'm wondering whether 2**20 or 2**24 might be enough.

If it was, then there is no need to extend the Association object because there
are plenty of Association type values available. 

Cheers,
Adrian

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