Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts

From: Loa Andersson <[email-masked]>
Date: Wed, 30 May 2012 04:59:31 +0200

Working Group,

This is to start a two week working group last call on two drafts:

- draft-ietf-mpls-gach-adv-02; and
- draft-ietf-mpls-tp-ethernet-addressing-01

Please send comments to the mpls working group list.

The working group last call ends June 15, 2012.

Thanks, Loa

(as MPLS WG co-chair)

-- 

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

---

From: Lingaraj Mishra <[email-masked]>
Date: Wed, 30 May 2012 00:43:32 -0700 (PDT)

Hello,
 
This is to authors of draft:draft-ietf-mpls-gach-adv-02.
 
The draft generalizes other protocol needs to be advertised in MPLS-TP network.
I have read the document and have two suggestions:
 
1 - The introduction section talks about GACH being used as 'Auxillary Data Channel' which is never being defined in RFC5586. It says GACH will be predominantly used for OAMP.
 
The following is with respect to ADB block:
 
2 - Here we are specifying that multiple protocols will use GAP for their necessary purpose. So, instead of defining "Application ID", we should use "Protocol ID" which will define specific protocol identifiers. 
 
Regards,
Lingaraj

________________________________
 From: Loa Andersson <[email-masked]>
To: "[email-masked]" <[email-masked]>; MPLS-TP ad hoc team <[email-masked]> 
Sent: Wednesday, May 30, 2012 8:29:31 AM
Subject: [mpls] wg last call  on gach-adv and ethernet-addressing drafts
  
Working Group,

Thanks, Loa

(as MPLS WG co-chair)

-- 

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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 30 May 2012 08:50:30 -0400

Dear Editors, Authors, et al.
I've a comment regarding Timestamp format (Section 3). I'd propose to use TLV for the Timestamp so that not only NTP but IEEE-1588v2 as well as any future formats can be used. The Timestamp might be of G-ACh Advertisement Protocol TLV format, i.e. included in ADB Element with Application ID 0x0000 (perhaps Lifetime of GAP's ADB can be set to all 1's and interpreted as Never Expires).

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, May 29, 2012 8:00 PM
To: [email-masked]; MPLS-TP ad hoc team
Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts

Working Group,

Thanks, Loa

(as MPLS WG co-chair)

-- 

                                              +46 767 72 92 13 _______________________________________________

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 30 May 2012 18:26:01 +0300

Hi Authors and List -

Some comments concerning both documents
1. Regarding the local source address format - that you state that it SHALL
follow the format in RFC6428.  I would like to point out that those formats
are all for IP based addresses, and assuming (as you do in the Ethernet
Addressing document) that you may be running in an environment without IP
addressing, I think some reference should be made to the global addresses
not based on IP addresses.

2. The semantics of the Lifetime field should be specified beyond "the
number of seconds" - is there a value (as Greg has suggested) for "never
expires" (either 0 or all 1's??). This would be very relevant for the
Ethernet Addressing application, on the assumption that the MAC address
does not change that often!

3. You suggest in section 5.1 that messages will be repeated (3 times?) but
in section 2 you state that the action taken for repeated information is
undefined at the GAP level, but should be defined at the application level.
 This also raises the question of whether overiding the information is a
reasonable action (since there is repetition to verify that it was properly
received.  I then looked in the Ethernet Addressing document to see if this
application defines the usage, for redundant or change information, and
couldn't find it.

Thanx,
yaacov weingarten

On Wed, May 30, 2012 at 3:50 PM, Gregory Mirsky <[email-masked]
> wrote:

> I've a comment regarding Timestamp format (Section 3). I'd propose to use
> TLV for the Timestamp so that not only NTP but IEEE-1588v2 as well as any
> future formats can be used. The Timestamp might be of G-ACh Advertisement
> Protocol TLV format, i.e. included in ADB Element with Application ID
> 0x0000 (perhaps Lifetime of GAP's ADB can be set to all 1's and interpreted
> as Never Expires).
>
>        Regards,
>                Greg
>
>
>                                              +46 767 72 92 13_______________________________________________
> mpls mailing list
> [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 30 May 2012 17:03:21 +0100

> number of seconds" - is there a value (as Greg has suggested) for 
> "never expires" (either 0 or all 1's??). This would be very relevant 
> for the Ethernet Addressing application, on the assumption that the 
> MAC address does not change that often!
I think that for NTP at least 0 and Max are both actual times so we 
would need a new bit.

As to Ethernet Addresses, they do change when you change a line card, 
and there is history (ARP) of IETF protocols asking for confirmation 
that the value is unchanged.

Stewart

---

From: Dan Frost <[email-masked]>
Date: Wed, 30 May 2012 18:10:18 +0100

On Wed, May 30, 2012 at 12:43:32AM -0700, Lingaraj Mishra wrote:
> 1 - The introduction section talks about GACH being used as 'Auxillary
> Data Channel' which is never being defined in RFC5586. It says GACH
> will be predominantly used for OAMP.

The description of the G-ACh in this draft matches the one in RFC 5960,
for instance.

> 2 - Here we are specifying that multiple protocols will use GAP for
> their necessary purpose. So, instead of defining "Application ID", we
> should use "Protocol ID" which will define specific protocol
> identifiers. 

It began as "Protocol ID" originally.  It was changed because GAP
applications are not necessarily protocols.

Thanks,
-d

---

From: Dan Frost <[email-masked]>
Date: Wed, 30 May 2012 18:22:23 +0100

Hi Yaacov,

On Wed, May 30, 2012 at 06:26:01PM +0300, Yaacov Weingarten wrote:
> 1. Regarding the local source address format - that you state that it
> SHALL follow the format in RFC6428.  I would like to point out that
> those formats are all for IP based addresses, and assuming (as you do
> in the Ethernet Addressing document) that you may be running in an
> environment without IP addressing, I think some reference should be
> made to the global addresses not based on IP addresses.

Thanks, we'll revisit this.

> MAC address does not change that often!

Describing the lifetime of a piece of data as infinite is a bad idea, I
think.  Better to refresh it periodically.

> 3. You suggest in section 5.1 that messages will be repeated (3
> times?) but in section 2 you state that the action taken for repeated
> information is undefined at the GAP level, but should be defined at
> the application level.  This also raises the question of whether
> overiding the information is a reasonable action (since there is
> repetition to verify that it was properly received.  I then looked in
> the Ethernet Addressing document to see if this application defines
> the usage, for redundant or change information, and couldn't find it.

The idea of the repeat transmission in Section 5.1 is that the messages
are sent with the same Message Identifier, so the receiver can identify
them as duplicates.  We'll clarify this in the text.

How the receiver handles receiving a TLV of a Type it already has is
another matter; this is specified in Section 5.2 (which is consistent
with Section 2).

Cheers,
-d